Yes, It Really Will Take at Least 23 Years to Complete

Yes, It Really Will Take at Least 2“3 Years to Complete

To paraphrase the elder Von Moltke's famous quote about battle plans: "No production schedule survives contact with reality." This is especially true of PW games because: (a) there is so little experience among publishers and developers in how to make such games and (b) there is only a little more experience in how to construct and follow a proper software development plan. This isn't because publishers and developers are all incompetent”many are and many others aren't. Much of the lack of experience is simply due to the relative newness of the medium. Remember (or if you're much under 40, believe) that the PC is just barely a couple of decades old. For the first decade or so, there was so much money to be made developing business- related software that most of the best designers/developers were busy trying to strike it rich with what they had hoped would be the next in a line of killer apps that started with Visi-Calc (which made the Apple) and continued with Lotus 1-2-3 (which made the IBM PC). The personal fame, power, and downright heavy loot that attended the market's acceptance of and frenzy about blockbuster titles like those two was enough to keep most creative software folks plugging away in the field of commercial applications. Oh, and for the first decade or so, the graphical capabilities of PCs weren't nearly what they are today, and the Internet was pretty much restricted to text messaging between military or academic correspondents. The gold mine that exists today for publishers and developers of PW games is comparatively new, and we should not be too surprised that some mistakes in the past 5“10 years have been doozies.

Two-year development times are possible for retail hybrids, even starting from scratch, because the feature set and content are generally much more limited than for a PW. Any PW team that tells you they can start a project from scratch and complete it in two years is delusional, trying to delude you, or else they have so little experience in the genre that they just don't know better.

Even if you're reusing old code or have licensed a client/server platform for your PW, plan on a two-year development and test process, minimum. If you're starting from scratch, it can't hurt to plan for as much as four years in the cycle, including six to nine months of scaled testing. Thirty-six months would be the ideal development cycle, but that assumes almost everyone on the project has experience on the commercial side of PWs, knows which features are necessary at launch and which can wait for a later update, and can make those determinations quickly and without a lot of fuss and meetings. Even then, you'll probably find that three years is pushing the edge. Why is it ideal and maybe pushing the edge, you ask? If you've read this far, you probably have at least a passing knowledge of computer hardware. What is just becoming available now that wasn't here 36 months ago? What was supposed to be here last year that now looks like, according to whatever sources you have found to be reliable in the past, it maybe will be coming around in a year or so from now (two years late), assuming the company that is in the lead to introduce it doesn't go out of business first? The point is this: Online gaming technology and features change rapidly . What is cutting edge today may well be obsolete when your PW is ready to launch. It may be a Herculean task, but you have to try to estimate not only the standard technology 36 months out, but also what the players will consider the standard feature set.

You may start with a holy text of a design document and intend to adhere to it scrupulously. You may be able to stick to it, but you may also find that two- thirds of the way through your three-year cycle, some new hardware capability comes out that has the potential of making your game appear "quaint." Do you stay the course (play the cards you have now), or do you expand your paradigm to take advantage of the new reality? One course is at least risky; the other is at least expensive.

So, three years it is, but as the blue- collar folks say about working on Saturdays during a busy season , "I'm only working half a day, but I'm still packing a lunch ."

You'll find that most of your time is taken up on two issues: balancing content and testing.

Balancing Content

Balancing a game's mechanics and content is a complex process. It requires exquisite attention to detail in the design stage. As mentioned before, design teams tend to overreach, and even a trimmed -back design will be complex. Design teams will try to shove in everything. This is such an inherent part of the process as seen in many previous games that it is becoming axiomatic. Notes experienced designer and creative director Richard Garriott, "Teams regularly bite off more than they can chew. An MMP can easily become an impossible -to-complete reality simulator."

Even if the team successfully plans for and develops a somewhat limited feature set, it still needs to make sure the features all work together and that no one combination of character race/class/skills/attributes/weapons/ armor becomes a virtually indestructible "tank" that can overwhelm the game's other players or the game's NPCs.

Testing

We can't emphasize this enough: Your Beta testing phase must take at least six months and must scale up the number of simultaneous players over the various stages of the Beta to match the load expected on launch day. At that, six months is probably too short for software as complicated as a PW, but it is generally three months more than such games have seen in Beta testing in the past. Hearkening back to the benefits of early-phase design: The more money you save by designing early and delaying the expensive coding part of the process, the more money you can allocate to intensive testing.

This is changing slowly in the industry as a whole, but as 2001's bad launches showed, not quickly enough. If the project plan doesn't account for at least a six-month process, add it in.

The games industry is starting to recognize the importance of scaled testing, but the fact that a number of games premiering in 2001 had serious problems associated with their launches means that it is not yet an inherent part of the culture. If your project doesn't have at least six months budgeted for testing, add it in before you shake your money tree. If you do have six months, don't let the finance people take it away. If necessary, agree to trim a feature, do more design early, delay the code-intensive period, subsist on Tombstone's frozen pizza instead of Wolfgang Puck's, do almost anything. You want to prove your game on adequately scaled testing (footprints in the Sands of Time); you don't want your game to end up the other way ( fragments of what used to be a refrigerator in the 46th St. alley outside NBC Studios).

No, More Programmers Won't Make It Go Faster

In fact, panicking and throwing more coders into the mix is usually a guarantee of more bugs and less stable technology at launch. Your best defense here is to make sure the core design team actually takes the time to finish the game design and technology design documents. With those documents to work from, you'll know within a body or two how many programmers, artists , and network specialists you'll need before a line of code has been done.