I'm using a hybrid of DDD (domain-driven development) and an entity-component system. That is to say:
- I have an
Entityclass with a list of
Components, and the ability to add/remove/get components
- I have
HealthComponent(health and is-alive),
DrawComponent(position + display), etc.
DrawSystem) that find a bunch of components and operate on them
I also have "domain objects" like
Monster, which subclass Entity. Their constructors usually add a bunch of components.
Since I'm a fan of the DDD idea of objects represent business/game entities, I model my classes around that. For a roguelike, my
Player class has methods like:
GetY(delegates to the position component)
- And others
It seems to me that the components are a white-box internal detail; they shouldn't be known to any outside objects. In fact, domain objects should operate on other domain objects (eg.
Most (if not all) of my actual game code operates on entities, not components. My tests usually do something like:
- Create an entity
- Grab a certain component
- Verify that it meets expectations
In general, this raised a question in my mind: isn't this a violation of encapsulation? Aren't components just an internal implementation detail of entities (that could change or disappear at any time)?
On the other hand, I have a lot of delegation, which seems useless (like
Player.getX() is just
This seems confusing. Can someone provide some clarity? What is the right mix of DDD, encapsulation, and entity/component composition?