Game Development Reference
In-Depth Information
■
If the noun describes a compound entity, what attributes describe it? (They
might be elsewhere on the list, or you might have to invent some new ones.) Add
any new attributes to your definition of the compound entity and go back to the
previous question to determine their qualities.
Unless a game offers only one gameplay mode and no shell menus (which would be
extremely rare), it will undoubtedly require an entity to record which gameplay
mode or shell menu the game occupies at any given time.
This process will give you an initial list of all the resources and entities your game
features. It won't be a complete list; you will undoubtedly add more as work goes
on. If your early design stated generalities but not specifics, add the details now.
Suppose you wrote, “Level 5 will consist mostly of formal logic puzzles.” At this
point, you must define the entities that the level designers will require to build the
formal logic puzzles. Will the player drag tiles, flip switches, and click on colored
marbles? Then add tiles, switches, and marbles to your list of entities. Now you've
got some attributes to think about: The tiles have positions, the switches have
states, and the marbles have colors. Write it all down.
Add the Mechanics
With your list of entities and list of verbs, you're ready to start defining the
mechanics. Again reread your earlier design work. If any sentence includes or
implies the word
somehow
, now is the time to define exactly how. “The player gets
money” or “gets money somehow” must turn into a precise specification of when
the player's money entity increases and by what amount.
As you read, remember that mechanics consist of
relationships
,
events, processes
,and
conditions
.
THINK ABOUT YOUR RESOURCES
Start with any resources that you identified in the previous step and think about
how they flow through the game. What sources bring them into the game? What
drains remove them? Can they be traded or converted automatically into another
resource? Every source, every drain, and every conversion requires mechanics that
determine how a conversion operates, when, and at what rate. Also ask yourself
what happens when the resource runs out. If nothing much changes, you may not
need the resource. Because a resource is a general concept rather than a specific
quantity like an entity, you may be able to determine a lot about a resource's
mechanics just by thinking through the resource flow in the economy.
Remember that games that don't deal in numeric quantities don't have resources.
Such games contain only symbolic entities.
