Welcome to the second edition of Hands-On Game Development Patterns with Unity; this edition is not merely a revision of the previous version, but a complete upgrade of the original book. After the first edition came out, I was fortunate to get a lot of constructive feedback, which inspired me to improve the structure of this new edition. As we will review in the following sections, this book concentrates on the "hands-on" aspect of the title; in other words, we are going to get our hands dirty and work on implementing systems and features for a fully playable prototype of a game with design patterns. This new approach to the book's structure will be more tangible and also more enjoyable. It's more fun to work on a playable game than with random code examples. So, before we begin, in the following sections, I will establish specific parameters to the book's content and overall approach.

Let's quickly review the topics we are going to see in this chapter, as follows:

• Notes about the new edition
• The philosophy of the book
• What are design patterns?
• Which subjects aren't covered in this book?
• The game project

As mentioned, I redesigned this edition entirely based on reader feedback from the previous version, and so, in consequence, I decided to cut some content from the last edition that readers considered to be trivial, such as the following:

• Game loop and update pattern chapters: These chapters focused too much on theory and didn't align themselves with the book's "hands-on" approach.
• Anti-patterns chapter: Anti-patterns is a complex and deep subject that deserves a book in itself to do it justice.

The end goal of this edition is not to cut content but to instead redesign the book to focus on practical game development uses of software design patterns in order to build a complete project. In other words, unlike the first edition, in which I took the approach of presenting each design pattern in isolation and with a self-contained code example, we will use them unitedly this time.

I added some chapters in this edition that were lacking in the previous version, such as the following:

• The Game Design Document: The beginning of a new game project often starts with writing a GDD. A GDD is a document that will help us understand the design intention behind the game systems and mechanics that we will build throughout the book.
• A Short Primer to Programming in Unity: We will use several advanced Unity engine concepts, C# features, and object-oriented programming (OOP) techniques throughout the book. In this chapter, we will take the time to review them to establish a shared knowledge base.

This book is not a technical bible or the ultimate authority on how to use design patterns with Unity, and it's best described as a guide filled with design propositions to resolve some game programming challenges in Unity. The code examples included in each chapter are not flawless implementations because the art of design and programming is a continuous refinement process, and so the core goal of this book is to introduce you to potential solutions and inspire you to find better ones.

For those that are very new to programming, design patterns might be a novel concept. The simplest way of explaining design patterns is that they are reusable solutions to common software development problems. An architect named Christopher Alexander originated the notion of design patterns to describe reusable design ideas. In the late 1980s, inspired by the concept, software engineers started experimenting with applying concepts of reusable design patterns to software development, and over the years several books were written on the subject, such as the classic Design Patterns: Elements of Reusable Object-Oriented Software by the so-called "Gang of Four".

But in this book, I will be avoiding covering the academic side of software design patterns, focusing instead on their practical use for programming game mechanics and systems in Unity. I will present a recurrent game programming problem in each chapter and propose resolving it using a specific design pattern adapted for the Unity application programming interface (API).

There are many facets to game programming, and a single book cannot cover them all with the depth they deserve. This book has a specific focus: design patterns and the Unity engine. So, if you are starting your journey into becoming a professional game programmer, this book will not be enough to complete your education. But luckily, some very talented individuals in our industry have taken the time to write very specialized books on core topics of game development. I recommend that anyone interested in joining the game industry reads each of the following reference books:

• Physics programming: Real-Time Collision Detection, Christer Ericson
• Engine programming: Game Engine Architecture, Jason Gregory
• Three-dimensional (3D) programming: Mathematics for 3D Game Programming and Computer Graphics, Eric Lengyel
• Artificial intelligence (AI) programming: Programming Game AI By Example, Mat Buckland 

I have focused the content of this book on a specific aspect of game programming, but I will mention concepts from other domains of game development throughout the book. So, if you feel unfamiliar with some of the topics mentioned, take the time to explore them in depth; the time invested in researching will make you a better game programmer.

Throughout this book, we will be working continuously on a single game project example. The working title of the game is Edge Racer. As the title may indicate, it's a racing game; to be more specific, it's a futuristic racing game in which the player drives high-speed motorcycles. We will review the core concepts of the game in more detail in Chapter 2, The Game Design Document. But before continuing, I wish to list the reasons I decided on a racing game instead of another type of game—for example, a role-playing game (RPG)—as follows:

• Simplicity: Racing games have a simple premise—get to the finish line as fast as possible without crashing. Because this book is not about game design but game programming, I wanted a simple type of game that will permit us to focus on learning about software design patterns and not get bogged down with the implementation details of complex game mechanics.
• Fun: I've worked on various games of many different genres, and I always found that racing games are the most fun to develop because they are enjoyable to test. In racing games, you can speed-run to specific parts of the game and quickly reproduce bugs or test new features. Unlike other games with deep game mechanics and large maps, such as RPGs, racing games are usually quicker to debug.
• Performance: The main challenge of programming a racing game is maintaining a consistent frame rate as you add more features and content. So, I find working on racing games forces you to maintain good game-programmer habits by always keeping an eye on how fast your code is running and not just making it more readable.
• Personal: There's also a personal reason for me choosing a racing game—it's because it's my favorite genre. I love playing racing games and I love making them. 

In conclusion, the game industry produces various products in many genres and sub-genres, but a racing game is a good reference point for us to start learning about design patterns in Unity because it's a simple context and forces us to keep an eye on keeping code clean and fast.

In this chapter, we reviewed the book's structure so that we can start with a clear understanding of its content and purpose. The key takeaway is that we will be using design patterns to build the mechanics and systems of a new racing game named Edge Racer.

In the next chapter, we will review the GDD to have a solid understanding of the game project that we will be working on in the upcoming chapters. I would not recommend skipping it because it's always a good practice to get to know as much as possible about a game project before starting writing code, as this helps in understanding how the parts fit the whole.