Game Development Reference
In-Depth Information
Visual prototypes
These are usually mockups of the game screens, sometimes with limited interactiv-
ity. Also called wireframes, they contain basic information on what data is on a
screen and what screens can be accessed from the target screen. Many graphics
programs, such as Visio and PowerPoint allow hyperlinks between pages. Placing
a link on a button mockup and then connecting it to another screen mockup is an
effective tool for spotting screen navigation problems.
Interactive prototypes
The goal of an interactive prototype is to simulate the game mechanics as quickly
as possible while being faithful to the designer's vision (in case you missed what a
game mechanic is, you can refer to
http://en.wikipedia.org/wiki/Game_mechanics
).
This is the phase where rubber meets the pavement; stuff gets done. There may be
a fair number of throwaway prototypes in this phase, possibly with multiple features
in a single app.
Generally a good way to power through this stage is to define the action the player
will do most during the gameplay and test it first. Once it is fun, test the second most
common activity alongside the first. Continue this process of adding new actions until
the gameplay feels robust; a good rule of thumb is from three to five elements and
no more than seven.
Once you have a good idea of how the gameplay works, then it's time to go to the
next type of prototype: reusable code.
Reusable code
Also called Evolutionary or Bread board prototyping, the goal here is to produce code
that is used in the final app. The prototyping process continues, even though the goal
is producing final code. Remember that in the Throwaway phase we were looking
for high-level (horizontal) solutions for design problems. Now we are digging deep-
er, looking for low-level (vertical) solutions to the underlying, possibly unanswered
gameplay details.
