Game engine and data driven design [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I've heard about data driven design and have been researching about it for a while. So, I've read several articles to get the concepts.

One of the article is Data Driven Design written by Kyle Wilson. As he described, it seems to me that the application code (i.e. the code for controlling resources such as memory, network...) and the game logic code should be separated, and the game logic code should be driven by external data sources. At this point, I can imagine that the developer would write some sort of game editor which accepts external data about in-game objects (such as character information, weapon information, map information...). The scenario design will be scripted by custom language/tool written by programmer to let the game designer create interaction between in game objects. The game designer will either use an existing/custom scripting language to write sc开发者_开发知识库ript for the game, or drag and drop tool to create game world. Example of tool approach I can think of is World Editor, which usually packaged along with Bliizard's games.

However, another article is against the use of Data Driven Design, The Case Against Data Driven Design. The author suggests to not let the game design driven by data, because it would take more time to develop a game, since the game designer has the burden of programming. Instead, there will be a game programmer to program the game freely from the sketch design, and is verified by the game designer after the game programming is finished. He calls this is programmer driven. What I think of this method is similar to the way I used to do: The game logic is the application itself, as apposed to the above idea, the application is the game editor, and the actual game is designed based on the tool.

To me, the first method seems to be more reasonable, since game components can be reused for many projects. With the second method which opposes data driven design, the game code belongs to that game only. This is why I think Warcraft has so many game genres in it, such as the original Warcraft and various custom maps, and one of the most famous: DOTA which actually defines a new genre. For this reason, I heard people call the World Editor is the game engine. Is this true how a game engine should be?

So, after all of this, I just want to verify that is there any flaw in my understanding about these ideas (data driven, programmer drive, scripting etc...)?

---

There will be different opinions, people prefer different approaches. There isn't a right one. You understand the approaches correct.

My defenition for Game Engine will be: - Runtime library with different managers like you saying resources, memory, networking - Tools (Editor, converters, packaging tools, etc.)

On top of the engine you can write applications or games. In some engines these are called MODs but I don't like this definition.

A good way to think of data driver approach is to imagine your engine being the executable project (it doesn't have to be but just bear with me). Then you can write some extra library that loads dynamically like plugin and then you pass to it some configuration. It can be a big package of scripts, sounds, models, textures. It can be a small script or some fixed folder structure with assets. It doesn't matter what it is the important thing here is that it's swappable. This is your data that the engine works with.

A programming driven approach is when you have your final application/game being the executable. Then you can still use engine a core library of managers, you can use middleware. Different levels can be loaded from resources. But the scope of the game will be probably hardcoded in this application.

None of the above has to be the way I suggest. You can mix and match as much as you want from both approaches as long as it fits your needs. The data driven approach by default has to take more time to build a game with. But at the end you should have more reusable software. Also usually games are very design driven. Programmers we like to make everything to be logic, physically correct, etc. but usually it doesn't make fun game. Designers usually want to iterate, try different mechanics, tweak some properties, etc. That is a lot of extra work for a programmer if you are using programming approach.

You should weight the pros and cons depending of your needs and time budget.

Edit: Designers and programmers will be needed in any of the possible approaches. There might be a slight offset in work distribution as percentage, but it won't be a lot.

The biggest benefit of data driven engine is once it is up and running, which takes a tremendous effort, it will be faster and more reliable to work with it. It should be faster to make changes since no recompile is needed. Data bugs usually can be intercepted much better and avoid crashing or restarting the application.

Probably the biggest problem with data driven engine is that all the good things about it come to a price. Usually there is performance and memory footprint hit.