1. Truthfully, this list is getting quite small. When I joined, collisions, meshing and the ECS were the biggest roadblocks. Now that those are solved the only big, core systems that spring to mind are the mod architecture and the job system/sparse updates. And well, let's just say I expect to see some joshwords on that soon. It's worth noting, however, that most of the time is not going to be spent on those tasks. It's going to be more like 60% gameplay, 25% iteration and polish, 15% other.

2. I think Josh has talked about this in the past, but it basically comes down to AI (well, everything in the game really) having a high frequency update loop for in-system updates, a low frequency up for planning and out-of-system updates, and a job system for handling sparse updates without having to iterate over a huge number of entities every frame. The planning AI is where decisions about what an AIs goals and projects are. The per-frame tick is just providing visuals so you can see the AI in action when you're close to it. The job system will provide the structure for us to do something like update all AIs once a minute, but stagger them so we don't update them all in the same frame. The frequency of the planning tick might be variable: e.g. we may update closer systems more often than further systems (in a topographical sense, as you'll be able to jump between systems). The details of that are in flux, as per the previous answer.

Though, naturally, the percentage of architectural rejiggering needs to trend toward 0. I understand you're not there yet, though.

You'd be surprised. The amount of progress we've made in the last few months has been incredible. We rarely touch the engine. There have been a few 30m tasks that pop up here and there, but the amount of work left there is minimal. I'd say the trend is continually leading toward drastically less architectural work. Even between the larger 'gameplay then infrastructure' sprints we've been doing that on a micro level. Gameplay is informing virtually every decision we make right now. The current non-gameplay tasks began as Josh and I sitting down and saying "let's implement this specific gameplay feature".

The frequency of the planning tick might be variable: e.g. we may update closer systems more often than further systems (in a topographical sense, as you'll be able to jump between systems).

I remember Josh speaking at length about how he was going to have something ala headless mode for AI in different systems. Being that they're so far away, the engine doesn't have to render them in the player's viewport (what the player sees through the UI).
I would reckon it would follow a similar vein of how IP Networking paths (e.g. Cisco routers) are chosen by different weights.
T1 lines would have a weight of 1 (because they're fast) whereas ISDN could be a 3, and PSTN (modems) would be a 5.
If we match this up to LT, the viewport and anything within 10km would be a 1, requiring a phased distance relationship between the player and the item being updated by the engine. Probably a wireframe update would kick in if the player initiated the Map and how it would show AI ships in your local system (Josh showed this working nicely when he released his youtube vids.
Further afield it would scale to a 4, which would include planets/ asteroids so far away from the player, he/ she wouldn't even know it existed yet.
Distant wormhole systems would be a 5, ala headless mode, and require only moderate updates, which scale quicker the closer the player is to a wormhole (or not, depending on whether the player has the wormhole engine installed or not ).

Adam, you're making my senses tingle knowing that since you joined, LT (and Josh) are in a better place, and that makes me happy.
As I could never hope to enunciate the way Flatfingers does in accurate wording, I can mirror his sentiment by saying Thank you for taking the time to write on the forums. It is greatly appreciated, and I look forward to hearing more about you in future.

Great news post, Adam! It's cool to hear how things are going from your end, and you have an interesting perspective on the work. Thanks for taking the time, keep it up, and don't let folks get you down!

I have a question regarding the super rad nodal interface that got put together a long while ago (shown here and here). Are there any plans to include graphical effects or UI widgets that function like the UI shown in those update videos?

I'm on board with this sentiment, although I'm not sure what we can do.

... we could for example know Josh by now and just accept that he will fall flat eventually on periodic updates, no offense, just saying how it is. Once that has been accomplished we could be grateful that Adam stepped in an provided and update on progress, instead of spitting bile at him, again, just saying how it is. Not directed at you, Grumblesaur, but I'm sure that would help quite some. Falling back into pouting mode won't make Josh feel more comfortable providing an update any time soon.

When there are no updates incoming, members are like 'just a short one-liner would be enough, is that so hard to do?'. And then, when there is an update it's like 'OMG, no pretties, and not from the mastermind himself, this is not an update, ffs gtfo grmbl!'

So one of the devs working on the game we care about so much decides to post an update and we decide to attack and insult him? Guys? What are we doing here? What exactly does taking out your frustration with Josh's communication issues on Adam accomplish?

Adam, your update is much appreciated by me and many other people who care about LT. It's good to know you're making progress, and the tidbits of game development are always fascinating to hear about. Certain individuals, no matter how loud or insistent, DO NOT speak for the community, regardless of what they may think. I am a part of the community, and I want to hear the devs of LT talk about their progress. And that includes both you and Josh.

I actually was a bit disappointed there weren't updates by you. So yeah. I'm pretty happy about this one.
And I'm actually surprised it isn't more common to keep simulation and rendering strictly separated.

The current non-gameplay tasks began as Josh and I sitting down and saying "let's implement this specific gameplay feature".

Adam,

Thank-you for an awesome update and even more awesome follow-up. Like many others have expressed, I just do not understand the tone and sesnse of entitlement displayed in the tiny minority of unpleasant messages directed towards you.

Gameplay is informing virtually every decision we make right now. The current non-gameplay tasks began as Josh and I sitting down and saying "let's implement this specific gameplay feature".

On that topic, what's a typical day's dev process like at the office?

I'd very much like to hear more on this. When do you guys get in? how many gallons cups of coffee do you guys drink each day? Do you guys have a formalized system for going from thought to code to testing to analysis to final implementation? Do you have cyclical tasks like "Every Friday we re-visit Dogfighting/Macro-AI/etc"?

But probably the most important question I can think of regarding development: Adam, are you looking to stay on the team after LT launches and be a founding employee of Procedural Reality, or are you looking to just help Josh get this to market and then move on with your own goals and pursuits?

Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can

Heh. Well, the office is a 10ft box. It's a small room attached to a shared working space. There's probably 6 total tenants in the space. It's actually really cozy. Josh's usual flair extends to his ability to decorate. Hours are 'kind of 9-to-5ish or whatever works for you but we should be here at the same time for the majority of the day'. Which, frankly, I think is the healthiest way to work. I'm typically here 9:30 - 6:00. Josh 10:30 until who knows when.

We've been trying different approaches and learning how we work since I joined, so our 'typical day' has continuously evolved. I get here, setup my laptop, read through my to do list, and decide where to start for the day. I keep Notepad++ open with a few tabs of information for myself. There's stuff like research notes (quaternions at the moment), fun tasks for weekends or relax days, and most importantly a fine grained, personal to do list. My memory is abysmal so this is how I manage to keep everything together. Then I just start plugging away. If I have questions, new ideas, or need a sanity check for something I'm doing I spin around and talk to Josh. Josh does the same and this is actually the most important part of our process I think. We communicate a lot. Often one of us see major simplifications the other didn't catch right away and it leads to more elegant code.

For new systems and major architectural decisions we talk through approaches at length. We tend to disagree fairly often and there's always some element of either enlightenment or compromise. This is another part of our process I find particularly productive. We have the same mindset about how to solve problems in general, which means we're able to work together in the first place, but we differ in the details. We're able to talk through the pros and cons of each option and make an objective decision. For larger problems we have a whiteboard nearby.

Once one of us finishes a task we commit and announce it, and almost always the other one will play with the new stuff and provide feedback. It's great for morale when someone immediately sees your work and comments on it. Many high fives ensue.

That leads to another extremely important part of the way we work together. We aren't afraid to clobber each other's code. A common theme for us is 1) talk through approaches, 2) one of us writes the initial implementation, 3) the other reads and rewrites it. It's always kind of hard to go back and refine code you just wrote (but you should still do it!) because you already have a specific solution mapped out in your head. A fresh set of eyes is far more likely to find issues and simplifications. Plus they have the benefit all the nuance that was learned in the initial implementation. You can't do that when you have team members that attach their ego to their code (my last studio was a nightmare and that was a large contributor).

Once we run out of tasks we have an impromptu 'planning meeting' where we adjust our direction and decide what the next goal and handful of tasks are. In terms of task management, we've gone through the ticket system in Assembla, plans written in Google Docs, a kanban board in the office, and probably some other stuff. At the end of the day it feels like those cost more time than they save when there's just 2 people who communicate well naturally. We still have milestones in Assembla with a timeline and the big tasks listed out, but that's not something we're staring at every day.

That's more or less our normal process. It's laid back. I tend to leave early if I finish a task late in the day or I'm just kinda burnt out that day. Josh takes days off when he needs to rest. Both are quite rare, but it makes a massive difference being able to just take a few extra hours or a day to recharge. I don't normally take breaks or eat lunch during the day, which I know they say is bad but it takes me a long time to 'get in the groove' and I don't like paying that cost. Fridays we stop working an hour or two early and play some games. On the weekends sometimes we try to come in and work on fun stuff (next time I want to try to get a debugger working in LUA).

I'd very much like to hear more on this. When do you guys get in? how many gallons cups of coffee do you guys drink each day? Do you guys have a formalized system for going from thought to code to testing to analysis to final implementation? Do you have cyclical tasks like "Every Friday we re-visit Dogfighting/Macro-AI/etc"?

I bring a 20oz coffee mug from home because the swill in the lounge here is unfit to be called coffee (and you know, sometimes I want a little something extra with my coffee).

Formal systems, not so much. We're not at a point where testing is time well spent, but that'll be something we have to figure out in the near future. Same with cyclical tasks. Once we get deeper into gameplay that will make more sense. Nice thing about the shared space is we can drag fresh eyes and even other game developers in for feedback (the entire building has maybe 30 offices and multiple game developers).

But probably the most important question I can think of regarding development: Adam, are you looking to stay on the team after LT launches and be a founding employee of Procedural Reality, or are you looking to just help Josh get this to market and then move on with your own goals and pursuits?

This is something we've talked about. Working with Josh has been the healthiest, most productive, and most enjoyable development I've done. I think it'd be unfair to call me a founder, but as a partner? Yea, it's definitely something that's on the table. However, that's far from decided. The plan right now is to ship LT and then evaluate what makes sense for both of us. Personally, I'm dying to get out of the south and I think Josh is undecided on that. We've also talked about how nice it would be to take a few years and fix a lot of the not-so-great toolchains programmers are stuck with. I've never been able to imagine programming anything other than games, but I have to admit that idea is becoming more and more appealing.