This is following from the thread on creating stories vs games in CS (thread) and a lot of comments about the need for a save system to make more ‘game-like’ CS games viable. I have lapsed into a state of insanity and spent my evening coding a demo for a save system.
This is something I already had in mind for my own games and I figured I may as well procrastinate from writing actual prose to build and share this instead.
What does the save system do?
- Autosaves the game. In the demo it does it before each choice, but it can also be used to make specific checkpoints (e.g. at the end of chapters) - you can make more than one autosave to checkpoint various parts of the game
- Players can manually make their own saves. Currently there are two save slots which are overwritable and you can load either save slot.
- Players can load the autosave or either save slot at any point
- Players can name their saves so they can find the right one to load
The save/load system demo - https://dashingdon.com/go/8162
How does it work? How easy is to use? Will it work for my game?
- The basic principle is that every important facet of the game is saved in a variable. For example, we might have ‘GoldAmount = 100’. The code then copies that value to a ‘save’ variable, for example ‘SaveGoldAmount_1 = 100’. For the second save slot, it copies it to ‘SaveGoldAmount_2’.
- To load, we simply reverse the process and set GoldAmount to the value of our save variable.
- There’s a bit of control flow here and there to make sure you’re recording the right thing at the right time and the correct saves/loads occur - but it’s nothing groundbreaking
I’d say it’s pretty straight forward to adapt to your own game once you have parsed through how it works. The hardest bit is ensuring the control flow is correct and that you’re saving where you’re supposed to, that the correct values are passed to the correct variables and so on.
This design should work for almost any game that I can think of (right now in my insane state).
The game saves all the required variables to define the ‘state’ of the game (obviously you will need to make sure you add all the necessary ones) and also the scene the player was on.
When they load the game, it will put them right back on that scene with all the variables set to as they were at that time - it will be as if they went back in time.
CS actually works really well for this system as it is itself a state-based language. Where you are in any game is entirely determined by the value of variables, the only movement you do is between scenes and labels and the load system can easily place you back where you need to be.
Is this useful for CS games? What would make it better?
I dunno. Discuss!