Re: [Adonthell-devel] Game saving

[Kai Sterker]

On Sun, 02 Dec 2001 13:24:12 -0700 Lakin Wecker wrote

>> One question is what happens with complex data, like a map that contains
>> various submaps, or a character that contains an inventory. 
> 
> The approach I would take would be to define a class called say Any (or use 
> one that is already available: http://www.boost.org/libs/any/index.html).
> This is a class which can hold any type of variable that you want, so it 
> works with Integers, Strings, Lists, Maps, etc.  It dynamically figures out 
> what it holds, and has all the proper overloaded operators, and copy 
> constructor functions.  So it acts like any normal type. 

> The saveToFile function can convert the the map to a format which is 
> represented by a string or we could write some utility functions to do that.  
> I would serve to have a standard format to convert an "any" value to a 
> string.  That way an "any" value could be streamed over a socket to 
> communicate between server and client.    

Hm. I'm not sure I see the advantage of using "any" as an intermediate
data storage. What we need for both saving and streaming our data is that
data converted to strings.

But "any" does not make string conversion any easier. I guess in the end
it had to rely on a toString() method of each type we want to save or
stream.

And even though loading or receiving everything as an "any" type appears 
to be easier first, I think it isn't. To correctly assign it we still need
to know an object's actual type, right? 

In fact, we'd receive a list of string pairs that are put into our
base_data "memento" class. And from the additional protocol information
we'd see when the "end" of that base_data object is reached, and to which
type it belongs.


As for complex data, like the character example; I guess yesterdays
suggestion had some flaws. So here's a new approach:

What if the base_data class was a (single) linked list? 

class base_data
{
public:
    // ...

protected:
    map <string, string> data;
    base_data *next;
};

Then the save() method of a character could look like

base_data* character::save ()
{
    base_data *data = new character_data ( /* simple attributes */ );
    data->next = my_inventory->save ();
    return data;
}

The inventory::save() method would append a base_data for itself and
each of it's items to the list in much the same fashion.


The actual work of converting everything to a string would happen in the
<xyz>_data constructor, which can easily be written for each type that
needs be saved or streamed.

And the <xyz>_data::stream() method would have the task to add any
neccesary protocol information. For character_data it could look like:

string character_data::stream ()
{
    ostrstream str;
    
    str << "character\n";
    for (map<string,string>::iterator i = data.begin(); ... )
        str << i.first() << "=" << i.second() << "\n"; 

    if (next != NULL) str << next->stream ();

    str << "end\n";
    return str.str ();
}

Aside from the protocol, which is probably crap, the general idea should
work pretty good. In fact, at that point you could easily save that string
to disk or send it over a socket. So if we define a sound protocol to send
our data over a network, we get saving/loading practically for free.
Which is what you suggested, Alex :).

We'd still have "database" or network code in a single module/class, which
is what we basically want. We also have all the protocol stuff in separate
classes (although still distributed over several of them).


To come back to "any": I think it wouldn't make much sense with the
suggestion above. And as I said, I cannot think of something better that
would involve "any". Which doesn't mean that there isn't a better way, of
course. 

Your turn, Lakin :).

Kai