NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/rec/arts/intfict/1130

Internet Message Format | 1992-12-22 | 7.1 KB

Path: sparky!uunet!spool.mu.edu!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!news.lth.se!pollux.lu.se!magnus
From: [e-mail] (Magnus Olsson)
Newsgroups: rec.arts.int-fiction
Subject: Re: What words to use and recognize
Message-ID: <[e-mail]>
Date: 22 Dec 92 11:12:19 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Owner of news files)
Organization: Theoretical Physics, Lund University, Sweden
Lines: 149
Nntp-Posting-Host: dirac.thep.lu.se

In article <[e-mail]> [e-mail] (Tom O Breton) writes:
>Magnus: Well, this thread seems to be almost at the incineration point (If
>that message about "SOLVE PROBLEM" "WIN GAME" wasn't already a flame),

No, it wasn't a flame. I was being sarcastic, but my sarcasm was aimed
at the direction I feared this discussion was taking, and not directly
at you or anyone else in particular. Sorry if you felt offended.

BTW, I think the reason this debate is getting a bit inflamed is twofold:

a) Everybody seems to be slightly misunderstanding what the other
people say. This is certainly not due to malice, and probably not
entirely to lack of reading comprehension either... No flame intended,
but I think we could all (including me) have expressed ourselves more
clearly at points.

b) The discussion has been a lot about abstract principles, and
speculation about what things will be like if they're implemented.
This makes it very easy just to start shouting "is" and "is not" at
each other...

>so I
>won't dwell on it at length. I have a few things to clarify, and then I'm
>done.

I fear I'll have to be done as well, since I really must spend all
available time onb my thesis right now.

>> Yes, I suppose it might be a good idea to be able to say "USE CUP ON
>> CANDLE" in this situation.
>
>I don't know where you're getting that from. It doesn't sound like anything I
>said.

Well, it was I who said that. It was my suggestion on how to implement
something that somebody (maybe not you) suggested - or at least, I
interpreted that somebody as suggesting that.


>I have to take objection to this theme: (quotations from various parts)

Note: You shouldn't just concatenate unrelated quotations, since then
it looks as if I'd written something different from what I actually
did. Please insert ellipses "[...]" or something like that between the
distinct quotations to avoid misrepresenting my views. (It wasn't too
bad in that case, but falemwars have been started over less).

>> IMHO an adventure that requires bad guessing is badly written. If the
>> author wants the user to use the cup to snuff the candle, then it's the
>> author's responsibility to make the game recognize all resonable semantics,
>> like "PUT CUP OVER CANDLE" and things like that. Of course, this requires
>> *extensive* play testing, but so do many other aspects of adventure games.
>
>> An adventure writer simply needs to work so hard on the game's internal
>> consistency that there aren't any logical holes in it. And the game must be
>> play tested by people who have keen eyes for internal logic.
>
>> Yes, but then the game is badly written.
>
>It is of course up to the individual authors, but I think here in this group
>OF such authors, it will be clear to most that an efficient return on your
>programming effort is desirable.
>
>Same work, more game... looks good to me!

It looks good to you, since you're taking the author's point of view.
I'm taking the player's point of view, and I'm not sure I like what I
think you're suggesting.

Let me make it clear that I'd prefer a game like your proposal (or
what I think is your proposal) better than a badly designed one where
one has to guess at the author's intentions. But I'd still prefer a
well-designed, "traditional" one.

>> I haven't played that game myself, but here's what I'd do if I were to
>> write such a puzzle:
>  [ Rather a lot of effort, with the *foreknowledge* of what exact objections
>    would be raised, deleted  ]

Foreknowledge? Well, I'd rather say afterthought in this case. But
foreknowledge *is* important - the author not only has to find puzzles
that make good sense to _him_ (her), but also has to try to put
himself/herself in the user's place, and think like the user.

This is hard indeed. But this is why it's of _vital_ importance that
all games be _thoroughly_ play-tested.

>I think you missed my point.
>
>  0:  Pretty much everyone agrees the game that included the example was
>      quite well-written. Telling me that this well-done game should have
>      been done *better* just makes my point for me.

Should it really have been made better on this point? I don't know,
since I haven't played this game, but I saw at least one post that
disagreed with your views on ablative shileds and so on.

>        Asking the author to manually make clear what functionality is
>        supported, discovering and covering even a good fraction of the
>        possible solutions, just is not a realistic request.

I'm afraid it is. But let me reiterate my point that the author should
design the problems in such a way as to minimize this task. If dust is
needed for a certain problem, then one shouldn't describe a lot of
rooms as "very dusty" just for the sake of atmosphere, because then
the user will want to get his dust from there, rather than from the
erasers.

>  1:  You are retrofixing problems *that you know about*.

Of course. But even a rather small number of play-testers (2-3) will
find most of these problems, and let you retrofix them. And I
seriously doubt that your ideas will eliminate the need for play
testing.

>  2:  You are spending an extraordinary amount of effort on "making sure" of
>      very tiny things. I'm suggesting an easier and more foolproof way.

Easier? More foolproof? I'm not so sure of that.

But let's stop talking generalities: Why don't you write a game with
an implementation of your ideas? Then we can see

a) if it saved you much effort

b) if the users will like it more than a "conventional" game, and if
   they won't feel that the game is "too helpful" (*)

And it's point b) that's the _really_ important thing, isn't it?


Footnote: (*) I've seen examples of games being too helpful; one
(unnamed, to save people from having their fun spoiled) game has a
helpful parser that supplies missing objects if there's only one
suitable object present. In one room, I thought I'd try to break
something I was carrying, but pressed return too early so my command
just became "break", upon which the parser decided I wanted to break
something else and proceeded to solve the entire puzzle for me.

This was of course a bug, but if you make your game very helpful and
forgiving towards the user, you may find that you have to spend your
time finding and correcting this sort of overly helpful behaviour
rather than finding alternative ways of solving problems...

              Magnus Olsson                | \e+      /_
    Department of Theoretical Physics      |  \  Z   / q
        University of Lund, Sweden         |   >----<
 [e-mail], [e-mail]  |  /      \===== g
PGP key available via finger or on request | /e-      \q