Welcome to our ninth blog post, Saving! Given our recent completion and integration of saving, we'd like to take a moment to explain how it effects the game.

The basis of our saving system is to do one very important thing- prevent cheating, while still being very versatile. And that’s a fairly difficult but interesting task to pull off given our fairly limited number of options we have at our disposal.

To start, there are some critical elements we need to store on every save.

The most direct of these include player's Army (top left image), their active Map Progression (top right image), and their Resources (bottom image). These variables could be considered our ‘liquid' variables. That's because Warriors can be slain in a moment's notice, we need to keep track of our Fog progression and slain enemies, alongside any various Resources or Key Items player manages to obtain. They can change very quickly, and we need to always ensure a finite state.

Then comes the much more ‘solid’ variables- active Map, list of our Maps, Research, Home Base, and misc elements like Time progression. After Map Generation, we need to ensure its stored properly and easily accessible for read/write if its the current Map. Research, alongside player’s Home Base, are largely static elements that will only update at very important moments in time. All of these also have some basis on Time, the in-game clock, and its need to retain a persistent state throughout each save/load/quit.

Given our large amount of variables, Autosaving persistence becomes difficult to control. We cannot have there be large pauses during gameplay for the game to save. In addition, given the large amount of variables of combat to save, saving combat as a whole becomes incredibly difficult. Thankfully, we can use some clever ingenuity to still achieve a saving system we desire, that’s fairly well-safeguarded against awful things like the game crashing, player’s computer losing power, and so forth.

Finally, the design we need, above all, must favor player convenience. As, with any RTS game, repetitive, dis-interesting content can happen fairly frequently and often, and its not something we want for our project. We want gameplay to be fairly fast paced and the central content.

The design we’ve decided to use is a single, adamant save. From there, only in specific locations in the World is player allowed to save. In addition, every time player transitions to a new map, the game is saved. This single save allows us to get around the paradigm of ‘multiple saves’ per playthrough, it keeps data loss during game crashes/power outages minimized, and it gives player quite a bit of versatility in their ability to save.

Defeat in not only this project, but RTS-type games in general, is fairly detrimental. It can sometimes mean a near-total restart. As such, we want to give players the option of being able to save conveniently (and allow for retrying difficult bosses in a simple manner), but not so frequently as to be able to cheat the game.

And, lastly, when all else fails- one can Accept one’s own Defeat, to reset things from how they are to a stable, basic standard, and ensure (from a developer’s perspective) against any unknown bugs or corruption.

That ends our segment on Saving, thank you for viewing our blog post! Please look forward to more coming very soon!

If you’re brand new, consider checking out our trailer and overall description of the game here: https://www.indiedb.com/games/moonrise