Aside from the cool factor of rolling your own db system, how does this compare/differ from current available databases, i.e. SQLite, MySQL? Is it lightweight/fast? What you have shown here looks good.

I plan on using a database for my own project, but I still have to read up on cost/benefits of one implementation over the next.

The last time I read your journal, I was far too brain-dead to have any clue what you were on about; now that I've re-read it with the benefit of consciousness, it sounds like a very interesting concept.

One slight philosophical tweak I would make, personally: let tags associate data with themselves. A bare object has no tags and is basically just a nameless, formless glob (or gormless fob, whichever you prefer). A tag consists of a nominative component and optional descriptive components; any object can have as many tags applied to it as is necessary.

To build off the initial example you provided, a purely nominative tag might be "Belongs to squad 1." However, I'd suggest a slightly different approach: the nominative portion is "Belongs to Squad" and a data component describes the actual squad number. This can then be generalized to many other things: team, unit type, properties (health, attack power, etc.), current orders, current AI routines... etc.


Slap on some judicious use of the Interpreter pattern, and you could get some interesting stuff: Find all objects tagged as 'Infantry Units' and tagged as 'Team A' and having tagged value 'Vitals.HP' < 20 percent of tagged value 'Vitals.MaxHP' That sort of structured language should be pretty easy to define a grammar and parse/execute engine for, especially combined with a generic object-tag system.


Just some thoughts.

RE: Nit

The question about using existing database systems is a very good one and is something I've put some thought into already. The system I'm describing here is atypical of the normal RDBMS model in that an entity isn't static in terms of properties. In a normal SQL database entities of the same type must all share the same properties; they cannot have additional attributes that others of the same 'type' have. You could acheive this in a small way by defining bolt-on tables that are linked via foreign keys to your master entity table but again these must all share the same attributes and it's impossible to modify them at runtime.

The main goal for this 'project' is to provide a database style system for games that doesn't force you into static models; it's designed to be dynamic so that you can assign additional data to entities whilst the game is running. Another primary goal is to be as 'independent' of any scripting or storage models as possible. This doesn't mean the system will not use technology, quite the opposite - it means that I'd like to have a system that could be accessed via the standard API that you see and have storage and other things implemented in whatever best suits the game it's being used in. This would mean that you could invoke method calls on objects scripted in Lua, GameMonkey, Python or whatever using the same API - it also means that data could be stored in a SQL database, in memory or in flat files such as XML.

It's interesting that you mention using SQL databases as the first prototype version I'm creating with this is actually based on the SQLite database. Although it fascinates me greatly to create my own database system, the amount of work spent to get just a simple prototype up will be prohibitive - I'll have to do reasearch into indexing, atomic transactions and all the stuff that makes up a database. So yeah, I have a simple table schema worked out for this system and will have to perform a bit of behind the scenes magic to make the query concepts mix (you can't query the entity db using SQL, for example).

One major piece of work with the project that I see right now is the caching side of it all; if objects are stored in a database we still need to maintain an in-memory cache of the 'active' objects - things that fall out of activity will be swapped out to the database and likewise for things becoming live.

Re: ApochPiQ

That's an interesting addition to the concept. I think I agree with the idea; it would allow you to start querying "all units attached to a squad", "all units attached to squad 2", "all units in a squad except squad 2", etc. It's definitely something I can see being used. The original philosophy would quickly get clunky without this in place, effectively meaning we'd be forced to assigning too many tags to objects to get what we wanted.

Thanks for this input, both of you =)