newstalk

Enabling data-driven object construction.

This is a part of "Free Sky: Objects in Space".

Series contents:

Free Sky: Objects in Space
Enabling data-driven object construction.
Building for persistence at a fundamental level.
Using tags for metadata and lookup.

In my research, I’ve spent a lot of time reading what the developers of rogue-likes have to say. One of the more famous rogue-likes, Angband, uses text files to define just about everything in the game. This sounds a lot like the Pragmatic Programmer dictum: “put abstractions in code, details in metadata.”

I like it because I’m still designing the game. I don’t yet know what stats the characters will have, or a million other details. I want to defer these details and make them easy to change. According to the Pragmatic Programmers, “It forces you to create a more robust, abstract design by deferring details–deferring them all the way out of the program.” More robust? Sign me up.

Whenever programmers talk about data-driven programming, Domain Specific Languages are bound to come up. While I typically prefer to use either pure python or a standard declarative syntax, sometimes a DSL is just the thing. One particular aspect of the prototype which I’m especially proud of is my “dstr” language. Since an RPG uses a lot of random numbers, I wrote a small parser using YAPPS for defining a random number pattern. So if you want to roll three six-sided dice with a modifier of +3, “3d6+3″ will do the job nicely inside of any text format you throw it into. Those are the basics, though I’ve added quite a few bells and whistles to create a simple randomization dialect. I hope to eventually clean it up and release it as an open source module.

Beyond that, I’d like to stick to either Python source or meat-and-potatoes text formats. There are a lot of choices when it comes to text-based data formats. I haven’t settled on a format, and I may ultimately use several. For instance, I’ve developed a DSV format for defining tags for external resources (i.e. images and sound files). I may also investigate cookie jar and record jar formats, if the domain seems to suggest it.

I’ll probably end up using a lot of INI-style formats, and mainly because of ConfigObj. The ConfigObj package makes me happy. It allows me to write an INI-style text file, load it into an application, and access it with a dictionary interface, with python primitives, validation, nested sections and more. ConfigObj is quite painless to adopt, and generally works as you would expect it to.

I’m finding that INI format isn’t a panacea, though, even with an excellent library, and certain domains don’t recommend themselves to it. I’m hoping to experiment more with some other formats, though I’d like to avoid XML if at all possible (YAML, on the other hand…). With luck, this experimentation won’t distract me from the true cause of writing a useful data-driven object system.

All that being said, I’ve discovered one particular shortcoming of declarative text: it becomes difficult to express, well, expressions. Without going off and writing a DSL, that is. Relationships can be difficult to represent as well. To address this, I’ve developed the idea of recipes, which I will discuss in an upcoming installment, when I tackle the (potentially rewarding) problem of object composition.

Possibly related:

Share this: