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).

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.

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.

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:

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:

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:

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.

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.

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.

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.

We can get to a well-architected state with less stress if we keep an eye on some common pitfalls. You’ll notice as you read this book that it’s not so much a step-by-step tutorial as it is a reference for when you need to implement a design pattern. Half the skill is learning if, and when, to use one at all.

Let’s summarize:

• Don’t use a design pattern just for the sake of using it. Impressing a review team or someone on GitHub isn’t worth it. If a part of your game needs some abstraction and decoupling, absolutely do it.
• Only add complexity where it’s needed. If you find that your project is overly architected, ask yourself if your codebase wouldn’t be cleaner and easier to read without it.
• Good software architecture is never free. Abstracting code takes time to learn, write, and maintain, and you may take runtime hits to performance and speed.

So why do any of this design pattern nonsense in the first place? Because complexity isn’t a bad word, performance can be improved later on, and the efficiency bump in your development process is well worth the up-front investment. You won’t get it right the first time, so enjoy the iteration. It’s all part of the process. And if you’re like me, using design patterns is like a puzzle, and when that code runs, it’s like finding that last pesky piece your cat hid under the couch – it’s magic.

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!

I know this was a lot of logistics and theory to get through – congratulations on sticking with it even if you were itching to start coding. This chapter has a lot of useful resources and content that you can (and should) refer to as you continue your design pattern adventure. Remember, we defined good software as flexible, reusable, and maintainable, so keep that at the forefront of your mind when reading each chapter.

Design patterns are internal systems that solve specific problems, and half the battle is matching the problem you have to the pattern that solves it best. There’s a time and place to use design patterns, but overusing (or misusing) them can lead to complexity you don’t need and time costs you don’t have to spend. Your ultimate job (which is down to me) is to come out of the other end of this book literate in the language of design patterns.

In the next chapter, we’ll dive into our first official design pattern – the Singleton pattern – and get a taste of thinking in systems!

If any of these topics sounds foreign, you can take a step back and check out the resource list I’ve put together below or push through and learn as you go along.

• For C#, I’d recommend starting with my beginner-level book Learning C# by Developing Games with Unity (7th Edition). I wrote it specifically to get new programmers up to speed with core programming skills from the ground up using C# and Unity, and you can find it at https://www.amazon.com/Learning-Developing-Games-Unity-coding/dp/1837636877.
• For a deeper dive into the C# language, Mark Price’s book C# 11 and .NET: Modern Cross-Platform Development Fundamental is fantastic, which you can find at https://www.amazon.com/11-NET-Cross-Platform-Development-Fundamentals/dp/1803237805.
• For Unity content, I’d recommend Hands-On Unity 2022 Game Development by Nicolas Alejandro Borromeo (https://www.amazon.com/Hands-Unity-2022-Game-Development/dp/1803236914) and Unity 3D Game Development by Anthony Davis, Travis Baptiste, Russell Craig, and Ryan Stunkel (https://www.amazon.com/Unity-Game-Development-design-beautiful/dp/1801076146).