Chi-Coder: Incoming Programming Rant.

Chi-Coder is my forum for sharing my experiences in game development.  This week I’d like to share some frustration about the harsh reality of game development.  It’s not meant to discourage you if you’re just starting out in the field, but I feel like as a developer with a platform where I can speak honestly I’m doing a disservice to the craft by not being honest about what actually goes into it.

Without making you wade through six paragraphs of rant before you understand my frustration, here it is; game development can be a lot more boring than it seems.  You see, like pretty much everybody who gets into game development, I was attracted to the field because I enjoy playing games.  The thing is, making games and playing games are two very different things, and as much as you might think you realize this from the outside looking in, it becomes so much more real when you’re working on an actual project.

There are several things that make game development boring but most of them revolve around the same annoying truth; game development requires a ton of tedious repetition.  Games like Assassin’s Creed, where the character beautifully moves through crowds, scales buildings, and performs feats of incredible acrobatic prowess all require immense amounts of testing and refining and retesting.  Every building that the character can climb up must be tested.  Can the character grab at all the right points?  Are there places where he shouldn’t be able to grab that he can?  When he grabs things do his limbs move in a natural way or do they stretch and contort?

Those problems are astronomically more difficult than anything I’ve tried to tackle, but the principle is still the same.  Everything has to be tested and checked constantly, and that vision that you have in your head of a huge sprawling game world filled with all sorts of things to do; it all starts to feel a little bit more weighty when you realize that something as seemingly simple as climbing a building is really a huge undertaking.

Let’s take Pong for example.  It’s about as simple of a game as one could possibly imagine, but even Pong requires the designer to answer a multitude of fundamental questions.  Here’s some of the things that you’d have to consider:

Is this a two player game?
If so, how do you deal with two inputs at once?
If there is a single player mode, what type of AI will have to be written to control the second paddle.
If there is a difficulty setting in the single player mode, what factors will determine difficulty?  Will it be the AI paddle’s accuracy, speed, etc…?
Will the paddles be able to extend off screen or will there be a barrier stopping them?
When the ball starts in the center will it pick a random direction to go?
if it picks an impossible direction like straight up and down, how will the game correct that?
Will the ball’s speed be set, or should it be random from round to round?

These are just some of the questions you’d have to ask yourself if you wanted to make Pong.  There are a lot more questions to be asked here, too.  Some of these questions have really complicated answers.  For instance, if you were going to implement a single player mode and thus an AI for the opponent, that’s not a trivial undertaking.  For an AI opponent to be worth playing it has to appear at least somewhat human-like.  It can’t simply track the position of the ball and always hit it back perfectly, that would be no fun for the actual human player.  So a complicated system has to be developed in order to make an AI opponent feel like a human opponent.  And this is still Pong we’re talking about here!  Imagine the type of AI that goes into a game like Madden Football.  Different coaches have different strategies, different teams have rosters that support different strategies.  Situations call for on the fly decision making.  The computer has to simulate all of that to the most realistic degree it possibly can.

The ten year old kid in all of us that wanted to make games because they seemed cool probably never had the Pong AI opponent’s decision tree in mind.  These are the realities of what making games becomes about though.  A million tiny piece of minutia that, when combined properly, feel like more than the sum of their parts.

A great game feels like more than just a series of programming statements.  The game worlds feel alive.  They elicit emotion.  They give the illusion that they’re created from more than ones and zeroes.  That doesn’t happen by accident though.  Mario games play so well because someone painstakingly tests and refines Mario’s controls until they feel perfect.  It’s the difference between him jumping 1.472 meters high and 1.471 meters high.  These little tiny things that go into making great games great are repetitive and tedious though.  They’re not the fun part of game development.  They are however, the most important part there is.

I think all of us who choose to develop games have a bit of visionary in us.  But if you’re a visionary, you know the trouble that comes with that.  You often times get caught up in the big picture, will little care for the minute details of what a project will entail.  The grand vision for an epic game overrides the fact that you have absolutely no idea how to turn your dream into a reality.  This post is meant to act as a reality check for myself, and all of you.  You can’t lose your vision, but you can’t ignore reality either.  The reality of game programming (of all programming really) is that it’s hard and repetitive and tedious.  Great games are not the product of great vision, they are the product of great execution.