MMO Tidbits

Perspectives on MMO Design and Production

  • Categories

  • Archives

  • Meta

  • Copyright Notice

    Contents Copyright 2009-2010 Arnold Hendrick

Project Management for Game Development

Posted by Arnold Hendrick on June 15, 2009

Game developers often abhor project management when making games. The battle cry of “It shouldn’t ship until it’s ready” sounds great to gamers, but projects managers and businessmen cringe. How do you know if the changes, the extra features, will really generate enough extra income to compensate for the extra cost? Veterans from game publishing are especially gun-shy because they’ve heard it dozens of times about games that went on to weak sales despite the extra effort – if those games even finished at all (Duke Nukem Forever, anyone?)

 The sad tale of Tabula Rasa is a case in point. Despite a star-studded development team and deep-pocket backing from one of the strongest MMO publishers in the world at that time (NCsoft), six years of development yielded about one year of live operation before shut-down. Some reports suggest that translated into $106 mil in development for less than $20 mil in income (see “Tabula Rasa took Too Long”).

This is not a new problem. In the business world “projects” are business activities that have a clear start and end – like developing and running an MMO. There are well-established methods for organizing and running projects to keep them on schedule and on budget while achieving a certain level of quality and profitability. These methods are called “project management.”

The Project Lifecycle

According to the “bible” of project management (the PMBOK 4th Edition, published by PMI in 2008), projects have lifecycles. Here’s an overview of the major “Process Groups” in the project lifecycle:

 07i.Project Lifecycle v2

Initiating: Project startup, charter, initial scope, initial team formation, etc.

Planning: Defining work breakdown structure, determining resources, defining activities, scheduling, risk planning, communication planning, etc.

Executing: Resources perform the planned work, including QA.

Closing: Product acceptance, recording results, performance analysis and postmortems, release of resources.

Monitoring & Controlling: Oversees the other activities; typically concentrates on scope, cost, schedule, quality and risk issues; reports status to management and customer; insures proper business administration occurs.

As the diagram illustrates, “monitoring and controlling” occurs most heavily during “planning” and “executing” activities. In my experienc, “monitoring and controlling” is typically the most difficult activity, especially during “executing.” A well-understood development process helps, but a skilled producer who wisely manages development tradeoffs is invaluable. Sadly, the industry still has some producers who can’t monitor progress quantitatively. Without such tools informed tradeoffs are nearly impossible.

Notice that multiple planning-execution cycles are possible within a project. Methodologies such as scrum actually formalize this into 2-4 week sprints, with each team planning at the start of a sprint and then executing during the sprint. In fact, a miniature of that process occurs each day, with planning issues surfacing (hopefully) during the 15-minute daily status meetings.

Game Development Lifecycle

Game developers frequently talk about “continuous development” and the need to iterate and refine for good gameplay. Merging this with the business needs of games resulted in a commonly accepted lifecycle for MMO game development. A version commonly used for MMOs is:

 07i.Game Lifecycles v3a

Prototype: Select, test and use engines, tools, software languages and build processes. Define design concept and art style; create initial design outline & first draft design doc; create initial concept art, gameplay prototypes and 3D art/animation prototypes.

Pre-Production: Build two to three fully playable zones (levels) including rewards and advancement. Build one zone using the same methods used in production – its the only way to accurately gauge production costs. Complete key concept art. Finish design doc. Complete production specifications (for programming, design, art, sound and QA).

Production: Build all other zones and gameplay so the game is code complete, including all data entry and scripting for AIs, quests, tables, art assets, sounds, etc. This typically involves additional resources (often via outsourcing) all working simultaneously on various tasks pre-production specifications. Create specifications and prototypes for billing, CS tools, and update systems.

Beta: Tweak the game for better gameplay, find and fix bugs, operational chokepoints, resulting final software stabilization (i.e., “no more fixes unless it’s a show-stopper crash bug”). Finish the billing, CS, update and other support systems. This beta does not end on the launch date, but when the day promotional “open beta” begins

Live: Game operates 24×7, typically starting with a promotional open beta. This is supported by at least two tiers of “live team.” The short-term tier handles day to day operational issues for the weekly patch. The long-term tier builds monthly updates and longer-term expansions.

            Mapping Project Processes to Game Lifecycles

First, avoid the “noob” error and listen to the wise old Jedi (PMBOK 4th edition), “Process Groups are not project phases.”  Do not equate the “Initiating” process group with prototyping, planning with pre-production, etc.

It is possible to map the project lifecycle against the game lifecycle, with Project Initiation at the start of Prototype and Project Closure at the end of the Live. This could work for small projects such as casual games. However, for traditional solo games (with or without multiplayer components) and almost all MMOs, the nature of the work in each phase is different. Furthermore, entering a new phase without finishing important bits of the previous phase becomes the road to disaster (see “An intervention”).

For example, scrum methodologies work extremely well for prototype and pre-production. Here scrum’s backlog priority system is ideal of tackling the mass of disparate possibilities, needs and goals. Scrum is wonderful for combining creativity and flexibility into tangible results.

The production phase is different. Now the development group must manufacture literally thousands, often tens of thousands of small items (art assets, quests, mob layouts, AI scripts, UI components, etc.). Each item has a multi-step process for construction, approval, QA and testing. Scrum struggles with vast numbers of small tasks. It really struggles if each is a multi-step activity. In large games the wise course is traditional tracking tools, from spreadsheets and databases to the oft-maligned MS Project. Similar issues can apply during beta if thousands of inputs and bugs must be prioritized and appropriately handled.

I advocate viewing each game phase as a separate project. In PMBOK-speak the game is a “multi-phase project.” This reinforces the need to finish one phase before starting the next, thus preventing the “intervention” situation described above by Eric Heimberg. Starting a new project for a new phase allows a clear, clean “change in how we work” for the development team. Finally, a clean exit for each phase improves the developer-publisher relationship.

The diagram below illustrates this mapping of  multiple projects with their process groups to game phases.

07i.Game Lifecycles with PM v3

The multiple project iterations during “Live” represents a series of game updates/expansions, each treated as a project.

The diagram also shows that initialization and planning for the next phase starts during the later part of the current phase. For example, during pre-production the producer might need to find and qualify an art outsource subcontractor to help handle the mass of art assets needed during production.

Irrespective of my preferences and the above examples, professional project management methods can coexist with almost any development process, be it scrum, agile, iterative, waterfall, with or without attention to CMMI “levels.” The important goal is how the general rubric of project management, applied intelligently, can prevent games and dev studios from experiencing another “crash and burn” event. 

Advertisements

3 Responses to “Project Management for Game Development”

  1. Martin Reimer said

    Great overview. As someone just getting into project management and eventually games, its good to see the whole process mapped over to game development.

  2. Great article. I run a slightly tweaked version of the above process here at Serious Business. Basically, I’ve broken our process down to three main phases: Planning, Implementing, and Learning. And we iterate quickly through that continuum. Usually our “beta” consists of dark launches of features (where the functionality exists but is not visible to normal players) and/or multivariate tests. Having a robust and sophisticated metrics platform is key for operating at speed. Cheers.

    .mike

  3. […] A. Hendrick, “Project Management for Game Development,” 15 June 2009. [Online]. Available: https://mmotidbits.com/2009/06/15/project-management-for-game-development/. […]

Sorry, the comment form is closed at this time.