RFC: Dom3 DB

[Edi]

Heads up, people!

What do you all want the Dom3 Database to look like? What do you expect from it?

I have a few ideas myself, some of which we kicked around way back when I was last active here (before Dom3 came out). I suppose most here are expecting something similar to the Dom2 DB, a spreadsheet that can be used for modding, mapmaking etc and containing much the same info as the old one did.

That is certainly doable, and I expect I will produce something akin to it. The problem with the old Dom2 DB was that it just isn't portable to anything else, which limits its usefulness. I've begun designing the structure of the new DB, and I figured that even if I do make a spreadsheet, I'll make it so that the thing will be portable to a relational DB like SQL, i.e. all data will be in elementary form. This would essentially mean two spreadsheets, one with units, weapons and armor info as elemental items and a second one that has essentially the same info but also contains the formulas to show the full end results instead of just base values (which would be referenced from the elemental file). This way just copying the files under a different name would enable changing things in the elemental file and seeing the final results immediately in the formula file. I expect something like that would be valuable for modders.

That way, we can have both a spreadsheet version and the SQL DB version I envisioned over a year ago where all data display would be by queries. Once I get the things fleshed out in more detail and underway, I expect that I'm going to need help with implementing the SQL side. I seem to recall that at least Horst F. Jens showed considerable interest in a possible SQL version and input from others would also be appreciated.

The SQL DB version could be especially useful if we can make it fairly comprehensive and somebody codes a front end for it that could be used over a network, allowing people to craft the queries they need through a graphical interface. If both DB and front end (possibly with options for changing the DB values) were available for download, people could use them much the same way as the two spreadsheet combo for making different DBs for different mods.

I do realize that this project is very ambitious and is likely to take some time to complete, which is precisely the reason I'm posting this thread. I want input already now because it's much easier to plan something thoroughly first and then implement it than slapping together some half-arsed construct and then going back and adding, modifying and tinkering with it (much like happened with Dom2 DB).

So, get cracking, people! Input, PLEASE! Good ideas expressed now will serve us all better in the future, none more so than me since I'm the sod who's fool enough to volunteer for this in the first place.

And if the developers see any potential in this and are interested, please weigh in. If I can make something useful for you, so much the better. You have given us so much already, from DomPPP to Dom3 that I would love to return the favor.

Edi

[NTJedi]

Yes the spreadsheet will be best so we can sort the columns easily. Also each unit trait should consist of three alphanumeric characters because using two or less can make it difficult to search for specific traits. For example the current unit list uses only "a" for aquatic and when searching for aquatic units the gamer has to manually scroll the list looking for a single "a" instead of using edit/find and typing "aq1" for aquatic.
Three alphanumeric characters should cover all possible unit traits.

[B0rsuk]

For a start, try my grepable spell file I use for my spellbook script:

http://www.shrapnelcommunity.com/thr...b=5&o=&fpart=1
I mean, it can be easily parsed.

Note: at this point, it contains only spells from Conjuration, Evocation, Construction, Alteration and Holy. More columns will follow, but ones like 'damage', 'area' 'number of effects' are low priority for now.

[Ozymandias]

Oooh I like plaintext, regex is the best sort of query!

[Edi]

B0rsuk, I'll take a look at that list. Thanks!

NTJedi said:

Yes the spreadsheet will be best so we can sort the columns easily. Also each unit trait should consist of three alphanumeric characters because using two or less can make it difficult to search for specific traits. For example the current unit list uses only "a" for aquatic and when searching for aquatic units the gamer has to manually scroll the list looking for a single "a" instead of using edit/find and typing "aq1" for aquatic.
Three alphanumeric characters should cover all possible unit traits.

Each stat is going to have its own column instead of the Dom2DB format of most special abilities being in a mishmash in a single column, so you can sort by whatever criteria you want without trouble.

Edi

[Horst F. JENS]

Well, i'm on it whatever the data-format is. I can make DB-Front-Ends in M$-Access, and maybe this project will finally motivate me to do something with a Linux-DB.
Important points:
1.) it should be relative easy to implement changes from patches or mods
2.) The whole thing must work offline;
i want to merge it with a not-yet-existing spell and item list and need an easy-to-export data format (like the plain text files from BOrsuk) to make wiki pages out of it (see below).

[B0rsuk]

Horst F. JENS said:
Well, i'm on it whatever the data-format is. I can make DB-Front-Ends in M$-Access, and maybe this project will finally motivate me to do something with a Linux-DB.
Important points:
1.) it should be relative easy to implement changes from patches or mods
2.) The whole thing must work offline;
i want to merge it with a not-yet-existing spell and item list and need an easy-to-export data format (like the plain text files from BOrsuk) to make wiki pages out of it (see below).

Sounds like sqlite, doesn't it ?
http://en.wikipedia.org/wiki/Sqlite

I just added all common Enchantment spells to the necronomicon file, but it's not uploaded yet. The file is still incomplete anyway.
I need some ideas for next columns. As I said, at the moment there are common spells only. What single column would you add for national spells ? Some national spells are available to two or more nations, I hear, and this makes things trickier.
What other columns to add ? My ideas:
- underwater/surface/anywhere
- purpose (assasination, summon, artillery, travel, paratroopers... that would be for rituals)

[Edi]

The way you could do the national spells is simply add more columns to the spell DB, namely something like nation1 and nation2 up until you have enough and then put the first nation to have the spell in the first column and the second to nation2 and so forth. If there was one thing I learned from the Dom2DB, it was that it's a safer bet to put in a few more columns even if they don't get used much than it is to try and squeeze too much information into too few columns. Especially if we're going to turn this into a comprehensive DB.

There should be one column for spell type, which could use categories such as

• global enchantment
• local (province) enchantment (e.g. domes, rain of toads, hurricane)
• ritual summon
• combat summon
• combat offensive (lightning bolt, fire darts etc)
• combat augmentation (quickness, fire shield etc)
• overland movement (teleport, cloud trapeze etc)
• overland attack (earth attack, seeking arrow, ghost riders etc)

In general, we want to keep the categories simple and avoid having too many. Hence the above listing groups things targeting a single province in one category, regardless of effect. Spells that summon usable things, like black hawks, angelic host and so forth that can be dropped on an enemy should be classed as ritual summons because you get to keep the things, while ghost riders would obviously be overland attack since they vanish afterward. That's my two cents on that anyway.

My project is already well on its way as far as the layout is concerned, I've added all the forts to the DB and I'm currently making a brand new magic site database. It's going to be preliminary until I get the unit DB side fleshed out so I can add everything the way I want it done.

This project is also great at unearthing some minor bugs and a lot of in-game typos, so I'm going to add those into a list as I go along.

Edi