Project Plans


Ah, here's where we contemplate the details. There have been some complex single-player games shipped in the past 20 years , but none of them comes even close to matching the complexity of the average persistent world (PW) game, and few need to be as delicately balanced as most multiplayer retail hybrids.

This complexity is self inflicted; online game designers are in the habit of trying to throw into a game everything they can possibly think of, as a hook to keep people playing ”and paying ”for years. This approach tends to create more problems than it solves because each moving part created has to link up with every other moving part in the game. Past a certain number of game mechanics, player-usable game items, and the variables that modify them, it becomes virtually impossible to make an alteration to game mechanics or item behavior without touching at least two other mechanics as well. In this scenario, it is very possible to add one new feature or game mechanic that completely upsets the game balance.

In today's online games, the complexity goes even further. Just adding a new rating class to an existing weapon means altering database descriptions to add the new weapon's class, perhaps even adding new art to depict the weapon, and testing the new weapon against every player a character calls, every other weapon, and all non-player characters (NPCs are characters or entities not controlled by a player) in the game to ensure you aren't completely upsetting the game's balance. It all takes code of some sort , of course, and sometimes code of different flavors.

Once you know what the design is supposed to be, everything in the document has to be turned into a series of tasks for assignment and tracking. This is pretty basic stuff for any project, but it is harder for an online game due to the complexity. All this has to be tracked in a project plan and timeline. To get a better picture of what we're talking about, the average retail hybrid has far fewer than 100 player-usable items (usually fewer than 50); fewer than 20 NPCs; and just enough player skills, attributes, and game mechanics to get through a solo game and create a few combinations for a multiplayer session. This type of project can be completed by experienced developers in two years or fewer. The average PW, on the other hand, has more than 500 player-usable items; 40 or 50 NPCs of various experience and power levels, with literally hundreds or thousands of them existing in the game at any one time; usually at least 8 player attributes that correlate and modify dozens of different combat, magic, and trade- crafting skills, all of which can grow or decrease over time in a variety of different ways and whose various combinations all have some form of art to depict them; and one or more database entries to track it.

You're probably starting to imagine what could happen if the project plan and development timeline aren't complete and are so chock-full of cross-referenced details that it makes the average person's head spin. Unless you have these details down on paper and turned into the various tasks necessary to complete each detail, it is nearly impossible to be flexible later on, if and when you need to trim back the feature set to get the game out the door before the turn of a new millennium .

The Baseline

When you have all the tasks noted in your tracking software, you'll have created your baseline from the start of coding to finish. Good software, such as Microsoft Project, will lay out a PERT or Gantt [1] chart for you that clearly notes what tasks block other tasks, the order in which tasks need to be completed to move on, and where critical chokepoints exist. This is all pretty basic stuff, but again, it is not yet a firm part of game development culture and is most often observed in the breach. The amazing thing is that more senior executives don't demand this kind of tracking accountability before one penny is spent on coding.

[1] A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for program evaluation review technique , a methodology developed by the US Navy in the 1950s to manage the Polaris submarine missile program. A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Both are graphic illustrations of a project that note what needs to be done in what order to bring the project to completion. Modern project planning software converts task lists into PERT or Gantt charts to provide an easy-to-see overview of the major events in a project and point out which tasks are dependent on others for completion.

The baseline, combined with the full project plan, should give your management their first true indication of just how realistically the design team is estimating the extent of the work, and it should be a real eye- opener in one of two ways:

  • The level of detail and the total number of tasks that need to be completed should give them pause.

  • The lack of detail or number of tasks listed should scare them about the team's judgment in these matters.

If it is the former, you're on the right track to a smooth development process. If it is the latter, it is time to rethink the whole process; you either need a more experienced team or this just isn't the right project for you and your company.

Flexibility

Flexibility here means being flexible in your feature set and being willing to trim (cut) some features to obtain a shorter and smoother development cycle.

A good producer and project manager will understand at the outset that the design team will always attempt to overreach. If left to their own devices, by the time the designers are finished determining what they want in the game, not even the presence of the 12 apostles on the team will produce any hope of launching the game before you're all ready to retire.

There is nothing wrong with this early in the process; it makes good sense to get as much on paper as you can because it is nearly impossible to add major features later on without upsetting the whole apple cart. At some point before the design documents are completed, however, you're going to have to trim back the feature set to something that approaches sanity . You can take this as a given and, in fact, it is a good exercise for the team to have to prioritize the feature set a number of times before the baseline is pronounced complete.

About six months into ramped-up development, when you begin to see how long the tasks really take to complete and can refine your estimates, you'll probably want to do the feature prioritizing and trimming exercise at least one more time. By this time, even your ramped-back feature set for launch from the first round will be suspect and you'll probably want to give yourself an edge by trimming at least a couple of the lower priority features.

If you find yourself needing to trim features in the six to nine months before the scheduled launch date, odds are that your launch date is already doomed, plain and simple. The smart money says that you're either going to launch poorly or miss the date. You might as well delay the launch, do a full evaluation, and decide whether the game is ever going to be in shape to launch. The worst thing you can do at this point is try to trim out so much that you can launch (poorly, remember) on time. Doing this type of feature triage will add so many bugs and exploits that the game will be unplayable and unstable, creating bad word of mouth. Additionally, there is a good chance that you will have to cut back further than the minimum feature set required for players to have enough fun to stay past their first 30 days.

The moral of this section is this: Trimming the feature set early is good; trimming late is deadly .



Developing Online Games. An Insiders Guide
Developing Online Games: An Insiders Guide (Nrg-Programming)
ISBN: 1592730000
EAN: 2147483647
Year: 2003
Pages: 230

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net