Invisible technical work

Over the last week or two I've been slowly pushing through some invisible, slightly tedious, but very important technical work on the game.

The crux of it is save games: I wanted to get players able to place items in the world, as building things is a major incentive for earning money. And pulling on that thread unravels a bunch of things that had to be figured out:

• How is the content of the world modified when an object is placed?
• Where can the player place objects?
• How do different objects save and restore their state across save/load?
• What gets saved and what doesn't get saved?

Ever since prototyping interiors ~2 weeks ago, all of this is also mixed together with dealing with indoors vs. outdoors too. For example, when saving items placed outdoors, how do we deal with layering the saved player objects on top of what is static in the level? Do we save the whole level?

Editor shot with prototype art. Visible here is both the crude 'player bed' which triggers saves - but also a refined 'door' system where doors can specify an 'entry' anchor for where players should actually be placed when they enter through the door.

Thankfully, I've think I've reached a good milestone on this now, and it's working enough I can focus back on game stuff:

• There is now a player 'bed' object which, much like Stardew, triggers save games to occur
• Regions are now saveable. There are currently three major regions:
  • The entirety of outdoors (which is the objects placed in the level editor). This isn't included in the save game, intentionally
  • The player 'plot' which is layered on top of the outdoor area. So anything the player builds outside ends up here. This is saved.
  • The player's house interior. This is also saved.

The result is that objects can now be placed both indoors and outdoors, and everything is saved correctly when interacting with the bed. The game is also automatically loading the most recent save.

Programmer rabbithole: "perfect" saves

As a programmer, the ideal imagined way to do save games is a 'perfect' system, where everything has a means to record state (or bonus points: recording state is an automatic property of just an object 'existing') and the entire game state is dumped out and loaded back in identically. No information is lost.

My favorite example of this kind of system done well is the FP state approach in Dreams  where the state that is saved is identical to the state that is actually used in game at runtime (!) to the extent they even used it to record replays for QA.

I could definitely work for a few weeks or months trying to do something complete like this - but beyond being technically fun to implement, I think for this game, doing it up-front right now would be a poor choice.

The reason I've chosen to emulate Stardew's 'bed' saves, is that I think this approach is actually very smart from a technical simplification point of view: By restricting where the player can save, it is impossible to save 'mid interaction' with an NPC, or in the middle of any other complex process. I don't really know the full scope of what I want in this game yet - and the prospect of literally anything I implement having to support complete and bug-free save/load capability is slightly daunting. Maybe I will add 'full' saves later on, but to begin with, these limited-scope saves are a great starting point. 

Random aside: level editors vs. save games
Another interesting rabbithole here is the distinction between the state the game produces, and what the level editor produces. Many games are also their own level editor (not the case here), so the line between what a 'save' is and a 'level' is can become blurred.

On the other end of the spectrum you also have games like shooters - where the level geometry etc. is often completely independent of the save, because the save game state typically contains very little data (e.g. player position, mission status etc.). One strange consequence of this approach is that often a new game will be created by loading a 'template' blank save game. Some games are designed in a way that this can be generated automatically/at runtime when the save game data is empty - but for others, there has to be an entire process for generating this 'clean' save.

Currently this game is on the 'shooter' end of the spectrum in that the level-editor generated world is a completely separate format to save games. The world is loaded, and subsequent saves are saves of only the player data. Maybe this will change? I'm not sure. I've certainly made mistakes here in the past: For example, I've made games where the level and save were the same format without thought for how to ignore 'default' player state (like health) when switching levels - which lead to a surprising amount of complexity and bugginess for no real reason.