Database Driven Torque

#1 I integrated SQLite3 into TGE 1.4, and am using it to store game data, but not GUI elements. I use it to store connections between mission maps (what map connects to what), lots of RPG-specific data like faction information, permanent player inventory and event tags, 'merchant' inventories, additional vehicle characteristics, and an RPGDialog-like system (I replaced the RPGDialog resource's text config files with database entries). I have fields for script callbacks in many of my tables, but am only actually using the ones I put in the RPG-Dialog tables at the moment.

I don't actually store datablocks in the database, but I have attribute-type information stored in them that is accessed by various datablocks after they are created. Nothing physics-related that the client-side needs to know about, but stuff like the vehicle 'cargo' capacities, base prices, etc..

So far, not only is storing this stuff in the database easier to manage than using just scripts for the same things, it will probably be easier for end users to mod the game.

So no, you're not crazy, and it should be worthwhile.

#2 I am working on an RPG, and I'm loving having SQLite integrated in TGE. I have got it creating item datablocks from the attributes stored in the items database, its quite easy to do (see dreamers MMORPG tuts) and makes life much easier. And, as mentioned, it opens up alot of modding options. I'm trying to have all my world statistics and game info in the database for easy manipulation.

Definately worth it.

#3 Very cool Brian and Gareth.

I am trying to grasp how it would be organized to stuff as much of the scripting into the database and what the minimum amount of code required to database stuff to "boot strap" the rest of the code. I have been thinking that if you have some number of standard widgets that can be created and stuffed in the database then the screens can be built at runtime. The widgets could be modified in only one location and the rest of the screens get updated automagically to use the new widget. This would make creating styles extremely easy so you could have the equivalent of WM themes that are extremely configurable. This same model could be extended out for the rest of the engine. In addition one could use templates that are modified for individual instance that could be generated as well. Think player object that gets branded as npc or pc when a filter is run over it. This would save on coding as well. Anyway, enough rant I need to get working on it.

Any pointers on where to start?

I figure my first objective is to generate generic boot strap code. I could leverage the current editor code to save to database versus creating my own editor to get started.

Thanks,
Frank

#4 I looked at what it would take to redefine the way torque loads up stuff and it is dauting even for a simple starting place like the MinApp tutorials. I think I will just use my database for new stuff and merge stuff as necessary. As I gain experience I think I will find ways to load stuff into the DB as I see fit. Definitely a good place for settings and the like, but even then there are a LOT of settings.

#5 One easy, but pointless, way to do it would be to load the contents of each of the script files into a text field in records in a database table. Then replace the calls to 'exec("filename.cs");' with calls to load each text record and 'eval' the contents. I say this would be pointless, since you wouldn't gain any modularity, and would lose the benefits of precompiled script files.

Instead, I've been splitting attributes out into the database based on their effect on physics. For example, I'm using relatively standard scripted datablocks for my vehicles (though I have a few specialized C++ subclasses), but then loading all the RPG-related attributes of each (cost, availability, list of mounted weapons, etc...) from the database. I've been splitting some attributes out of the datablocks into the vehicle instances, like max energy, max health, etc... to allow for player upgrades which are loaded from the database, but otherwise am using the basic script datablock structures. The vehicle instances then load the RPG-related attributes from the database.

I'm not sure if this is technically the optimum way to factor things, but it works the way my brain does.

#6 Brian,
Your way of splitting out what is different is a very good idea. You are using the default constructs as templates and applying the differences based on your "save" file. That makes a lot of sense as you are leveraging the current code.

For fun I am going to try just doing guis to start as an exercise. The problem I am running into conceptually is losing the default editing tools or having to modify them to use the database. It is a good system already. I do not expect to really use it for everything like I had imagined as that would be a lot of work for little gain. For now I am just going to play with building guis out of database structures just to get practice with the database.

I really like the idea of building templates that are "hidden" in the database and then applying changes to the templates by using eval commands as you suggested. That way you write code once and apply the changes for each specialization. I played around with this when I writing some neural net code. I made a default neural "class" if you will and applied changes to this template. This allowed me to write the code for manipulating neural net lists once and only had to change it from one location to fix bugs. It simply was a *.cs file that I would load and replace tags using a simple replace command in Torque script. The problem is this exposes the template code to user manipulation if not hidden/protected somehow. I am now thinking I can create the template in the database and generate the template and the mods completely from the database on the fly. No code to hack into because it is not written yet!