Game databases

[Cheery]

What kind of databases there are in [TA]Spring? How they have been implemented?

[[K.B.] Napalm Cobra]

HPI, CCX, UFO, GP3.

[Cheery]

Which kind of formats they are?

[CaptainExo]

.hpi, .ccx, .ufo and .gp3



They're all pretty much unit storage. Glorified, specialised zip files, to put it bluntly. (But not that easily opened)

[Cheery]

Well, has the team buildt it themselves or have they used some ready library for that?

[zwzsg]

It's Total Annihilation data formats.
If you need info on those formats: http://visualta.tauniverse.com

[CaptainExo]

Well, has the team buildt it themselves or have they used some ready library for that?

See above. They're all used in basic TA, so TASpring uses them to make things easier.

[Cheery]

Why don't they use free databases like sqlite3? I'm just wondering. They would be easier to modify and update. Also you could tumble all the data into one database(one file).

I don't see it as such a easy thing to make databases yourself. Especially when they are pure textual information like the weapons in tank or the health of it.

[Trump Card]

Because like Zszwg said, those are the formats that TA used. The SY's don't want to have to make us convert every one of those to that new format just to play with addon units and mods.

[CaptainExo]

Why don't they use free databases like sqlite3? I'm just wondering. They would be easier to modify and update. Also you could tumble all the data into one database(one file).

What's the point in using a new file format, if you already have a (group of) much more popular one(s) that is better known and more widely used for TA stuff?

It makes TA stuff compatible with Spring, and means modders don't have to worry about releasing different formats of something, and also means the players don't have to faff about converting their existing custom units to work with Spring, thereby making them useless in vanilla "top down" TA.

[JeeZ]

Guys, to me it looks like you are talking about different things. Cheery asked about databases, not different formats for units etc.

As for databases, Spring have no use for a traditional database, such as SQLite3. The multiplayer server, however, uses a database to keep track of all registered users etc.

Regarding the formats, they were picked simply because all existing content were using these formats. (SJ, correct me if I'm wrong). Nothing says it isn't possible to create new formats, better suited for Spring, when developing new units and when the requirements are better known.

[Cheery]

I just wonder because I found sqlite database really efficient when it comes to storing object information. If somebody doesn't know what sqlite is. It's much like MySQL but it saves the complete database into one file, is super small and simple, but it's also fast to read and write, even faster if you don't care if the target file may corrupt when system crashes...

So instead of loading every unit at once, the program could just load up the necessary parts like commanders, making game start much faster.(if it doesn't already load up only necessarities) When people would make units, it would load them while the game is going.

Then you could use simple file formats like 3DS or wav to store models and sounds.

Another remarkable pros is that sql databases are extremely easy to modify and extend, you would get a big THANKS! from guys who are modding TASpring.

[Min3mat]

go for it guys! this looks like a step in the right direction concerning copywrite and may make preloading maps take less time :D

[PauloMorfeo]

... Spring have no use for a traditional database, such as SQLite3. ...

The unit packs are just like a database. And a relational one. We have fields like the unit's name, it's description, it's texture, etc, etc. And we have at least one relation inside. Units have a field that is it's weapon that must be searched in another independant list, the list of weapons.

This is just what an SQL database is all about.

Much of my programming course has been SQL and the final project has already started and i've been working on it's basis, that is, it's SQL database.

[Dragon45]

Read: the key word in Jeez's statement was traditional.

[Cheery]

Well, if you get fast insertion&deletion&add&remove&search with some other way, you better not to use SQLite, but otherways, you would be better to try it.

[Doomweaver]

I think in the future, Spring should be downloaded with support for my file formats - more compression databases whatever, and also other 3d object formats like 3ds. (Althopugh not 3ds, it has had issues since day 1. Not sure what format should be used, but anyway.)

[JeeZ]

Relational databases are a good choice for storing...ehm...relational data in table/column format. In most cases it is best to keep the database normalized and relations are described through foreign keys etc.

I can't see why Spring would need all the power (and overhead) of a RDB to load unit descriptions and that kind of stuff.

Well, if you get fast insertion&deletion&add&remove&search with some other way, you better not to use SQLite, but otherways, you would be better to try it.

Ehm...we don't need fast insertion? Are you planning to add game content while playing a game? Same goes for deletion/remove and add operations. "Search" is handled simply by quickly scanning the file structure at startup (or when needed) to locate game content.

To summarize: do you have any clue what you are talking about?

[Cheery]

But is the search faster than with sqlite?

We need all the power to modify the database, not to load it. What do you mean with 'are you going to add game content when you play?'. What else I'm doing when I put up a base and add everything in? But maybe that's not a work for a file database.

I think you lose nothing when doing things more standardised.

Edit: And btw. I read that overhead with SQLite is very small.

[SeaEagle1]

I assume that a keeping track of the bases you build is done in the memory, which is always faster than whatever file or database...