Game Saving And Loading Discussion

[LookingForAPath]

I figured, I'd start a topic to discuss how other developers out there, handle game saving and loading. This could also be considered, a general saving and loading, out side of just games, lol. The reason for this topic, is because I'm currently deciding how my world editor is going to save the objects and I'm stuck between the existing choices.

We all know that when you save information a pointer points to(the data, not the pointer itself) in a file, it does not mean that the pointer will point to that exact data, when it is reloaded, anymore, because it doesn't know to point to it. Although this is a pain, it is something that cannot be avoided, because although what the pointer points to IS data, the pointer itself isn't data.

If you don't know what something is, I'll explain it the best I can. At the time of writing this discussion, I was going to go on ahead and explain them all, but
I'm busy helping someone with PC related problems and I'm being overly distracted.


My vote is for a ID based system.

Pros of a ID System:

Easy to implement.
Not slow, but not fast.

Cons:

Slower then other options in some areas.
Can lead to some leaks, if not properly managed.

[serengeor]

We all know that when you save information a pointer points to in a file, it does not mean that the pointer will point to that exact data, when it is reloaded, anymore, because it doesn't know to point to it. Although this is a pain, it is something that cannot be avoided, because although what the pointer points to IS data, the pointer itself isn't data.

I can't imagine why would you want to save pointer, since it is useless once you'd try to load things back, since the data does't exist anymore, or it's in the wrong place.
I have my serializer in my framework and it serializes things into xml, which for me is pretty good as I can load it back with text editor and look trough it, modify it manually.

It's capable of serializing entities, their properties, their components and component properties. Entities hold pointers to components, but it doesn't mean I have to save components pointers. What I do is save components type, name, data etc. then when I load back the data I recreate the components by type,name and set its data back.

I hope this makes any sense to you (got up way earlier than usually )

[LookingForAPath]

You misunderstand what I mean, haha. I mean to save the data the pointer points to, not exactly the pointer itself. (I'm sorry, my explaining has always been bad)



For example:

cpp Code: Select all

 
 
class Item
{
Player* Owner;
int ItemCost;
 
public:
         Item();
         Item(Player* TheOwner);
        ~Item();
};
 
 

When you try to save this "item" and reload it, the item won't know what "player" owned it when it is reloaded. Which is also, what you said in your post.

Which is why, I'm asking how other people generally save that data and reload it.

A ID System, is the closest thing to what you're using, except that you're recreating the object through the "entity" that pointed to it, or at least that is what
I got from your explanation.

[hendu]

Meh, saving and loading objects and pointers... Better keep saves small, only save exactly what you need to save. Player position, level, and score? That's three floats and two ints.

[LookingForAPath]

True, but saves cannot always be that small. Especially when it comes to worlds, you have to save where all the props have moved to and reload them, or lets say
you have a first person shooter and the player is surrounded by 10 bad guys and 20 more are looking for him. You'd have to save all their positions, the mesh and texture they use(Not save the ACTUAL mesh or texture, but like a link to them. So when they are reloaded the know which ones to use.) and that they are "currently searching for the player".

So as to what you "need to save", the list can get quite large, even in "somewhat" small type games.

[serengeor]

When you try to save this "item" and reload it, the item won't know what "player" owned it when it is reloaded.

I see two possibilities for this.
1) gather all items in player class and save them with player data.
2) save all items and somehow mark to whom it belongs to.

[LookingForAPath]

Option 2: Is basically the ID system, I was talking about.

On Save:

You'd have the Item have: Its own ID and the Player's ID, that owns it.

The Player would have: Its ID.

On Load:
Then it would cycle through each item and if the item's PlayerID, match the Player's ID, it would add that item into the player's inventory.

My explanation, must be entirely fail, that or what I'm talking about is just me being stupid..lol.

I guess, my design is going to be on a ID system basis, lol.

(If you're asking why, I'm creating my own world editor instead of using another, well it comes down too 2 reasons: 1. The Learning Experience. 2: The Ability to know the internal workings and so that it works specifically for me.)

[serengeor]

have a look at my attempt on saving stuff with my world editor:

cpp Code: Select all

<entity name="Level2" id="1" groupid="0">
    <components>
        <component type="1" family="1">
            <properties>
                <property name="mesh_file" type="6" value="./media/mymap.obj" />
                <property name="position" type="8" x="0" y="0" z="0" />
                <property name="rotation" type="8" x="0" y="0" z="0" />
                <property name="scale" type="8" x="1" y="1" z="1" />
                <property name="use_lights" type="5" value="0" />
            </properties>
        </component>
    </components>
</entity>
<entity name="Level3" id="2" groupid="123">
    <components>
        <component type="1" family="1">
            <properties>
                <property name="mesh_file" type="6" value="./media/mymap.obj" />
                <property name="position" type="8" x="0" y="0" z="230" />
                <property name="rotation" type="8" x="0" y="0" z="0" />
                <property name="scale" type="8" x="1" y="1" z="1" />
                <property name="use_lights" type="5" value="0" />
            </properties>
        </component>
    </components>
</entity>
<entity name="Level3" id="3" groupid="123">
    <components>
        <component type="1" family="1">
            <properties>
                <property name="mesh_file" type="6" value="./media/mymap.obj" />
                <property name="position" type="8" x="0" y="0" z="460" />
                <property name="rotation" type="8" x="0" y="0" z="0" />
                <property name="scale" type="8" x="1" y="1" z="1" />
                <property name="use_lights" type="5" value="0" />
            </properties>
        </component>
    </components>
</entity>

There can be many components in a class(think of components as items in your case). I save their type so I can attach the same type of component when I load back and also reset its properties to what they were.
This might be a lot faster since you load back things entity by entity, item by item and you don't have to reiterate for every item you have.

[hendu]

True, but saves cannot always be that small. Especially when it comes to worlds, you have to save where all the props have moved to and reload them, or lets say
you have a first person shooter and the player is surrounded by 10 bad guys and 20 more are looking for him. You'd have to save all their positions, the mesh and texture they use(Not save the ACTUAL mesh or texture, but like a link to them. So when they are reloaded the know which ones to use.) and that they are "currently searching for the player".

So as to what you "need to save", the list can get quite large, even in "somewhat" small type games.

It's a question of design. Is an instant-save in all situations really what's needed? Is having it good or bad for the experience, does it cheapen the experience, make things too easy?

[LookingForAPath]

@serengeor: That would actually be faster, I think I'm going to go about this scheme if I can. Just not using XML.
It still kinda looks like the ID, thing I was talking about though, in a way.

Could you give me a example of how you would save parented objects? (then I can determine for sure..sorry if that sounds stupid, but sometimes
I have to look at it from the basis, I am thinking).

@hendu: My simplistic game, would require a instant save, as it isn't exactly a whole "big" project. It would keep the experience right where I want it, because
the player has no explicit goals. Although, I wouldn't really need to save NPC state, because they are always looking for the player.
I've really already determined whats needed, just how to save it and load it, is what I am determining.
I know ways to do it, but I'm looking for ways other people do it to see how what they use works.

My flaw is simply: Which way to go about saving and loading a map. What if, this scene node is parented to this scene node? How do I know that when I reload it?
Things like that, which is why, I've been basing this off the "ID System".

[serengeor]

@serengeor: That would actually be faster, I think I'm going to go about this scheme if I can. Just not using XML.
It still kinda looks like the ID, thing I was talking about though, in a way.

Could you give me a example of how you would save parented objects? (then I can determine for sure..sorry if that sounds stupid, but sometimes
I have to look at it from the basis, I am thinking).

Well, my entities don't really have this parent-child relationship, though I think I know where to find such
Will write back when I find it.

[teto]

Boost serialization seems to do a good job. I never had the chance to try it but I will one day
XML may be more interesting if a third party may need to look at the data.

You forgot another solution: Resorting to scripts. If you use Lua for example, you might juste create a file :

cpp Code: Select all

 
Player:setLife(30)
Player:setPosition(4,5);
Level:setProgress(0.4)
 

or something along those lines. Once you have a scripting system running, it is quicker to do so than to use xml (and self explanatory)

[LookingForAPath]

Hmm, I hadn't thought about using lua, but a good point.

I'll be back in a couple of hours, I've been up for, nearly 24 hours now.

When designing things like this and coming down with a appropriate design, I usually can't sleep, but I gotta force myself.
Be back soon and thanks for the discussion thus far.

[serengeor]

You forgot another solution: Resorting to scripts. If you use Lua for example, you might juste create a file :

cpp Code: Select all

 
Player:setLife(30)
Player:setPosition(4,5);
Level:setProgress(0.4)
 

It might be good to have scripting system, but it won't do the job for you automatically, you would still have to write the damn serializer


Just remembered that irrlicht has it's own scene serializer, it's in CSceneManager.cpp.

Basically it's only iterating over children and using recursion of same function on the child nodes until there are no more children and storing them in a way like I posted above (nested i think is the term).

[Radikalizm]

As stated, decent serialization is the key for efficient saving and loading;
I'm using a system which uses XML files for my game entities, world, configurations, effects, material, etc. for use in debug mode, which allows for easy editing; in release mode these are stored in a memory-efficient binary format (which also makes it difficult for people to get hold of my assets)

The key in memory-efficient asset and world saving/loading is to save just the right amount of information needed to reconstruct your world, and nothing more;

If you're sticking with an object-oriented design for you game, it's a good idea to document your 'primary' class attributes (ie. attributes which can not be derived from others) from the very beginning of the class creation, and in which state they should be to conform with the class invariant; if you do this, the serializer implementation for your class becomes rather trivial, because it only has to make sure these attributes are saved and restored correctly to perfectly recreate the previous state of your class (be aware that the class should be responsible for recreating non-primary attributes after the primaries have been restored by the serializer)

It all comes down to a good serializer and clean code in the end, how you use this serializer is a completely different issue, whether you want to use scripts for this really doesn't matter (as serengeor stated, you'll still need a serializer)