We’ve been working on improving how we save the state of the game. We previously wrote about how we save the state of the player’s characters and caravan. In our latest update we’re now saving the state of the entire level, including trees chopped down, minerals extracted, berries harvested, elders rescued, and the state of any enemies in the level.

Levels

Each level/biome in our game consists of a primary level, as well as multiple sub-levels (we’ve broken up the biomes into many sub-levels for performance purposes). The primary level contains the landscape, audio, and non-interactable scenery, while each sub-level contains all of the things we now save, such as resources worked on and cheeky enemies.

When a saved game is loaded, the caravan and characters are placed at their last location, and then the primary level loads in relation to the caravan’s position in space. When the caravan loads, it also triggers the loading of any nearby sub-levels. This cascading load sequence reduces the complexity and effort of loading a game state.

Loading responsibilities for primary and sub-levels

Saving

Since a level’s enemies implement the same state saving interface as the player’s characters,there was little difficulty in saving them. The transform (location, rotation, and scale) and resource values for all logs produced from harvested trees are saved, allowing the logs to be spawned in place upon loading a game. Resources like mineable rocks and berry bushes have their remaining resource count and individual resource values saved as well. For tracking which trees have been harvested, we took the reverse approach; a unique identifier for each tree felled is recorded and when a sub-level is loaded, the game checks the list of felled tree ids and deletes any trees in the list. We use this same approach for rescued elders: since an elder’s bonuses are saved in the caravan state, any elders that have been rescued can be deleted.

An abundance of logs

Sadness

Unfortunately, we’ve encountered a tricky situation where sub-levels load their save state even when they player has not yet visited them yet: when the game is initially loaded we want all of the nearby sub-levels to have their state loaded; however, this means that when new, unaltered sub-levels are loaded in as the player progresses, those new levels will have their save state loaded as well. This loading is unnecessary for new levels as the player has yet to alter their state, and can cause a small hitch in game performance. Ideally we would only load the state of the levels present at the start of a gaming session. We’re currently unable to differentiate these two situations when loading a sub-level, but surely after enough coffees we will figure this out.