Domain Driven Design approach for game

Question

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

1. Prevent behaviour references each others in the bad ways.
2. 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?

Answer 1

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.

Answer 2

After working on the project so hard. Do not think about fully DDD.

But adapted DDD work very well.

First, If we think of it carefully, We pick only some parts from DDD. By bounding a domain. This make every domain single responsibility.

I think of DDD a mindset to design domains and states.

Here are some domains example:

• Player
• Game
• Flag

So we separate it's bounded context.

• FlagCapture BC may have

  • PlayerFlagCapture
  • FlagCapture

• Life BC

  • PlayerLife

• HealthPoint BC

  • PlayerHealthPoint

Now adapted CQRS, We apply event to every changes and cutout the command part.

Because reason to have events in CQRS is about tracking any single changes of domains. And reason to have command in CQRS is about communicating between micro-services.

Then we add cross-aggregates logics by having EventHandlers.

And don't make your architecture thick. I've no adapter to communicate between BC. Only interface if needed.

Also, No infrastructures, No repositories, No services, No application layer and no actual ID inside a domain because all domain will be embedded to a single GameObject/GameEntity which will have shared ID.

By doing this we gain a lot benefits from adapted DDD & CQRS.

• Replay all the gameplay.
• Sync state when new device joined between the game.
• Very high modularity.

---

I'will update later after I've done my project.

---

UPDATE:

Currently, I'm working on ECS architecture instead of approaching on DDD first.

ECS decoupled almost everything and you can let anyone in teams working on any system independently.

As the answer said, Game would be the last place to use DDD, DDD is better at multiple distributions on micro-services, Without too frequent interaction between domains.

Answer 3

Can't comment because of rep.

First off, DDD is anti-anemic models. Entities should be rich with logic and the main place to describe your system.

On a side note: I've seen a huge push for anemic models because of functional programming taking over a lot of mainstream stuff. Is this good for games? Maybe. Look at Pure Functions by Mr. Carmack for a taste of some of it.

But back to DDD. You'd only be able to communicate with other entities through Domain Events, so this makes most of your game logic decoupled into many event handlers. The reason why I say many is because your entities (being specifically game entities - player, monster, item, etc.) are all going to need each other to carry out typical game operations (ex: hit player w/ monster, player pickup item, etc.). I think this might be a bit too much for maintainability. You could argue that components do the same, but in a more reuseable way.

I've only built puzzle games using a DDD approach and it worked great since the pieces didn't have many behaviors. But I wouldn't use it to make something like Minecraft, Terraria, or whatever.

The important thing to remember is separate your code using SRP and unit test as much as you can. Separate your logic from your view to make unit testing fast and easy. You'll end up with an architecture for your specific needs.