Robert Nystrom - Game Programming Patterns

The full text of this book lives online at gameprogrammingpatterns.com.

Copyright 2014 by Robert Nystrom.

All rights reserved.

ISBN: 978-0-9905829-2-2

Ive heard only other authors know whats involved in writing a book, but thereis another tribe who know the precise weight of that burdenthose with themisfortune of being in a relationship with a writer. I wrote this in a space oftime painstakingly carved from the dense rock of life for me by my wife Megan.Washing dishes and giving the kids baths may not be writing, but without herdoing those, this book wouldnt be here.

I started this project while a programmer at Electronic Arts. I dont think thecompany knew quite what to make of it, and Im grateful to Michael Malone,Olivier Nallet, and Richard Wifall for supporting it and providing detailed,insightful feedback on the first few chapters.

About halfway through writing, I decided to forgo a traditional publisher. Iknew that meant losing the guidance an editor brings, but I had email fromdozens of readers telling me where they wanted the book to go. Id loseproofreaders, but I had over 250 bug reports to help improve the prose. Id giveup the incentive of a writing schedule, but with readers patting my back when Ifinished each chapter, I had more than enough motivation.

What I didnt lose was a copy editor. Lauren Briese showed up just when Ineeded her and did a wonderful job.

They call this self publishing, but crowd publishing is closer to the mark.Writing can be lonely work, but I was never alone. Even when I put the book on ashelf for two years, the encouragement continued. Without the dozens of peoplewho didnt let me forget that they were waiting for more chapters, I never wouldhave picked it back up and finished.

Special thanks go to Colm Sloan who pored over every single chapter in the booktwice and gave me mountains of fantastic feedback, all out of the goodness ofhis own heart. I owe you a beer or twenty.

To everyone who emailed or commented, upvoted or favorited, tweeted orretweeted, anyone who reached out to me, or told a friend about the book, orsent me a bug report: my heart is filled with gratitude for you. Completing thisbook was one of my biggest goals in life, and you made it happen.

Thank you!

To Megan, for faith and time,
the two essential ingredients.

In fifth grade, my friends and I were given access to a little unusedclassroom housing a couple of very beat-up TRS-80s. Hoping to inspire us, ateacher found a printout of some simple BASIC programs for us to tinker with.

The audio cassette drives on the computers were broken, so any time we wanted torun some code, wed have to carefully type it in from scratch. This led usto prefer programs that were only a few lines long:

Maybe if the computer prints it enough times, it will magically become true.

Even so, the process was fraught with peril. We didnt know how to program,so a tiny syntax error was impenetrable to us. If the program didnt work,which was often, we started over from the beginning.

At the back of the stack of pages was a real monster: a program that took upseveral dense pages of code. It took a while before we worked up the courageto even try it, but it was irresistiblethe title above the listing wasTunnels 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?

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 acharacter generator for the table-top game and not a game in itself.) But thedie was castfrom there on out, I wanted to be a game programmer.

When I was in my teens, my family got a Macintosh with QuickBASIC and laterTHINK C. I spent almost all of my summer vacationshacking together games. Learning on my own was slow and painful. Id getsomething up and running easilymaybe a map screen or a little puzzle but as the program grew, it got harder and harder.

Many of my summers were also spent catching snakes and turtles in the swampsof southern Louisiana. If it wasnt so blisteringly hot outside, theres agood chance this would be a herpetology book instead of a programming one.

At first, the challenge was just getting something working. Then, it becamefiguring out how to write programs bigger than what would fit in my head. Insteadof just reading about How to Program in C++, I started trying to find booksabout how to organize programs.

Fast-forward several years, and a friend hands me abook: Design Patterns: Elements of Reusable Object-Oriented Software.Finally! The book Id been looking for since I was a teenager. I read it coverto cover in one sitting. I still struggled with my own programs, but it wassuch a relief to see that other people struggled too and came up withsolutions. I felt like I finally had a couple of tools to use instead ofjust my bare hands.

This was the first time wed met, and five minutes after being introduced, Isat down on his couch and spent the next few hours completely ignoring him andreading. Id like to think my social skills have improved at least a littlesince then.

In 2001, I landed my dream job: software engineer at Electronic Arts. Icouldnt wait to get a look at some real games and see how the pros put themtogether. What was the architecture like for an enormous game like MaddenFootball? How did the different systems interact? How did they get a singlecodebase to run on multiple platforms?

Cracking open the source code was a humbling and surprising experience. Therewas brilliant code in graphics, AI, animation, and visual effects. We hadpeople who knew how to squeeze every last cycle out of a CPU and put it togood use. Stuff I didnt even know was possible, these people did beforelunch.

But the architecture this brilliant code hung from was often anafterthought. They were so focused on features that organization went overlooked. Coupling was rife between modules.New features were often bolted onto the codebase wherever they could be madeto fit. To my disillusioned eyes, it looked like many programmers, if they evercracked open Design Patterns at all, never got past .

Of course, it wasnt really that bad. Id imagined game programmers sitting insome ivory tower covered in whiteboards, calmly discussing architecturalminutiae for weeks on end. The reality was that the code I was looking at waswritten by people working to meet intense deadlines. They did the best theycould, and, as I gradually realized, their best was often very good. The moretime I spent working on game code, the more bits of brilliance I found hidingunder the surface.

Unfortunately, hiding was often a good description. There were gems buriedin the code, but many people walked right over them. I watched coworkersstruggle to reinvent good solutions when examples of exactly what they neededwere nestled in the same codebase they were standing on.

That problem is what this book aims to solve. I dug up and polished the bestpatterns Ive found in games, and presented them here so that we can spend ourtime inventing new things instead of re-inventing them.

There are already dozens of game programming books out there. Why writeanother?

Most game programming books Ive seen fall into one of two categories:

• Domain-specific books. These narrowly-focused books give you a deep dive on some specific aspect of game development. Theyll 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.