Game Development Reference
In-Depth Information
▪
We want to give the player a quest—someone needs to deliver and
explain the challenge
.
▪
We need several dozen “fodder”-type enemies to create an escalat-
ing challenge for the player in this mission
.
And so forth.
As a potential first link in this chain, the designer must very clearly define
why this character exists and, at a core level, what Design needs from it.
For example, Character A needs to be able to detect, move toward, and
attack the player with either melee or ranged attacks; Character B has no
combat requirements but needs to be able to talk to the player to provide
a quest.
It can be tempting to wander into the area of Narrative Design here, as
the designer might instinctively start weaving contextual whys and where-
fores into the fabric of the character definition. There's nothing inherently
wrong with that, but all that is usually
needed
at this earliest of stages are
the answers to some basic, Design-centric questions:
1. Why do we need this character?
2. What function(s) is he intended to serve?
3. How prominent in the game is this character likely to be? How
much in-game “screen time” will he probably get?
4. Is it a single character or a class/group? If the latter …
a. About how many of them will the player encounter?
b. Is it enough that a variant-generating system of some kind may
be required?
5. What ability or abilities are implied or required?
6. What strengths or advantages are implied or required?
7. What weaknesses or vulnerabilities are implied or required?
8. Does (or can) anything about the character grow and change over
the course of the game?
Out of this information comes a specification sheet for the character
that will support Narrative Design as well as other downstream team
