Save game structure

[Chaingun]

From Paradox PoV their DDF (data description format) is pretty sensible. Scanning it is pretty fast (for instance, to locate all army entries, scan for tags starting with army etc. and skip rest within { } for unrelated tags). So load to such a file, they can either A) build a tree graph representing the tag hierarchy, or B) just use some kind of callback system where each kind of tag invokes some specific loading method directly at load time. Saving is much easier.

The downside, like you see, is there aren't any public GUI-editors for it. One can program one however. Don't know if anyone did this yet but it may be possible someone has (I've seen it being discussed).

Using an SQL database? Would you install an SQL server on the user's machine and run it in background to serve the game? Not sure if loading would in fact be any faster either. Consider: Each time a save game is loaded or saved, all data from save is used (transferred to/from main memory). This is not what a general DBMS is designed for. Importing/exporting to a native text or binary format in this case is much easier and in most cases probably faster.

Now, there are some things where a real DBMS might have been better. Consider the huge amount of character data (family trees) in Crusader Kings. It should really only have been swapped to/from disk as needed since there were very few times it was actually used (player viewing 1 character at a time, or at an inheritance without direct heir). Instead, as Paradox's DDF was used, huge save files were generated that took long time loading/saving and memory was filled up. And so unimportant dead characters had to be deleted from family trees.

What I'd really love to see would be a true scripting language to accompany Paradox' DDF (or even replace it). Currently a lot of things are impossible to make with mods that'd require an executable script language. Event scripting simulate this but it's not enough. I've been propagating for Lua and Python for a while now but I doubt it'll happen.

 

[Chaingun]

I'm talking about save games. It's impossible to deny that a SQL database would be quicker in loading/editing than a save game. DBMS are designed to store huge swaps of data, and because the text files are actually databases (but slower) I don't see why there is any reason not do to this.

Text files are not slower than databases. It depends entirely with you do with them. If you A) know exactly where in the text file the data resides, B) can load it into main memory all at once it's going to be faster in fact. Why? Because query parsing/optimization needs to be performed by a DBMS, whereas loading text files require minimal amounts of calculation.

With a Paradox game save file you would only end up writing SELECT * statements everywhere since all data must be loaded anyway. That's equivalent to loading all data in a text file. Loading all data in a text file can in best case be done on a single pass with an intelligent loading algorithm.

For Paradox' format you can load it on one pass like this assuming each loaded tag is only dependent on its parent tags:

main loading method:
do
X = read next tag
call appropiate callback method for X
until end of file

callback method for X:
do
Y = read next tag
call appropiate callback method for Y within context of this method, this context could be for instance be "allies" Y of a country X (allies X on the base level wouldn't make any sense, but neither does "country" Y inside method for country X)
until end of tag (which is } character)

Otherwise you can store data into a tree in main memory on first operation and operate on this tree afterwards with methods similar to the above.

---------------------

Like the person above me says, changing to XML would be a better suggestion if you'd like a standardized comparable format.

 

[Chaingun]

Well the thing is, everything is loaded from text file and after that everything is done in memory. Most game data loaded is needed every frame for game world updates, AI updates, user interface display, etc. The only problem with this is when the data gets so large it no longer fits in memory, or leads to excessive loading/saving times. Only Crusader Kings did so far have this problem (characters breeding like rabbits). But then again, it's not unreasonable to think Rome will face the same issues considering it's supposed to have a character system too. However, probably Paradox has had time to think it through properly this time (unlike CK which was rushed).