Game Development Reference
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 vari-
ous 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 pre-
sent the greatest risk.
The finished prototype not only shows the vision, but also establishes that your pro-
duction 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.
Development is the long haul.
Your development schedule is likely to last six months to two years. Some Flash and
mobile games can be designed, coded, and tested in less than six months. At the other
end of the spectrum, games that are longer than two years in development run the risk
of going stale, suffering personnel turnover, having features trumped or stolen by
other games, or seeing technology lapped by hardware advances. Any of these prob-
lems can cause redesign and rework which, in turn, lead to schedule delays.