Hello,

I've been studying game programming with SDL and I came across a very interesting subject which is the Data-driven design. I searched around the web and I found lots of definitions and approaches about it and I didn't understand it very well. What is it exactly? How can it be used in game programming?

Thanks in advance

lvenonl

A data-driven approach might have a file like:

// orc.json
{
  "name": "orc",
  "hp": 150,
  "armor": 10
}

While a non-data driven approach might do something terrible like:

// orc.cpp
class Orc : public Monster {
public:
  string_view getName() const { return "orc"; }
  int getHp() const { return 150; }
  int getArmor() const { return 10; }
};

The latter approach is bad. It hard-codes the orc into the game. A designer must be an engineer and have the ability to recompile the game to make a simple change. After making the change, the game must be completely restarted to see the change; it cannot be edited while the game is running.

The former approach uses a data file. A designer can edit this file. A nice GUI for editing these files can be produced, or tools that import it into a database or CSV for each comparison with other monsters and to making tuning and balancing easier. The file could be reloaded while the game is running. etc.

There'd still be code, of course, but it should be general and non-specific. The code specifies _how_ something is done, but the data specified _what_ is done. e.g., in a data-driven approach, you might have:

// monsterdata.cpp
struct MonsterData {
  string name;
  int hp;
  int armor;
};

// load from a JSON file
bool LoadMonsterData(string path, MonsterData& data);

// save to a JSON file
bool SaveMonsterData(string path, MonsterData const& data);

and there the data is a simple struct you can edit with AntTweakBar or a custom editor GUI. It can be loaded, saved, etc. Much more flexible. You can take this even further and not have a specific Monster class but rather a general purpose set of components or attributes (so anything can have HP, not just monsters, for example) which now lets designers create whole new types of objects out of small pieces rather than needing an engineer to write code for new types of objects.

Again, let the code decide _how_ things are done (HP/kill tracking, etc.) and let data decide _what_ is done (who has HP, how much, what causes damage, how much damage is done, etc.).

I see! It looks more efficient!

Just one more question: Is XML a good option for data files? Do you recommend any other data file instead of XML to use for a 2D game?

XML isn't bad, just really, really verbose. I think these days most people prefer JSON, but you'd be fine with XML as well. You can get libraries to parse either for basically any programming language nowadays.

Just one more question: Is XML a good option for data files? Do you recommend any other data file instead of XML to use for a 2D game?

XML is just one of many options. It is a format that lots of tools can easily support. JSON and YAML are also formats that lots of tools can easily support. You can even make your own data formats if you want, just recognize that less tools will easily support them.

What matters is that the programmers are not hard coding everything.

Data driven means values can be adjusted by modifying data. Examples.... When you want to print a new document, you don't modify the source code of your word processor to the contents you need, instead you have a document that you modify and print. When you want to manipulate a table of data, you don't build a specialized spreadsheet program with those specific values hard coded, you use a general purpose program that manipulates a chunk of data stored in a separate file. You don't distribute a specialized executable to display a web page, then another specialized executable for another web page, instead you have a program that loads data and takes actions based on the contents of the file.

The map is something that can be modified with data, it doesn't require the programmer to adjust arrays in the code. The attributes of objects can be modified with data, they don't require someone editing a .cpp file and changing a value. Adjusting the AI's interest level in doing something can be adjusted by a designer directly, and doesn't require a programmer to make the change, start a build, and deliver a new updated executable.

The point is not to worry about a specific data format, instead, data driven means to separate the data from the executable.

For some code, including prototype code designed to prove or disprove an experiment in a few hour's work, the values might be coded directly in. In certain contexts, like in code designed to be used once then thrown away, a non-data-driven system is acceptable. Also in certain old systems, like the very old games in consoles where memory was measured in bytes, it made sense to store values directly and in their minimal forms. In special cases like these having hard-coded values is a known exception that makes sense.

Thanks for all the information guys!

I'm making some tests with both XML and JSON to see which of them I like the most. I managed to implement XML in my game using TinyXML.

However, I'm having issues with JSON, I'm using RapidJson and I got some errors with their headers when parsing the file and reading it:

d:\sdl\include\rapidjson\reader.h(392): error C2228: left of '.Peek' must have class/struct/union

Does anyone know how to solve it? Maybe there's a better library for json?

d:\sdl\include\rapidjson\reader.h(392): error C2228: left of '.Peek' must have class/struct/union

Does anyone know how to solve it? Maybe there's a better library for json?

Sorry, not too familiar with RapidJSON, but as far as alternatives... perhaps you may like JsonCPP ?

d:\sdl\include\rapidjson\reader.h(392): error C2228: left of '.Peek' must have class/struct/union

Does anyone know how to solve it? Maybe there's a better library for json?

Sorry, not too familiar with RapidJSON, but as far as alternatives... perhaps you may like JsonCPP ?

JsonCPP is better! Could use it without a problem! I think I'll use JSON...it's easier to write than XML!

Thanks for the help guys! I really appreciate it!