11

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?

OmniOwl
  • 339
  • 3
  • 13
  • 3
    Welcome to the site. You have two questions here (generally you should ask only one question per post), and the second question about "how to get started" is considered off-topic, so I've edited it out, as well as pared the question down. If you want to have discussions about how to get started with something, consider visiting the [chat]. –  Jul 23 '13 at 14:24
  • @JoshPetrie But that was the most important one as I've been to many sites now and got no answer whatsoever. Not even a poke in a direction. There must be SOME people who got a bit of insight on these subjects. – OmniOwl Jul 23 '13 at 14:29
  • 1
    Also related: http://gamedev.stackexchange.com/questions/17331/game-engine-and-data-driven-design –  Jul 23 '13 at 14:29
  • 1
    Perhaps it's the most important to you, but it's off-topic here (see the [faq]). I could also have just closed the question. Visit the [chat] or an actual discussion forum like GDNet if you want to ask how-to-get-started questions. –  Jul 23 '13 at 14:30
  • @JoshPetrie I understand and I am thankful you didn't lock it. I've also read the question you linked there. But it didn't help me much. It just didn't help because it's still just theory rather than actual examples or code. I've read a lot of articles with theory and I am trying to find some concrete examples. Also I asked the question on gamedev but no answer so far. – OmniOwl Jul 23 '13 at 14:35
  • 1
    @Vipar Pop into chat if you want help with the off topic question. Not guaranteeing you will get help but a lot of smart people hang around there . – ClassicThunder Jul 23 '13 at 14:38
  • @ClassicThunder I will give that a try. Thanks for telling me. – OmniOwl Jul 23 '13 at 14:41
  • I don't see why it's necessary to put the question on hold, when it was answered. – OmniOwl Jul 24 '13 at 17:46

2 Answers2

11

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.

Roy T.
  • 10,208
  • 34
  • 56
  • Yes I forgot to mention the separation part. And this is exactly the kind of thing I'd like to see. I can only read so much theory. I need to see some concrete examples. Thank you. Will also have a look at the articles! – OmniOwl Jul 23 '13 at 14:38
  • Oh wait finally found the best explanation I read a while ago. Turned out that it was an answer on a question I asked here http://gamedev.stackexchange.com/questions/48971/when-where-to-update-components :D – Roy T. Jul 23 '13 at 21:50
4

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.