home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / arts / intfict / 1121 next >
Encoding:
Internet Message Format  |  1992-12-21  |  7.1 KB

  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!sunic!news.lth.se!pollux.lu.se!magnus
  2. From: magnus@thep.lu.se (Magnus Olsson)
  3. Newsgroups: rec.arts.int-fiction
  4. Subject: Re: What words to use and recognize
  5. Message-ID: <1992Dec19.132352.3897@pollux.lu.se>
  6. Date: 19 Dec 92 13:23:52 GMT
  7. References: <BzDIsJ.M9M@world.std.com> <1992Dec17.163944.10997@pollux.lu.se> <BzFA13.Hro@world.std.com>
  8. Sender: news@pollux.lu.se (Owner of news files)
  9. Organization: Theoretical Physics, Lund University, Sweden
  10. Lines: 156
  11. Nntp-Posting-Host: dirac.thep.lu.se
  12.  
  13. In article <BzFA13.Hro@world.std.com> tob@world.std.com (Tom O Breton) writes:
  14. >Magnus:
  15. >
  16. >> What's the point of a puzzle where the solution is to find a new use for
  17. >> some everyday object if you can just ask the game and get a complete list
  18. >> of all possible ways to use the object in question.
  19. >
  20. >Hope you don't mind if I respond by quoting myself, but:
  21. >
  22. >"Where 'command CUP' would be a catchall for command words that you
  23. >deliberately withheld from a player. (Presumably providing some clever way to
  24. >discover them)"
  25. >
  26. >If you, say, wanted to make use of the cup to safely snuff a candle flame,
  27. >and the player is supposed to cleverly realize this can happen, you might use
  28. >this.
  29.  
  30. Yes, I suppose it might be a good idea to be able to say "USE CUP ON
  31. CANDLE" in this situation. [Historical footnote: to save space, my
  32. first adventure game (a re-creation of which is available as
  33. pub/Misc/atomia.zoo from leif.thep.lu.se) actually only supported the
  34. verbs TAKE, DROP, LOOK, WHERE (to describe one's surroundings),
  35. INVENTORY and USE, as well as the movement commands.] 
  36.  
  37. However, there's a disadvantage to this: suppose the player wants to
  38. use the cup to collect some molten candlewax, types USE CUP ON CANDLE,
  39. and to his/her surprise finds out that this snuffs the candle instead.
  40. Personally, I *hate* it when you're trying to do one thing and the
  41. game decides that it know better than you and does something
  42. different... 
  43.  
  44.  
  45. >The idea is that
  46. >
  47. >  0:  it only happens when the author *realizes* that they're putting forth a
  48. >      puzzle, not when the author didn't think of something.
  49. >
  50. >  1:  The player knows that there's a puzzle there, thus distinguishing it
  51. >      from (unavoidable) similar-looking problems whose "solving" isn't part
  52. >      of the game.
  53. >
  54. >      (IE, parser stupidity, unforeseen-and-unsupported actions, and
  55. >      unsupported vocabulary.)
  56. >
  57.  
  58. Sorry, I didn't get that. I thought the reason for having these
  59. "general-purpose verbs" was to provide a workaround for parser
  60. stupidity. 
  61.  
  62. >I picture a player coming up with half-a-dozen odd-but-plausible things to
  63. >tell the cup before the parser understands "snuff candle with CUP". It's
  64. >still mixing up "Can you solve my clever puzzle?" with "What have I supported
  65. >in my stupid parser?", but at least it's fairer than blind guessing.
  66.  
  67. IMHO an adventure that requires bad guessing is badly written. If the
  68. author wants the user to use the cup to snuff the candle, then it's
  69. the author's responsibility to make the game recognize all resonable
  70. semantics, like "PUT CUP OVER CANDLE" and things like that. Of course,
  71. this requires *extensive* play testing, but so do many other aspects
  72. of adventure games.
  73.  
  74. >> An adventure game should of course not be a "guess the correct verb" game,
  75. >> but IMHO what every game designer should work _very hard_ to make all
  76. >> puzzles so "intuitive" that it's possible for the player to express the
  77. >> needed action in a very simple sentence, with everyday words (of course the
  78. >> game should accept all reasonable synonyms and alternative wordings).
  79. >
  80. >Again quoting he-whom-I-admire-most:
  81. >
  82. >"there is no way an IF writer can truly support all the uses a player can
  83. >think of (I can think of at least a hundred things a brick might be used
  84. >for);"
  85.  
  86. Indeed; but please note that I wrote "all *needed* actions". You can
  87. do a hundred things with a brick, and the game can't possibly support
  88. all of them (we're talking about games, not real-world simulations)
  89. but if the game requires you to do one thing and one thing only with
  90. the brick, it should also understand all *reasonable* ways of
  91. expressing this. If there are 769 ways of expressing or doing this,
  92. then IMHO the puzzle needs some reconstruction to make the solution
  93. more unique. 
  94.  
  95.  
  96. >However hard a designer works, I expect that within a *minute* I can find
  97. >something I can do in real life that the game does not support (Barring
  98. >extraordinary dodges such as a spartan setting to specifically defeat this)
  99.  
  100. Of course, but let me stress again that we're talking about *games*,
  101. not artificial worlds (which seem to be an AI-complete problem).
  102.  
  103. >I would much rather play a game that used a 'sensible default' mechanism like
  104. >this than one whose author worked "really really hard" to support synonyms.
  105.  
  106. And I wouldn't. De gustibus non est disputandum.
  107.  
  108. >> An adventure game should of course not be a "guess the correct verb" game,
  109. >
  110. >It goes beyond mere VERBS. All too often, it comes to a question not of
  111. >solving the puzzle, but of guessing which way of solving it is *supported*.
  112.  
  113. Yes, but then the game is badly written.
  114.  
  115. >I recall someone describing a puzzle where one had to get past laser beams by
  116. >clapping an eraser so that you could see the beams outlined in the dust.
  117. >
  118. >Clever? Yes, but you also have to *GUESS* that this functionality is
  119. >implemented, whereas other functionalities such as
  120. >
  121. >  sweeping dust instead up from the floor,
  122. >  improvising a mirror,
  123. >  improvising an ablative shield that would hold for the few seconds
  124. >    required,
  125. >  holding something disposable before you as you go as a 'mine detector',
  126. >  etc,
  127. >
  128. >  are not. (Nor could one reasonably expect all such creative solutions to be
  129. >  supported)
  130.  
  131.  
  132. I haven't played that game myself, but here's what I'd do if I were to
  133. write such a puzzle:
  134.  
  135. 1. Make sure the player gets the information that the erasers are
  136. chalky (for example, when he/she examines them).
  137.  
  138. 2. When the player manipulates the dusters in other ways, they should
  139. give off a lot of chalk dust.
  140.  
  141. 3. Sweeping dust up from the floor should work *if there is any dust
  142. in the game*., but it needn't do that. BTW, you need quite a lot of
  143. dust to create a cloud, and it's not unreasonable to assume that hte
  144. rooms aren't *that* dusty.
  145.  
  146. 4. Improvising a mirror requires reflective material. If there isn't
  147. any in the game, there's no need to support such a solution.
  148.  
  149. 5. If the laser beams are merely *detectors*, rather than death-rays
  150. (again, I haven't palyed the game myself), ablative shields or
  151. disposable objects won't help - the detectors will still be triggered.
  152.  
  153.  
  154. *BUT* if a problem is such that there are scores of possible solutions
  155. inside the game, then it's of course very bad only to allow one of
  156. them. 
  157.  
  158. An adventure writer simply needs to work so hard on the game's
  159. internal consistency that there aren't any logical holes in it. And
  160. the game must be play tested by people who have keen eyes for internal
  161. logic. 
  162.  
  163.  
  164.               Magnus Olsson                | \e+      /_
  165.     Department of Theoretical Physics      |  \  Z   / q
  166.         University of Lund, Sweden         |   >----<           
  167.  magnus@thep.lu.se, thepmo@seldc52.bitnet  |  /      \===== g
  168. PGP key available via finger or on request | /e-      \q
  169.