Practical Tips for Independent Game Development
by Jacob A. Stevens

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.

Cash Cow (PC), Riverman Media’s first finished game.

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:

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.
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.
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

Contents

	Introduction
	Setting the Stage
	Iterative Development
	Work smarter and harder

	Printable version
	Discuss this article