koobas.hobune.stream
Create an autosave/checkpoint feature for my game?
Hi,
I'm currently working on an action/adventure style game. I wanted to implement an autosave/checkpoint feature that will be triggered at the start of each scene. This will then allow the player to load into the latest level/area they were in from the main menu.
My problem is I'm at a total loss how to do this, the tutorials I've looked at so far have been that different from eachother I don't know what I should be doing. I'm still kind of a beginner with coding, so any help or advice is much appreciated!
People tend to make things too complicated. The question you have to ask yourself is, what's the absolute minimum amount of data that you can save and still be able to reconstruct the savegame effectively? In some games, like Prince of Persia on the Nintendo, that can be as simple as a 9 digit numerical "passcode". What's the data that's needed there? Stage number, checkpoint number within that stage, total time left, and a flag that says which health boosts you've gotten. That's it.
The breadth and depth of your save functionality depends on the needs of your game- most games aren't completely linear like the original Prince of Persia game, and so most can't be saved into a 9 digit numerical passcode. But it's usually not that much harder. Figure out what all you need, and make a data container type for all of that (literally just call it GameDataContainer or something). When it's time to save, fill that container with all of the data it needs, serialize it into binary, JSON, XML, or whatever you like, then write it to the disk. None of your scene objects need to be "saved" per-se, you only need the data that's required to reconstruct those objects at a later time.
I have no idea what the specific needs of your game are, so I can't really be more specific. There are tons of threads / guides around for how to serialize / write to disk / load from disk / deserialize- it really isn't much more complicated than that, just make a choice between binary (1s and 0s), JSON (strings, useful for storing on web servers), or XML (human-readable), and then run with it.
Thanks Lysander, it makes so much more sense now! I've tried to keep the gameplay aspects fairly simple, so the player only has to avoid detection and sometimes fight some enemies while trying to reach the end of the level. If I'm not mistaken, I probably just need the level number, the checkpoint number and the player's health for the container?
Yeah. As an example, if the game has an inventory system with items, but the items are really specific and in specific slots (like most Zelda games), then you only need to store a list of which items are unlocked, and a list of ammunition possessed. Assu$$anonymous$$g less than 255 item types exist in the games, and ammo stacks to less than 255, all of that can be stored as bytes in an absolutely tiny amount of space. List(Byte) Unlocks, where each entry is just an ID, and then List($$anonymous$$eyValuePair(Byte, Byte)) Ammunition, where each key is an ID and each value is an amount, for instance.
However, in games where each item is semi-uniquely generated, like World of Warcraft, you need to store a lot more data about each item- the name, the stats it has, the requirements, etc... Some of that data might be static based on the item type, and for that all you need is the ID of the item type, but anything that's randomly generated will need to be stored in the save data in full.
This same logic extends to absolutely everything else in the game- the only thing about quest data you need to store are the choices and progress you've made- that can probably all be expressed in simple numbers (quest ID, progress checkpoint, and any choices made as a number too). If you need to save a dropped item's position in the game world, then store the ID of the item and it's position/rotation to a given degree of accuracy, but there's no need to store what sprite it uses or anything if that's automatically tied to the item ID type.
If your game is really straightforward, and doesn't have items to keep track of, or quests to keep track of, then yes, the level number and checkpoint number and health may be enough. That doesn't seem much though, so I just wanted to clarify my answer a bit and go more in depth on the kinds of things normally tracked. All of that should go into one save container (current level and checkpoint, items, quest progress, achievements, etc...) and then serialized and saved to disk.
Hope that helps!
Brilliant! Yeah, that's really helped, I've been trying to self $$anonymous$$ch myself a few things but the save aspect was something I just couldn't get my head around. Thanks very much and happy new year!
