Data design game

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.

As he described, it seems to me that the application code i. 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 Example of tool approach I can think of is World Editor, which usually packaged along with Bliizard's games. 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 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. 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. 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.

In the end, there isn't a right or a wrong answer. It's a question of how you and your coworkers are comfortable working. When I wrote that blog a while back, there was a lot of talk about how all the work should be pushed to the designers, and I wanted to write about how plenty of successful game companies that I knew of found a different balance. Also, as a side note, my blog entry is 5 years old. It seems like a lot more studios are moving towards scripting languages and whatnot these days but are creating mature tools for debugging them, which was my main complaint.

When I had written this, I don't think Unreal Kismet existed, which I haven't used, but it seems like they are trying to simplify scripting and it apparently has a debugger.

No idea how well it works though. For smaller scale games, I definitely don't think you want to try and roll in a scripting language or similar functionality into your tech, but if you have a huge team and a lot of time to devote to technology, it's possible to do this right and the time investment may make sense depending on the way your development team likes to work.

You should look the BitSquid Tech Engine. It is build using DOD concepts. The blog of Niklas Frykholm is very interesting. There are many articles on how this engine is designed. Sign up to join this community. The best answers are voted up and rise to the top.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Game engine and data driven design Ask Question.

Asked 10 years, 4 months ago. Active 2 years, 11 months ago. Viewed 13k times. Improve this question. Amumu Amumu 1 1 gold badge 2 2 silver badges 5 5 bronze badges.

This is ignorant. Add a comment. Active Oldest Votes. For your specific questions: Is this true how a game engine should be? Improve this answer.

Perhaps many people do not notice this detail, including me, since for learning we mostly use automated build integrated in IDE like Netbeans or Eclipse such as Java. Location coordinates are stored as text values, so we can store coordinates for 3D games as []. Coordinates for 2D games can be stored as. In some games, locations will have a number of squares that are used to house structures or units.

A dimension can be simply number of squares in a 2D or 3D grid. It can be NULL when locations are predefined and players compete to occupy them. The structure table contains a list of all structures we can build at various game locations. Structures represent improvements that allow us to produce better units, perform new types of research, produce more resources, etc.

In most cases, there are requirements that must be met before players take certain actions. Maybe we need to complete a defined amount of research before we can build new structures or vice versa. The foreign key pair to this table forms its unique key.

This table also has two text attributes containing formulas with as parameter. We need them because we must define the resources spent in building each structure.

We also need to define resource production after upgrade, if structure generates any resources i. Research or technologies in games are usually requisite to the creation of other features. Research also can have its own requirements. Or perhaps players need to complete a certain level of research before they can start new research.

All of these requirements will be handled in this section. Below, we can find the data model for Research and Resources:. The research table contains a list of all possible research actions in our game. It uses the same logic as the structure table.

Resources like wood, ore, gems, and energy are mined or collected and used later to build structures and other improvements. Resources are used to produce units.

Units can be used to transport resources, attack other players, or in general pillaging and burning. We need to describe each unit with specific characteristics.

A list of all possible characteristics is stored in the characteristic dictionary. We will use only one attribute, value , to store the desired value. And now, the fun part. Production is fun, but moving units around and taking action is even better. Either units are stationed on a location or they are moving between locations. In addition, we need to define possible actions during movements. The number of the units of the same type within a group is defined in the number attribute. Each movement can transport resources from one location to another.

This field stores the amount of resources players move from the starting point to their destination. In most cases, players can call others to join their adventure. Each group can be assigned to an allied action only once, so foreign keys form the unique key of this table. This model gives us the basic structure needed to build an MMO strategy game.

It contains the most important game features: locations, structures, resources, research, and units. It also relates them, lets us define prerequisites in the database, and stores most of the game logic in the database as well. Almost every table has a unique key value, either a feature name or foreign key pair. How would you change this model? What do you like, and what would you do differently?