Game Development Reference
In-Depth Information
attribute goes over 500, set the eligible to win flag to TRUE for that car. Continuously
check all cars to see if the location attributes of the cars that are eligible to win show
that they are on or beyond the finish line. Set the winner entity with the number of
the first car whose location attribute meets that condition.” It's okay just to say,
“The first car that has completed all 500 laps and crosses the finish line is the win-
ner,” because this is a perfectly familiar situation.
The less familiar the mechanisms that you document, the more specific you need
to be, especially if any of them run counter to convention. In the dart game 301,
the player starts with a score and reduces that score by the amount that he hits on
the dartboard. The object of the game is to be the first to achieve a score of exactly
zero. Because this runs counter to convention, it's the sort of thing you have to
explain more precisely. Similarly, the mechanic that describes the behavior of
female dragons in the earlier sidebar “Analyzing a Mechanic” requires more detail
because female dragons are entirely imaginary; nobody can count on his existing
experience with dragons to know how they should behave.
If you know how to program even a little bit, you can write pseudo-code to docu-
ment processes that you need to explain extremely carefully. Pseudo-code includes
the if and while statements that indicate conditional or repeated operations but
without exact variable names or the other syntactic features of a real programming
language. Pseudo-code can be handy in circumstances that call for precise explana-
tions, which is why potential designers would benefit by taking at least one class in
programming. It doesn't much matter what language you study, as long as it
includes the concepts of conditional and repeated execution.
Revisit Your Earlier Design Work
To begin designing the core mechanics, go back to your earlier design work and
reread it to identify entities and mechanics. Make a list of the nouns and verbs that
you encounter. Whenever you come across a noun in your design documents, that
noun will probably be implemented in the core mechanics as an entity, a resource,
or both. Whenever you see a verb, that action will probably be implemented as a
mechanic. Also watch for sentences that include the words if , when ,and whenever .
These designate conditions that will become part of the mechanics.
Look particularly closely at the following items:
Your answers to the question, “W hat is the player going to do? ” The answers
to this question give the player's role and some information about the challenges
he will face and the actions he will perform. They will include some of the most
critical nouns and verbs of all. Even if the answer is simply “fly an airplane,” it con-
tains the key verb for the whole game, fly , and the key noun, airplane .
Your flowboard of the game's str ucture. Each gameplay mode and shell menu
represents a separate state of the mechanics, so the mechanics will require a sym-
bolic entity to keep track of the current gameplay mode during play.
Search WWH ::




Custom Search