Anatomy of a Gamedev: The Programmer

By Isaac Smith

When I first started looking into game development, I basically thought that gamedevs were computer scientists gone rogue. (Roguelike pun not intended, but whatever.)

Much to my delight and chagrin, it turns out that’s not the case. Sure, you find some CS people roaming around the game development world (most often without actual Comp Sci degrees), but game design is a very different animal, and the differences between the two are interesting. And they are, in fact, what I’m going to be covering today!

To understand what the heck makes gamedevs unique (like Mr. MicMillen here on the right), we’ve got to understand what goes into the turtleneck-wearing Javanauts that go into Computer Science. The skills that regular CS people learn very often doesn’t serve them well at all in the realm of game development. Consider the following!

Big-O notation: Big-O notation is a “simple” (often mind-numbingly not simple) way of expressing how much computing power a certain thing takes. You get things like “logarithmic”, “linear”, “linearithmic”, “quadratic” (uh-oh), “exponential” (hoooo boy, something is very wrong here). They involve a lot of theory and quite a bit of math. But for the majority of game developers (who develop smaller games), they’re mostly irrelevant. They gauge the efficiency of an algorithm as it starts to deal with large numbers of items, but most games deal with fantastically small numbers of objects. (With the notable exception of games like Minecraft, but Minecraft is the exception to pretty much every rule here and only exists because a bunch of dedicated people had serious computer science, math, AND game development chops.) Even if you have 100 enemies on the screen, the amount of time it takes to process 5 calculations for each and 20 calculations for each is negligible. Your computer can do it 60 times a second and still have enough power to download an entire season of Game of Thrones simultaneously.

Non-object-based programming languages: To successfully become a super nerd computer scientist, you need to gain a bit of experience with different types of programming languages. The most common is Lisp, a dynamic programming language. I’m not going to get into the nitty gritty of what’s what, but games are pretty much made up of objects… which dynamic and other non-object-based programming languages (predictably) don’t have. There are many dynamic, aspect-oriented, and other programming languages, but the knowledge you gain of them in your time spent getting a degree will only serve as a curio while developing games. (That said, there is a community of dedicated Lisp game makers, so it can be done. You really just shouldn’t.)

There are tons of other specific things that comp sci people get deep into that gamedevs never touch, but a lot of them are quite technical and tough to explain, so I’m just going to say “Trust me, or spend a long time on help forums” and move on my way.

By this point, you probably understand that computer scientists are generally well-rounded in their knowledge of computer-y things (if not social-y things… see pictures above for proof). Gamedevs, on the other hand, are coding gladiators who are really good at hacking and slashing their way through the game making process.

Gamedevs excel ridiculously in a few arenas of computer programming. They kind of HAVE to, to stand a Sno-cone’s chance in hell of successfully completing a game.

Being Organized: Yep. Number one skill of successful game developers has nothing to do with coding (and everything to do with making a working program). I gained some insight into this topic in an interview with Jeremy Ingham from Arclight Worlds (which you should have already read HERE). The amount of organization involved in even a modest game is STAGGERING. Flowcharts, gamestate management, event handling, garbage collection and data storage are just the tip of the iceberg when it comes to how gamedevs deal with all the crap they’re creating. Do I store the constants I need in a separate file and then import it into the engine? What if I need it in the graphics definition file? Two imports, or handle the graphics initialization inside the engine? (If you have no idea what any of this means, I’m jealous.)

Imagine briefly how SAVE GAMES work. We take them for granted, but in reality, they’re phenomenally difficult to deal with. If you’re playing a 2-D platformer with items and cutscenes, you have to somehow efficiently store the player’s position, health, damage, entire inventory, gold, which level they’re on, the position and type and health of every enemy on the field, plus the position and ID of every item and piece of gold on the level. Add to that which cutscenes have been viewed (especially location-based cutscenes within the level), which treasure chests have been opened, etc. If you have a game that involves exploration like Don’t Starve or Metroid, you have to keep a record of what’s been revealed and what hasn’t. And you have to do this in a manner that’s both easy to store, and easy to read from when your game loads up.

Holy cow. Talk about organized.

Graphics-based programming: This one, you definitely get into with Comp Sci, but the breadth of knowledge you get even after developing a single game, successful or no, feels like your Java Graphics class final was the Shire and your current location is somewhere on the slopes of Mount Doom. And Sam wasn’t even there to help, unless “Sam” is a nickname of Stack Overflow and the handkerchief that soaked up all of your bitter tears.

Most programmers don’t deal with graphics much. Think about this: every server that’s ever been written had to have been written by someone who codes. Every signup form for a website. Every authentication protocol. Every bit of security in every website ever. There are billions and billions of lines of code written by brilliant programmers that have never even bothered with displaying images in more than a cursory manner.

When we get to game programming, it’s intense. Even a simple jumping action is a trial: how does the player’s image get from running to jumping? Standing still to jumping? Jumping to standing still? Jumping to running? How long is a jump when compared to the animation? Does the player move high enough to avoid their feet clipping the ground while the jump animation is playing? Considering all that crap, the amount of work that went into Samus Aran’s jumping in Super Metroid seems tremendous, and is one of the many reasons why I think that game is one of the best ever made.

Even after dealing with the jumping issue (precluding double jumps, wall jumps and that pesky Screw Attack altogether), dealing with atmospheric visual effects like those seen in games such as Lone Survivor is an impressive feat, even for games that are made completely of pixel art. And where I said that Big-O notation was relatively unimportant with regards to the efficiency of an indie game, how you process, produce, and render graphics is TREMENDOUSLY important and a complicated issue that there has been incredible discussion on for many years.

We talked about Minecraft earlier: in a modest view distance, there are 4.09 million blocks, each with 6 faces, some of which are often animated. I told you they were ahead of the curve by miles, but if they hadn’t found a way to make that drastically easier to handle, Minecraft never would have seen the light of day.

I wish I could go deeper into the topic, but the point is this: game developers aren’t normal programmers. It doesn’t mean they know more than any other programmer, but just that their knowledge is centered in very specific areas that make them really, really good at what they do. If you’re interested in learning the nitty-gritty of it, check out Invent with Python, a free online resource that teaches you Python by making games. Do some of the chapters, then go look at a normal programming tutorial and realize the enormous difference between the skills you’ve acquired and the skills of a typical programmer, even half an hour into making games.

And you haven’t even made a flowchart yet.

~Isaac