So in continuation from my last post I was confronted with what seemed to be my problem with this methodology.
Your problem appears to be that you are suffering from design paralysis because you're trying to take in the entire scope of everything that could be considered data-driven design at all once, including complete existing implementations, so you can rebuild it yourself. This is bound to result in frustration and failure. You need to start small, and build systems that you need for your games. Reading other people's code can be interesting, but often lacking in a lot of critical detail about the why of various decisions that can easily lead you astray.
You can read Josh's entire comment in the thread.
I looked over what I wanted to do and is now trying to split it into very small bites and take it a step at a time.
I was advised to look at parsing XML or JSON but I wanted to try something else first as I like visuals. Parsing, in my experience, is not that hard.
So I started designing a flat hierarchy structure which seems to be common for DDD software. From what I understand this design below should follow the philosophy of DDD.
The system is build up of Entities which consist of Components, each defining a behaviour or attribute that the entity can have. So an entity is defined by it's components and is otherwise an empty shell without behaviour or attributes.
Each Entity got an ID specified by a simple Int. Might change in the future of course. The ID is given when the Entity is born. It got a list of Components which is done by making a list that contains objects which implements IComponent. Every component will implement IComponent and if in the future every single Component needs a certain behaviour or attribute it can be implemented via the Interface.
In this case, since I want to just render a sprite on screen, I've made two component classes. The SpriteComponent and the MovementComponent. They don't contain any logic whatsoever only fields.
They both use objects from the SFML Framework which is also shown in this picture.
My goal this time around is simply to render a sprite on screen given X,Y Coordinates.
Am I on the right track?
Would you suggest different naming given what I want to achieve above?
The reason I called it "MovementComponent" is because I want it to signal that this entity can move from A to B, rather than PositionComponent which would indicate that it's stationary. (At least that's what I think, correct me if you feel it's backwards).
Now to handle Components and Entities I use Managers. Some seems to call them Systems, but if I understand it correctly it simply comes down to preference as they do the same thing.
In DDD you want to update things in pairs rather than in sequence. So instead of doing ABC, ABC, ABC which will have a horrible impact on performance, you do AAA, BBB, CCC and so on.
So for every component type you need a ComponentManager. The following design should illustrate it.
The EntityMgr holds a reference to one of each Component Manager which in turn will hold every single component of their type. They all implement the IManager Interface since they will all need their implementation of the Update() Method. So if in the future you want to extend the engine with more managers and component types this should be easy to follow.
The EntityMgr also creates entities and gives them an ID. The EntityMgr can also remove an entity and all of it's components when we don't need the entity any more. When Create is called it's supposed to put the components in their rightful manager. I am still debating the idea whether an Entity will just be there so that I can assemble it and its components from it's ID or if I should keep a reference for every single Entity in the EntityMgr.
Am I on the right track? And if so:
Which do you think would be the smartest in this case?
This could turn into a series of threads where I get from zero to hero
Edited by vipar, 24 July 2013 - 10:00 AM.