Development

Development is the long haul.

Your development schedule is likely to last six months to two years. Some Flash and mobile games can be designed, coded, and tested in less than six months. At the other end of the spectrum, games that are longer than two years in development run the risk of going stale, suffering personnel turnover , having features trumped or stolen by other games , or seeing technology lapped by hardware advances. Any of these problems can cause redesign and rework which, in turn , lead to schedule delays.

The deceptive part of development is how long it seems at the start. You have a good plan, and it's easy to think that anything and everything can be accomplished. This phase of the project can be dangerously similar to summer vacation. At the beginning, all you see are weeks and months stretching out in front of you, with plenty of time to accomplish everything that's on your mind. Then, as the deadline draws near, you wonder where all the time went and suddenly start scrambling to fit everything in.

The trick to surviving this long stretch is to break large tasks into small, manageable tasks that are rigorously tracked. You can't know whether you're behind on a project if you don't track the tasks . This is something that you should do as often as once a week.

One successful task-management technique is to have each developer track his own tasklist, complete with time estimates. These individual lists roll up into a master list that shows at a glance the estimated time to completion for the entire project. This method is particularly useful for seeing whether one person's taskbar sticks out beyond the others. If this happens, that person is the de facto critical path for the project and you should take a close look at his list to see whether some tasks can be offloaded onto someone else.

This method also has the advantage of leaving the developer or artist in charge of his own estimates, instead of imposing them from above. This increases their buy-in to the schedule and makes them less likely to miss deadlines.

If you are an external developer working for a publisher, your progress is tracked for you in the form of contractual milestones. The incentive to stay on schedule is clear: if you don't meet the milestone, you don't get paid. Well-run internal groups use the same structure. Milestones are established at the start of development and there is usually a companywide , monthly project status meeting where all the producers get together and go over the status of their projects in detail. What senior managers look for during project reviews is not only whether the project is on schedule, but also how the producer is working to minimize any risks that could endanger the project in the future.

Here are some non-technical tips for surviving the development phase:

• Bring the test lead on at the beginning of development. If you are the test lead, get yourself involved early. Add testers at first to create the tests you will need and then transition them to test execution as development progresses toward Alpha.

• Maintain good communication across the team. Keep the project documents updated and accessible ( especially the game design doc, tech design doc, and the art production plan). Establish internal mailing lists that allow groups to email their peers without clogging the inboxes of the entire group .

• Track your actual expenditures against your budget.

• Maintain the team's identity and spirit. You don't have to use some management guru's oddball exercise for this. Instead, find an activity that fits the personality of your group, whether it's going to an amusement park, playing laser tag or paintball, or just going out for a movie and popcorn every once in a while.

• Work with marketing and PR to keep them fed with the materials they need. The resulting previews and features will re-energize your team members when their spirits are low.

• When it's time for a tradeshow, remember that demo versions of the game are like miniature projects ‚ they cannot be tossed off in a few overtime hours. Demos need their own tasklist and schedule and must be included in the technical plan from the start. Testing should be included in any demo plans. It's also a good idea to form a mini-team, including testers, that is dedicated to making the demo successful. Their work should include doing dry runs and testing of demo hardware setup, software installation, in-house execution of the demo, and, when the time comes, performing at the demo site. The dates of major tradeshows are known years in advance, so no one should be caught short when the next one rolls around.

• Be ready for a shock or two. We work in a volatile industry and any project that lasts more than a year is likely to experience at least one management upheaval , corporate buyout, or other calamitous experience. The trick to surviving these is to keep your head down and do the work . Things are rarely as bad as they seem. If you stay focused on the job at hand, the corporate storms that rage above your head are less likely to kill you.

• Lastly, have a few features ready to "throw off the back of the wagon" to help you manage scope.