adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Game saving


From: Lakin Wecker
Subject: Re: [Adonthell-devel] Game saving
Date: Tue, 04 Dec 2001 08:37:34 -0700

> 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.

You're right at some point in time you still need to convert it to a string.  
So it doesn't seem to save any time and effort. 

However here is how I see saving a character would be easy. (however this may 
require alot of changes to the current save engine.  Which if it is the case 
then using the suggestion kai has below would seem better).
[savegame]
{
  charactername:"nikal",
  hp:45,
  sp:35,
  inventory: [ "sword", "shield", { gold: 500 }, "final key" ],
  pos: [ 45, 64 ]
}

This is a _very_ simple example but as you can see the inventory is stored 
directly as a list in the character.  If this approach is to have a feasible 
programmatical representation an Any class is required.

But like I said before, the approach below would be just as easy(if not 
easier), but I'm not sure it'll be more flexible.   Regardless,  Kai is more 
familiar with the save game system and so I'm for his version. 
:)
Lakin

> 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
>
>
>
> _______________________________________________
> Adonthell-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/adonthell-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]