Excerpt from Game Architecture and Design
by Andrew Rollings and Dave Morris
Coriolis Press © 2000

Page 298
While sometimes it can be useful to implement the game prototype as a board game, or as a paper-based role-playing game in order to get the mechanics correct, other options are becoming available. Recently, more-advanced prototyping solutions have been released into the market. These are applications that provide a virtual testbed for interactions and behaviors. A particularly good example (and, in fact, the only one I have used) is Virtools Dev™ by Virtools (ed. Virtools SA), details of which are available at their Web site (www.virtools.com). This package allows a complete 3D world to be built and actors placed within it using behavioral building blocks that can be expanded, if necessary, by a developer using a C++ interface to the package.

Pages 507-508: Preparing A Prototype
Preparing a prototype isn't always as simple as just sitting down and hacking some code out (although it can be in some situations in which you already have a pretty good idea of what will be required).

Undirected effort is usually wasteful at whatever level of development. Nowhere is this truer than with prototypes. By their very nature, prototypes can involve a lot of meandering and sidetracking development. So, in order to minimize the loss of development momen- tum, it is essentiel to consider exactly what needs prototyping.

As I have already stated, prototyping is a risk-reduction mechanism, and you should keep this foremost in mind when considering where to focus our prototyping attentions.

For example, as far as I am concerned, the biggest risk in any game project is the gameplay itself. This is the make-or-break point: you can have the best architecture in the world, but, if the gameplay isn't there, you end up with an expansive slide show.

Getting a gameplay testbed up and running is the single most important thing. wether it is a paper-and-pencil mockup, a primitive board game, or a crude graphical representation, the important thing is to investigate it. These investigations are a lot cheaper to perform with a prototype than they are within the game itself, 18 months into the development cycle. Some cash-rich companies (such as Blizzard) can get away with this approach (as seen in Chapter 7), so it cannot be completely discounted. Unless you happen to be in a very financially secure position and very experienced in the field, then the prototype is the best place to do these refinements, at least at the first level. Subsequent fine-tuning may be required within the game itself.

Other areas of risk can also be prototyped, especially in the areas we have already described. In this way, the prototype serves as a useful risk reducer. Think of it as a low-cost model that allows us to approximate the problem to the first order of complexity. An analog would be NASA training astronauts for weightlessness: it's a lot cheaper to put them in a swimming pool than it is to ship them into space for their weightlessness training.

In essence, the prototype should be prepared in the same way as any other part of the project. The key goals of the prototype are flexibility and low cost. It doesn't matter if it looks like a 10-year-old text game. It doesn't even matter if it crashes every half hour or so, as long as it doesn't lose data (although you'd hope it wouldn't.)

You are going to throw the prototype away anyway (you are!), so, as long as it was cheap to develop and was flexible enough to serve your needs, no less and no more, then it was worthwhile. All that matters is that it allows you to thoroughly explore the problem do- main that you are prototyping.

Note that a testbed doesn't have to be hard coded using a custom-written program. Off-the-shelf packages such as Virtools Dev™ by Virtools (ed. Virtools SA) (a demo of which is included on the CD-ROM) are excellent for creating good-looking prototypes that allow for drag-and-drop specification of complex behaviors. These can be great for developing prototypes so advanced that they could pass for the game itseif, but then care has to be taken not to get so wrapped up in creating a great-looking prototype that the game itself suffers. Of course, Virtools Dev can be used as the basis of a game - the engine is licensable - but this is not a decision to be taken lightly. It is certainly suitable for this, but the learning curve of new technology should be taken into account. Certainly, it still would be easier than developing a new game engine from scratch, but you may find that you need to augment the system with custom-written add-ons.

Virtools Dev are the ultimate in soft architectures. They attempt to define a complete game framework that can be used to create a quality 3D game. How successful this is will be revealed by the tests of the marketplace, but the future certainly looks promising for this sort of product.