Finishing a Full Game

Michael
July 31st, 2004

Games can be big business, but they can also be a hobby. Quite a few people build games on their own time. And why not? Making games can be fun.

Sadly, the majority of hobbyist games never reach a completed state. Some may be playable, but most are not. Even if the author had the best intentions going in, the games never even reach beta status most of the time.

This article takes a look at how to choose an achievable scope and examines the hobbyist game developer's most common pitfalls.

The Steps

Technically speaking, creating a game can be summarized by a three step process.

First, you must adopt or create supporting routines to take care of mundane tasks such as image loading, memory management and joystick initialization.

Second, you build art assets for your game. You need at least placeholders before you proceed.

Finally, you have the sound basis required to develop your game. This is the time to write your gameplay code and build your levels, generally speaking.

The funny thing is, the majority of games never get past the first stage. Too many developers visualize technical perfection and see it as an achievable milestone early in their game's development, which brings us to pitfall #1:

Pitfall #1: Refactoring your tech when it is good enough.

I don't care if money isn't a factor, you're still trying to beat the clock. Instead of being handed a deadline, the race is psychological. You're trying to get the game done before your ideas become tired and boring to yourself and you feel compelled to start something new.

You need to get through technology development as quickly as you can. If you disagree with this statement, you care about something else besides finishing your game. This is a conflict of interest, and you need to sort this out before dedicating your time to your game.

The best programmers know when to stop refactoring and when to deliver without relying on outside forces to force them forward.

Pitfall #2: The almighty pipeline.

When working on a commercial game, a decent producer will learn the costs of building content for a given technology. This is factored in when evaluating the developing team's proposals. This is the content production pipeline, and every game has one. Commercial games have massive pipeline requirements which become even more insurmountible with every passing console generation.

So then, why would it make sense to make your technology mimic the hottest thing from Id Software? Even if you were able to conjure up an engine on par with Doom 3's (and you aren't going to without a team sanity checking your work by creating a game in parallel) you'll never be able to produce enough content to make your endeavor worthwhile. This doesn't seem to stop a shocking number of would-be game developers who get caught up creating content for a pipeline that is not designed for the people who will be developing in it.

Critically examine every feature before implementing it. Scrolling means more content is necessary. Ogg Vorbis means you're playing music for ears attuned to quality production values. Multiplayer means having to carefully manage arcane game states. (What were you planning on doing when client 3 is unacked-disconnecting on client 1 and disconnected on clients 2 and 4?) Were you planning on testing your fallback DX5 software rasterizer on Matrox cards before release?

Some features cause your pipeline to bloat, and some make life a little easier. Orion, Frogtoss's tech, has remote debug logging. It does not have bump mapping. If you can, place higher priority on features which make life easier, not harder. Game development is tough enough.

Don't build your pipeline by accident. Build it by design.

Pitfall #3: Non-commital Componentization

I can't count the times I've walked in the door at 8 in the morning, to find a bleary eyed programmer leaning back in his chair, with a satisfied look on his face. "No component depends directly on any other component." He then fires up his build of the game, and I watch a 60% complete implementation of the feature whiz by.

While it may be good practice to not shove DirectDraw code into your game logic, encouraging extreme componentization behooves the fact that you will most likely be compelled to throw away the majority of your code on the next game anyhow. You're probably using C++, which means you already have the annoyance of declaring function prototypes. Defining interface or intermediary classes increases the time necessary before you get results. Standardize and organize when you know you've got something cool. That could possibly mean waiting until the second game before defining your generic interfaces if you must at all.

With Orion, we have a core library subset which we unabashedly depend on throughout our codebases. There are satellite "toolkits" such as the interface or networking components. These still depend on the core library, but not on each other, and the dependency is only one way. I can #if 0 out the networking toolkit and the rest of the engine will continue to function. Not sexy, but it gets the job done.

Pitfall #4: Exploration Games

The last sign of big budget game envy: exploration games. Exploration games are the underlying design direction in some of the most successful titles out there. It is also the cornerstone of big budget single player titles: consumption of content.

Rather than have your users consume content for fun, pick a gameplay idea that works in a small play area. A few years ago, I would have recommended a puzzle game, but that genre's pretty well sewed up.

Please do not attempt to make Metroid Prime, or Wind Waker. While they are wonderful games, you cannot create a spiritual sequel to either on weekends.

Summary

The majority of hobbyist developers imitate big budget development houses. This is an insane undertaking. Independent movies don't have big explosions and million dollar effects; they focus on strength areas like plot and storyline.

In my opinion, games do not have a successful and vibrant independent underground movement like movies and music. There are no largely successful independents left for beginners to look up to. As a result, the developers bite off more than they can chew and the work is never completed.

Ultimately, pragmatism is the only thing that matters. If you follow another God, your path may never lead to a finished product.

(Response bucket)

Michael
July 31st, 2004