What are some programming design patterns that are useful in game development? [closed]

Question

I have a few books on Design Patterns, and have read some articles, but cannot intuitively figure out which programming design patterns would be useful in game development.

For example, I have a book called ActionScript 3 with Design Patterns that details several design patterns such as Model View Controller, Singleton, Factory, Command, etc.

As someone new to this, I cannot figure out which of these would be useful, or in fact if any of these are the design patterns I should be learning and trying to use. Perhaps there are other, more game-programming-specific design patterns that I am not even aware of?

If you have experience using a certain design pattern in game development, I'd love to hear it. Reasoning as to why it was used, code samples, or online resources would all be very helpful as well if you have them. I am at the moment most interested in ActionScript 3 and C++ implementations, but could definitely benefit from experience and examples from any language.

Thanks!

Answer 1

Now for a less flippant response, with some suggestions. Don't take these as implementation recommendations, more as examples of possible use.

• Builder: set up component-based entity one component at a time, based on data
• Factory Method: create NPCs or GUI widgets based on a string read from a file
• Prototype: store one generic 'Elf' character with initial properties and create Elf instances by cloning it.
• Singleton: this space deliberately left blank.
• Adapter: incorporate an optional 3rd party library by wrapping it in a layer that looks like your existing code. Very useful with DLLs.
• Composite: make a scene graph of renderable objects, or make a GUI out of a tree of Widgets
• Facade: simplify complex 3rd party libraries by providing a simpler interface to make your life easier later.
• Flyweight: store the shared aspects of an NPC (eg. models, textures, animations) separately from the individual aspects (eg. position, health) in a mostly transparent way
• Proxy: Create small classes on a client that represent larger, more complex classes on a server, and forward requests via the network.
• Chain of responsibility: handle input as a chain of handlers, eg. global keys (eg. for screen shots), then the GUI (eg. in case a text box is focused or a menu is up), then the game (eg. for moving a character)
• Command: encapsulate game functionality as commands which can be typed into a console, stored and replayed, or even scripted to help test the game
• Mediator: implement game entities as a small mediator class that operates on different components (eg. reading from the health component in order to pass the data to the AI component)
• Observer: have the renderable representation of a character listen to events from the logical representation, in order to change the visual presentation when necessary without the game logic needing to know anything about rendering code
• State: store NPC AI as one of several states, eg. Attacking, Wandering, Fleeing. Each can have its own update() method and whatever other data it needs (eg. storing which character it is attacking or fleeing from, the area in which it is wandering, etc.)
• Strategy: switch between different heuristics for your A* search, depending on what sort of terrain you're in, or perhaps even to use the same A* framework to do both pathfinding and more generic planning
• Template method: set up a generic 'combat' routine, with various hook functions to handle each step, eg. decrement ammo, calculate hit chance, resolve hit or miss, calculate damage, and each type of attack skill will implement the methods in their own specific way

Some patterns left out due to lack of inspiration.

Answer 2

I wrote a book on exactly that topic: Game Programming Patterns. The chapters that are there might be helpful for you.

Answer 3

One thing Brandon Eich had the good sense to bring up in Coders at Work is that patterns are hacks and workarounds: [Patterns] show some kind of defect in the language. These patterns are not free. There's no free lunch. So we should be looking for evolution in the language that adds the right bits.

As game programmers rather than compiler designers we rarely get the option to evolve the languages we use, but we can learn to evolve our own style to better fit our language and requirements. Patterns are some of this, but not using patterns is another part, especially since as Brandon says, patterns rarely go without a notable performance or memory or code agility cost. MVC just is not a great pattern for many things in games. Singleton is a workaround for lame C++ static initialization rules, and you probably shouldn't be doing those anyway. Factory simplifies complicated object creation - maybe your objects should just be simpler to start with. The popular patterns are tools to resort to when we need them to manage something complex, not tools we should be longing to use to build something complex at the start.

Good (game) code might use patterns, or it might not. If it does use patterns, fine - they're a great communication tool to explain code structure to other programmers at a high, language-independent level. If you think the code is better without using a pattern, don't beat yourself up over it - it probably is.

Answer 4

Of course, as others have said, all patterns are useful in the right circumstances, and part of learning how to use them is learning when to use them. However, the excellent book Core Techniques and Algorithms in Game Programming by Daniel Sanchez-Crespo Dalmau, lists six programming patterns and six usability patterns as especially useful in game programming.

Programming:

• Singleton: I don't hate this one like many people do; it can be used for things like the single-player player or the keyboard reader.
• Factory: Lets you create and destroy objects efficiently.
• Strategy: Lets you change out AI strategies elegantly.
• Spatial Index: Helps perform queries on spatial data sets.
• Composite: Sets up a useful object heirarchy.
• Flyweight: Frees memory by genericizing things like identical enemies.

Usability:

• Shield: Protects from accidental activation of dramatic actions.
• State: Visual cues of the world/UI status.
• Automatic Mode Cancellation: Makes the game work more intutitively.
• Magnetism: Autoaiming and easy unit selection.
• Focus: Eliminating distracting UI elements.
• Progress: Universally useful.

The book, of course, goes into more detail on each of these.

Answer 5

Entity systems are a nice kind of pattern. It's not exactly a design pattern since it's not strickly OOP. However you can mix it with OOP.

Some good links (start from top for intro):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

Answer 6

All of them. Except Singleton. [/flippancy]

Answer 7

The curiously recurring template pattern can be really useful for avoiding virtual methods and the performance penalty that can come from the virtual function calls.

This can be the appropriate pattern when you don't actually need to have a container of the base class type which has the interface you're after, but you'd like to have similarly named behaviors and interfaces.

For example you can use this when compiling classes for multiple platforms or engines (dx vs. opengl) where the variance of type is known at compile time.

Answer 8

Not really about patterns, but about basic principles behind them. In "Design Patterns: Elements of Reusable Object-Oriented Software" (1995), the gang of four (Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides) recommends only two principles for object oriented design: (1) program to an interface and not to an implementation and (2) favor object composition over class inheritance.

These 2 principles are very helpful in many tasks of game development. For example, many game programmers have used a deep class hierarchy to represent game entities. There is another approach based on composition - component-based game objects. Article about this approach. Even more links. It is a Decorator pattern example.

Answer 9

A design pattern that I evolved over the course of many years, and which has been spectacularly useful to me, is something I refer to as "brokered definition sets"; how to summarize it in GOF terms appears to be controversial, but this question I wrote about it on StackOverflow goes into some detail about it.

The core concept is that some property of a model, like the species of a creature, is set up so that each possible value for the property has a corresponding definition object -- a single, shared object per value -- that specifies its behavior, and these are accessed through a central broker (which, GOF-wise, may be a Registry, a Factory, or both). In my usage, they're also generally accessed via scalar keys, to facilitate weak binding for runtime morphism purposes.