Sign in to follow this  

RPG save game

This topic is 3152 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

For saving files I was going to use the Boost serialization stuff, this is where the relevant classes define a single serialization method which takes an Archive which it them typically passes down to the classes components. The thing is you have two different contexts in which you want to save a class, when the content is first being designed in some kind of tool and when the contents have changed because of the players actions and the changes need to be saved. So your classes could have two separate serialize methods for saving their entire state and saving only their mutable state, or some other way of doing things. I think you'd want this to be designed from the outset to be as transparent and robust as possible, since any kind of save game corruption is a bit of a deal breaker for an rpg. Seems like rpgs are particularly difficult since you have so much to keep track of. Say in an RPG you have an Area class, which has contents like creatures, triggers and so on which can change, creatures can be killed, triggers can be fired, and also things like it's tile map and walk mesh which can't be changed. The player also needs to be able to go to an area, change something, go to another area and then save their game. So one way you could do things is make it so that when the player loads their save game the mutable contents of all the areas they have visited are all loaded into memory and stay their at all times before being written back again when they save their game. Is that typical, or is it more likely that stuff has to be written to temporary files?

Share this post


Link to post
Share on other sites
In sacred 2 we have a quest-"database". Quests can have several states (like inactive, active, won, lost, ...), quest-relevant creatures (questgiver, victim, attacker, ...) and quest-relevant items, area's which can be 'reached' or objects which can change state (unlock, opened, ..)

Now we inform the quest-system of all relevant actions, eg
* I talked to questgiver 5 and clicked on 'yes'
* I killed quest-relevant creature with the database-id "10"
* I picked up quest-relevant item with database-id "20".
* reached area with id "x"
* used object x (eg opened a door)
etc etc

From this action-log, we can at any time recreate the entire state on load.
No need to save big "blobs" of data (you would still need that for hero + equipment + fog-of-war obviously).
We can have 1000s of actions - and still our savegame is tiny (<100kb)

Concerning enemies we keep track of how many were killed in a sector (sectors are eg 200x200 meters), and when you leave it, we remove everything from it. If you go back immediately, we respawn the 'remaining' creatures. Over a period of time (eg 10-20 minutes) we fill it back up to "full" again. I wouldn't store the exact position of each spawn-enemy - just respawn (no need to save either :)

regards

Share this post


Link to post
Share on other sites
Interesting thanks. I can see the idea of a "change log" type object could be useful, I'll have a think about it. I'm not sure I'd want to tie it directly to quests, I wasn't planning on having a quest object as such, but implementing them through a lose collection of scripts, dialogs and triggers.

Share this post


Link to post
Share on other sites

This topic is 3152 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this