Is Domain Driven Design good for games?

Question

I've just read about Domain models and it enlightened me since I've been developing a game that has a class which only holds data (few behaviors/methods). I assigned the job of handling these classes to the managers...and now my manager seems to look like a God object. My game object that supposed to be handling the logic is just an anemic domain model.

My current design pattern is in Singleton and I want to do some recoding to get this stuff out. I've never seen a DDD on games (as of now) but is this a good approach? I'm just a novice programmer (inclined to game dev't) so I want to learn more about good architecture before the game gets too bloated for redesigning.

Answer 1

I'd never heard of domain driven design before your post. A quick look at a couple of references - here and here - seem to suggest that it's just a fancy name for the traditional 90s method of object-oriented programming that I was taught in university, where you try and write classes for each noun that appears in the situation you're trying to model with software, so that the structure of the software seems to follow the structure of the real-world concept.

As such, my answer to this is that it's not "good". It's usually a reasonable starting point but proves to be inadequate as you go along. You rarely have a single domain but several different domains within one piece of software - for example, you may have the domain of the game (the world, the characters, the items), the domain of the renderer (the shaders, the meshes, the materials), the domain of input (the filesystem, the network, the keyboard and mouse), and the problems come in where the domains overlap and influence each other. Often in the course of joining 2 domains together, you realise that there is actually a dependency there that requires a change, meaning one of your representations becomes more of a burden than a help.

A vague example might be a mathematics library on a console and your in-game characters. Your maths library will like to have a large list of data and then 1 instruction to perform on that list, to run efficiently. Your in-game characters will each have their own set of vertex data for rendering and animation etc. Now, how do you get a long list of all the vertex data from each of your characters to be able to handle it in one go? You could perform a slow copying operation, or instead you could refactor your characters so that their data is more amenable to being processed by the mathematics library - but then one of your domains is breaking down to favour another one.

Personally I am very wary of any label that resembles "Whatever-Driven-Design". Software is both too wide-ranging and too complex for there to be a one-size-fits-all approach to creating it. Instead, when trying to write the best software I can, I try and fall back on the SOLID principles. These give you a good idea of how good your code is, without promising a panacea of a method that you can follow and magically arrive at good code. Unfortunately, without such an attached methodology, it takes a lot of experience before you learn how to conform to these guidelines, which is probably why so many people like the methodologies.

Regarding your issue of having anaemic classes and manager objects, this is usually something that is covered in introductory object orientation lessons and doesn't really require you adhere to any special methodology to 'fix' it. (You might want to pick up a book on object oriented programming if you're just starting out.) A class is a coupling of state and behaviour, where the behaviour modifies that state, and this is called encapsulation. Generally you try and encapsulate as much as possible, which means that the state should be manipulated by the object itself (and only that object). Only for behaviour that cannot be modelled within the class would you delegate to an external class, such as a manager, which is why the existence of manager classes is often considered a sign of poorly-written object-oriented code.

My current design pattern is in Singleton and I want to do some recoding to get this stuff out.

I don't know what you mean by that line. A design pattern is a well-known way of writing a small part of your program. You wouldn't have a 'current' design pattern, nor would it shape the rest of your program. For beginners, these patterns are useful for getting you on the right track, whereas for experts they're more of a way to communicate about common code situations. One thing is important however: singletons are almost always a bad idea, and you should avoid them whenever possible. You can find many opinions about singletons on this site and over on Stack Overflow, but here is one practical question with answers that help you avoid needing them.

Answer 2

Paradigm

As of the time that this answer was written, the other posted answers here are all wrong.

Instead of asking whether or not Domain-Driven Design is good for games. You should ask whether or not "Domain Modeling" is good for games.

Is domain modeling good for games?

The answer is: sometime it's absolutely fabulous. However, if you're creating a real-time game such as a platformer or FPS or whatever (MANY MANY kinds of games) then no. It's not necessarily well suited for those systems. However, there may be systems within that those games in which implementing the domain model pattern is effective.

As others have mentioned here, component-entity frameworks tend to be very popular, and for good reason. However, in game-development culture there seems to be a distinct lack of layered architectures. Again, this is for good reason as most games that people are going to develop just mutate state on entities and let the emergent consequences be the game.

ALL SOFTWARE IS NOT THE SOFTWARE THAT YOU ARE WRITING. Some are quite different from others.

Some examples of domains in which domain modeling works well are card games, board games, and other types of systems that are event-driven.

Games that run at X frame rate with movement etc determined by time deltas as core domain concepts are probably not a great fit. In this case, our "domain" is often so simple that there's no need for domain modeling. Collision detection, spawning of new entities, influence of forces on existing entities etc tend to cover most gameplay.

However, as things become complex you do start to see developers implementing domain models within their entities to handle certain types of behavior and calculation.

Domain model pattern in game architectures

Your game engine (for example, Unity3D) is often component-entity oriented. In a platformer, you may have an entity for your character and its state is constantly mutated to update position etc.

However, in a more event-driven game, it's more likely that the component-entity framework's role is more to just exist as the User Interface. You end up with a layered architecture.

UI renders game state to the user. User interacts with the UI, triggering commands in the service layer. Service layer interacts with domain objects. Domain objects raised domain events. Event listeners hear the events and trigger changes in the UI.

UI > Service Layer > Domain Model

In short, end up with model-view-controller with a service layer implementation.

Using this architecture, you have a completely unit-testable game core (A rarity in game development culture, and it shows) with an event-driven interface.

Ok now, what is DDD?

Domain-Driven Design specifically is a culture / movement of emphasis on analytic patterns which are used to learn about the domain, so that you're actually building the right thing, and then implementation patterns that empower you to implement a model layer that represents the concepts in the domain model using your language's idiom. DDD comes out of a community that works with complicated domains and is always seeking for ways to manage high complexity in their applications by focusing on domain modeling.

DDD doesn't do so well if your goal is to just start coding, play around with the system and then figure out what you want to build later, etc. It assumes that there's more or less a domain in existence. So, if you have no idea what your game is going to be.. Then, it's not going to work.

Answer 3

No, I don't think DDD, or any other "buzzword" architecture is really good for games. With the possible exception of "component system", which seems really popular here.

When I hear questions and discussions like this, I'm reminded of this site. Pondering various architecture buzzwords will usually do you less good than actually designing and coding your own application.

Answer 4

Yes, but you should adapted.

When using DDD you will get modularity and single responsibility of each domain. But anything else just make things complex.

See my answer here