-
Notifications
You must be signed in to change notification settings - Fork 513
Expand file tree
/
Copy pathintroduction.html
More file actions
312 lines (307 loc) · 18.9 KB
/
introduction.html
File metadata and controls
312 lines (307 loc) · 18.9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>Introduction · Game Programming Patterns</title>
<!-- Tell mobile browsers we're optimized for them and they don't need to crop
the viewport. -->
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<link rel="stylesheet" type="text/css" href="style.css" />
<link href="https://fonts.googleapis.com/css?family=Merriweather:400,400italic,700,700italic|Source+Code+Pro|Source+Sans+Pro:200,300,400,600,400italic,600italic|Rock+Salt" rel="stylesheet" type="text/css">
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-42804721-1', 'gameprogrammingpatterns.com');
ga('send', 'pageview');
</script>
<script src="jquery-3.6.0.min.js"></script>
<script src="script.js"></script>
</head>
<body id="top">
<div class="page sidebar">
<span class="theme-toggler" title="dark theme" onclick="toggleTheme()"></span>
<div class="content">
<nav class="top">
<span class="prev">← <a href="acknowledgements.html">Previous Chapter</a></span>
<span class="next"><a href="architecture-performance-and-games.html">Next Chapter</a> →</span>
<span class="toc">≡ <a href="/">The Book</a></span>
</nav>
<h1>Introduction</h1>
<h1 class="book"><a href="/">Game Programming Patterns</a></h1>
<p>In fifth grade, my friends and I were given access to a little unused
classroom housing a couple of very beat-up TRS-80s. Hoping to inspire us, a
teacher found a printout of some simple BASIC programs for us to tinker with.</p>
<p>The audio cassette drives on the computers were broken, so any time we wanted to
run some code, we’d have to carefully type it in from scratch. This led us
to prefer programs that were only a few lines long:</p>
<p><span name="radical"></span></p>
<div class="codehilite"><pre><span></span><code><span class="mf">10</span> <span class="kr">PRINT</span> <span class="s">"BOBBY IS RADICAL!!!"</span>
<span class="mf">20</span> <span class="kr">GOTO</span> <span class="mf">10</span>
</code></pre></div>
<aside name="radical">
<p>Maybe if the computer prints it enough times, it will magically become true.</p>
</aside>
<p>Even so, the process was fraught with peril. We didn’t know <em>how</em> to program,
so a tiny syntax error was impenetrable to us. If the program didn’t work,
which was often, we started over from the beginning.</p>
<p>At the back of the stack of pages was a real monster: a program that took up
several dense pages of code. It took a while before we worked up the courage
to even try it, but it was irresistible — the title above the listing was
“Tunnels and Trolls”. We had no idea what it did, but it sounded like a game,
and what could be cooler than a computer game that you programmed yourself?</p>
<p>We never did get it running, and after a year, we moved out of that classroom.
(Much later when I actually knew a bit of BASIC, I realized that it was just a
character generator for the table-top game and not a game in itself.) But the
die was cast — from there on out, I wanted to be a game programmer.</p>
<p>When I was in my teens, my family got a Macintosh with QuickBASIC and later
THINK C. I spent almost all of my <span name="snakes">summer vacations</span>
hacking together games. Learning on my own was slow and painful. I’d get
something up and running easily — maybe a map screen or a little puzzle —
but as the program grew, it got harder and harder.</p>
<aside name="snakes">
<p>Many of my summers were also spent catching snakes and turtles in the swamps
of southern Louisiana. If it wasn’t so blisteringly hot outside, there’s a
good chance this would be a herpetology book instead of a programming one.</p>
</aside>
<p>At first, the challenge was just getting something working. Then, it became
figuring out how to write programs bigger than what would fit in my head. Instead
of just reading about “How to Program in C++”, I started trying to find books
about how to <em>organize</em> programs.</p>
<p>Fast-forward several years, and a <span name="friend">friend</span> hands me a
book: <em>Design Patterns: Elements of Reusable Object-Oriented Software</em>.
Finally! The book I’d been looking for since I was a teenager. I read it cover
to cover in one sitting. I still struggled with my own programs, but it was
such a relief to see that other people struggled too and came up with
solutions. I felt like I finally had a couple of <em>tools</em> to use instead of
just my bare hands.</p>
<aside name="friend">
<p>This was the first time we’d met, and five minutes after being introduced, I
sat down on his couch and spent the next few hours completely ignoring him and
reading. I’d like to think my social skills have improved at least a little
since then.</p>
</aside>
<p>In 2001, I landed my dream job: software engineer at Electronic Arts. I
couldn’t wait to get a look at some real games and see how the pros put them
together. What was the architecture like for an enormous game like Madden
Football? How did the different systems interact? How did they get a single
codebase to run on multiple platforms?</p>
<p>Cracking open the source code was a humbling and surprising experience. There
was brilliant code in graphics, AI, animation, and visual effects. We had
people who knew how to squeeze every last cycle out of a CPU and put it to
good use. Stuff I didn’t even know was <em>possible</em>, these people did before
lunch.</p>
<p>But the <em>architecture</em> this brilliant code hung from was often an
afterthought. They were so focused on <em>features</em> that organization went overlooked. Coupling was rife between modules.
New features were often bolted onto the codebase wherever they could be made
to fit. To my disillusioned eyes, it looked like many programmers, if they ever
cracked open <em>Design Patterns</em> at all, never got past <a class="pattern"
href="singleton.html">Singleton</a>.</p>
<p>Of course, it wasn’t really that bad. I’d imagined game programmers sitting in
some ivory tower covered in whiteboards, calmly discussing architectural
minutiae for weeks on end. The reality was that the code I was looking at was
written by people working to meet intense deadlines. They did the best they
could, and, as I gradually realized, their best was often very good. The more
time I spent working on game code, the more bits of brilliance I found hiding
under the surface.</p>
<p>Unfortunately, “hiding” was often a good description. There were gems buried
in the code, but many people walked right over them. I watched coworkers
struggle to reinvent good solutions when examples of exactly what they needed
were nestled in the same codebase they were standing on.</p>
<p>That problem is what this book aims to solve. I dug up and polished the best
patterns I’ve found in games, and presented them here so that we can spend our
time inventing new things instead of <em>re</em>-inventing them.</p>
<h2><a href="#what's-in-store" name="what's-in-store">What’s in Store</a></h2>
<p>There are already dozens of game programming books out there. Why write
another?</p>
<p>Most game programming books I’ve seen fall into one of two categories:</p>
<ul>
<li>
<p><strong>Domain-specific books.</strong> These narrowly-focused books give you a deep dive
on some specific aspect of game development. They’ll teach you about 3D
graphics, real-time rendering, physics simulation, artificial intelligence,
or audio. These are the areas that many game programmers specialize in as
their careers progress.</p>
</li>
<li>
<p><strong>Whole-engine books.</strong> In contrast, these try to span all of the different
parts of an entire game engine. They are oriented towards building a
complete engine suited to some specific genre of game, usually a 3D first-person shooter.</p>
</li>
</ul>
<p>I like both of these kinds of books, but I think they leave some gaps. Books
specific to a domain rarely tell you how that chunk of code interacts with the
rest of the game. You may be a wizard at physics and rendering, but do you
know how to tie them together gracefully?</p>
<p>The second category covers that, but I often find whole-engine books to be too monolithic and too
genre-specific. Especially with the rise of mobile and casual gaming, we’re in
a period where lots of different genres of games are being created. We aren’t
all just cloning Quake anymore. Books that walk you through a single engine
aren’t helpful when <em>your</em> game doesn’t fit that mold.</p>
<p>Instead, what I’m trying to do here is more <span name="carte"><em>à la
carte</em></span>. Each of the chapters in this book is an independent idea that
you can apply to your code. This way, you can mix and match them in a way that
works best for the game <em>you</em> want to make.</p>
<aside name="carte">
<p>Another example of this <em>à la carte</em> style is the widely beloved <a href="http://www.satori.org/game-programming-gems/"><em>Game
Programming Gems</em></a> series.</p>
</aside>
<h2><a href="#how-it-relates-to-design-patterns" name="how-it-relates-to-design-patterns">How it Relates to Design Patterns</a></h2>
<p>Any programming book with <span name="alexander">“Patterns”</span> in its name
clearly bears a relationship to the classic <em>Design Patterns: Elements of
Reusable Object-Oriented Software</em> by Erich Gamma, Richard Helm, Ralph Johnson,
and John Vlissides (ominously called the “Gang of Four”).</p>
<aside name="alexander">
<p><em>Design Patterns</em> itself was in turn inspired by a previous book. The idea of
crafting a language of patterns to describe open-ended solutions to problems
comes from <a href="http://en.wikipedia.org/wiki/A_Pattern_Language"><em>A Pattern
Language</em></a>, by Christopher
Alexander (along with Sarah Ishikawa and Murray Silverstein).</p>
<p>Their book was about architecture (like <em>real</em> architecture with buildings and
walls and stuff), but they hoped others would use the same structure to
describe solutions in other fields. <em>Design Patterns</em> is the Gang of Four’s
attempt to do that for software.</p>
</aside>
<p>By calling this book “Game Programming Patterns”, I’m not trying to imply that
the Gang of Four’s book is <span name="nongames">inapplicable</span> to games.
On the contrary: the <a href="design-patterns-revisited.html">Design Patterns Revisited</a>
section of this book covers many of the patterns from <em>Design
Patterns</em>, but with an emphasis on how they can be applied to game
programming.</p>
<p>Conversely, I think this book is applicable to non-game software too. I could
just as well have called this book <em>More Design Patterns</em>, but I think games
make for more engaging examples. Do you really want to read yet another book
about employee records and bank accounts?</p>
<p>That being said, while the patterns introduced here are useful in other
software, I think they’re particularly well-suited to engineering challenges
commonly encountered in games:</p>
<ul>
<li>
<p>Time and sequencing are often a core part of a game’s architecture. Things
must happen in the right order and at the right time.</p>
</li>
<li>
<p>Development cycles are highly compressed, and a number of programmers need
to be able to rapidly build and iterate on a rich set of different
behavior without stepping on each other’s toes or leaving footprints all
over the codebase.</p>
</li>
<li>
<p>After all of this behavior is defined, it starts interacting. Monsters
bite the hero, potions are mixed together, and bombs blast enemies and
friends alike. Those interactions must happen without the codebase turning
into an intertwined hairball.</p>
</li>
<li>
<p>And, finally, performance is critical in games. Game developers are in a
constant race to see who can squeeze the most out of their platform.
Tricks for shaving off cycles can mean the difference between an A-rated
game and millions of sales or dropped frames and angry reviewers.</p>
</li>
</ul>
<h2><a href="#how-to-read-the-book" name="how-to-read-the-book">How to Read the Book</a></h2>
<p><em>Game Programming Patterns</em> is divided into three broad sections. The first
introduces and frames the book. It’s the chapter you’re reading now along with
the <a href="architecture-performance-and-games.html">next one</a>.</p>
<p>The second section, <a href="design-patterns-revisited.html">Design Patterns Revisited</a>,
goes through a handful of patterns from the Gang of Four book. With each chapter,
I give my spin on a pattern and how I think it relates to game programming.</p>
<p>The last section is the real meat of the book. It presents thirteen
design patterns that I’ve found useful. They’re grouped into four categories:
<a href="sequencing-patterns.html">Sequencing Patterns</a>, <a href="behavioral-patterns.html">Behavioral Patterns</a>, <a href="decoupling-patterns.html">Decoupling Patterns</a>,
and <a href="optimization-patterns.html">Optimization Patterns</a>.</p>
<p>Each of these patterns is described using a consistent structure so that you
can use this book as a reference and quickly find what you need:</p>
<ul>
<li>
<p>The <strong>Intent</strong> section provides a snapshot description of the pattern in
terms of the problem it intends to solve. This is first so that you can hunt
through the book quickly to find a pattern that will help you with your
current struggle.</p>
</li>
<li>
<p>The <strong>Motivation</strong> section describes an example problem that we will be
applying the pattern to. Unlike concrete algorithms, a pattern is usually
formless unless applied to some specific problem. Teaching a pattern without
an example is like teaching baking without mentioning dough. This section
provides the dough that the later sections will bake.</p>
</li>
<li>
<p>The <strong>Pattern</strong> section distills the essence of the pattern out of the
previous example. If you want a dry textbook description of the pattern,
this is it. It’s also a good refresher if you’re familiar with a pattern
already and want to make sure you don’t forget an ingredient.</p>
</li>
<li>
<p>So far, the pattern has only been explained in terms of a single example.
But how do you know if the pattern will be good for <em>your</em> problem?
The <strong>When to Use It</strong> section provides some guidelines on when the pattern
is useful and when it’s best avoided. The <strong>Keep in Mind</strong> section points
out consequences and risks when using the pattern.</p>
</li>
<li>
<p>If, like me, you need concrete examples to really <em>get</em> something,
then <strong>Sample Code</strong> is your section. It walks step by step through a full
implementation of the pattern so you can see exactly how it works.</p>
</li>
<li>
<p>Patterns differ from single algorithms because they are open-ended. Each
time you use a pattern, you’ll likely implement it differently. The next section,
<strong>Design Decisions</strong>, explores that space and shows you different options to
consider when applying a pattern.</p>
</li>
<li>
<p>To wrap it up, there’s a short <strong>See Also</strong> section that shows how this
pattern relates to others and points you to real-world open source code that
uses it.</p>
</li>
</ul>
<h2><a href="#about-the-sample-code" name="about-the-sample-code">About the Sample Code</a></h2>
<p>Code samples in this book are in C++, but that isn’t to imply that these
patterns are only useful in that language or that C++ is a better language
for them than others. Almost any language will work fine, though some patterns
do tend to presume your language has objects and classes.</p>
<p>I chose C++ for a couple of reasons. First, it’s the most popular language for
commercially shipped games. It is the <em>lingua franca</em> of the industry. Moreso,
the C syntax that C++ is based on is also the basis for Java, C#, JavaScript,
and many other languages. Even if you don’t know C++, the odds are good you
can understand the code samples here with a little bit of effort.</p>
<p>The goal of this book is <em>not</em> to teach you C++. The samples are kept as
simple as possible and don’t represent good C++ style or usage. Read the code
samples for the idea being expressed, not the code expressing it.</p>
<p>In particular, the code is not written in “modern” — C++11 or newer — style.
It does not use the standard library and rarely uses templates. This makes for
“bad” C++ code, but I hope that by keeping it stripped down, it will be more
approachable to people coming from C, Objective-C, Java, and other languages.</p>
<p>To avoid wasting space on code you’ve already seen or that isn’t relevant to
the pattern, code will sometimes be omitted in examples. When this occurs, an
ellipsis will be placed in the sample to show where the missing code goes.</p>
<p>Consider a function that will do some work and then return a value. The
pattern being explained is only concerned with the return value, and not the
work being done. In that case, the sample code will look like:</p>
<div class="codehilite"><pre><span></span><code><span class="kt">bool</span> <span class="nf">update</span><span class="p">()</span>
<span class="p">{</span>
<span class="c1">// Do work...</span>
<span class="k">return</span> <span class="n">isDone</span><span class="p">();</span>
<span class="p">}</span>
</code></pre></div>
<h2><a href="#where-to-go-from-here" name="where-to-go-from-here">Where to Go From Here</a></h2>
<p>Patterns are a constantly changing and expanding part of software development.
This book continues the process started by the Gang of Four of documenting and
sharing the software patterns they saw, and that process will continue after
the ink dries on these pages.</p>
<p>You are a core part of that process. As you develop your own patterns and
refine (or refute!) the patterns in this book, you contribute to the software
community. If you have suggestions, corrections, or other feedback about
what’s in here, please get in touch!</p>
<nav>
<span class="prev">← <a href="acknowledgements.html">Previous Chapter</a></span>
<span class="next"><a href="architecture-performance-and-games.html">Next Chapter</a> →</span>
<span class="toc">≡ <a href="/">The Book</a></span>
</nav>
</div>
</div>
<footer>© 2009-2021 Robert Nystrom</footer>
</body>
</html>