Sean Eshbaugh

Web Developer + Programmer

Finally Learning to Make Games

One of my earliest aspirations I can remember seriously having was to be a video game developer. Sometime in elementary school it dawned on me that people actually made the video games I played every afternoon. There were grownups who got paid to dream up and create games. I wanted in on that because obviously, I naively thought, it must be as cool as playing video games.

When I was in sixth grade a friend and I decided we would attempt to learn to program and make our own games. He got his parents to buy him a book on C++ (It's been over 15 years so I have no idea which book it was) and we both started to read it. The first chapter was a bit of a dumbed down history of computers and programming which I had no problem comprehending. But with the second chapter the actual programming began. It took less than two pages for me to be completely lost and give up. My friend fared a little better and was able to get a compiler installed on his computer and even got a "Hello World" program working.

Turns out, learning to program is hard. Reading about programming is so easy an eleven year old can do it without much effort. I consider myself lucky to have grown up with parents who encouraged my love of computers if not my love of video games over homework. That encouragement is greatly responsible for my desire to make video games never really going away. It did, however, sort of lay dormant for a few years.

When I was 13 I started playing Ultima Online. Eventually I learned one could emulate Origin's servers and write their own custom scripts for the server. This was around the time I was taking Computer Science in high school and learning C++ (for real this time). I eventually rescripted large portions of the game and in the process learned a ton about interpreted languages.

In college I started to read books specifically about video game programming. I would always get stuck though. Rather than going into how to build a game and really design the whole system of parts that makes a game engine; the books I tried would really just get bogged down in the low level details of how to setup OpenGL or DirectX and drawing things on the screen. Don't get me wrong here. That is tremendously important knowledge if you want to make a game. If you don't know how a simple triangle is rendered and all the steps necessary to do even that it's unlikely the bigger picture will make any sense. But after a few chapters I always felt like I was spinning my wheels so I would stop reading and abandon my dreams for a few months. This has been an ongoing cycle for about 7 or 8 years now, each time with a different book that promised to teach me to make games like a pro(!).

The furthest I ever got was a "shooter" that was really just a camera that let you move in an empty space surrounded by a skybox and shoot projectiles. Sure, it impressed my mom, but I wanted to do more. And the code I'd hobbled together from books and internet tutorials just couldn't be turned into anything resembling an actual game.

All this has been a lead into what I really inteded to write about: a book that finally taught me something I felt was useful. XNA 4.0 Game Development by Example: Beginner's Guide by Kurt Jaegers. This book is exceptionally good for a host of reasons. The least of which is that it delivers on the title's promise to teach by example. Each chapter has well written, easy to understand, and clearly explained code for working games.

The "working" part is really the key here. Instead of examples that touch on one isolated subject, leaving it up to the reader to tie it all together into something that can be played, the author presents complete games. The reason this is such a big deal, for me at least, is that it lets you see all the parts and more importantly where they all fit together. That's what I had always felt I was missing. The bigger picture. The overall flow of the entire system. Yes, knowing how to normalize the camera's view matrix is important, but without knowing how you're going to keep track of the state of the things in your scene it's close to useless. XNA 4.0 Game Development actually addresses those things. And because it uses the XNA framework it skips over the boilerplate stuff.

I really can't emphasize enough how important that boilerplate stuff is. I don't want to be misunderstood as saying it should never be learned. However, abstractions exist for a reason. Every game ever made has a main loop and some sort of timing mechanism and a way to draw stuff to a screen. Really, the implementation details of those things aren't important to the actual logic of the game and they really shouldn't be too important to the actual game play. After spending a few weeks with XNA I feel like it's let me do what I've always wanted, focus on the game, not the graphics library. This is the same reason I love Ruby on Rails. It abstracts away the boilerplate code that nearly every web application needs and lets me focus on my application, not reimplementing the wheel.

I hate reimplementing the wheel. Mostly because I know that no matter how good of a programmer I become, unless I become a dedicated wheel maker, I will never be as good at making wheels as the people who think about making the wheels all day every day because that's their job. And by wheels I mean the lower level stuff that any useful program sits on top of, whatever it may be. Most of the time the stuff that sits below my level of concern is only incedental to the problem I'm trying to solve. Without it I can't get anywhere, but that doesn't mean I have to be the one to build it.

Failure to recognize this is the reason all the other game programming books I've tried haven't clicked. Drawing a series of polygons to the screen that makes a cube or moving a 3D character model from A to B isn't what I'm trying to do. But they're all written as if it is the problem I've set out to solve. Very little of the code in XNA 4.0 Game Development is even XNA code. Rather it's video game code that happens to use XNA as its means of getting things done. I'm here for the high level architecture and logic, and the fine people at Microsoft responsible for XNA and Mr. Jaegers seem to understand that very clearly.

I'm admittedly pretty late to the XNA game, but I suppose I wouldn't have appreciated it as much earlier in my programming career. I've been a fan of C# for years now though, it's probably the best thing to come out of Microsoft. It's not my favorite language, but if I'm on Windows it's my first choice by a mile. XNA supporting C# is a big part of why I've been enjoying learning how to use it.

When I finish the book I plan on making a game of my own. For the first time in my life I think I just might be able to do it.