As you probably already know, the first Doofus game was released a few weeks back, and though I haven’t fully shaken off the lethargic hangover that accompanied the game release; I am slowly coercing myself to get back to daily chores. After every project one must look back and take a note of hits and misses of the project development cycle (Causal Analysis). That’s what I have been doing for the past few days, and though there have been lots of those (hits and misses), one of the important lesson I have learned from the whole experience of making the game is the importance of data-driven programming.
Most of the tedious and time consuming activities during development turned out to be simple manipulation and ordering of code. Placing scene-nodes, structuring the scene-graph, ordering render batches, grouping shadowing objects, and the list could go on. Things like these took up ridiculous amounts of time. In the game all this is done through code — when this could easily have been solved by a more data driven approach. I must admit there were times during development of the project when I yearned (almost cried) for a more flexible system. The problem was a lack of script driven programming, or should I say, a lack of a more data-driven system on top of the engine. Everything with the engine is currently done in C++, except maybe the configuration files. I hate it when you have to recompile 20-30 files just because you had to move a local variable to a class member. This does happen, especially for classes that have a long list of data variables and/or the ones that operate and integrate game data. We had initially planned on integrating a script and data-driven system into the engine, but that was later push down the priority of things to be done — and ultimately pushed out from the release due to lack of time and resources. Through not verbatim, that’s probably the story with every dev project out there that has to keep up with at least some sort of deadline.
In data-driven programming, data controls the flow of the program. Data is not just used to define an object state but also used to control the program flow, sometimes externally. Data-driven programming means writing generic code that consumes data and modifies it’s behavior depending on the structure of that data. The concept of data driven programming is not new. UNIX utilities have traditionally been data-driven and many applications use data driven designs. A web browser is a good example of a data driven application. It consumes a web page and modifies it’s behavior based on the structure of the web-page code, in this case HTML. Markups are again an excellent examples of data that encodes structure within itself (XML).
Well, there is a lot to take away from the current project. The engine will be made more data driven in the future, that’s for sure. The game also allowed me to pinpoint exact areas where a data-driven approach is needed. Many of those places wern’t immediately obvious during design.
