architecture - Game engine and data driven design

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 script 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...)?

Answer

Making your game (or any software product) data driven is almost always a benefit. The only real con is that you may spend slightly more time building the relevant systems up front; it will pay off over the rest of your career as a programmer though (even if you don't reuse those same systems for that entire time, you'll reuse the techniques you employed to build them).

The challenge, and where the disconnect in those two articles you linked comes in to play, is what you elect to put in data and who you elect to give access to that data. Fundamentally, data driven design and development just means that you put information in external storage, load that information at run time, and act on it. Your application code does what that external data tells it to, rather than you writing application code that directly does what you think the end result should be. It's not a complex idea.

You don't have to build complex "component driven architectures" (as is the fad these days). Putting constants for tweaking physics (gravitational force, restitution coefficients) in a text file is data driven. Scripts (in Lua or something else) are data driven. Describing your level data in XML. Anything like that.

You can drive just about any component of software with data, and you can pick and choose which ones you want to do so with. Developer time is expensive; programmer time especially so. If you can save you or other programmers time by putting behavior and data in external storage and not requiring the game to be recompiled for every little change, you should. You'll save money and get things done faster.

Furthermore, you run a huge risk in attempting to make "designers design" and having programmers "make those designs a reality," forcing a programmer to exist in the iteration loop for a designer's job: you run the risk of making the programmer feel like he is just a code monkey, making trivial little tweaks for the design constantly. This can be massively demoralizing for a large majority of programmers, who want to work on interesting technical challenges and not on being a designer's proxy.

For your specific questions:

Is this true how a game engine should be?

A "game engine" doesn't really have a fixed definition. Generally it's the unified collection of underlying technology used to make a game, usually supported by a bunch of related tools (and thus quite data driven). But it varies fairly widely from context to context.

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...)?

You seem to be more or less on the right course, although you're perhaps over-complicating what data driven design and development is by conflating it with component-based systems.