Dev Process Fundamentals

Major games can be considered the equivalent of any large business project (in terms of producing a good). When you have over fifty employees, any major part (art, audio, programming) of such a project is handled by multiple people working together.

Also, there are individual aspects of a single task that can be so numerous that you can't just handle them in your head. This is why "how things are done" need to be written down and properly communicated.

In the 80s you had sprites, animation frames, beeps and the most basic of scripting. One person could do everything. Now, something as simple as a single object in a game can require the following:

Textures
Mesh
Wrapping
Skeleton
Materials
Physics mesh
AI response / interaction
Fracture / destructible type
State (other than destructible or fracture)

And within each of these properties are sub properties. For example:

A texture if it exists as a single bitmap file can have multiple surface types on it. For example, the front of a house can be a single texture but it contains brick as well as wood. If the player interacts with these materials (by shooting, striking or otherwise causing some sort of impact), a different behavior is required from whatever is generated as a result of the impact, whether it be a fracture (piece falling off), a decal (for bullet hits) or sound effects that might apply to any of these interactions.

All of these considerations are important for any game engine where the game requires realism and control of objects. But just as important is the process in which these properties are defined and set by the user.

At numerous companies I have worked at / with, processes have been set up, but they all require regular maintenance. And at some companies these processes are not set up. Areas I have noticed where this falls short is particularly the maintenance, and sticking to the process to begin with.

These are administrative duties that usually fall into the responsibility of a production team. A producer and / or assistant producer will be responsible for documenting a process that has been tested and approved as working within the timeframe of the overall project schedule. This staff as well as a discipline director (in this case, an art director) will also ensure that new disciplines hired will be trained with this process.

Let's take a look at the maintenance factor first:

Maintaining a process

A process may undergo changes for many reasons:

This is all fine and dandy, but what is forgotten often is the need to update documentation and education for the process. An email to a group often is not 100% effective, and usually at least a few iterations of a new process or engineering support to fine tune the process are necessary to ensure that it is successful across disciplilnes.

This is what usually does not happen at a game studio, rather, a process will be "fudged" and in some cases repeatedly done incorrectly until the approved new process is standardized.

Sticking to a process

Design may be "law", but without discipline design can destroy the entire process system. Understanding the need for iteration by design on the engineering side, and understanding the need for iteration on the engineering side by design is critical.

Many times (as has been noted by Danc in his Lost Garden article), failure is a part of fine tuning a game system. This failure, when properly accounted for by the publisher as well as the developer, is the key to success. It allows for iteration on the design and engineering sides in pre production and accounts for future iteration as systems begin to merge and the need for iteration continues.

Scrapping final assets is the greatest cardinal sin of any project, yet it happens a lot. When an entire design mechanic changes it forces drastic changes to a project schedule and wastes an awful lot of time.

Establishing various mechanics with temporary assets is very important. For example, you do not need lighting to achieve good combat mechanics unless that lighting is an integral part of the gameplay, and usually it isn't. This makes it difficult though because often a demo is not taken seriously without final looking lighting in a milestone review by the publisher.

How do you feel?

Team morale is also at risk when a process changes, especially when the production team does not consider all disciplines involved and how it may affect them.

Complaints may surface because members of the team are convinced management has no idea what it wants the game to be. In addition, less communication also means team members feel less important because they are not consulted about a process, if they are the ones actually doing the work.

Let's boil it down. What is there to learn from all this?