Pre-Production

Pre-production can last as long as six months. The aim is to do all the concept evaluation and project planning necessary to reduce risk in the later stages of development. It’s undertaken by members of the core team, in close consultation with one another. In many ways, it’s the most exciting part of the project, but it’s usually done under time pressure with inadequate resources available, which rather dulls the edge. In particular, a number of important deliverables will have been prepared by the end, all of which will almost certainly have needed more work on them than they actually received.

These deliverables are

• A visualization document. This is produced first, by the lead designer. Although only a few pages long, it sets the tone for the entire endeavor, asserting the project’s mission statement, its philosophy, its goals, its main features, and its look and feel.

• A design document. Because the designer(s) creates this, I spend much of Chapters 3 through 5 of this book addressing the kind of material that goes into it. For the moment, though, suffice to say it defines things such as the world’s background, its architecture, its mechanics (including gameplay), its control mechanisms (how players interact with it), and its integral community support systems ¹. Specifics will be added constantly as development continues.

• A technical design review, assessing hardware and software requirements. What technologies are needed? What tools (both bespoke and middleware)? The technical design review is often folded into the design document.

• An art bible, describing the stylistic conventions to be used along with examples illustrating the range of material required. This is so that artists can produce work that is consistent with a single overall look ².

• A production management assessment, which uses the other deliverables to gauge the project’s demands. It will include a schedule (with milestones), resource requirement details and some risk assessment. The schedule will be continually updated in the light of how things actually proceed, as opposed to how they’re supposed to proceed.

• Prototypes to provide proof of concept and to show that potential technical difficulties can be overcome.

Pre-production is primarily a planning phase, therefore the construction of (limited) prototypes might seem to be out of place. Prototypes are necessary partly for commercial reasons—they demonstrate to investors that the team can produce the goods—but they also benefit the team itself.

They ensure standards for design, programming, and art have been set, and that source control works. They show that the basic principles will work, and (hopefully) can be integrated. For companies that produce a steady stream of material for different projects, assembly line style, the basic pathways for communicating with the various production centers also will have been tested.

The technical design review addresses basic issues, such as how the server code will be modularized, what network transport layer protocols will be used (TCP/IP versus UDP), how background content will be trickled to clients, and how multiple access options will be incorporated (PC/console, web browser, mobile phone). Additionally, it has to consider topics not directly related to the virtual world at all, primarily back-end systems for login, billing, and so on. The necessary software development tools (including ones for system testing and debugging) must be acquired at this stage, in addition to as many pieces of middleware as are suitable. In particular, even with the typically huge license fees involved, it is usually more cost-effective for a company to buy a database, 3D engine, and billing system than to write its own from first principles ³.

Whether or not you can acquire useful middleware for world creation and AI scripting is project-dependent, however, because it requires great flexibility. Developers usually like to have their own tame programmers available to make any necessary changes expediently, rather than having to rely on someone else’s people to do so at short notice.

The production management assessment covers a wider brief than its name might suggest. The term comes from the computer games industry, where typical products don’t need a great deal of support after they hit the stores. Computer games management assessment therefore only needs to cover production. Virtual worlds (whether or not games) do, however, need to be managed after launch—immensely so! The production management assessment for them must also extend through the rollout and into the operation phase. This means it has to consider things such as quality assurance, live team management, community maintenance, content creation, and patching. It’s also the place where the battle with the Marketing department starts over the handling of the product’s launch.