Preproduction (Proof of Concept)

Preproduction is gearing-up time. Your goal is to complete the game design, create the art bible, establish the production path , write up the project plan, and create a prototype. This phase is also used to do technical prototyping to demonstrate the feasibility of any new technology you hope to deliver. Preproduction basically proves that your team can make the game and that the game is worth making.

If you are an independent developer, your publisher can also use preproduction as a test-the-waters period for your relationship with them. If they learn that you are professional, reasonable, and able to deliver on time, they're likely to go ahead. Otherwise, they might write off their loss and move on.

The work products of this phase are the game design document (GDD), the art production plan, the technical design document (TDD), and the project plan, which itself is actually a suite of documents. Preproduction culminates in the delivery of the game prototype ‚ a working piece of software that shows off how fun the game is to play.

The Game Design Document

By the end of preproduction, you should have a game design document that exhaustively details everything that will happen in the game. The features in this document become the requirements from which the art production plan and the technical plan are made.

During the development cycle, the game design document should always be the most current representation of everything there is to know about what the player experiences in the game. This should include complete information about the gameplay, user interface, story, characters , monsters, AI, and everything else, down to the finest detail.

Such a document, if committed to paper, would be the size of a telephone directory, impossible to maintain, read by no one, and almost instantly out of date. Instead, put it on your internal network as a set of Web pages. See www.openwiki.com for a methodology that makes this easy.

Maintaining your documents as Wiki pages not only has the advantage of keeping the design up to date, but also enables everyone on the team to have easy access to everything at all times. The savings to the group over the course of development are enormous .

The Art Production Plan

Preproduction is when you establish the "look" of your game and decide how the art will be created.

The Art Bible

During preproduction, the designer, art director, and concept artist collaborate on setting the artistic style of the game. The concept artist makes reference sheets for other artists to work from. Together, the team arrives at a unified "look." Establishing this art bible early on helps orient new artists coming on to the project and ensures the final product will have a consistent style throughout.

Most of this art can take the form of pencil sketches , but it's often useful in selling the game to develop a few glossy pieces that capture the high concept and pack a good visual punch.

In the early stages of the game it's also a good idea to assemble a visual reference library of images that reflect the direction you want the art to take. These images can come from anywhere ‚ magazines, travel books, movie posters , and so on ‚ as long as they are used only for guidance and do not find their way into the final product.

Production Path

The production path is the process by which you go from concept to reality, from an idea in someone's head to actual figures and gameplay on the screen. For example, to create a functioning character in an action game, you must find the most efficient way to go from a designer's spec to a concept sketch to a 3D model to a skin for the model to animation for the figure to applying AI to the character to dropping him in the game and seeing how he works. All the tools you select along the way must be compatible. They must be able to "talk" with each other so that the work you do at one step can be imported to the next step, manipulated, and passed up the line.

Assets, Budgets, Tasks , and Schedules

The production plan also includes the first draft of the asset list, team task lists, equipment budget, costs, and so on. Like the game design document, this plan must be updated and kept current throughout the life of the project.

The Technical Design Document

The technical design document sets out the way your tech lead plans to transform the game design from words on a page to software on a machine. It establishes the technical side of the art production path, lays out the tasks of everyone involved in development, and estimates the time to completion of those tasks. From these man-month estimates, you learn how many people you need on the project and how long they'll be with you. This, in turn , has a direct effect on your budget.

In addition, the TDD specifies

• What core tools will be used to build the game

• Which tools are already in-house

• Which tools have to be bought or created

• What hardware and software must be purchased

• What changes must be made to your organization's infrastructure ‚ for example, storage capacity, backup capabilities, and network speed ‚ in order to support development

The Project Plan

The project plan is the roadmap that tells you how you're going to build the game. It starts with the raw tasklists in the tech plan, establishes dependencies, adds overhead hours, and turns all that into a real-world schedule. The final project plan is broken down into several independently maintained documents.

Manpower Plan

The manpower plan is a spreadsheet that lists all the personnel on the project, when they will start, and how much of their salaries will be applied to the project.

Resource Plan

The resource plan calculates all the external costs of the project. It takes from the tech plan the timing of the hardware purchases to support internal personnel, and it estimates when the external costs (voice, music, video, and so on) will be incurred.

Project Tracking Doc

This is where you keep track of whether you're on schedule. Some producers use project management software for this, but many find the programs too inflexible to manage all aspects of the game's development. The producer usually enters tasklist data into the software to create a Gantt chart that reveals dependencies and the critical path, but he frequently also uses a hodgepodge of other homegrown techniques to keep track of the project.

Budget

After applying the overhead multipliers to the manpower plan, you combine these numbers with the resource plan to derive your month-by-month cash requirements and the overall budget for the game.

P&L

The original Profit and Loss estimate was made during the concept phase. As development progresses and costs become clearer, the P&L must be kept current.

Development Schedule

Many developers chafe against creating a firm schedule and committing to a specific release date, but you owe it to yourself and your company to do exactly that. After a release date has been set, a whole different machine goes into motion. The marketing team books advertisements that will appear in the months running up to the release date. The PR department negotiates with magazines for cover stories and well-timed previews and feature articles. The sales group commits to end caps in the software stores. Changing the release date of the software is likely to torpedo all the carefully planned efforts of these groups and result in your game selling far fewer units than it could have.

Milestone Definitions

Milestones are significant points in development marked by the completion of a certain amount of work (a deliverable ). These deliverables should be concrete and very precisely defined, with language such as "Concept sketches for fifteen characters, front, side, and back" or "Weapon #1 modeled , skinned , and operational within the game with a placeholder sound effect, but without animations or visual effects."

Avoid fuzzy deliverables, such as "Design 25% complete." The best deliverables are binary: They're either complete or they're not, with no room for argument in between.

Game Prototype

The tangible result of preproduction is the game prototype. This is a working piece of software that captures on-screen the essence of what makes your game special, what sets it apart from the rest of the crowd , and what will turn it into a hit.

This "look and feel" demo can be the single greatest influencer of whether the project goes forward. Publishers like to be able to look at a screen and "get it" right away. If they can't see the vision within a minute or two, they're less likely to fund the rest of the project. This is a tough task to pull off, especially if the project requires a new engine or if one of your hooks is new technology that won't be built until much later in development. When this is the case, most developers simulate what the final product will look like. Most often that is done by pre-rendering material that will be rendered in real-time during the game.

Another approach is to prepare stand-alone demonstrations that prove that the various pieces of planned technology are feasible . These small tech demos might not be much to look at from the artistic point of view, but they show that your goals are reachable . Typical tech demos might show nothing more than a lighting scheme on a few spheres, the camera moving through a featureless "cube" environment, or a bunch of particles bouncing off one another as they stream from an invisible source. The point is to show that the building blocks of your technology are solid. The features you choose to prototype in this way should be the most difficult ones, the ones that present the greatest risk.

The finished prototype not only shows the vision, but also establishes that your production path is working and that you can go from ideas to reality in a reasonable and effective way. It also gives testers their first look at what's going into the game. If the prototype includes working code, this is a good time to try out some of your tests using your test environment, which itself may be a prototype at this point in the project.