[RaceIntoSpace-developer] Using sqlite as data storage

[holy_moly <hol...@gm...>]

Hi!

I've not been committing stuff these last few days. This is on the one
hand side due to my workload which leaves close to no time for projects.

On the other, more interesting side I've been conducting a local
experiment. I'm not too far along the way but I like the results already.

My main thought was: "Heck... why are all the data structures so...
basic?" - basic as in... close to assembler.
I figured that it's got to do with the history of the game (lately we've
been talking about XML) but also with the power of the CPUs. It was a
good choice to put things in memory and keep it there.

My thesis is that today's machines can handle some more load and thus
make things easier for us.
I'm trying to use a database engine (in my current experiment it's
sqlite3) to provide input data and hold the current game state.

In my eyes this provides a number of benefits:
- data independent of implementation (no more bit shifting and endianess)

- data structure more flexible (new attributes can easily be added to
the database, alterations are only an UPDATE-statement away)

- data referencing - this is like pointers within a structure
"commenting" on the pointer's target

- referential integrity! data can not easily get mixed up (sqlite does
not provide this atm)

Where would I like to use it?
a) data input like the mission blueprints and their steps or the astro data

b) savegames - they can be tables within the database, each just
pointing to the input structures and correcting/amending them where needed

c) current game status - this can be implemented just the savegames


The last idea would make the integration of scripting languages a lot
easier, provide rather loose coupling and still allow the scripters to
use all data as input and change everything. There may be scripts
generating news under the influence of the average skill of the 'nauts,
or mission success can be influenced by technology not used in the
current mission. A lot of ideas come to mind.

What's the current status?
I'm still working on the basics. Currently I'm entering the mission
blueprints into a sqlite3 database. When I'm done with that I'll go to
the game code and make it use the database instead of the missions.dat
file. This should be transparent.

If this works well I'll go a step further and try to save the actual
mission path with the dice rolls and things like that in the database
(this should come in handy on replays if we decide to go for them).

At that point I'll commit the changes to a new branch so others may
inspect and provide feedback.
I'm not counting on finishing this work earlier than December of this
year though.

I'll try to make it work with sqlite3 as this is a rather easy to use
database engine and it's lightweight. We'll see further on.


Comments are welcome, as usual!

Fabian