In this great land of game development, I've seen more than my share of death. If I had one dollar for every game development team I've seen fail, I could fund the development of Duke Nukem Forever! It's always a sad thing when a group goes down for the count, leaving only a half-baked demo that crashes on startup as the only reminder of their great game idea. It's too easy to say that every dead development team died because of "lack of dedication." There are many circumstances where all the dedication in the world won't help the situation. By carefully looking at my own experience with now-dead development teams (both amateur and professional - in my pro career I've worked on a couple of cancelled titles), I've come up with several ideas about why teams fail, and what can be done to prevent them from dying. I'm presenting these ideas in "development order," meaning design comes first because that's what you do first when building a game, and implementation comes second.

This article was originally a 2-part series published on GameDev.net back in 2000. It was combined and revised by the original author in 2008 and included in the book Business and Production: A GameDev.net Collection, which is one of 4 books collecting both popular GameDev.net articles and new original content in print format.

Design Document? What Design Document?

For a team to succeed it needs a common vision, that is, everyone on the team must know exactly what he or she is aiming for. The best way to get that common vision is by writing down your idea. In the original version of this article, published on GameDev.net, I wrote: "the best way to get that common vision is through a big, fat, detailed design document." That's misleading - while you certainly need something about your design written down, a "big fat design document" isn't generally appropriate for indie teams. The most important thing is to nail down the areas of ambiguity. You should be able to play your game in your mind and answer every question that starts with "what if the player does this." You don't need 800 pages detailing every option, but you do need to think about the big issues before you start developing. Developing without a design document is like driving without a destination - ultimately, you'll burn a lot of fuel and end up somewhere you don't want to be. Learn to resist the "start developing it now!" impulse that always comes with a new idea, and instead concentrate on getting that idea fleshed out and on paper. NEVER start developing a game the same day you think up the idea for it. Wait, and write about it instead. Also, continuing with the driving analogy, if your design document is your map, remember to follow your map. Don't develop technical features that your design doc doesn't call for. As an example, if your design document doesn't specifically mention that you need seamless travel through your huge city, then don't spend time coding it. Many programmers go insane about creating functionality and "building an engine." If that's what you want to do, that's awesome - making an engine can be just as rewarding as making a game - but if you want to release a game, you should realize up front that the game, not the engine, is the priority. Aim for developing only what you know you need.

Too Many Requirements, Not Enough Resources

History has proven that the people who think they're invincible are the ones who usually get clobbered. Game development is no different, so it's important to make sure that you keep your head out of the clouds. I'm not saying you should be forever content with making 2D Space Invader clones. I'm saying you should think about the scope of your game, and your own abilities. It's OK to challenge yourself, and reach for a couple of features you're not sure you can do, but in general, you shouldn't be completely overwhelmed by your game design. Think realistically about the resources (number of people, tools, and amount of time) you have at your disposal, and don't bite off more than you can chew. Also, tasks that are technically easy can still take a lot of time. The fact that it's easy to make one level doesn't mean it will be easy to make ten levels. Numbers have a way of tricking developers into thinking something's easier than it is. Saying "this game will have 5 levels, with 5 different enemies on each level" makes it sound easier to do than saying "this game will have 25 different enemies." Be careful about such things, and be positive you know for sure what you're dealing with.

The "I Can Do Anything in a Week" Attitude

Along that same line - many indie game developers severely underestimate how long something will take, assuming an "I Can Do Anything in a Week" attitude. The vast majority of programmers significantly underestimate how long it will take them to code up a feature. It may not seem very important at first, but if you can accurately estimate how long things will take, and design milestones around those estimates, good things will come to you. Your game will get done, your teammates will respect you, and your team will have a good reason to feel proud of themselves. Good estimates, however, are very difficult to create. A good rule of thumb is to take your absolute worst-case estimate, double it, and then use that as your best-case estimate. You laugh now, but it's true. Here are some additional tips for making better estimates. There are enough books written on this subject to fill a library - search for "software project management" - but here are some basic tenets:

• Break down complex tasks. Say you've got a task like "create a renderer." That's huge. Break it down. What features do you need? Particle system? OK, maybe a week, but break that one down too. Mesh particles, sprite particles, both? How do they spawn? Do they collide? Continue breaking down complex tasks until you get an outline full of smaller, easy to estimate tasks, and then add up all the times. A good rule to follow is that no single task should take longer than 3 days. If a task looks like it'll take longer, it can probably be broken down further. Software that creates Gantt charts - like Microsoft Project - can be helpful here.
• Track your estimates. During development, revisit how long you thought it would take you to code that enemy vs how long it actually took. This will ground your future estimations, ideally giving you a "scaling factor" that you can apply. And of course, conduct post mortems on things fairly often to bring inefficiencies to light. For example, if creating those three levels took you way longer than you thought, is it because your editor sucks, or is crash-prone? If so, it may be worth fixing that problem to streamline the development of the remaining levels. That's an oversimplified example, but you get the idea.
• Find similarities in tasks. Relating a task you have to estimate to a task you've already done (or estimated) can give you better estimates. For example, if you have to estimate a task like "write an octree to speed up rendering," think to yourself, "hmm, that's a lot like that one time when I had to convert our renderer to using octrees. What did that take?" That's an obvious parallel, but you get the idea - often times a task that seems very unique is similar to one you're more familiar with, and comparing how it's similar, or how it's different, can bring to light subtasks or approaches you hadn't initially considered.

The Ego War

There's another, more subtle danger related to the "I Can Do Anything in a Week" attitude - The War of Egos. Quite frequently, members of indie game development teams will start competing against one another, showing off how quickly they can get something done. Programmers might race against artists or other programmers to see who can get the most done over a weekend. With restraint, this can be helpful and inspiring, but if it gets even slightly out of hand, it can burn out your team, lower the quality of your game, and possibly jeopardize its completion. In an Ego War, otherwise-sane programmers will rush insanely through code without properly testing or integrating it, and artists will rush ahead with their creative work without first making sure it's within code requirements. People stop talking, and problems start appearing. It's always better to spend time doing something right the first time. Keep team competition in check, curb your developer's egos (this is easier said than done), and remind everyone that they're all fighting on the same side of the battle.

The Dictatorship

A common symptom of a dictatorship is a team whose leader considers his fellow teammates "employees," even though he or she isn't paying them. Decisions are made on the "employee's" behalf, reducing them to unpaid cogs in a very badly run machine. Truth is, team members are paid in two main ways: money, or enjoyment, and if you can't afford to pay money, you had better make sure that there's more than enough enjoyment to go around. Promising future royalty cuts is NOT the same thing as money; regardless of how great you feel about your team and your idea, the fact is that the odds for failure are so high that royalty cuts are useless. Unless you're signing paychecks, your team does not work for you. So, it's imperative that your team is having fun. Your team members should be your friends. Your team should tackle tough decisions as a group, debate the design document as a group, and share in the grand game creation experience as a group. Developing games is fun. For some people, it's so much fun that they're willing to work 80-hour weeks for half their potential salary. If your team isn't having fun, there's something seriously wrong. Just because you've gathered everyone together doesn't mean that you can tell them what to do. The best teams are the ones where everyone is given equal input into things, and where everyone's considered an equal. The first rule managers learn is that they are enablers - their job is not to lord over everyone, their job is to clear obstacles and make sure that the team can move forward. They work for the team. But in some cases, some people are more equal than others. If you've put hard cash in something, you deserve to say where you want your money to go. If I put up $1000, and my team members each chip in $50, then yep, it's not a democracy, I get more say than everyone else. If I buy the snacks for the weekly meeting, I have final say over whether we're drinking Dr Pepper or Coke. But these are easy to spot exceptions; in general, the team should make the decisions, and make sure everyone has a reason to remain interested.

Exclusive Membership

Bad teams are more concerned about membership than creating games. If your team spends most of its time debating whether or not Johnny gets to join, you may want to get out of game development and go build a tree house instead. The only good reason why you shouldn't let new people join your team is size - it's more difficult to lead a 50 person team than a 5 person one. In general, however, you should be very open about who joins. If you must rely on criteria, I would suggest that you focus on dedication and follow-through potential instead of raw talent. It's better to have an average programmer who's dedicated and excited about the project than a guru who "might find time for it in a few weeks." Keep your doors and minds open, and don't waste valuable development time debating whether someone new gets to join. Of course, make sure that the people who are on the team - the people who are taking up a precious slot - are contributing. If someone's just along for the ride, that's a problem that the team needs to address.

Eating Dessert First, and the Infinite Alpha Syndrome

Beware the "Infinite Alpha" syndrome. This is where the project for some reason or another never manages to progress from alpha to beta (or, more rarely, from beta to gold). Far too often, it goes like this: an alpha version is made, showing off something cool. Six months later, another alpha version is made that shows off something else cool, but completely different. When asked about the change, the developers say something like, "Yeah, the old code was good, but it was a bear to work with. This new code is much better, much faster, and much cleaner." In effect, the game gets repeatedly rewritten, each time getting "faster" and "cleaner" than the last iteration, but never getting any closer to finished. A common cause of the Infinite Alpha syndrome is that too many developers "eat dessert first." That is, too many developers think that game development is all about implementing cool things; they don't realize that a significant chunk of time on each project needs to go to mundane (and less-tasty) things: in-game menus, saving/loading games, resource management, compatibility, scalability, etc. The game developers ignore these more healthy dishes and insist on eating dessert first. There are quite of few facets of game development that are flat-out boring, technical, complex, and arduous, and these facets do just as much (or more) for the game as the "cool" technology. Don't let your development team fill up on the tasty desserts of game development without also paying attention to the more bland (but essential) staples.

Burnout

Burnout is one of the greatest threats to the success of an indie project. All of a sudden a project that used to be fun to implement is now boring, hopeless, and arduous. Tired team members start to lose passion for the project, and they begin refocusing their efforts on other things. Developers say things like, "this project's become too complex; what we need is a really simple diversion game we can develop in a few weeks, so that we can 'take a break' from this project, and get back to it later." The sad truth is that 99.9% of the time, developers never return to a project they'd previously vowed to "get back to later." It's important to realize that burnout can never be completely eliminated. Burnout occurs at different times for different teams, but eventually, it will happen on your project. However, there are several things you can do to subdue its effects. Most importantly, don't bite off more than you can chew. The best way to limit burnout is to make sure that by the time it starts to affect your team, you're finished (or nearly finished) with the project. Everyone likes to see the light at the end of the tunnel; if the game will soon be complete, team members won't get burned out as easily.

Hot/Cold

The symptoms of this are easy to spot - your team members will work on the game for two weeks straight without sleep, and then won't touch it for two months. Then, after two months, they'll work nonstop for another few days. They're impatient, yet oblivious to the fact that they spent so long not doing the game. Hot/cold isn't the same thing as when your developers work all weekend on the game, and then ignore it during the week because they have other priorities (job, school, etc.). Developer focus doesn't need to be constant day-after-day to be useful. But at the same time, if a developer ignores the game for two months, then takes a week off of work to do nothing but code... that's hot/cold, and that's something to watch out for. Hot/cold developing leads to all sorts of problems. For starters, your team is much more likely to fall victim to burnout. Their attention will drift more easily, the things they produce will appear disjointed, and they may have problems seeing the big picture. Also, it's hard to re-establish a context after you haven't touched something in a long time, which makes it too easy to slip backwards and redo things you'd forgotten you'd already done, or to go around in circles, etc. The best way to fight the hot/cold syndrome is by setting a good example for your team to follow. Stick to deadlines, and set realistic goals. Consider starting a blog - even if it's private, it'll force you to keep context, and will provide an excellent way to refresh your memory should you have to set your project aside for a while. This will be very helpful to any new members you pick up midway through development.

Tunnel Vision

Developers are notorious for what's known as tunnel vision. Tunnel vision is closely related to eating dessert first - someone has tunnel vision when they lack the ability to see the big picture. For example, if, two weeks before your beta release date, your programmer is obsessed with getting 10% more frames out of the rendering pipeline, and is ignoring the fact that there are no enemies, weapons, or powerups in the game, that's tunnel vision. He or she is concentrating on one very small and often nonpriority aspect of the project, and ignoring the stuff that really matters. Prevent tunnel vision by keeping a big prioritized list of everything that has to be done. Continually ask yourself "is there anything more important than what I'm working on right now?" If so, drop what you're doing and concentrate on it, instead.

Lack of Commitment

If you're trying to assemble a team, sooner or later you're going to run into people who are not dedicated, but are instead all talk. These people care more about impressing others than they do about getting things done; they're the ones who show a small sample of amazing work, but then fail to produce anything more. They often lie about the status of their work, using high-tech variants on the dog-ate-my-homework excuse, like "my drive crashed, and I lost everything," or "I accidentally deleted the folder." Learning to recognize and avoid these people is easier said than done. It's very difficult to spot a lie in an email message, or in a chat room, and everyone makes mistakes; I've deleted stuff I've needed, and I've had hard drives crash on me. Knowing how to discern who's not dedicated to the project is tricky, but it gets easier over time - the people who are dedicated will have produced something, and the people who could care less will still be making excuses. After a few months of solid development, you'll be able to separate the people who walk the walk from the people who simply talk. The best way to combat lack of commitment is for your team to brush the non-committed people off to the side of the project - have them do the lower priority tasks with fewer dependencies. Your team should demonstrate through example that the people who do the most work are the ones who are trusted when it comes to the big, fun stuff. Don't assign the task of developing your main character animations to the slacker artist; give him the background animations instead. The nice thing about this system is that the big projects are often also the exciting ones, so team members who work more get to do the fun stuff.

The Mutual Admiration Society

Lone wolf developers don't have the resources to do play-testing and market research like the pros. However, even the most "independent" game developer can take steps to ensure that the finished product is one that gamers, other than the people who developed it, actually want to play. It's perfectly OK for developers to test the game, and of course the game should be dictated by what they want to do. But, simultaneously, it's important to get outside opinions. The outside opinion can act as an arbitrator should the team get split about which approach would be more fun. Remember: as you develop something, you spend many hours playing it, and you naturally get good at it. This fundamentally skews your perception of the game's difficulty and learning curve. To get an accurate measurement of how fun your game is, think about your target audience, and recruit game players to play what you've created. Just watching them - seeing what they smile at, where they get lost, what awesome thing they never even tried - can be incredibly useful.

Conclusion

This is but a sketch of several issues that can arise for the lone wolf developer, or development team. There are many great books on the process of software development and project management. If you want to learn more about project management, check out some or all of the following:

• Code Complete, by Steve McConnell. I can't recommend this book highly enough. If you read it and follow its advice, you will become a better programmer, estimator, and software development team member. A must read.
• The Mythical Man Month, by Fred Brooks. Considered by some to be one of the most important books on software project management.
• Dynamics of Software Development, by Jim McCarthy. A collection of short tips and scenarios designed to highlight problems in software teams - simultaneously entertaining and informative, and one of my favorites. Don't flip the bozo bit!
• AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, by William J. Brown, Raphael C. Malveau, and Thomas J. Mowbray. In the same vein as the above, with the same mixture of entertainment and information, but from a slightly different angle.

If nothing else, remember that two main things influence the quality of your project - the quality of your vision, and your dedication, or the solidity and consistency of your team's work. A shortcoming in either one will seriously jeopardize your project; good work can't make up for a lack of vision, and even the best idea can't make up for a lack of commitment and hard work. Keep your expectations realistic, your team happy, and your nose to the grindstone, and Good Things your way will surely come.