It takes time to load a video game. Whether it happens all at once in one big loading event that gets it all done up front or it is broken up into smaller pieces and loaded in smaller chunks (or even streamed in while the game is running), the game data needs to end up in memory somehow. On top of this, players don't all have the same preference of one solution compared to another. Our original strategy was to load the entire game world in one shot so the game would have no loading screens at any other point. Unfortunately some players didn’t like the idea of having to wait for 30-45 seconds right at the start, especially if they didn’t know in advance that they wouldn’t be exposed to any more loading delays until they closed the game. So… it was time to rewrite some code to allow the game to be loaded in smaller chunks. Unfortunately this changed one of the core assumptions about how the game was architected: not everything in the game was available. In our original paradigm where the entire game world was loaded, if we needed to move an NPC for a cutscene we would know with 100% certainty that they were out there somewhere, they could be located, and they could be moved. With the game data loading in chunks, there is a decent chance that what you are looking for might not have been loaded yet. The conversation with the computer now goes something like this: Cutscene Engine: “Go get that NPC and move them to this room for a cutscene.” Game World: “That NPC doesn’t exist. The part of the game they are in hasn’t been loaded yet.” Cutscene Engine: “Well go find them.” Game World: “I don’t know where to look. The part of the game they are in hasn’t been loaded yet.” It makes a good point, therefore we need a way to tell the game where things are supposed to be before they are loaded. And when an object gets loaded it also needs to ask if there is some save data that needs to be applied, because we can’t assume that it existed when all of that game data was being applied (as a matter of fact, it probably didn’t). And an object needs to save and track its own default state just in case it gets loaded one way but then has to get reset to a different state that isn’t explicitly marked in the save data. And… and there are just a lot of things that need to be considered. Especially in a game with save data as complicated as Reina & Jericho, because every time you find a new save point a new timeline is saved in whatever state it is in at that specific moment, so there are dozens of timelines recording dozens of potential world states. And that has been an interesting and fairly complicated problem. In the next updates we'll focus on something a bit less technical, and we’ll have some nice visual before and after comparisons soon, but for the past week or two the story has been the pains of loading data asynchronously in a game about asynchronous timelines.