This article has since been revised and updated

[size="5"]Intro Preface: This article was originally written and posted on my web site a few months ago. However, I figured I'd "rerelease" it as a feature article here, since the GameDev.net "Gauntlet Style Project" is starting up. 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 afford to program games full time! It's always a sad thing when a group goes down for the count, but too often we forget to ask "Why." 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, I've come up with several ideas about why teams fail, and what can be done to prevent them from dying. This first part will cover things that can go wrong during the "Idea" or "Design" phase, before actual development starts. The next part will cover things that could happen while in development, or after development. And now, the ideas... [size="5"]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 through a big, fat, detailed design document. 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 down on paper in as detailed a form as possible. NEVER start developing a game the same day you think up the idea for it. Wait, and write about it instead. Also, remember that your design document stands alone as the compete description of your game. If it's not in the design document, don't spend time developing it. For example, if your design document doesn't specifically mention that you need alpha blitting, then don't spend time coding it. Many programmers go insane about "creating toolboxes" and "building a solid library of functions." Toolboxes are certainly important, but you shouldn't spend time developing something just for the sake of developing it - a professional toolbox is a collection of code snippets that have all been used somewhere else. Don't waste time coding stuff that will never be used - make sure that what you're working on has a direct part in your finished title. [size="5"]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. Think long and hard about what it will take to create each aspect of your game. Don't ask yourself, "Can I do this?" Instead, ask: "Do I absolutely, positively, without a doubt, know that this is within my grasp?" I'm not saying you should be forever content with making 16 color Space Invader clones. It's perfectly acceptable for your team to have a couple of "challenging areas" in your designs. But don't overdo it - make sure that by the end of your design phase, your team still considers your project "easy." Also, just because something isn't technically hard doesn't mean that it's not a lot of work, that is, just because 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 make sure you know for sure what you're dealing with. [size="5"]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. A sure sign of failure is when your team starts saying things like "Yeah, we can do a 3D engine. Give me four days." or "FMV? No problem, I'll have 10-minute intro by the end of the week." Sentences like those are downright scary. 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 colleges will respect you (after all, how many game companies do you know that stick to deadlines?), and your team will have a good reason to feel proud of itself. Good estimates, however, are very difficult to create. Quite frequently, it takes a lot of thinking to come up with a realistic estimate. Make sure you do that thinking when designing your project. Also, remember that it's better to meet your deadlines early than to repeatedly blow past an unrealistic milestone. 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. [size="5"]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 frequently race against artists to see who can get the most done over a weekend. With careful moderation, 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. 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. [size="5"]The Dictatorship A dictatorship occurs when the head of the team insists that things be his or her way. 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 "employees'" 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 in 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. Which leaves enjoyment. What this really means is that 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 experience as a group, otherwise, it's really not worth the trouble. 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. It's not just fun for the leader - it's fun for everyone. If your team isn't having fun, there's something seriously wrong. Just because you've gathered everyone together doesn't mean that you've got any authority. Team leaders do many things - they organize meetings and keep everyone in sync - but they most certainly do NOT hold any power. The best teams are the ones where everyone is given equal input into things, and where everyone's considered an equal. But, in some cases, some people are more equal than others (oink). 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 capitalism dictates that 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. These things are easy to spot exceptions to the main rule: in general, the team should make the decisions. [size="5"]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 or a fraternity 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." Also, remember that all of the really talented people already have salaried jobs at professional development shops. Keep your doors and minds open, and don't waste valuable development time debating whether someone new gets to join. [size="5"]End Of Part I All of these points may seem painfully obvious when written down, but they're much harder to spot when it's your team and yourself. Given that, the most important thing you can do to ensure success during the design phase is to listen to your team members, look for clues, and constantly monitor what's going on. It definitely takes some hard work. Far too many great ideas and great teams have fizzled out over the years because of bad group dynamics, poor team leaders, and other reasons, and while they all have their own unique reasons for calling it quits, after seeing so many, patterns begin to emerge. These patterns are the basis of these two articles. This is the end of part one. Stay tuned for part 2...