Coding: Data Manager Class

[Blake]

Okay, heres a game component to design and code (or steal ).

Functions:
Manages game variables.
Loads from txt files.
Loads from compiled files.


The primary function of this class is to load&parse files, that look something like this:

[Variables]
Growth = 40 #Nominal population growth ( /1000 for %age)
Growth_Per_SE = 4 #The change to growth caused by each + in SE Growth

Growth would be a variable, and the data manager would keep variables handy for other classes to get to.
And # means comment, ofcourse The word between [ ] basically indicates what to do with the following stuff, until the next [ ]

Another example would be classes

[unit]
name = "Light Tank"
hitpoints = 300
range = 4
firepower = 3
speed = 10

[unit]
name = "Hover Tank"
hitpoints = 150
range = 3
firepower = 3
speed = 20

When it encounters "unit" it will know what follows is a unit defintion. However it wont have to do anything with the data, rather it'll call a function in the unit factory which will know how to extract the data it wants from the token stream, do stuff with the data (create a new unit, I should hope), then return when it hits the next [ ] or hit's an error.
However the data manager will have to provide functions to extract the tokens from the stream, for example a snippet of the factory method for a new unit might look something like this

unit = new Unit;
dataman->discard("name ="); // dataman complains if doesn't find "name ="
unit->name = dataman->readString(); //complains if doesn't find a string
dataman->discard("hitpoints =");
unit->hitpoints = dataman->readInt(); //complains if it doesn't find a int

Notes:
Use c style streams, as c++ streams are really dodgy at the moment, they seem to work a different way with each version of gnu g++.
Stuff like compiled formats are very low priority.
It could be fun to have a way to register a factory method (and associated class name) with the data manager class, thus avoiding the need to change the code when adding more factory methods.
A singleton class could work well.
The format can basically be designed on the fly, however it could be worthwhile looking at how other games do. My examples look quite a bit like FreeCiv's data format.
Everything I've said or suggested is basically a suggestion, discussion of better methods is welcome.

Any volunteers?

[Kurilka]

what do you mean with c style streams?
fopen etc.?
Why don't we use STLPort to make sure that c++ streams work well?
And why don't we use XML for such things?

[Blake]

Oops, didn't know STLPort did streams too, that'd definitely be an option then.

Well, XML would be a possibility (I hear Clash uses XML), but really, I cant see the advantages for using XML for a game, I think a specialized format and loader would serve our purposes better.

[Kurilka]

Clash?
The biggest advantage I see is that it is eXtensible ML, consider situation when we need not sections/parameters, but something a little bit more complicated (nested parameters or something like that).

[Kurilka]

some example:

<faction name="human">
<unit name="Light Tank>
<hitpoints value="250"/>
<range value="4"/>
...
</unit>
</faction>
<faction name="aliens">
...
</faction>

Apolyton formatting sucks

[DeathByTheSword]

maybe another parameter for units could be: visiblity

if this are all the parameters I will get boring after a while....some extra parameter wouldnt hurt....

[Kurilka]

yeah, but that is not the question, the main topic to discuss is the format of the data file, i was trying to make something and came to colclusion that we need some NESTING (like XML do).

To make code like this (pseudocode, sorry ):

for each f in dataman->sections("factions") do
 add faction f->name
 for each u in f->sections("units")
   add_unit u->name, u->range, u->hitpoints...

[Blake]

Actually using the method I outlined it's not nessecary... every time it runs into a unit definition it simply calls the factory method.
Well, you are right that we need *some* nesting, the question is, do we need an arbitary level of nesting, or will just one (1) level of nesting do the trick?

The main advantage of XML I see at this point is it makes it much easier to extend or partially define stuff (ie add fields, or have optional fields)....

Expat would be a good choice of an XML parser, I believe, it's fast (and used in Mozilla)

[Kurilka]

Well that doesn't seem good choice (IMHO):

- C and not C++ (but C++ wrappers exist);
- stream-oriented - SAX and not DOM which is more suitable for our needs - applications must register handlers...
- a bit too large.

I propose tinyXML (http://www.grinninglizard.com/tinyxml/index.html), disatvanages (but i don't see them important for our game) :
- no DTD support;
- no XSL support;
- only ASCII.

The library seems to be quite stable and well designed.

[Blake]

Okay, TinyXML looks rather good.

[Kurilka]

And apart from data loading classes/routines there are some more questions:
1. What will we store in our data files?
2. Will there be 1 file for all stuff (seems to be quite unusable ) or many-many files?

[Blake]

many-many files.
Ideally, it would be possible to choose a selection of files to load, for example a core set of rules, but then being able to load extra files, like for extra units or something. (making it particullary easy to add simple mods)

It may make sense to then compile all the rules into a single binary file (I have a few ideas on how to do that, it wont really be the data managers responsibility), because as I understand it a single large XML file would be hell slow to load, *especially* using DOM.

Basically, we want to store everything we possibly can in the data files, except save games, map data etc which should be in a binary format. Or IOW, everything that we want the players to be able to edit, for example editing the save games would not be a sensible thing for a player to do.