Jump to content
  • Advertisement
Sign in to follow this  
MGB

Save game architecture

This topic is 5398 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

Hi all, The save game topic has been pounded over quite a bit looking at the search facility, but not so much from the architectural side. I'm currently starting to implement mine and have considered: - Memento's - abstract the class away from the archive and allows re-use (can set up game state easily). - Use the Visitor approach (centralise archiving code) - Each class has its own << archive operator (messy but required?) I can see +'s and -'s with each... Can anyone share their experiences with approaches that have worked for them?

Share this post


Link to post
Share on other sites
Advertisement
Not quite sure what you mean by the first option...

Between 2/3 - Unless you have few pointers in your data structures, I'm going to guess that going with the Visitor approach would be the easiest and most straightforward to implement, since going through two passes (load object specs then map id/pointers to each other) with the <</>> operators seems hard and focusing on the object, when in fact you'll need some temporary data to map item ids to their pointers (when loading) or mapping pointers to their item ids (when saving). The visitor approach just seems to lend itself more to this approach (to me... but I'm relatively new to the approach and still trying to full grasp it in my mind).

Share this post


Link to post
Share on other sites
I actually branched my save-game code off from my network communication code. Since everything needs serialized for both it fit rather well.

Share this post


Link to post
Share on other sites
Hmm good point Telastyn -- not done any network stuff yet but something to bear in mind.

MMonkey: Memento description here: http://www.dofactory.com/Patterns/PatternMemento.aspx
Bit of a pain when serialising, this OO stuff eh? ;)

Share this post


Link to post
Share on other sites
Interesting - UML diagrams don't explain things for me but a minor bit of googling did.

The main problem I've allways run into is mapping pointers to ids and vicea versa.

Share this post


Link to post
Share on other sites
For me, I built a hash-table [erm... std::map?] that stores the UID to pointer mapping [in addition to each game object having it's own UID stored in the class]

so a unit for example has


class unit{
// ...
UID guid;
hexinfo *hex;
unit(){
guid=hashtable->genuid();
hashtable->insert(guid,UNIT,this);
// ...
}
~unit(){
hashtable->delete(guid);
}
//...
}


Then when network communication occurs [or the game is loaded] pointers are serialized.

For example, my unit communication simplifies down to

unit
guid ###
...
hex #### [where #### == unit->hex->guid]
...
done.


The game then looks up the guid in the table. If the guid doesn't exist, it queries the server for the full info for hex ####. [in the load game case, it actually just waits until eof. If a guid still isn't loaded, it aborts.]

When the hex's info comes it, it has a pointer to the units in it. As part of its constructor on the client side, it goes to each unit and updates the ->hex pointer [or of course asks for more info if the list of unit guid's contains missing members]

Hrm, sorry if that wasn't too clear, it's late.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!