Ultimate Game Design : Building game worlds

Building Game Worlds
118
U L T I M A T E G A M E D E S I G N
You can see that the table specifies a character’s common traits with numbers you
can alter (shift up or down) if need be. For an RTS, you will build tables to specify in
great detail your characters, vehicle offensive and defensive abilities and dependencies,
resource system dependencies (for example, gold, water, oil, gas, wood, spice),
general weapons abilities, research systems, trade systems, political relationships,
and so forth.
You might have a similar table to define a unit vehicle—let’s say it’s an armored
troop transport. You’ll need concept art and a description of this vehicle. It might
have three flavors: Standard, Super, and Mega. It might have both a projectile
weapon and radius weapon. It will have a certain number of hit points (places where
it’s able to take damage) and a certain armor rating. It will have a certain capacity to
carry troops. Every single unique unit requires definition. It will look different as a Mega
transport then as a Standard transport.
Once the unit definitions are solid, you will want to describe unit behavior. Okay,
we know something about the units—now what do they do? Do they auto-fire if an
enemy is detected? Do they seek something? What do they seek? What is their default
movement pattern? Can it be altered by the player? How can it be altered? How does
this impact code and interface?
Carrying through with our troop-transport example, we need to determine this
unit’s mobility (for example, it drives from point A to point B; it can be set on patrol
on a square or circular perimeter; and so forth). Also, our troop-transport vehicle has
a projectile and radius attack. How do they work? Is it just a straight projectile? Does
it heat-seek or curve in flight? From how far can it attack (how many grid units can it
cover)? Can this projectile weapon be enhanced? How? We need answers to similar
questions for the radius attack. Is it a ring or “shockwave” attack? What does it look
like? How far does it extend or how many grid units will it cover? Can it be enhanced?
How? If these are rechargeable weapons, how are they recharged? Does the
unit have to return to a resupply base? Will a resupply droid fly in and recharge the
unit? Is the “fly in” automatic or initiated by the player? Now we need to go through
a similar process to define and describe the resupply droid.
These are just a few of the many questions to answer in starting to define unit
behavior.
There is plenty of information coming at the player in an RTS. What’s the state of
my units? What’s the state of the enemy’s units? What’s the state of that particular
unit (the one that’s on fire)? Likewise, players are able to direct large amounts of information
back at the game. Go build this. Try and protect that. Harvest this resource.
Patrol this area. Are the trade routes open? Are my fishing vessels sinking?
You get the idea. How does this information flow back and forth between the player
and the game? It flows via the interface.
The game interface is the operational shell that surrounds the game. Building an
interface that is sleek-looking, comprehensible, and powerful is not easy. Certain