One thing, Marvin, if you want to make this much simpler: Use save slots instead of the complicated stuff we've got going on in the Restore Screen. In a game where you have persistent inventory, stats, and other attributes that carry between rooms, it isn't extremely useful to allow a player to restore to any room they've been. If you are building up your character during the game in standard RPG fashion, you rarely want to go back in time to where you've been, because that means rolling back all your character-building progress. Depending on your game design goals, you might even disallow explicit saving to multiple slots and just give the player one slot per character. (I think Angband does this, which makes for some nerve-wracking, but dramatic situations when you can't meta-game your way around risks.)
A fairly easy way to save games: When a new game is begun, create a new .dat file with a "
working copy"
of all the levels, rooms, etc. We have functions in CDbBase that open dat files and return views from them. You'd change these around a bit so that certain views would be returned from the "
working copy"
database instead of the "
hold"
database. The "
working copy"
database can change based on which slot the player chooses to restore from.
Now, here's the nice part: When the player leaves a room, just call CDbRoom::Update() and changes for that room are saved. I mean, that should work right now with no extra coding. You can just get rid of the "
saved games"
view, although you may want to have some kind of slot management view in the players.dat file to keep the associations between slots and working copy .dat files.
-Erik
____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals |
twitch stream |
youtube archive (NSFW)
