Beginning Game Programming

Well, it’s been forever since I updated. I can assure you, if something interesting had happened, I would have blogged about it. As it stands, several uninteresting things happen (I went to work! I ate good meals!) and for such banalities you can follow me on Identi.ca or Twitter, conveniently also reprinted at the bottom of my left-hand sidebar, if you don’t have an account with the latter sites.

A few days ago, however, a friend of a friend asked how one goes about getting into game programming. I was fairly happy with my response, so I reprint it here roughly verbatim. Note of course that this is my experience… your mileage may vary.

It’s somewhat intimidating to just dive on into games programming. I had several aborted tries before finally getting to a point where I think I understand the basic framework (or a basic framework).

So, where to start? Well, first thing’s first: lower your expectations. Whatever game you really want to make, put that on the backburner for now. Come up with a few simple prototypes just to find out how to put a game together—and I mean “game” in the most trivial sense. Something that takes input, displays ~~graphics~~ any kind of output, and has an internal system with rules and an end state. Maybe with a title screen, and a main game screen. Really, keep your first try basic, like re-making Pac-Man or something similarly simple. If you try to make a big game right up front, you’ll be caught over-designing the game’s rule system, as opposed to finding out how to put a functioning game engine together. You won’t learn how to make a game; you’ll just get bogged down in technical details, likely get discouraged, and possibly give up. This is one of the reasons for my several false starts at programming games.

As for opinions on engines to start with… well, that’s more a matter of personal preference. Your first few prototypes should probably be 2D, in which case I have to say that I’m partial to SDL (Simple Directmedia Library). It’s a nice library for creating a game window, displaying sprites, getting keyboard/mouse input, playing sounds, and so on (there are some good tutorials here). It’s low-level, which some might consider a downside, but I actually like the fact that it gives more control to the programmer. It’s written for C/C++, and my favourite point is that it’s cross-platform, so I can program for Linux, Mac, and Windows at the same time—though of course I had a few hiccups with the Mac version of Overbourn. Despite the small troubles, Overbourn serves as a nice example of a small prototype put together to become familiar with programming a game’s structure.

If you’re going the 3D route, OGRE is a nice library, again written (strictly) for C++ and again cross-platform, which always gets a huge ++ in my books. It’s extremely well-documented, and their forums (fora?) are very active and welcoming, so you can always ask more questions there. OGRE is purely a graphical engine though, so you need something else to handle input/sound/networking/etc… luckily, you can tie in OGRE with SDL, using the former for graphics and the latter for everything else. Technically, you can also use SDL and pure OpenGL for 3D games, but OGRE really does provide a great graphical library, so it’s simply way more practical to go the OGRE/SDL route.

I’ve mentioned “programming a game’s underlying framework” a few times, and I think that’s fairly important. From my point of view, this includes the fact that you’re going to have several game “states” (splash screen, menu, options, main game, and the like), as well as the fact that for each one, you’ll have to figure out what to do with input, what sort of internal state has to be considered, and how to render everything. These seem like fairly straightforward problems, but I caught myself spending a lot of time thinking about them, and had a surprisingly difficult time finding answers to what I thought were basic questions. However, I found a few good articles/tutorials here (particularly the first three or so). The lessons are built around Microsoft’s XNA and C#, but I found that they were my best introduction to the concept of a basic engine with several “screens” or “layers”, one for each game state. The engine then keeps track of which state is current, and calls the appropriate game loop functions for that state—essentially, Process (input), Update (internal game state), and Render (display results), as I like to call them. Ignore the language details, and the tutorials might be of some service.

Bon, so that just about covers everything I can think of. As I said: start small and simple; C++/SDL is good for 2D games; C++/OGRE+SDL is good for 3D games; and try to understand the basics of a game engine before you move on to complex things. Here’s hoping that’s enough of a starter to get you going. Do try to put a full project together; Overbourn itself wasn’t much of a game per se, but it was a completed package and I’m thoroughly happy that I went through with it.

Finally, make sure to bookmark GameDev.net’s forums. They are the very first place I go to if I’m having issues—so much so that I’ve found their search engine for Firefox’s toolbar. They’re that handy.

Hope this has been of some help. Happy coding.