ch5.mht

游戏设计大师Chris Crawford的大作《The Art of Game Design》唯一不足的是英文版的

  manipulability must be meaningful to the fantasies of the game. =
Finally, the=20
  manipulability must be focused: the options from which the player =
chooses=20
  while manipulating the key element must be closely related. For =
example, in=20
  the game GOSSIP, the key element (statement of affinity) assumes a =
linear=20
  sequence of values ranging from hatred through love. ENERGY CZAR =
violates this=20
  principle by requiring the player to choose from a large, disconnected =
set of=20
  options. Menu structures and use of the keyboard both arise from =
unfocussed=20
  key elements.</P>
  <P>Many games employ multiple key elements. For example, most combat =
games=20
  include both movement and shooting. This is not necessarily bad; if =
both key=20
  elements are kept simple, or if one key element retains primacy, the =
game can=20
  be successful. However, too many key elements violating too many of =
these=20
  principles will rob the game of its focus.</P>
  <P>Your main problem with creating the I/O structure is overcoming=20
  constraints; your main problem with creating the game structure is =
realizing=20
  possibilities. Your previous work with the I/O structure defines the=20
  limitations on the structure of the game. You can take more liberties =
with the=20
  internal structure because the player will not directly encounter it. =
For=20
  example, for the game TACTICS I developed a very complex combat =
algorithm that=20
  realistically calculates the effects of armor-piercing shot. The =
complexity of=20
  this algorithm would have confused the player had I tried to explain =
it. But=20
  the player does not need to understand the internal workings of the =
algorithm;=20
  he need only grasp its effects. I therefore did not feel constrained =
to design=20
  a simple-minded and intuitively obvious algorithm.</P>
  <P>Concentrate an providing enough color to guarantee that the game =
will=20
  convey the authentic feel of reality. Keep your sense of proportion =
while=20
  adding details. It will do your game no good to provide exquisite =
detail and=20
  accuracy in one sphere while overlooking the most fundamental elements =
in=20
  another sphere.</P>
  <P>A very common mistake many designers make is to pile too many game =
features=20
  onto the game structure. In so doing, they create an overly intricate =
game, a=20
  dirty game. As I discussed in Chapter 4, dirt is undesirable; a game =
is a=20
  structure that must fit together cleanly and well, not a brushpile. =
Dirt=20
  creates a second problem not mentioned in Chapter 4: it gums up the =
I/O=20
  structure of the game. For example, the long-range scan feature of =
STAR=20
  RAIDERS does provide some nice additional capabilities, but it adds =
another=20
  keystroke to be memorized by the player. That=92s dirty input. =
Fortunately this=20
  problem is overridden in STAR RAIDERS, because the fantasy puts the =
player at=20
  the controls of a starship, and so the player finds the intricacy of =
the=20
  control layout a supporting element of the fantasy rather than a =
hindrance. In=20
  most games, you may well be forced to give up nice elements in the =
game=20
  structure in order to maintain the quality of the I/O structure. On =
the other=20
  hand, you may be forced to go back and change the I/O structure to =
incorporate=20
  a game feature you are unwilling to abandon. If you do so, do not =
simply tack=20
  on a now command; rethink the entire I/O structure and modify it so =
that the=20
  new command fits well with the rest of the I/O structure.</P>
  <P>Designing the game structure is emotionally very different from =
designing=20
  the I/O structure. While designing the I/O structure, the designer =
must thread=20
  a precarious path between the Scylla of expressive power and the =
Charybdis of=20
  expressive clarity, even while the storms of hardware limitations toss =
her=20
  design to and fro. While designing the game structure, the designer =
finds=20
  herself on a placid sea stretching flat to the horizon. The challenge =
taunting=20
  her now is "Where do you go?" <FONT size=3D-1><A=20
  =
href=3D"http://www.vancouver.wsu.edu/fac/peabody/game-book/Chapter5.html#=
top">Top</A></FONT></P>
  <P><A name=3DProgram></A><B>Program Structure</B></P>
  <P>The program structure is the third object of your design =
attentions. This=20
  structure is the vehicle which translates the I/O structure and game =
structure=20
  into a real product. One of the most important elements of the program =

  structure is the memory map. You must allocate chunks of memory for =
specific=20
  tasks. Without such safeguards, you may end up expending excessive =
quantities=20
  of memory on minor functions, and having insufficient memory remaining =
for=20
  important tasks. Definitions of critical variables and subroutines are =
also=20
  necessary. Finally, some documentation on program flow is important. =
Use flow=20
  charts or Warnier-Orr diagrams or whatever suits your fancy. This book =
is not=20
  primarily concerned with programming; if you need guidance on program=20
  development, consult any of the many excellent books on program =
development.=20
  <FONT size=3D-1><A=20
  =
href=3D"http://www.vancouver.wsu.edu/fac/peabody/game-book/Chapter5.html#=
top">Top</A></FONT></P>
  <P><A name=3D"Evaluation of the"></A><B>Evaluation of the =
Design</B></P>
  <P>You now have three structures in hand: the I/O structure, the game=20
  structure, and the program structure. You are satisfied that all three =

  structures will work and that they are compatible with each other. The =
next=20
  stop in the design phase is to evaluate the overall design for the =
most common=20
  design flaws that plague games. The first and most important question =
is: does=20
  this design satisfy my design goals? Does it do what I want it to do? =
Will the=20
  player really experience what I want him to experience? If you are =
satisfied=20
  that the design does pass this crucial test, proceed to the next =
test.</P>
  <P>Examine the stability of the game structure. Remember that a game =
is a=20
  dynamic process. Are there any circumstances in which the game could =
get out=20
  of control? For example, if the game has money in it, could a =
situation arise=20
  in which the player finds himself the owner of ridiculously large =
amounts of=20
  money? In short, does the game structure guarantee reasonable upper =
and lower=20
  bounds on all values? If not, re-examine the game structure carefully =
with an=20
  eye to structural changes that will right the situation. If you have =
no other=20
  options, you may be obliged to put them in by brute force (e.g., "IF =
MONEY=20
  &gt; 10000 THEN MONEY 10000")</P>
  <P>Now probe the design for unanticipated shortcuts to victory. A =
player who=20
  can find a way to guarantee victory with little effort on his part =
will not=20
  derive the full benefit of your game. Insure that all unintended =
shortcuts are=20
  blocked so that the player must experience those processes that you =
want him=20
  to experience. Any blocks you place must be unobtrusive and =
reasonable. The=20
  player must never notice that he is being shepherded down the primrose =
path.=20
  An example of obtrusive blocking comes from the game WAR IN THE EAST=20
  (trademark of Simulations Publications, Inc). This wargame deals with =
the=20
  Eastern Front in World War 11. The Germans blitzed deep into Russia =
but their=20
  advance ground to a halt before Moscow. To simulate this the designers =
gave=20
  the Germans an overwhelming superiority but also gave them a supply =
noose=20
  whose length was carefully calculated to insure that the Germans would =
be=20
  jerked to a dead halt just outside Moscow. The effect was correct, but =
the=20
  means of achieving it were too obvious, too obtrusive.</P>
  <P>The last and most crucial decision is the decision to abort the =
game or=20
  proceed. It should be made now, before you commit to programming the =
game. Do=20
  not hesitate to abort the game now; even if you abort now you will =
still have=20
  I earned a great deal and can say that the effort was worthwhile. A =
decision=20
  to give up at a later stage will entail a real loss, so give this =
option=20
  careful consideration now while you can still do it without major =
loss. Abort=20
  if the game no longer excites you. Abort if you have doubts about its=20
  likelihood of success. Abort if you are unsure that you can =
successfully=20
  implement it. I have in my files nearly a hundred game ideas; of =
these, I have=20
  explored at length some 30 to 40. Of these, all but eight were aborted =
in the=20
  design stage. <FONT size=3D-1><A=20
  =
href=3D"http://www.vancouver.wsu.edu/fac/peabody/game-book/Chapter5.html#=
top">Top</A></FONT></P>
  <P><A name=3DPRE-PROGRAMMING></A><B>PRE-PROGRAMMING PHASE</B></P>
  <P>If the game has made it this far, you are now ready to commit your =
ideas to=20
  paper. Until now your documentation has been sketchy, more along the =
lines of=20
  notes and doodles than documents. Now you are ready to prepare your =
complete=20
  game documentation. First, commit all of your design results from the =
previous=20
  phase to paper. Define the I/O structure and the internal game =
structure. The=20
  tone of this documentation should emphasize the player=92s experience =
rather than=20
  technical considerations. Compare this first set of documents with =
your=20
  preliminary program structure notes; adjust the program structure =
documents if=20
  necessary. <FONT size=3D-1><A=20
  =
href=3D"http://www.vancouver.wsu.edu/fac/peabody/game-book/Chapter5.html#=
top">Top</A></FONT></P>
  <P><A name=3DPROGRAMMING></A><B>PROGRAMMING PHASE</B></P>
  <P>This is the easiest of all the phases. Programming itself is=20
  straightforward and tedious work, requiring attention to detail more =
than=20
  anything else. Seldom has a game failed solely because the programmer =
lacked=20
  the requisite programming skills. Games have failed to live up to =
their=20
  potential because the programmer did not expend enough effort, or =
rushed the=20
  job, or didn=92t bother to write in assembly language, but in few =
cases has=20
  talent or lack of it been the crucial factor in the programming of a =
game;=20
  rather, effort or lack of it is most often the responsible factor. If =
you=20
  place all of your self-respect eggs in the programming basket, I =
suggest that=20
  you get out of game design and work in systems programming. Otherwise, =
write=20
  the code and debug it. <FONT size=3D-1><A=20
  =
href=3D"http://www.vancouver.wsu.edu/fac/peabody/game-book/Chapter5.html#=
top">Top</A></FONT></P>
  <P><A name=3DPLAYTESTING></A><B>PLAYTESTING PHASE</B></P>
  <P>Ideally, playtesting is a process that yields information used to =
polish=20
  and refine the game design. In practice, playtesting often reveals =
fundamental=20
  design and programming problems that require major efforts to correct. =
Thus,=20
  playtesting is often interwoven with a certain amount of program=20
debugging.</P>
  <P>Sometimes playtesting reveals that the game is too seriously flawed =
to=20
  save. A nonfatal, correctable flaw is usually a matter of =
insufficiency or=20
  excess: not enough color, too many pieces, not enough action, too much =

  computation required of the player. A fatal flaw arises from a =
fundamental=20
  conflict between two important elements of the game whose =
incompatibility was=20
  not foreseen. You must have the courage to trash a game with such a =
fatal=20
  flaw. Patching after the game is programmed can only achieve limited =
gains; if=20
  the game is badly deformed, abortion is preferable to surgery.</P>
  <P>If playtesting reveals serious but not fatal problems, you must =
very=20
  carefully weigh your options. Do not succumb to the temptation to fall =
back on=20
  a quick and dirty patch job. Many times the problem that is discovered =
in=20
  playtesting is really only a symptom of a more fundamental design =
flaw. Be=20
  analytical; determine the essence of the problem. Once you have =
determined the=20
  true nature of the problem, take plenty of time to devise a variety of =

  solutions. Don=92t rush this process; sometimes the ideal solution =
comes from an=20
  unexpected angle. Choose a solution for its promise of furthering the=20
  faithfulness of the game to your goals. Do not opt for the easiest =
solution,=20
  but the solution that best meets your goals.</P>
  <P>For example, while designing EASTERN FRONT 1941, I ran into a =
severe=20
  problem with unit counts: there were far too many units for the player =
to=20
  control conveniently. After wasting much time trying to devise ways to =
shrink=20
  the map or directly reduce the number of units, I eventually stumbled =
upon=20
  zones of control, a standard wargaming technique that extends the =
effective=20
  size of a unit. The inclusion of zones of control in the game not only =
solved=20
  the unit count problem; it also made the logistics rules more =
significant and=20
  gave the game a richer set of strategies. I set out with the narrow =
goal of=20
  reducing the unit count, but I found an improvement with much broader=20
  implications.</P>
  <P>If your initial design was well-developed (or you are just plain =
lucky) the=20
  game will not face such crises; instead, the problems you will face =
will be=20
  problems of polish. All of the little things that make a game go will =
be out=20
  of tune, and the game will move like a drunken dinosaur instead of the =
lithe=20
  leopard you had envisioned. Tuning the game will take many weeks of =
work. For=20
  the short term you can scrimp on the tuning while you are working on =
other=20
  problems, for tuning the game requires delicate adjustments of all the =
game=20
  factors; any other changes will only throw off the tune. Therefore, =
defer=20
  final tuning work until the very end of the polishing stage.</P>
  <P>There are actually two forms of playtesting. The first is your own=20
  playtesting done in the final stages of debugging. The second form =
comes later=20
  when you turn over the game to other playtesters. The =
salient-difference=20