Design Patterns and Game Programming

Design Patterns is a complex subject. Maybe that’s why sometimes its concept and utilisation are misunderstood. In game development, for example, there are some myths about the usage of Patterns, and in this post I will try to break them apart.

Before starting, it’s important to understand what are the Design Patterns and how this concept appeared.

Design Patterns is a catalog of good practices, usually used to solve a specific problem in software development. That means, if you have a problem to solve… maybe someone else already had solved it in a good way?

The patterns, contrary to what most people may think, where not “created by a single person”. It happens that a team of researchers made an extensive analysis over existing code and came with the first catalog of patterns, based on 23 general reusable solutions to commonly occurring problems in software. The results of this research generated this book (first published in 1995).

A pattern’s catalog includes its name, other names which is also known, the problem which applies, implications of its usage and source-code examples, among other information.

Finally, there are many patterns beyond these 23 generic ones, focused or not on a specific platform (web, mobile, games, etc.).

That being said, let’s see the myths about their usage in game programming and why they are wrong:

1- Design Patterns are not used in game development

This is perhaps the most absurd of all. Any good framework you’ll use contains a big amount of patterns, and certainly you will have to learn them to use the framework or extend its functionality. Even the most simple “add component” in Entity Component Systems (like Unity) is based on a Design Pattern.

Focusing only in the game code you develop nowadays (not considering frameworks or libraries), if patterns are not being used while defining the architecture, one of those three things might been happening:

  1. The programmer may be coding an existing pattern without knowing, and reinvented the wheel (maybe not in the best way).
  2. The programmer is using an Anti-Pattern, a bad solution for a problem (which is also a common practice).
  3. The programmer is using a pattern which was not recognised yet.

If we don’t consider the last case (let’s face it, it’s highly unlikely to happen due to the amount of cataloged patterns), one of two things is happening: either the programmer is defining the architecture using Design Patterns or Anti-Patterns (that means, a good or bad architecture).

2- The use of Patterns makes the code unclear and difficult to be maintained

This is not true according to one of the main purposes of using the patterns: to make it easier for other programmers to know what you did only by knowing which patterns where used in the solution.

An example would be, if a programmer puts his hand on a code and finds a class called Observer (or Listener, or Delegate, names which this pattern is also known). The programmer should be able not only to recognise what is the purpose of the class but also have an idea of how it was implemented.

What can happen sometimes is, the programmer may not have the concept of the pattern and really doesn’t understand what was done, taking more time to make changes in the code (of course). But this fact alone shouldn’t be a reason for not using Design Patterns.

In the end, a Junior programmer will take the time of a Junior to make changes. It doesn’t matter if the code is using patterns or not. As for Seniors, it’s much worse to put the hands on a code with bad structure than a good one.

Some could say that using patterns requires the gameplay logic to be distributed in many classes, which increases the complexity of the code, which is also not true. When the logic is well distributed in classes (e.g. each one with a specific responsibility), it’s much easier to be maintained than a code made with the famous Anti-Pattern God Object (everything in just one class) and Ravioli Code (lots of small and distributed code).

Finally, as more complex the problem, more patterns need to be used to create a solution. That means, the architecture may be difficult to be understood, but it’s related to the complexity of the problem itself. For such cases, this is the recommended technique: documentation.

3- Using Patterns means losing performance

Not always. Each pattern has its “side effects”, but usually they are related with the architecture itself (cohesion, coupling, etc.), not with performance issues.

It’s important to notice that Architecture and Algorithms are not the same. An algorithm usually have a higher probability to create performance issues than using a Design Pattern.

Patterns are usually used to achieve: (1) a standard and well-tested solution for a problem and (2) to get to a desired level of code flexibility. But it happens that one could also use the patterns to implement algorithms in an elegant way (why not). An example would be to use the Strategy pattern along with the A-Star algorithm, to be able to change its heuristic function at runtime.

Another affirmation I’ve heard is about the usage of POO mechanisms itself (classes, inheritance, etc.) can cause bad performance due to the amount of additional processing. Given the current state of compilers and devices’ capacity of processing, I would say the “impact” in this case is almost zero. For me, not using these features would be the same as not using Generic Programming when provided by the language, for example.

4- Not all Patterns are used for game development

Excluding the fact this is not a good reason for not using patterns, it sounds like a lazy excuse for not learning about them.

The thing is, each pattern solves a problem. You may never had to solve a specific problem because you don’t develop certain feature. A game developer may never have to use a pattern for a recurrent web-related problem for example.

But today, the games (as any other kind of software) are getting more and more complex. When developing a game which is a bit more complex than Flappy Bird, the final product will probably have extra layers for things like multiplayer, monetisation, analytics, social media and lots of other meta-game features.

One thing is clear: if you know the patterns and what problem(s) they solve, the chances for you to think out of the box and find a fast/nice solution are much higher.


During my time as both Programmer and Lead Developer, it was clear that using Design Patterns during the architecture definition brought many benefits during the project and when maintaining it.

For proving each of my points true, it would be needed a lot of examples and discussion. Maybe it would be enough material to create a book!

Anyways, I find this subject really interesting. If you have comments and suggestions, please post a comment.

2 thoughts to “Design Patterns and Game Programming”

  1. Hi Leonardo, nice article!

    I agree with the things you mentioned here and would like to put my two cents:

    1 – Maybe design patterns were not used in gamedev a long time ago, and the same was true regarding OOP. But they are here for some time now — really, when was the last time you worked on a non-OOP project? I’ve seen/written a few non-OOP code but they were rare, optimization stuff and very platform-specific.

    2 – If there is a junior in the team that is still learning design patterns, my suggestion is to have a senior help him/her. Unfortunately I have seen the opposite (but fortunately only once): a so-called senior would refactor some code to patterns and leave code written by the junior untouched (i.e. broken). In that case, it would be best to have both developers talk and refactor the code together.

    3 – Everybody should follow Knuth, no premature optimization. No performance guesses as well – just profile and check where the bottleneck is.
    Also set a minimum performance threshold versus development speed/maintenance.

    4 – For this topic, I think the following warning is valid: don’t go bananas with patterns if you don’t have to (99% of the time, you don’t hehe). Some folks get crazy and try to apply all GoF patterns in one project when all they needed was a couple of if’s (ok, very extreme and stupid example, but you get the point, right…)

    For more on this topic, I suggest Nystrom’s book

    Thanks for sharing your thoughts with us! Looking forward to read more!

Leave a Reply

Your email address will not be published. Required fields are marked *