This article has since been revised and updated

[size="5"]Intro This is the second (and last) part of this series (for the first part, click here). The first part covered things that can go wrong during the "Idea" or "Design" phase. This part will cover things that could happen while in development, or after development. And now, the problems: [size="5"]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 first eating the more bland (but essential) staples. [size="5"]Burn Out Burn Out is probably the number one reason why independent games fail. In case you're not familiar with the term, we're using the "non drag racing" version of the term: Burn Out is what happens when all of a sudden a project that used to be fun to implement is now "boring," "hopeless," "arduous," etc. Slowly but surely, team members start to lose passion for the project, and they start refocusing their efforts on other, more "exciting" projects. 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 burn out can never be completely eliminated. Burn out 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 subdue burn out is to make sure that by the time it starts to effect 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. [size="5"]The Binge and Purge Syndrome Closely related to burn out is The Binge and Purge Syndrome. 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. Binge/Purge 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 things to do (like a real job). There's nothing wrong with developing around everyone's schedules, and I'm certainly not implying that developer focus needs to be constant day-by-day to be useful. If a developer is consistently focusing on the project for equal intervals of time, that's outstanding. If, on the other hand, he or she ignores the game for two months, then takes a week off of work to do nothing but code... that's binge/purge, and that's something to watch out for. Binge/Purge developing leads to all sorts of problems. For starters, your team is much more likely to fall victim to burn out. Their attention will drift more easily, the things they produce will appear disjointed, and they may have problems seeing the big picture. The best way to fight the binge/purge syndrome is by setting a good example for your team to follow. Stick to deadlines, and set realistic goals. Also, consider starting a daily development diary - diaries force you to focus on something every day, and they provide an excellent way to refresh your memory, or bring new members up to speed on where you've come from, and what you're doing now. [size="5"]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's no enemies, weapons, or powerups in the game, he or she might be suffering from tunnel vision. He or she is concentrating on one very small and often pointless 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. [size="5"]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, but no action." 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. Frequently, they 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, and I emptied the trash before I realized it." Learn to recognize and avoid these people at all costs. That, however, 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 talk." The best way to combat lack of commitment is to brush the non-committed people off to the side of the project. Make it known from the start that the people who demonstrate that they do the most work are the ones who get the big projects. 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 frequently, the big projects are also the exciting ones, so team members who work more get to do the fun stuff, which is As It Should Be. [size="5"]Developers as Play Testers? 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 people are actually interested in playing. For starters, try to avoid letting the developers play test. The people making the game are not the best ones to play-test it. It's perfectly OK for developers to test the game, but far too often developers acting as play-testers will assume the game is too easy, too boring, or too short. They'll more than likely want to spend time implementing "just one more feature" to make the game "perfect." This leads to the Infinite Alpha syndrome, explained above. To get an accurate measurement of how "fun" your game is, recruit game players. [size="5"]Conclusion I've simply given a cursory 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; many of these are useful for doing games, as well. If you want to learn more about project management, check out books like Code Complete, by Steve McConnell. They provide excellent advice on getting quality software done on time, and go in to much more detail than I have. If nothing else, remember that primarily, two things influence the quality of your project - the quality of your design document, coupled with how solid and consistent your team's work habits are. A shortcoming in either one will seriously jeopardize your project - good work can't make up for a poor design, and even the best design document 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.