Introduction

I grew up knowing I would make games for a living. In 4th grade, I stayed inside during recess so I could program text adventures in Basic on my teacher's Apple II. In high school, I attended Digipen's summer workshops and learned how to program 2D graphics in Visual Basic. In college my Friday night social life generally involved a game of StarCraft followed by a marathon pixel-pushing session.

I started at least a couple dozen game development projects between the time I was in elementary school and when I graduated from college fifteen years later. Some of them were solo projects that I worked on just for fun, some were group projects that I started with friends in college, and a few I actually intended to get published and commercially released.

For at least a decade though, all my game development endeavors had one thing in common: none of them were ever finished. I had a different excuse for every project. Maybe the hardware platform I developed it for was becoming obsolete. Maybe my friends and I had just come up with a great idea that we had to start working on right away. Maybe I was just caught up in school work. Regardless, for one reason or another, none of my ideas ever became real games.

Thankfully, I was eventually able to break my habit of leaving projects unfinished. I started a company called Riverman Media that has now published two casual PC games and a WiiWare game, and has several more iPhone and WiiWare games in development. I've also contributed to about a dozen published retail games including Contra 4 and Sigma Star Saga.

This article will discuss the mental shifts I had to make before I was able to complete and release my company's titles.

Why do most indie projects fail?

There are three broad categories of issues that led to the failure of my early game development efforts:

1. Some of the projects were doomed from the start. They were way too ambitious, programmed for the wrong platform, or started by a team that wasn't quite up to the task.
2. A linear development cycle led to burnout and misguided design decisions. The traditional waterfall process of design, implementation, and testing, doesn't work well for small teams or for games in general.
3. We worked really hard, but on the wrong stuff. It's easy to get distracted by tasks that don't directly contribute to the final product, like building tools and editors. Most small projects don't need these things.

Setting the Stage

As tempting as it is to launch directly into development, there are some key decisions you can make before you start that will give your effort the best possible chances of succeeding. These decisions include choosing a dedicated and capable team, determining an appropriate platform, identifying your team's core strengths, and defining self-imposed limits.

Choosing the right team

Creating a game will take months of your life and hours of your free time every single day. Not only that, but most independent developers create their products without regular pay. Therefore, there's no denying that making an indie game requires some serious devotion!

Let's face it: Lots of people think they want to make games. In my experience though, not so many people actually want to sacrifice other aspects of their lives enough to tackle a project of even modest ambition. This is totally understandable! After all, making an indie game demands a gargantuan amount of work and often has very little payoff. The truth of the matter is, though, that you want people on your team who are willing to do what it takes to get the job done and help you complete your project.

Looking for devoted individuals is trickier in practice than in principle. Many independent game projects are started by team members who have never created a game before. So how can you tell if someone is likely to stick it out to the end?

The key is to look for demonstrated self-motivation. Has the person worked independently on any other games or game-like projects? Perhaps a mod, tool, or some concept art? Were these projects finished? If you go to school with the individual, another good indicator is class participation and grades. Good test scores may not always indicate a good game developer, but at least they show that someone is willing to work for positive results.

Another aspect to consider is team size. I've found that a good rule of thumb is to keep your team between two and five people. More than five people can be difficult to manage without a definite leadership hierarchy, and I've found that it's hard to stay motivated working solo. You won't be able to create the next big MMO with a three person team, but you are a lot more likely to finish your game!

Choose the right platform

There are a lot of great platform options for independent game development these days. I like to choose the platform before I choose a game concept. The platform has a fundamental impact on the features and limitations of a design. Think of how different a fighting game on Wii would be from a fighting game on iPhone!

Also, platform choice directly affects how your game will be distributed and sold. Until recently, Nintendo DS games had to be published and shipped to retailers. This is often a difficult proposition for non-mainstream titles. On the other hand, XBox Live and WiiWare were practically created just so independent developers could publish their games without a middleman.

Here's a rundown of the development platforms that my team has investigated closely. This is by no means an exhaustive list, so don't be dissuaded if your platform of choice isn't discussed here. Think of this as a springboard for doing your own analysis:

PC / Mac Download

o Pro: Lots of development information available
o Pro: Easy to distribute (no publisher required!)
o Pro: No "gatekeepers." Anyone can make a PC game.
o Con: Lots of competition and it's hard to get a project noticed.

Web Based (Flash, Java Applet, or Silverlight)

o Pro: Very easy to distribute for free
o Pro: Tools designed for newbies
o Con: Hard to distribute for money
o Con: Some technical limitations

WiiWare / Xbox Live

o Pro: Less competition
o Pro: Wide mainstream exposure
o Con: Tough approval process
o Con: Very little community support

iPhone

o Pro: Easier approval process
o Pro: Suited for small projects
o Pro: Generous Royalties
o Con: Saturated with competition

In general, if you're just making a game for fun and want it to reach as broad an audience as possible, I'd consider using a web-based platform. If you'd like to make some cash, I'd suggest WiiWare, XBox Live, or iPhone.

Know your strengths

Once you've chosen a team and a platform, it's a good idea to take an assessment of your team's strengths. With a small team, chances are that you'll have areas where you excel and areas where you're less experienced. It's important to choose game concepts that capitalize on the things that your team members are good at!

For example, I happen to have a lot of traditional experience painting landscape backgrounds. I've always loved the outdoors and my first job in the game industry was as a background painter. Therefore, we've exclusively chosen projects that make use of painterly backgrounds and outdoor scenery. Could I make a character-driven game that takes place on the inside of a space station? Probably, but I'd be developing an entirely new set of skills rather than drawing upon years of experience making outdoor scenes.

Similarly, if you've got a great network programmer on your team, make a multiplayer game. If someone on your team wrote her thesis on group AI, make a game with lots of interacting characters. If your artist loves vintage comic books, make a cell-shaded or hand-drawn game!

There's plenty of time for learning new skills in the future. But mastering a new technique can take years. If you want to make a game now, I'd suggest taking advantage of the skills that you already have.

Set Limits

Game development is completely unbounded as an art-form. Anything that you could do in a movie, book, musical recording, or painting could be put into a game. If you wanted to go really crazy, you could even design your own hardware to provide the player with novel forms of interaction.

Despite the rich array of options available to you as a developer, it's important that you set your own limits so that you can focus on elegant design and implementation. It has been shown time and time again that limitations boost creative output. When "the sky's the limit" our minds take so many tangential journeys that it's hard to accomplish anything concrete. Too much freedom creates design churn and indecision.

Defining self-imposed limits before you start a project is the best way to overcome this. For example, Riverman Media generally sets the following two limitations for ourselves:

1. Our games are always 2D. I'm the primary artist, and I'm significantly more experienced with 2D than 3D. Therefore, we don't even consider 3D as a design choice.
2. We don't create networked games. My brother, my company's main programmer, is a brilliant coder. However, he doesn't have a lot of experience with networking. Also, networking requires servers and lots of additional testing. Therefore, we leave it totally off the table and focus on single-player or same-screen multiplayer games.

You might think that setting limits will stifle your creativity. The opposite is true though. Once you've set some rules for yourself, your brain will immediately start thinking of ways to create the coolest game within those parameters. Your creativity and productivity will both see dramatic improvements!

Thought experiments

One of the trickiest parts of software development is estimating how long a project will take to develop. It's important to have a reasonable guess at how long a game will take to create so that you can decide if it's a realistic project for your team.

In general, programmers and artists are terrible at creating schedules for themselves! I've found that the reason for miscalculation is that we often forget supporting details when we consider a feature from a broad perspective.

Take, for example, a menu that is displayed when the players pauses your game. At first this might seem ridiculously simple, and you might think, "No problem! I can code that in an hour." Once you consider it more closely though, you realize that the menu has to be slightly different for each of your game's fifteen modes, your platform provider requires a screensaver for static images, and the networked aspect of your game should have idle timeouts that boot inactive players, which need to supersede the menu.

Suddenly, a minor, hour-long project is going to take a week to implement!

My team uses "thought experiments" to avoid drastically underestimating the complexity of game's features. The basic idea is to imagine playing your game from the moment it's loaded. Step through the title screen, main menu, the gameplay, winning, losing, viewing high scores, being disconnected, choosing characters, and using in-game HUDs. Be meticulous. The idea is to identify every button, text field, graphic, transition sequence, and animation that your game might have. Only then will you have a realistic estimate of the scope of your project!

Here are some diagrams of thought experiments we made for the iPhone version of our game Cash Cow:

In the end, Cash Cow ended up being 10% gameplay code and 90% code that supported details like menus and transition sequences. Luckily, this wasn't a surprise to us because our thought experiments identified a majority of the game's intricacies! Knowing this before-hand helped us plan ahead.

Iterative Development

There's a secret to game design that I only recently discovered: Great games are created through trial and error.

StarCraft may be the most well-balanced pinnacle of RTS bliss ever created, and Super Mario Bros. 3 might have the tightest, most responsive controls of any platformer. But the designers at Blizzard and Nintendo didn't just pull these games out of their heads and implement them straight away in their final form. It was only through years of prototyping, play-testing, re-working, and refinement that these games became the classics we know them as today.

Pick a project and go

A common misconception is that a great game starts with a great idea. I don't believe this is true at all. Consider the concepts behind some of the most successful and respected games: StartCraft is a real-time strategy game that takes place in space with somewhat generic sci-fi characters. Zelda is an action-adventure that stars a boomerang-wielding Peter Pan impostor. Resident Evil is a third-person game about blowing off zombie heads with a shotgun.

None of these are especially novel ideas. They're solid and time-tested, but nothing that a 5th-grader couldn't have come up with. StarCraft, Zelda, and Resident Evil are genius games because their creators painstakingly refined the details of the games until they were virtually flawless.

My point is this: don't labor over your choice of a concept too much. It's tempting to wait until a lightning bolt of brilliance strikes you before you commit to an idea. If that happens to you, great! But if it doesn't, and you still want to make a game anyway, just pick something interesting and go with it. If it's reasonably cool, not excessively ambitious, and something that you think you'll be able to stick with for a few months, then the concept is fine.

You'll be much better off spending your time refining your actual game than laboring over the perfect concept.

Iterative Design

We're all taught to measure twice and cut once. Don't commit to something until you have it carefully planned out! Avoid repeating work at all costs!

Of course this philosophy makes a lot of sense for construction projects, and anything else where the task, goals, and procedure, are clearly defined. But it doesn't work well at all when you're trying to make a game.

Games are about fun, and, increasingly, other emotional responses. Due to the fact that the effect of a game is rooted in human psychology, it is almost impossible to predict from a design alone whether it will resonate with audiences.

Luckily, it is very easy to tell whether a game is fun or not after it has been made. All you have to do is call some friends over to play it!

That's where iteration comes in. You obviously don't want to make an entire game, show it off, and then make the entire game again based on their feedback. Instead, it's better to think in terms of structured prototypes.

Prototyping is a fairly common task among professional and hobbyist game developers. However, prototypes are often meandering and freeform undertakings that are created without specific goals in mind. More often than not, a prototype is really just an unpolished version of the final game, but with bad programmer art!

This type of prototyping can be useful, but prototypes are even more effective with a more structured approach. My team generally tries to follow this procedure:

1. Ask a question about the game's design
2. Determine what gameplay elements will need to be implemented to answer the question
3. Build a prototype with the identified elements
4. Test the prototype with players
5. Refine the game
6. Come up with new questions and repeat until the game is complete

Let's walk through a quick example. Say that your team wants to make a realtime strategy game about swarms of warring insects and other arthropods. A question for your first prototype might be, "What sort of strategic mechanics are afforded by using bugs as units?"

Think about what core elements would help answer this question. Choose the most important ones to explore in the first prototype. For example, I might include these mechanics:

• Four types of bugs: Ants, wasps, scorpions, and spiders
• Each type bug has artificial intelligence based on its social structure: Ants colonize and protect the queen, bees swarm and protect the hive, scorpions are solo predators, and spiders spin webs to trap their prey.
• Hive-minded creatures (ants and wasps) are controlled as a group with sweeping mouse gestures, while solo creatures (scorpions and spiders) are controlled as individual units.

After defining the prototype, implement it in presentable form. The graphics don't have to be perfect and it doesn't have to have an epic musical score, but remember that really bad production values can be a distraction to players. Use your judgment to include just enough polish so that your testers will be able to give the experience a fair verdict. Once your prototype is ready, hand it over to players and see what they think!

Here are some tips to help you get the most out of play-testing:

• Favor the comments of players who are unfamiliar with your game. The uninitiated won't be as tainted by previous iterations.
• Try not to explain too much. Watch closely for confusion or situations where the player is stuck. These are areas that will benefit from improvements.
• Keep an eye on players' faces. You can learn a lot from facial expressions. You'll be able to spot surprise, frustration, boredom, and a wide range of other responses.

Once you've had a chance to watch a handful of players try your game, use your observations and their comments to answer the initial question. Some hypothetical feedback about the insect game might be:

• Players generally liked the idea of controlling armies of bugs.
• The different types of movement (solo and swarm) provided a novel experience but will need to be carefully balanced.
• Interactions between the wasps, which can fly, and the ground-based units felt unnatural.
• Players didn't feel the game captured the feel of the microcosmic world of very small creatures.
• Some players lacked a clear goal. Winning and losing conditions were not obvious.

From these results, we can create a new prototype that might include the following features:

• Capture the flag mechanic to give players a clear goal
• Different strata of terrain, such as underground, ground-level, and above-ground, to more clearly define interactions between creatures.
• More terrain-based mechanics, such as camouflage and burrowing.
• Graphics made to better reflect miniature world, such as giant leaves and flowers.

If you go through this cycle enough times, chances are you'll eventually hit upon a really cool design!

Note: Iterative game design, or as he calls it, "The Loop" is explored in detail in Jesse Schell's fantastic book, The Art of Game Design.

Ditch the design document

Now I'm going to deliver a bit of good news! You know that design document that everyone says you'll have to write? Go ahead and skip it!

Design documents are way too rigid for iterative development. They take a long time to write and nobody bothers reading them anyway. As long as your team has solid, consistent communication, design documents are a waste of time.

Instead, I like to use a design notebook. We use Riverman Media's design notebook partially as a brainstorming tool and partially as a to-do list. It's really just a freeform collection of ideas where we can record anything we want concerning our games.

Here are a few random pages from our notebook.

Having an informal sketchbook for our ideas helps us keep our creative momentum flowing. We can write down ideas as soon as they come, and it's portable enough to take to dinner! You can doodle concept art, sketch flowcharts, and stick on post-it notes. It's incredibly flexible and accessible. Almost all of Riverman Media's design documentation exists within the pages of our notebooks. We have very few digital files describing our designs.

Build in polish

Polish is all the little details that make your game an intuitive, vibrant, and refined experience. Polish comes in the form of graphic effects, tutorials, scene transitions, sound effects, special animations, and just about anything else that isn't required by the design but that make the game feel rich and come alive.

Instinctively, it makes sense to hold off polishing your game until after the core mechanics are already in place. After all, isn't it better to spend time testing core mechanics before you commit to all the trivial details?

The problem is, polishing generally requires big changes to code, and making these changes at the last minute could easily break it. Or, even more likely, you just won't bother polishing at all. Because of this, it's best to build polish in your code from the ground up.

A classic example is found in block-based puzzlers like Tetris. In prototypical form, the blocks would fall in discreet, grid-based, units. However, an expected modern refinement is for blocks to animate smoothly from grid unit to grid unit. This isn't required by the game mechanics, but it does look nice.

Unfortunately, making the blocks fall smoothly is almost impossible to add later without ugly and dangerous hacks. If the code wasn't built to support it, there probably won't be a clean solution.

On the other hand, it doesn't make sense to include this feature from the start, because your prototypes should focus on game mechanics, not incidental visuals. So what do you do?

The answer is painful: Write the game once without polish, and playtest it. If the design works, write it again but with polish built in. The code re-write will hurt, but not as much as debugging ugly code will hurt later. And, as a bonus, re-writing your code will encourage the iterative refinement that will make your game better. Do not fear refactoring!

Work smarter and harder

Now you've got a working concept for your game, and you understand that an iterative process will be the best way to forge a solid design. Where do you go from here? What do you actually do?

This section will discuss how to apply your energy effectively so that you can focus on tasks that directly contribute to your game.

Tools and editors

I've started many game development projects where my first instinct was to build a full-featured editor or tool to facilitate creation of design assets. I love imagining myself using a really slick, custom-built program that I use to build my level designs, AI patterns, and puzzles.

Luckily, our lead programmer, who would have to code it, always gives me an emphatic "no" when I ask him for such a tool. Why? Because he knows it's a waste of time.

The fact is, unless you decide to include an editor with your game, players will never see your slick design software. It won't spread word of mouth, it won't beautify your screenshots, and it won't tighten your game's controls. If you're on a small team, an editor is a luxury you probably can't afford.

Of course, you have to design levels for you game one way or another. My suggestion, especially in the prototyping phase, is to hardcode the levels in whatever language you are writing the game in. Using arrays, constants, and whatever other data structures your game might employ, simply create the assets in code. This might seem like a programming faux pas, since it violates the separation of data and control. However, as long as you use common sense source organization, your code will maintain its elegance and readability.

There are several compelling advantages to using the hard-coded design approach:

• Your compiler takes care of parsing and formatting for you. You won't have to spend extra time designing and troubleshooting file formats and serialization routines.
• Your levels can easily be adapted to changes in design brought about by iterative development. You won't have to rebuild your editors (and levels!) every time you make changes in the game's mechanics. You can just adapt the code as needed.
• It is easier to place objects with precision if you're defining the positions of objects with numbers instead of eyeballing it. Even in commercial games, lots of bugs are caused by sloppy placement of objects in graphical level editors. If you've ever fallen through an invisible pit or been stuck in an invisible wall, you know what I mean.
• If you're as much of a perfectionist as most game developers are, designing a nice editor will take as long as designing your game!

Chances are, once you've created a few levels in code, you'll realize that you didn't need a fancy editor anyway. You'll be solving all sorts of other design problems, polishing the art, and showing your game to playtesters. The last thing you need to be thinking about is a snazzy editor that nobody will ever see.

Collaboration and scheduling tools

Along the same lines, I'd suggest you consider avoiding the use of collaboration, scheduling, and bug-tracking software. Products like MediaWiki and Bugzilla are great for globally distributed group efforts; however, for small, local teams, they take more time to use and implement than they save. I've spent hours producing pretty content for Wiki pages, when I really should have been working on the game itself.

Nobody will ever see your fancy, Web 2.0 enabled, design database. Redirect all that creative energy to your game!

Standout technology

Instead of spending your time on editors and groupware, you might consider implementing one or two innovative technologies for your games. A lot of the most groundbreaking and successful games have relied on new, cutting-edge, technologies for some of their core mechanics. For example, the original NES Legend of Zelda was one of the first console games to have a battery-backed save feature. Zelda's design was changed dramatically by allowing players to retain their progress. A play session was no longer limited to a few hours. A game of Zelda could take weeks, months, or in my case, years!

My point is that technologies can make your game stand out and facilitate new ways of playing. For our game Primate Panic, we developed an elaborate system of 2.5D parallax backgrounds to make the world feel more rich and deep. Although this feature wasn't as revolutionary and fundamental as Zelda's save feature, it made the game stand out and we have received lots of positive comments.

Of course, you don't want to use technologies as a crutch. Some physics-based games these days seem to exist entirely because the programmer wanted to play with a physics engine. Instead of using interesting play mechanics, they rely on impressing the players with realistic physics. This is a common trap of new technologies. Conversely, games like World of Goo use physics as a way of achieving a great design, rather than relying on physics as the design.

Conclusion

Over the years, I've learned that creative process is what drives successful creative products. A great game is the culmination of all aspects of its development methodology. Choices like team composition, development paradigm, and product scope have a direct impact on the viability of a game implementation effort. By making sure your project is built on a solid foundation, by using iterative design, and by focusing solely on work that will affect the final product, you will be poised to created polished and memorable experiences for players.