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!
