I’ve been playing with it a bit, and as far as I can see, the benefits far outweigh the possible speed issue. Any speed issue only seems likely during load and save games when I’m loading or dumping huge amounts of data, and really, reading the graphics off the hard drive is likely to be slower than reading the significantly smaller data out of the database.

Already, I have most of the sprite definitions in the database, and I’ve started defining other data sets, like planet styles and space station styles. I’m even going to set up star system styles, so that, while you can create a totally random star system, I will also be able to specify types that limit the number of planets or stations or have specific backgrounds, etc. These types of things are much harder to set up when you have to do it in a script file or some other non-data oriented format. The ability to add options just by adding more data in a simple, easy to understand and query format will be key to getting updates and additional content provided after the game has released.

This was one of the problems with Derelict. The data format was painful to manipulate, even with tools.

I’m examining using SQLite for data storage. It’s a cross platform database engine that can be built right into whatever application you’re working on. The benefits could be large in terms of how long it takes to add new data to the game as well as the tools that already exist to manage the database. It’s also very flexible in terms of what can be stored in it. Potentially, I could store everything in that single database file and be able to store metadata about something like a sprite in the same record in the db, which would make retrieving that information really simple. My biggest concern would be speed, but it’s supposed to be pretty fast. I’ll have to do some experiments soon.

This entry brought to you from my iPod while lying in bed.