Game Development Reference
In-Depth Information
exampleofhowasimplegamewithrelativelyfewscreensmight
look. In this example, bolded text represents buttons or links that
can be clicked to access the associated screen. A simple wireframe
like this is also often helpful to artists, reminding them of any
necessary buttons, callouts, etc.
You might have noticed ( ) around the Quit button. This indi-
cates that a Quit button is optional. It makes sense for games that
a player will download to his/her computer, but for Web games in
abrowser,itdoesn
t really have a place. If you add the option to
QuitfromyourgameinaWebpage,besureyouknowwhere
you
'
'
re going to send them.
Step 3
With your description and basic wireframe in hand, it
stimeto
outline the core mechanics that your game will utilize. This is
more or less a feature list and can simply be in bulleted form, but
the more detail you cover the less surprises you
'
'
ll run into once
you
re in production. It allows you to break down the gameplay
into its main pieces of functionality. These include components
such as the game
'
s rules, input mechanisms (such as the keyboard
or mouse), movement and collision, and how the player
'
sscoreor
progress is determined and recorded. Once again referring back to
Pac-Man as an example, here
'
'
s how a mechanics list might read:
￿
Maze tile engine
￿
Nothing can move through walls
￿
Any open space is filled with food, power-ups, or bonus
items (fruit)
￿
One pass-through connecting left and right sides
￿
Each tile has at least one and up to four possible
connections to other tiles
￿
Collision management
￿
Maze
￿
Ghosts
￿
Pick-ups
￿
Player
￿
Keyboard input; directional arrows
￿
Lives
-
Player has three lives at start of game
-
Player loses a life every time he is hit by a ghost without a
power-up
-
When player dies, his progress in the current level is
maintained
￿
AI
￿
Normal behavior: chases player
￿
Power-up behavior: avoids player
Search Nedrilad ::




Custom Search