   Save game
  Hey guys,Think I've got an interesting question for you.I'm creating a rather complex (understatement) game. So that begs the question is how am I going to allow the player to save his/her progress. Something simple like writing lines to a text file to read back later is going to be a too much of a hassle. What I'd like to do is write the entire player object to a file and simply load the object back in later. So the question I gotta ask... is this even possible? If so can someone point me in the right direction?Thanks guys for any advice you can give!   
  You could serialize your object's and write them in binary format.However, I'd suggest a human readable format like xml for the beginning (easier to debug, etc.)   ;Quote:Original post by ShadekfWhat I'd like to do is write the entire player object to a file and simply load the object back in later. So the question I gotta ask... is this even possible? If so can someone point me in the right direction?Maybe, it depends on a lot of things: what platform? what does your player object look like? etc.If you're using .NET, it's fairly simple to use the BinaryFormatter to serialize objects to a stream.If you're using C++, it's a bit more tricky. If your objects are simple and contain no pointers to other objects, no inheritence, etc, then you can just write the binary data of the object to disk. For more complex object heirarchies, you'll need something a bit more intrusive. Boost.Serialization is available, though I personally have never used it.   ;  I'm using C++ and my objects are a little tricky with a lot of pointers and inheritance. I've used boost before for other things but I'd prefer to not use external libraries (even if they are free) unless I have to. Is there any other way to serialize the object that's inherent to c++?   ;  If you have a bunch of objects with pointers in them to other objects, unfortunately no, you cant just write them out, because obviously when you read them back in, the pointers will all be invalid.One technique you might however, is give every object that you want to save a "Save" function which is passed a file handle and the object will write out it's own data that it wants to store and then call "Save" for all of it's children so they can do the same.Then, do it in a similar fashion for loading.No simple answer here, sorry!   ;  If you have a bunch of objects with pointers in them to other objects, unfortunately no, you cant just write them out, because obviously when you read them back in, the pointers will all be invalid.One technique you might however, is give every object that you want to save a "Save" function which is passed a file handle and the object will write out it's own data that it wants to store and then call "Save" for all of it's children so they can do the same.Then, do it in a similar fashion for loading.No simple answer here, sorry!   ;  Serialization of important state variables is pretty much the only solution.  Save/Load is often thought of as the biggest pain in the ass in game development.  Usually, that's because the design of that system is usually put off until other features are complete (aka your situation).  It's trivial to maintain a save/load system, it takes months to get it working in a system where it's either been broken for a while or hasn't existed.-me   ;Serialization. Assuming you still want to do it yourself, anyway.   ;  I've had the pleasure of implementing save/load functionality into games that were already well into development, and let me tell you it's a boatload of fun and win </sarcasm>The hardest part of designing a save/load system isn't really the serialization itself, but rather figuring out what needs to be serialized in the first place and the relationships between all your data.  What state is specific to that particular "instance" of the game and needs to be saved, versus what state is "static" (i.e. a property of the map or archetype, or a loaded resource)?  What data can be reconstructed on load by inference as opposed to being saved directly, or simply rebuilt from scratch?  What are the similarities and differences between your in-memory and on-disk representations of objects?  When objects reference other objects, when does one object "own" another object versus simply reference it?  When do you serialize the explicit reference to another object, versus simply serialize the referenced object "inline" inside the referencing object?  I could go on, but this is just a small list of things that need to be taken into consideration.Essentially it comes down to a figuring out who owns what data, what needs to be saved versus what can be inferred/rebuilt, and how you can save it so that the same (or equivalent) game state can be reconstructed on load.   ;Quote:Original post by ZipsterThe hardest part of designing a save/load system isn't really the serialization itself, but rather figuring out what needs to be serialized in the first place Well, I guess if you want an EXACT copy of your current world state, that is not a problem. Just serialize everything.I remember Unreal 1 saved games took about 10 MB every game, and 100 MB ten slots.Maybe you don't have to save eberything. It is not importante to save enemy states who have not seen, for example.BTW, somebody told about BOOST. What libs do you use to serialize?Thanks.   