Data-Driven Design

I just came across an article on Data-Driven Design for game engines. We have found it to be very useful to data-drive as much of the game as possible. Though we haven’t managed to be as complete in our purging of hard-coded game-specific features, we have gone pretty far down the data-driven road. The biggest thing that we still have hard-coded (and I wish we didn’t) are the global enums… things like the nations, careers, control types, and outfitting slots that appear in the game. The stuff that actually USES these things all comes from XML files, but the constants themselves are all defined in the code. Unfortunately that means that every time we need to add something to one of those lists we have to make a code change and make the poor designer wait for a build, a sin that breaks one of my own rules.

Look at me reblogging 5 year old posts. :)


4 Responses to “Data-Driven Design”

  1. Rich Bryant replied on :

    Hmm, hard coded enums?

    Why not simply use strong typing instead and inherit from the XML?

    Or is there an app-specific reason?

  2. Joe replied on :

    The only reason we’re using compile-time enums is that they pre-date our use of XML by a couple years. We really only started using XML extensively for static game data about 2.5 years ago, and some of these enums go back to the early days of the project over 4 years ago.

    It sounds like you’re referring to a specific technique, though. Is there some sort of standard way to define enums in XML and then use them from C++ code?

  3. Rich Bryant wrote on :

    There’s a couple of ways but what seems to popular right now is to define a class which exposes a collection and load that collection from XML.

    It’s a workaround way to get some of the benefits of .NET’s XML integration without using the framework.

  4. Joe commented on :

    That’s fairly similar to what we’re doing now. We have a text file that defines the enum values and then access them by name (read: string) in the code. We don’t actually look them up in the code very often (or at all in some cases) so there isn’t much of an efficiency hit there. And the boost we get from designers being able to add their own enum values is huge.

    If only we didn’t have all those legacy enums… :)