Re: [Adonthell-devel] sql database for gamedata?

[Kai Sterker]

On 3/30/06, Alexander Hupfer <address@hidden> wrote:

> As I see there are no formats for saving gamedata like map layouts, item
>  descriptions, characters or dialogs specified at the moment.

True. Since it is uncertain what is needed to store these things,
there aren't any format definitions. Dialogues are Python scripts
themselves, so they need not be stored in any special way. For the
rest, the plan was to store them in a gzip-compressed, binary file.
This is done by those put_state and get_state method found in various
files.

In general, I think there would be two sets of files. The binary data
used by the engine and plain text or xml files used by the editors.
Latter can be stored in CVS more easily, to allow multiple people to
work on the same file(s) with a full revision history. Former can be
more easily handled by the engine.

> So what about using an SQL database instead of plain text files?

In general, storing things in a database wouldn't be bad. But I think
it might take away some flexibility. With the file-based approach, any
type of item or character can write its unique properties to a file
and new item types can be added by simply writing their script and the
matching put_state/get_state methods. With a database backend, we most
likely would have to change some tables to take thosee properties we
had not thought about before.

> I think SQL might provide an better performance than the plain text
> sollution, as it is heavily optimized for the task of finding and
> providing the data needed. On the other hand a remote database might be
> an good option for doing colaborative work on the game designers side.

Reading or writing to compressed files is definitely slower than using
a well-designed database. OTOH, the data files are pretty small, so
loading or saving the game should still be fast. Larger files like
graphics or music will probably take much longer to load then the
rest. Collaboration can also be done via CVS, which has the benefit of
keeping a revision history of the data files. Changed to the database
could not be tracked down so easily.

So I wouldn't really use a db for storing our data. Instead I would
make up the file formats as we write the classes and editors. That's
perhaps a less "professional" approach, but it saves us some
additional design and implementation work.

Kai