Learning Design Patterns with Unity

Priming the System

As programmers, our job is to design, build, and integrate software features into cohesive products that are useful and hopefully bring joy to our users. And somewhere in all of that, the software has to work. Our job can be anything from building a login feature or networking layer to a subscription and payment portal. In games, we’re thinking of moving a playable character, building an adaptive AI enemy, or adding a random level generator. The big idea that should pop out at you is that these elements don’t exist in a vacuum. In fact, they tend to wither and die of boredom if they’re not connected to each other.

When you think of the code powering your applications and games, you’re thinking about a collection of systems built around specific features or mechanics, but more importantly, around specific problems that come with making those features work as expected. If I could manage it, I’d have the word systems jump off the page and do a little dance to get your attention, because that’s what this entire book is about: games (and applications) are made up of systems – the more these systems grow and interact with each other, the more complicated things get.

Systems may not be anything new to you, and they’re certainly not new to the programming industry, but there are problems that you’ll repeatedly run into that are directly related to systems running and interacting. And that’s really what I want to drive home before we get started: design patterns provide reusable solutions to problems we face in our everyday software lives and offer a common vocabulary for understanding and talking about best practices.

Now the real work starts – how do we identify the parts of our code that could benefit from a design pattern? How does all this relate to software architecture? How can I adapt these patterns for game development in Unity?

These are big questions, which is why we’re spending this first chapter getting a holistic feel for the following topics:

Software architecture vs software design
Design patterns and the categories they belong to (creational, structural, and behavioral)
Why use design patterns at all?
When to use design patterns
Common pitfalls
Starter projects for this book

By the end of the chapter, you’ll have the necessary foundation to dive into design pattern implementations and a big-picture view of the flexibility, reusability, and structure they can add to your projects. But first, let’s make sure you know what to expect from this book and that you’re coming to the table with the prerequisites for getting the most out of the experience.

At the time of writing, all chapter examples and project files were built using Unity 2023.1.5f1. Unity is the visual tool we’re using to make the learning process more inviting, but the bones of the design pattern content are still 100% applicable to C# projects. The main differences that come into play between Unity, C#, and design patterns are how objects are created (new classes vs MonoBehaviours) and assembled (inheritance vs GameObjects and Components). Don’t worry, we’ll cover these variations in each pattern. Learning how each design pattern works as a system doesn’t depend on a specific platform or language – it’s all problem-solving skills!

A word about software architecture

Software architecture is a big topic and shouldn’t be confused with software design even though they both deal with “patterns.” When we talk about architectural patterns, we’re talking about big-picture solutions to problems that are typically focused on how multiple components work together at the application level, as well as conventions, best practices, and principles that guide the overall development process. When we talk about software design patterns, we’re talking about problems that crop up when you’re building those internal components. Figure 1.1 provides a simplified example of the key difference we’re talking about: Process A is made up of multiple internal components (the software design portion) while managing and organizing how these internal components fit together (the architectural portion).

Diagram Description automatically generated

Figure 1.1: Example diagram of software architecture vs design

Clear as mud? OK, let’s take a more relatable example: if we think about building a house, the architectural patterns are focused on how the entire house fits together and how the component parts (electrical, plumbing, insulation, etc.) come together into a functioning structure you can live in. Think LEGO (because that always helps me): architectural patterns deal with problems affecting the overall structure you’re building, while design patterns focus on the individual LEGO blocks that make up the final structure. You ideally need both types of solutions in a great application or game, but they solve fundamentally different problems, which is why I bring this distinction up so early in our journey. We’ll be focused on the software design aspect of things, but you can (and should) continue your journey into architectural waters after or in conjunction with this book.

In your everyday life, when you open Twitter (or whatever app you go to first thing in the morning), you’re involved in what’s called the Client-Server architectural pattern – the client (the app on your phone) consumes information from a server somewhere in a basement and displays it to you in a way you can understand. But it’s not concerned with how the app remembers your login credentials or uses face recognition to log you in. Those are software design problems because they focus on the internal features of the application.

Before we get to the why, when, and how of design patterns, we need to agree on a basic understanding of what good software design is to see the benefits of design patterns. Books on software design are everywhere. Amazon thinks you want them, and your co-workers probably have a few gathering dust on their desks right now. Hell, your computer monitor might be sitting on a few of them at this very moment. This isn’t one of those books.

I like to think of software design as a tool that might make things harder in the moment but easier in the long run, like going to the gym. It’s a pain to use the Stairmaster every day, but being healthy has far-reaching benefits throughout a lifetime. The same is true of approaching a project with an eye to software design. With that in mind, let’s set up a simple definition for ourselves as a kind of guiding light for what we mean by good software design:

A codebase that is flexible, maintainable, and reusable is the product of good software design.

This is easier said than done no matter how well-intentioned you or your team start off developing your game. Decoupling your code can speed up your development process, but it adds overhead and maintenance time. On the other hand, interdependent code can be costly when you want to make changes, big or small. It’s all about balance, even if you can’t have everything you want all the time. Fast, good, or cheap – you can only ever have two.

With a working definition of good software design, we can move on to talking about what design patterns are, how they’re categorized, and how they fit into Unity projects.

What are design patterns?

If I haven’t harped on this point enough, I want you to keep thinking to yourself “Design Patterns are systems” over and over. Let’s say that again, design patterns are systems, and systems are designed to solve specific problems. It doesn’t matter if it’s the brake system in your car, the biological systems that run our bodies, or the banking system in Figure 1.2. They’re all systems and they’re all trying to solve a problem or keep their respective system organized and balanced (and sometimes both).

Figure 1.2: Diagram of how bank accounts work using credit and debit

More than anything, design patterns focus on making code more flexible and reusable, two tenets we’ll hammer away at throughout this book. Just keep repeating our mantra every time we dive into a new pattern: design patterns are systems!

The Gang of Four

Back in 1994, a group of four daring engineers banded together to better tackle OOP practices and recurring problems that kept popping up in their programs; Design Patterns: Elements of Reusable Object-Oriented Software written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides is the product of that team-up. The book covers 23 design patterns split into three categories according to their core functions, with examples written in C++ and Smalltalk. While the book was and continues to be an important resource, these patterns have been adapted and expanded since 1994, leaving some more (and some less) relevant depending on your chosen programming language and environment.

There are also those who have pointed out that a fair few of the patterns are replacements for perceived missing features in the C++ language. However, this argument has never resonated with me when I look at my code in other languages (whether it’s C# or something like Swift) because wearing my systems-thinking glasses has always made me think more critically and write code more intentionally.

You’ve likely heard the phrase “Gang of Four” whispered with quiet reverence (or loud and angry fist-shaking, depending on who you’re talking to), but with topics like this, I’ve found it’s best to learn design patterns as a skill before making judgments. There are impassioned programmers on both sides of the aisle, which means getting your hands dirty is the best thing you can do for yourself. A lot of the debate gets lost in theoretical or pedagogical minutiae (and personalities) but the core skillset behind design patterns has always been a useful tool for programming.

Pattern categories

There are three categories that all original design patterns fall into – Creational, Behavioral, and Structural. As with all things, additional patterns have evolved since 1994, resulting in useful patterns that were not included in the original Gang of Four book that we’ll cover on our journey and a few honorable mentions (because we can’t cover every design pattern in a single book).

Before we get into the category details, I feel it’s important to address a problem that crops up at the beginning of most journeys into design patterns – how do I find the right pattern for the problem I’m facing? Do I need to read and memorize every pattern, or is there a better way to navigate this topic?

The answer might surprise you, but no, this isn’t a memorization game and you don’t get extra points for knowing everything about every design pattern – systems thinking is a learned skill, not a closed-book test. It’s almost a detective game: first, knowing what problems each pattern category addresses is super important because it narrows the field you have to search. Second, reading the first few pages of each chapter in the applicable category will show you pretty quickly if you’re in the right place. From there, the more you use design patterns, the more you’ll get a feel for the problems and effective solutions out in the wild. As you’ll see, design patterns offer solutions to well-documented problems, but they’re not set in stone; it’s up to you to adapt them to your project.

Now that we know the basics, let’s dive into the nitty-gritty of each design pattern category and what specific problems they aim to solve.

Creational patterns

Creational patterns deal with creating objects that are uniquely suited to a given situation or use case. More specifically, these patterns deal with how to hide object and class creation logic, so the calling instance doesn’t get bogged down with the details. As your object and class creation needs become more complex, these patterns will help move you away from hardcoding fixed behaviors toward writing smaller behavior sets that you can use to build up more complex features (think LEGO). A good creational pattern black-boxes the creation logic and simply hands back a utility tool to control what, who, how, and when an object or class is created.

The creational patterns we’ll cover are listed in the following table:

Pattern	Description
Singleton	Ensure a class has only one instance and provide a global point of access to it – commonly used for features like logging or database connections that need to be coordinated and shared through the entire application.
Prototype	Specify the kinds of objects to create using a prototypical instance and create new objects from the “skeleton” of an existing object.
Factory Method	Define an interface for creating a single object, but delegate the instantiation logic to subclasses that decide which class to instantiate.
Abstract Factory	Define an interface for creating families of related or dependent objects, but let subclasses decide which class to instantiate.
Builder	Allows complex objects to be built step by step, separating an object’s construction from its representation – commonly used when creating different versions of an object.
Object Pool	Avoid expensive acquisition and release of resources by recycling objects that are no longer in use – commonly used when resources are expensive, plentiful, or both.

Table 1.1: List of creational design patterns with descriptions

Behavioral patterns

Behavioral patterns are concerned with how classes and objects communicate with each other. More specifically, these patterns concentrate on the different responsibilities and connections objects have with each other when they’re working together. Like structural patterns, behavioral patterns use inheritance to divvy up behaviors between classes, which gives you the freedom to let go of any white-knuckled control flow responsibilities and focus on how objects can work together.

The behavioral patterns we’ll cover are listed in the following table:

Pattern	Description
Command	Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests and the queuing or logging of requests.
Observer	Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically.
State	Allow an object to alter its behavior when its internal state changes. The object will appear to change its class – commonly used when object behavior drastically changes depending on its internal state.
Visitor	Define a new class operation without changing the underlying object.
Strategy	Define a family of interchangeable behaviors and defer setting the behavior until runtime.
Type Object	Allow the flexible creation of new “classes” from a single class, each instance of which will represent a different type of object.
Memento	Capture and externalize the internal state of an object so it can be restored or reverted to this state later – without breaking encapsulation.

Table 1.2: List of behavioral design patterns with descriptions

Structural patterns

Structural patterns focus on composition, or how classes and objects are composed into larger, more complex structures. Structural patterns are heavy on abstraction, which makes object relationships easier to manage and customize. Patterns in this category will use inheritance to let you mix and match your class structures as well as create objects with new functionality at runtime.

The structural patterns we’ll cover are listed in the following table:

Pattern	Description
Decorator	Attach additional responsibilities to an object dynamically keeping the same interface.
Adapter	Convert the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces.
Façade	Provide a unified interface to a set of interfaces in a subsystem. Facade defines a high-level interface that makes the subsystem easier to use.
Flyweight	Shares common data between similar objects to limit memory usage and increase performance.
Service Locator	Provide a global access point for services without coupling client code to the concrete service classes.

Table 1.3: List of structural design patterns with descriptions

The goal with each of these problems is to use a solution that is coherent, reusable, and above all, designed for efficient change.

Why use design patterns?

In four words – reusability, flexibility, and maintainability. You’ll see these concepts pop up around software architecture and code complexity topics, but they are the central beneficial tenets of design patterns. For example, if you need to create variations of the same object in your game, it makes more sense to create a build system instead of individual hard-coded objects. Figure 1.3 illustrates an assembly line that turns out little robots, with each step fulfilling a specific function in the object creation process.

This is a simplified but effective mental model for the Builder pattern:

Figure 1.3: Reusable Builder pattern creating objects

Let’s start with reusability, which OOP principles like encapsulation, abstraction, and inheritance already address and are the cornerstones of many design patterns in this book. There’s no better feeling than sitting down with a new feature task to implement and realizing you already have the building blocks you need to get it done. Your only real task is to stack them together into a form that makes the feature work and test it out. With design patterns, you have the option of using class inheritance, delegation, and object composition to create reusable components for your game code. Each has its pros and cons, which we’ll get into later, but they can also give you an efficiency bump when you’re writing new code.

Figure 1.4: Flexible control scheme diagram using the Command pattern

In terms of flexibility, design patterns can help you structure your code for the future, and by the future, I mean change. When we talk about change and reusability, we’re talking about code that can handle changing requirements and changing scales. No program you will ever write is going to be static, because no code is perfectly balanced on the first try. If you don’t build in flexibility, the first strong wind is going to snap your project in two, and that means redesigns, feature implementations, and new rounds of testing.

The beauty of correctly using design patterns is that you don’t just have to choose one – you can mix and match to get the desired result. For example, your game will always need player controls like in Figure 1.4, but what if you want to switch out individual commands or button assignments? Your code would be more flexible if you could separate the control input from the implementation, which is something the Command pattern is great at.

Figure 1.5: Adapter pattern as an example of designing for change and easy maintenance

Finally, we come to maintainability. The ideal is to have working code that has the right level of architecture and complexity; not only does this make our code readable, it’s easier to debug if each component or class has a defined role we can isolate. I italicized “right” because it’s a tricky task. On the one hand, you want enough structure in your project to make updating the code as easy and efficient as possible. On the other hand, too much complexity can needlessly clog up a project, having the exact opposite effect. Correctly identifying design patterns that’ll help you achieve the former instead of the latter is the balancing act of code maintenance.

When to use design patterns

You know you’re doing something interesting when the answer to the question of why or when is both maddeningly simple and complex. The answer you’ll hear the most about design patterns is that you should only use them when they’re needed. Helpful, right?

The easiest way to know if you should use a design pattern is if you identify a concrete problem area in your code. Symptoms of a problem include code smells like tightly coupled classes, monolithic subclass hierarchies, and dependencies on specific operations, object representations, and hardware. Hardware and software dependencies are particularly acute in game development when you need to port your code to different devices or systems.

NOTE

If code smells are a new concept, don’t worry, they’re just a fancy industry term for characteristics of your code that might point to a deeper problem. Code smells can include huge, bloated classes, misuse of Object-Oriented principles, changes in one place necessitating changes in other places in your application, and excessively coupled objects.

All those symptoms are related to the idea of designing for change, and how easy or hard it is to make changes to your code. This is a topic we’ll explore with each pattern individually, but here are a few high-level red flags to look out for:

Is a class hard to add to or maintain?
How much knowledge does the programmer making a change need to have of the entire system they are working on?
Is it difficult to create slightly different objects from existing classes?
Does a change in one area crash a secondary or even unrelated part of the codebase?
Can your code satisfy an operational request in only one way?
If you’re working with algorithms, does changing the implementation break the object using the algorithm?

If any of these questions ring a bell, then your code could use some design pattern love. But design patterns aren’t all fun and games (pun intended); there are pitfalls with any tool – software or physical – that we have to address before diving in.

About the example projects

When I first started learning about design patterns, I found the wealth of resources, tutorials, and applicable scenarios overwhelming (if this has happened to you too, I hope finding this book will make your journey much, much easier). The problem wasn’t the technical information that I was finding, but the way it was presented. More often than not, the design pattern content seemed to be shrouded in dry, overbearing technical language, complicated examples, or just plain old incorrect solutions.

One of my main goals in writing this book was to present the foundation of these wonderful tools with as little fluff as possible. However, this turns problematic when trying to find a balance between teaching the design pattern itself and getting it to run in a meaningful way – because just like design patterns, new skills wither and die in a vacuum. This is all to say that I’ve created the starter projects for each chapter as simply and meaningfully as I possibly can. The balance is delicate, and you might find the examples weighted to one side or the other, but it’s always been with the intention of making the design pattern the star.

Client code

Some of the ways I’ve implemented UI code, client scripts, or any of the simple systems around using each design pattern are not production-ready or best practices – they are the simplest way of using the pattern with context. On the flip side, I’ve given as much thought and page count as possible to pattern variations, extensions, and best practices so you have concrete tools to bring to your own projects.

Again, this book isn’t about Unity (although it’s a delightfully fun learning environment), but rather how we can learn problem solving skills and apply them to software.

Old vs new input system

As you’ll see in the next chapter and onwards, I’m using Unity’s old Input System rather than the new Input System. Why? Because it’s the simplest way to get the client code running with a minimum amount of setup and screenshots for you to follow. I love the new input system (I feel I need to put this on the record or risk banishment), but it does require a little specialized knowledge and experience that doesn’t contribute to design patterns. As always, I encourage you to experiment with implementing the design pattern solutions in whatever context works best for your project. For learning, I’ve found the old Input System works best.

Art assets

I love beautiful Unity projects that are full of life, sound, ambiance, and thematic feeling, but these things don’t help us learn new skills – in fact, they tend to distract at best and hinder at worst. All example projects use the most basic primitive objects and materials possible (essentially white boxing everything), not only to keep things consistent but to keep you focused on the design patterns. And who knows, the lack of excitement in our projects might just inspire you to deploy your new skills in ways you hadn’t thought of before.

I hope the simplicity of the examples I’ve prepared doesn’t make you nervous, because it should really make you hopeful. The fact that we can use these patterns as systems to be plugged in and interchanged with the UI, clients, or any other aspect of application development only strengthens the very first point of this chapter – design patterns are systems!