What is data-driven design? [closed]

Question

I've been reading up on a lot of articles covering data driven design for games. It seems to come down to:

• No hard coding
• No game-specific code in the engine
• Scripting for AI, cutscenes, et cetera.
• Generalizing code for reusability
• Component design
• Modularity
• Low coupling
• Editors (for data, maps, scripts)
• External data retrieval
• Constants kept in text files (.ini or otherwise)
• Expose data through editors for scripting and manipulation by designers

Now, my question is, is this understanding correct?

Answer 1

I'd say this is not correct. I believe the most important idea in data driven design is separating your data from what modifies (or updates) the data.

So going from a standard OO deep hierarchy like this:

class MyCreature{
     vector position;
     void update(){ position += 1; }
}

to a separate state and system

class CreatureState{
    vector postion;
}

class MovementSystem{
    list<CreatureState> states;
    void update() {
        for each CreatureState state in states {
            state.position += 1;
        }
}

On of the most influential DDD paradigms at this moment are Entity Systems. Some nice resources to look up are:

http://gamedevrubberduck.wordpress.com/2012/12/26/a-hybrid-entity-system-component-architecture/

http://entity-systems.wikidot.com/

Of course as with all paradigms/ideas there isn't an exact definition and not everybody understands the same idea when talking DDD but this is what I believe the most important thing.

Answer 2

I think you are overcomplicating the definition. Certainly, many of the principles contained in your bulleted list of points are good ones from a software engineering perspective, but they aren't all necessarily part of the definition of "data-driven." Many of them have some overlap, or are best implemented using a data-driven approach, but don't constitute the act of data-driving something.

The actual definition of data-driven software development is generally fairly simple: a program performs actions mainly based on some outside information (a piece of level data, script data, et cetera) instead of having a series of predefined and fixed steps within the code itself that determine control flow.