Introduction to Software Design Patterns for Game Devs

Introduction

Software Design Pattern – A general, reusable solution to a commonly occurring problem within a given context in software design.

The entire goal of game development, and software development in general, is to solve problems. The process of producing a game is basically solving a series of problems. If you’re good at solving those problems, you’ll end up with a fun, playable game. There is no shortage of problems, and that’s the reason software design patterns are so valuable. Software design patterns are templates for how to solve a commonly occurring type of software development problem. They provide templates for solutions which you can apply to your own specific context in your code. Like the system that is managing your game state, or the instantiation system you need to spawn the legion of minions spewing forth from the depths of hell.

Design patterns are not concrete implementations in code. You can’t just copy & paste them into your codebase to solve your problem like a cheat-code. They’re more like Pro-Tips: giving you effective strategies to handle difficult bosses. Just like trying to defeat a difficult boss, once you understand the patterns that works against it, and learn to recognize the situations in which those patterns can be applied, you’ll have a much easier time getting through that fight. Software design patterns are the proven strategies that you can use to defeat those Cyberdemons in your code!

And just like pro-tips, software design patterns can be trusted! They’ve been around for a long time. The definitive book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software, was first released in the early 90’s, which is almost the dawn of time in software development terms. The most well known design patterns have been thoroughly critiqued, and tested over the years. There are a wealth of resources you can access to learn more about, and see example implementations of all the design patterns.

What Is A Software Design Pattern?

A design pattern names, and generally explains a solution that addresses a recurring design problem in object-oriented systems. It describes a design problem, the solution, when to apply that solution, and the consequences of that solution. Object-oriented design patterns typically show interactions between classes or objects, without specifying the final application classes or objects involved. They are not specific implementations, although many discussions of design patterns will be accompanied by implementation hints and examples.

Design patterns are language agnostic, and the pattern of object interaction that they describe can be coded into any language. That being said, the applicability of design patterns will vary from language to language because the problems you encounter will slightly vary from language to language. Some languages come with data structures and/or standard library methods that may solve a problem that is addressed by a design pattern.

Design patterns can speed up the development process by providing proven, tested development approaches. Designing efficient, effective software requires either the ability, or the experience to be able to consider issues that may not be visible until later in the implementation. It’s not impossible to come up with your own solutions to the types of problems that design patterns solve without using design patterns. But it will likely take you many, many more iterations of development on that solution to work out all of the subtle bugs and edge cases that are already solved by using the design pattern. Save yourself time and pain by using the design pattern!

Using design patterns also helps improve your code readability for developers who are familiar with these patterns. Design patterns are a kind of common language that we can use as software developers. Once you learn the patterns, you will see them frequently in the software you work with, and you can use them to communicate your design ideas to your fellow developers.

Structure of a Design Pattern

As we’ve covered, design patterns are descriptions of how to solve problems. Commonly, most design documentation contains the following elements:

• The context in which the design pattern is used
• The forces in the context that the pattern resolves
• The suggested solution

There isn’t a single, standard format for documenting design patterns. Different authors have come up with different ways to document design patterns. However, despite the lack of an agreed upon standard, certain pattern forms have become more well-known than others, and these well-known patterns end up becoming the basis for new patterns. One example of this is the documentation format that is used by the Gang of Four in their book. It’s a well known, and thorough format that contains the following sections:

• Pattern Name and Classification: A descriptive name that identifies the pattern.
• Intent: The goal or reason for using a pattern.
• Also Known As: Alternative names for referring to a pattern.
• Motivation: A scenario consisting of a problem and a context in which this pattern can be used.
• Applicability: Situations in which this pattern is useable.
• Structure: A graphical representation of the pattern (Class Diagrams and Interaction Diagrams)
• Participants: A listing of the classes and objects used in the pattern and their roles.
• Collaboration: A description of how classes and objects used in the pattern interact with one another.
• Consequences: A description of the results, side effects, and trade offs that come from using the pattern.
• Implementation: A description of an implementation of the pattern.
• Sample Code: An illustration of how the pattern can be used in a programming language.
• Known Uses: Examples of real usages of the pattern.
• Related Patterns: Other patterns that have some relationship with the pattern/a discussion of the differences between this pattern and other similar patterns.

As mentioned, depending on the source, not all design pattern documentation will contain all of that information, presented under those headings. But the list does give you good insight into the kinds of things you should be thinking about when analyzing a design pattern.

How Many Design Patterns Are There?

The original Gang of Four book covered 23 different design patterns. These 23 are the fundamental design patterns, and as long as you’re familiar with them, you can hold your own in any discussion of design patterns. Since then, many different authors have put forward many other design patterns, and domain-specific patterns have emerged to solve problems in specific domains such as user interface, secure design, web design, and others. Keeping in mind that at their core design patterns are simply reusable solutions that can be applied to solving a common problem, it’s not surprising that you can find a lot of different design patterns for different domains out in the wild.

Furthermore, new design patterns are being invented and put forward by authors all the time. Some of these patterns gain traction and widespread acceptance in software development. Others find initial success, but are then abandoned. The general lifecycle of a design pattern can be summed up in the following stages:

1. Author writes about design pattern in a book.
2. Book becomes well read, possibly best seller.
3. Design pattern enters public consciousness, and begins to gain mindshare.
4. The design pattern gets used. It works well. The design pattern gets more mindshare.
5. The design pattern becomes a silver bullet to fix all problems, and starts to get overused.
6. A different author writes “Design Pattern Considered Harmful”.
7. Design pattern becomes Anti-Pattern.

Design Pattern Categories

Design patterns are categorized based on the kind of problems they solve. Design patterns are grouped into three broad categories: Creational Design Patterns, Structural Design Patterns, and Behavioral Design Patterns.

Creational Design Patterns

Creational design patterns are concerned with the way things are created in our code. They provide solutions to problems related to the instantiation of objects. Creational patterns provide the capability to create objects in a controlled way based on required criteria. The category can be further subdivided into class-creation and object-creation patterns. Class-creation patterns use inheritance in the instantiation process, while object-creation patterns use delegation effectively to get the job done. Creational design patterns include:

• Abstract Factory: Creates an instance of several families of classes.
• Builder: Separates object construction from it’s representation.
• Factory Method: Creates an instance of several derived classes.
• Object Pool: Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.
• Prototype: A fully initialized instance to be copied or cloned.
• Singleton: A class of which only a single instance can exist.

Structural Design Patterns

Structural design patterns are all about Class and Object composition. They provide you with way of organizing different classes and objects to form larger structures and provide new functionality. Structural design patterns include:

• Adapter: Match interfaces of different classes:
• Bridge: Separates an object’s interface from its implementation.
• Composite: A tree structure of simple and composite objects.
• Decorator: Add responsibilities to objects dynamically.
• Facade: A single class that represents an entire subsystem.
• Flyweight: A fine-grained instance used for efficient sharing.
• Proxy: An object representing another object.

Behavioral Design Patterns

Behavioral design patterns are focused on the way our classes communicate. They identify common communication patterns between objects and present patterns on how to structure you communication between your objects. Behavioral design patterns are concerned with algorithms and the assignment of responsibility between objects. They can help to reduce complex object interaction between classes. Examples of behavioral design patterns include:

• Chain of Responsibility: A way of passing requests between a chain of objects.
• Command: Encapsulate a command request as an object.
• Interpreter: A way to include language elements in a program.
• Iterator: Sequentially access the elements of collection.
• Mediator: Defines simplified communication between classes.
• Memento: Capture and restore an object’s internal state.
• Observer: A way of notifying change to a number of classes.
• State: Alter an object’s behavior when its state changes.
• Strategy: Encapsulates an algorithm inside a class.
• Template Method: Defer the exact steps of an algorithm to a subclass.
• Visitor: Defines a new operation to a class without change.

Criticisms of Design Patterns

I realize that since I have done such an incredible job introducing and selling you on the concept of design patterns, at this point you might be thinking that design patterns are the infallible solution to all your programming problems! While design patterns are great, they are not without their issues and criticisms.

Targets the Wrong Problem

The need for design patterns from computer languages or design techniques that lack sufficient abstraction ability. As mentioned previously, some languages come with features that solve the problems that design patterns provide solutions to. Some argue that design patterns are nothing more than a kludge that is used to provide functionality to ineffective languages.

Design Patterns Increase Complexity Unnecessarily

Your situation is always determined by your context, and so you have to be careful. Design patterns are templates that you can adapted to any context, but they all have some level of complexity and overhead inherent in their implementation. In some contexts simpler approaches can solve problems, and implementing design patterns in these situations just incurs technical debt.

Blind Acceptance Leads to Inefficient Solutions

Design patterns put a system to approaches that are already widely accepted. This formalization of the approach is seen by many as dogma, and they implement the patterns to the letter, instead of adapting them to the context of their particular project. This leads to bloated code bases that contain unnecessary abstraction that has been inserted only because it satisfies the structure of a design pattern.

Unjustified Use

A common problem among novices after they first beginning learning about design patterns, is that they begin to apply those patterns everywhere, even in places where the pattern is inapplicable or unnecessary. This is where the gas is really poured on the fire for the previous two criticisms. Noobs unnecessarily implementing design patterns leads to bad code. Noobs implementing design patterns appropriately however, is awesome and should be encouraged! While the design patterns themselves aren’t the cause of this issue, they still get the bad rap for their improper use.

Conclusion

In conclusion, design patterns rock! They won’t be applicable to every situation, but they are a valuable tool to have. Even if they aren’t applicable to your specific context, going through the process of evaluating your problem against the design patterns will give you insight into your problem. You also have to understand where you should stick strictly to the pattern, and where you should leave stuff out if it’s going to incur unnecessary overhead. It’s all about understanding your problem. Design patterns give you better tools to evaluate your problems and solutions to those problems as well. It’s a very handy tool to have in any game developers toolkit!