Hey guys!
I'd like to make this thread to dedicate what I learn about Data Driven Design (DDD for short) as I go along. This thread will also serve as a Questions thread to some of the, hopefully, more skilled people on these forums. It is done with the intention of learning and teaching at the same time.
I've written many applications in the past using Object Oriented Design (OOD for short). When I started looking into game programming it became apparent to me pretty fast that OOD just won't cut it. DDD is another way of making applications and it's a way I am not familiar with at all.
So I am starting from scratch trying to learn my way around DDD while making what I want.
My end-goal is to make a 2D Tile Engine, much the same as the one seen in A Link To The Past. Free Movement in all 8 directions, top-down, fighting and so on. This will take time and I am not going to become a wizard over night, I realize this.
So with that out of the way, lets start.
I've now read many articles on the subject of DDD. It seems that instead of using deep inheritance which discourages rapid change to the chain itself, you use Components and a flat structure which does not implement inheritance at all or at least, to a minimum. This is to reduce coupling and to make everything modular so you can plug-and-play what you want in the engine and game. You also focus on separating Logic from Data entirely. Finally you avoid hard-coding and also any game specific code so it's very reusable.
In my system I wanted to go for an Entity-System-Component (ESC for short) pattern. Every entity consist of component who each is just a bag of data. An Entity on it's own is nothing. Just an empty shell. No component have any behavior. The behavior is done in the Logic part since Components and Entities only act as Data.
For handling and managing entities and components there are Systems. Each System got it's own job and will be running Update() every frame. The EntitySystem will be making and removing entities. When an Entity is created it is given an ID expressed in an Integer. It also have all of it's Components given out to the respective ComponentSystems. Every frame of the game the EntitySystem calls Update() on all ComponentSystems which in return calls their Update() method as well, making everything update in a series rather than in a sequence (AAA, BBB, CCC instead of ABC,ABC,ABC).
Every Component implements the IComponent Interface so they can be grouped together in a List regardless of Component Type and every System implements the ISystem Interface so that the Update() method can be mandatory on all Systems should Expansion of the engine happen in the future.
Since this is a tile engine, some things will not be changed. There are Tiles which consists of a Vector2i for a Position and an Image which can be made into a Sprite at runtime seeing as Images can be saved while Textures in Sprites only exist temporarily. Levels consists of a 2D array of Tiles.
Here is a diagram of the design:
http://puu.sh/3KVcr.pngI would like to hear opinions on this approach.
