I'm working on a realtime multiplayer game project.
There are entities like Player, Game, Flag etc.
And bunch of it's behaviours like
PlayerRespawnBehaviour, PlayerWalkBehaviour, PlayerLifeBehaviour, GameGoalBehaviour
Over 60 behaviours…
However it's get to level that very hard to break new features into part and let another developer handle the development without know every each behaviours doing.
So I currently consider adopt DDD. Take parts of DDD technique by separate the concern of game features instead of domains? (without having much layers, mutiple machines as DDD)
I'm sure there will be lot of sub-domains which will separate by each feature.
Goals here are
- Prevent behaviour references each others in the bad ways.
- Introduce new features to new developer who just jump in.
But I'm not sure that it'll cause problem if I do need too much numbers of integration between sub-modules.
So is it a good practices?
Does any one experiences this pro & cons?
Best Answer
I would not use DDD for this. The point of DDD is to organize code into discrete and non-reusable parts to ensure reliability and predictability.
For your game to be modified and have new features added, being able to reuse entities would help greatly. Adding new features is more important for a game than ensuring absolute reliability.
In DDD, you often purposely develop an anemic domain model; an anemic domain model would be disastrous for the development time of most games.
In short, a game would be the last place I would use DDD.
However, that does not mean you cannot take some of DDD's principals and leverage them, it's not all or nothing.
For example, the registration process would be a candidate for being a completely different domain than the game itself.
The best way to stop behaviors from interfering with each other is to reduce coupling and use interfaces when possible; this can be done in more ways than just DDD.