A friend of mine has often been heard to say that he’s never regretted making something configurable via data.  I tend to agree.. although my usual development process for home stuff is to do a lot more in code than I do in data.  But MMORPG Tycoon is becoming large enough that I’m really starting to see the benefit of doing more and more data-driven design.

And of course, this’ll be nice for anyone who wants to modify the game, since the data is all unprotected text files.  It’s trivial to make new buttons, move old ones around, etc.

In this shot, you can see the “On Foot” action bar, used when you’re just walking around.  As you can see, it provides a “Kick”, a “Punch”, and a “Mind” button, which actually send “Attack 1”, “Attack 2”, and “Attack 3” commands to the game.  In practice, this “On Foot” action bar will (eventually, post-MS1) have buttons set by the design choices you make in the game.  But most other action bars will have a static set of content, and this “ActionBars.cfg” file declares their default state, plus other information about orientation and where they fit on the screen.

But most of the day today was spent on revamping the file reading code.  Gratuitous technical details are below the fold.  Short version:  “Stuff is better now.”

[technical details]

Anybody who’s looked under the hood of the VectorStorm source code will have noticed that the “FS” file reading system is nicely defined at the top level (the “fsFile”) and the bottom level (parsing individual “fsToken”s out of a string), but that the middle level (the “fsRecord”) is horrible horrible horrible, with awful, unmaintainable code, particularly in regards to “blocks” of data.

In the fsFile text format, data consists of lines, where each line begins with an optional label, and then an arbitrary number of “tokens”.  For example:

Color 1.0 0.0 0.0 1.0

In the above, “Color” is the label (used by a game to make sure it knows what it’s reading), and the four numbers are the RGBA values defining the color.  We also support “blocks” of data:

VertexArray{
0.0 0.0
1.0 0.0
1.0 1.0
0.0 1.0
}

The curly braces {} define a larger “block” of data, with each line getting its own (optional) label, followed by some data values.

There were two annoying things about this;  one was that it only worked for a single level of data block.  That is, you couldn’t embed a block of data inside another block of data.  The other annoying thing was that you had to put the opening brace on the same line with the label for the block, when most programmers would expect to put that opening brace on its own line.

Well, today I fixed both problems;  that opening brace can now be placed on its own line (the parser “reads ahead” to detect this), and you can now have nested blocks of data (as you can see in the screenshot), so you can have an ActionBar which contains a Button or a Tab which can, themselves, contain their own data.

And as if that wasn’t enough, I also dramatically cleaned up the ‘fsRecord’ code, so it should be easier to maintain and fix any further bugs that might turn up.  If you couldn’t tell from the sheer volume of text that I’ve written about it, I’m very, very happy to have straightened out that mountain of tangled code!

Tomorrow, hooking up quest editing with the new action bars.