Development Issues

We assume that your development team has actual knowledge in programming, art, and the other basic tools necessary to actually build something. It has been our experience that most development teams are fairly proficient in these arts, with the possible exception of the server-side programming and administration, which still have some way to go to develop standards for the niche.

So, if the people involved have the basic skills, why do these games always seem to ship late, with critical bugs and design flaws?

Why Are These Games Always Late to Ship?

It seems to be the rule that online games start with a 24-month development schedule and ship somewhere between month 36 “48. Some of the past delays can be attributed to inexperience of the teams and/or developing new technology for a new market, but that isn't the whole story.

The biggest reason we've noticed for development delays is the tendency for online game teams to start building before they've finished designing. This is particularly true of projects that start from scratch, where the creators want to get busy creating (a project's version of youthful folly: hexadecimal-gram 123456, an ironic numerical version of "first things first"). It can also be a difficult-to-resist temptation for teams that use legacy code in a project. They can easily get the impression that since they have a "head start," any mistakes or changes based on executing before design completion will be more easily fixed (a project's version of misplaced trust: hexadecimal-gram 2B2B2B, in which the lead designer questions the value of existence, and in some cases, decides that cult life has something to be said for it). These perilous exuberances bypass the necessary step of completing and vetting the design to create a coherent and completed thought. It is like beginning development of a new car without knowing exactly how many parts you'll need, what they will cost, and where each will fit onto the car. One could start building the next Corvette, end up with the next flame-prone Pinto, and have to scrap all that work and start again.

Like all such situations, this creates more work later on, not less. For example, as noted by the quotes from experienced professionals throughout this book, most teams tend to overreach from the start in terms of the number of features and mechanics they try to pile into a game. If the team starts building without a finished design, imagine what happens later on when the designers discover six months into development that certain game mechanics can't be made to work. As you've probably guessed, they find themselves forced to strip out pieces and rebuild them, which affects every other piece of content already built in, probably causing many of them to have to be redeveloped as well. Instead of being six months ahead, the team can find itself back at square one (which would be a fine place to be if it were the start of the project, but that was half a year ago, and where they are now is more like six months in the hole). If the team had a cohesive design before starting execution ”one vetted for overenthusiasm, overload, and with the features prioritized ”its time savings from avoiding redevelopment would likely be enormous .

Two other major contributors to development delays are the NSS and its associate, feature creep. As the whole concept of an enforced CCP is foreign to most game developers, teams prone to the NSS and feature creep quickly find themselves falling behind in milestone development as they try to add in all the "cool" things that spring from those two attitudes. Later, they discover that adding moving parts to the equation without fully modeling them beforehand is breaking other parts, causing even more delays to fix them. To torture the car analogy a bit more, it would be like deciding six months into development to use a more powerful carburetor and finding that it needs more space than the old one. Married to the idea of the new carburetor, the team starts stripping apart the engine to build more space for the new part, only to discover that, with the engine in pieces on the floor, 15 old parts will have to be redesigned to be smaller or have a different shape to accomplish the task, at a significantly higher cost per part and adding six months to the project. Now, not only is the team not six months into the project, but they've also added six months, effectively losing a year ”oops!

The Vision Thing can also create delays in the sense that designers and developers who become enamored of and married to an idea are extraordinarily resistant to changing it, even when it is obvious that change is needed. You wouldn't believe the lengthy, circuitous rationalizations developers are capable of spinning to keep from having to yank or rethink a cherished concept. They'll keep pouring more time and skull sweat into it in the belief that they just haven't quite figured out the nuances yet, but it is only a matter of time, just around the corner, or subject to an impending epiphany. By the time it becomes obvious that the concept or idea is going to have to wait for another project, literally months can be expended.