Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
I can say a popular design for games is a Component architecture. A new design that is getting some play at the bleeding edge of games engines is data oriented design (just means that how the data is placed in memory is the highest design concern really). But I can not speak to Domain Driven Design in video games.. so hence, just a comment. – James Oct 9 '11 at 18:06
Games are not business applications. Sound architecture in a business application (DDD/CQRS) is definitely not sound in a game, and visa-versa. Why not research the decorator model, or component model? Those are "good" for games and would alleviate your singleton problem - even in saying that, singletons are usually fine in games; especially if you are doing indie development. Concentrate on finishing something, else you will land up like me with a great architecture, but no game. – Jonathan Dickinson Oct 11 '11 at 14:27
Thanks for the suggestion. I'll read about Component design. I'll finish the game I'm working on even though it's design is not that good. I have a deadline this November lol. I've removed the concept of Singleton and I'm injecting modules to objects that need it. I guess that'll be enough for now but I need to learn more. – Sylpheed Oct 13 '11 at 12:34
up vote 9 down vote accepted

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.

share|improve this answer
Okay let me change the question a bit. Is there a difference between domain models and domain driven design? My idea about domain models is that a class should be able to handle itself without relying on a controller/manager as much as possible. My current design defeats this purpose. I may be misunderstanding something. So in an RPG game, my player class has its own domain and is composed of different domains like skills, items, etc. – Sylpheed Oct 10 '11 at 2:07
Yes, a class should be able to handle itself without relying on a controller/manager as much as possible, but that is nothing to do with domain models and is just a standard approach of object oriented programming. It's not clear what you might be misunderstanding because I don't know why you have these manager classes. – Kylotan Oct 10 '11 at 9:39
I don't see how to make my module working without a manager or a class that queries my object. For example, I have a module for quests. For me to access the right quest, I have to query from the manager. So how do I go over this without a manager? – Sylpheed Oct 13 '11 at 12:31
What is the 'right' quest? How does the manager know what is right? My guess is that the logic that makes such decisions draws on other objects to make them, and those other objects are better candidates for this functionality. – Kylotan Oct 13 '11 at 12:53
Well right now my manager is acting just like a repository after some cleanup. For example, I have 10 live quests. I'm accessing these quests through ID for easier retrieving. So my player has a component for quests (the manager) and I'll access the quest from there. It's still the player who is controlling what quest he can have. Is this a bad idea? – Sylpheed Oct 13 '11 at 18:07

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.

share|improve this answer
+1, it becomes a valid answer just adding a "No" at its beginning. – o0'. Oct 11 '11 at 9:21
(which I can't do due to the stupid "modify at least 6 characters" rule) – o0'. Oct 11 '11 at 9:22
@Lohoris maybe I should rephrase it like this... – Nevermind Oct 11 '11 at 11:55
+1 for "actually designing and coding your own application." those patterns are guidelines and thought provokers to me - nothing more. Changing a problem so that it fits into a solution is the wrong thing to do. – Jonathan Dickinson Oct 11 '11 at 14:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.