working on savegame systems today, aka the literal most boring part of game development
q: what's so bad about savegame systems
a: they require a completely different knowledge set (json serialization, file i/o), they take forever to test (since finding edge cases requires constant saving/reloading), and there's approximately zero interesting decisions to be made along the way
gonna try adding one of those "last saved the game [x] seconds ago" things to the quit screen though, so that's fun
-
from the very beginning, keep the broader state of the game in a "progress" thing, in an incredibly boring format. you think the player's inventory is a property of the player character? dead wrong. that's a property of the human player's progress through the game. if forgetting about it would feel like losing progress, it goes on the progress object
- but if it makes any sense whatsoever, track which player's inventory/etc it is, somehow. maybe you have no intention of ever having multiple players, but this is the sort of thing where it costs nothing now to leave the door open to the possibility, whereas trying to retrofit it on later will be a truly staggering pain in the ass.
-
PUT A VERSION FIELD ON THE PROGRESS OBJECT. DO IT NOW. SET IT TO 1. DO IT. DO IT NOW
-
consult the progress object frequently. it is the arbiter of truth do not let anything else think it knows better. do not "cache" anything you fool just check the progress object
-
now serialize it, like literally throw it at a json library
-
that's it you saved the game
-
for bonus points you can describe the schema later and validate on load or whatever but honestly if someone constructs a bogus save file and crashes their own game that's on them
