General IF criticism, mostly about exploring a bit about time limits
JAN THORSBY
to go through the same conversation more than once is not really
interactive. Most players will try to make sure he had not missed any vital
information so he will be forced to play through all possible variations of
the conversation, instead of choosing one. Therefore it would have been
easier and faster if the player could type "talk" and get the whole
conversation in one go. In the same way I think much of the exploring in IF
is not really interactive. Particularly the use of the "examine" command. I
think many games should not implement "examine".
Every time I, (like I assume many players), get to a new room in a game I
read through the room description and then methodically examines every item
in the room. (and then I often have to examine every new item that pops up
in the descriptions of the first items). I don't feel I have must choice in
doing this, I can't risk missing out on any information I need to win the
game. So it is not really interactive. This process can easily take half the
playing time of a game, and it is by far the most tedious half. If I read a
long room description, I can never enjoy it, I just feel bad about all the
things I have to examine. Often I start examining things before I have read
through the whole room description. I suspect many writers make shorter room
descriptions than they would ideally prefer, cause they do not want to
burden the player with examining to much.
There is a good reason why in static fiction every object is not described
in detail. People know what an ordinary table or an ordinary three looks
like. And there are no real reason to describe these things in IF. Or rather
there is a reason if "examine" has been implemented. Then one has to write
descriptions for everything, because standard phrases like "you see nothing
special about that" is annoying. But remove "examine" and you remove the
reason.
Any important or interesting or funny information about an object can be in
the room description.
In the same way, the descriptions of object in your inventory could be
available when typing "inventory". (Possibly when this makes for long
inventory lists, one can have another command witch just lists the objects
in your inventory and not their descriptions.)
Another problem with "examine" is in situations with time limits. Lets say I
am in a cave with a wolf who is getting closer. I know I am supposed to
shoot the wolf with my silver bullet. But instead I examine the wolf. And I
examine it's very sharp teeth. And I examines it's regal fur. And the wolf
eats me. So I load my saved game. But I do not shoot the wolf. Instead I
examine the stalagmites. And I examine the stalactites. And I examine the
large rocks. And the wolf eats me again. So I load the game, examine the
medium sized rocks, the small rocks and the puddle of water, gets eaten once
again, load the game and then shoot the wolf. This is not only tedious, it
totally ruins the excitement, since it is difficult to fear for the player
character's life when he is constantly getting resurrected. Examine is also
a problem in situations with time limits that do not result in your death,
for instance a train journey where you automatically get out when the train
stops.
The writer could make the time limits really long, but that would be a
problem for players who can't think of things to do, or players who for some
reason are playing through the scene for the second time and therefore know
what actions are necessary. Better to remove "examine".
(There is another way around this problem. "Examine" could be a command that
takes up no game time. In many cases this is realistic, since often when one
types "examine" (or "look" or "inventory"), the player character dos not
really examine the things, he merely conveys information he already know
about it to the player. For instance if the player asks the PC to "examine"
the PC's own couch, and the PC says it is green, the PC did not have to look
at the couch to know that.
In the same way I do not think "look" and "inventory" should take up any
game time. Neither should actions that the PC for some reason do not
perform, like if you type "move couch" and get the response "You know you
are not strong enough.")
Many games start off with the player character walking around picking up
objects. Again I do not think this process is really interactive. I am not
talking about the objects you get when you do a real puzzle. I am talking
about the thing you find when you examine the bushes, look under the bed or
search the dead bandit. There is no real challenge in finding these things;
usually when you look at the mess in the basement you will be told something
like "there is no telling what might be lurking in such a mess". And a game
where the things where hidden in truly unexpected places, whit no hints to
the player, would be even worse; the player would not have to do any more
thinking, instead he would be forced to search everything.
If the player need a lot of objects early in the game I think more often
than not they should all be in the same spot. Or even better, they should
all be in the inventory from the start.
And if you manage to make a game without any hidden objects you should not
implement "search". Or "look behind". Or "look under". Or "look inside".
This will save the players time.
There are problems with not having "examine" or "search" in a game but I
think they can be avoided:
1. It is usually bad not to implement a lot of verbs. It gives the player
the feeling that he can not do anything. For instance lets say that in a
game you are supposed to shake a table. Earlier the player has perhaps tried
to move the table. If "move" is not implemented then the player is likely to
think that "shake" is also impossible. So if basic things like "examine" and
"search" do not work, how is the player going to think that anything works?
I think the problem gets solved if you just tell the player straight away
that he cannot use these verbs. After all a lot of games uses simplified
talking system with just the word "talk". As long as I am told this at the
beginning of the game, I do not feel frustrated that is can not use "ask" or
"tell".
2. One uses "examine" to determine if the objects in the room description
has really been implemented. If you get a message like "You can not see
that." it usually means the object is not something you can interact with.
So if you are making a game without "examine", all objects in the room
description should be implemented. (One slip up here could result in the
player not trusting the game at all, and so he might have to "touch" or
"move" everything he sees to test if it is real. Which kind of ruins the
point of removing "examine.")
3. Sometimes there might be a good dramatic reason why the room description
should come first, and the description of one of the objects in the room
should come later. Maybe the room description contains the set-up for a joke
and the description of the object contains the punch line, and you want
there to be a pause between. Or maybe the description of the object casts
the whole room description in a different light. For instance lets say you
find the room of happy teddy bear where everything seems nice. But then you
search and find the mutilated teddy bear corpse and things do not seem so
nice anymore. But there are plenty of ways to let the player find the corpse
without "search". For instance:
>look
This is the happy teddy bear room where hundreds of happy teddy bears are
dancing with joy, singing with delight and frolicking in ecstasy. In the
middle of the room the happy singing banana tree are singing happy banana
songs. Somewhere behind it lies a happy banana, also singing. In a corner is
a large box covered in all the happy colours of the rainbow.
>open box
Argh! There is a mutilated teddy bear corpse in the box.
Or:
>get banana
You move around the tree to get the wonderful bana. Holy cow! There is a
mutilated teddy bear corpse here!
Or:
>talk to bears
You ask the bears why they are so happy.
"We have to." says one bear.
"Or else we end up like him" says another and point at something behind the
tree.
You go to see what it is. Oh sweet God no! A mutilated teddy bear corpse!
Off course if there is a lot of this sort of thing in a game it might be
easier for the player if one implements "examine" or "search" after all.
I should also add that someone once suggested a less extreme way of saving
the player to type "examine" to often; that anything important in the room
description is highlighted, so the player knows the rest is just scenery and
dos not try to interact with it.
Lastly: this was not meant as criticism of any specific game, and I know
that there has been many good games with a lot of exploring.
Jon Ingold
> Then one has to write
> descriptions for everything, because standard phrases like "you see
nothing
> special about that" is annoying.
I disagree with this. As you say, a table is a table, a fork is a fork. When
a player sees this message for the third time or so, he *stops reading it*
and just takes it as a dismissal, so it uses up *no reading time*. And it
allows the player to dismiss the object more easily.
Actually, this is all a better argument for using "That's not important in
the course of this game", because it makes the game world more manageable
without any particular cost (assuming its not a game about exploring a tight
environment, I suppose. It's the difference between a space-opera
doorstopper and a Virginia Woolf novel).
Jon
Mike Roberts
> It has been said that a menu-based conversation system where
> it is possible to go through the same conversation more than
> see the whole thing anyway: why not just show it all in one go?].
This definition - interactivity equals choice of outcome - has been proposed
here before, but I disagree with it. I think it's way too narrow, and even
more importantly, misses the point.
I'd define interactivity as control over *process*, not outcome.
You could say I'm just nitpicking about definitions and that this is
irrelevant to your point. But when people around here talk about
"interactivity" - and this applies to your thesis as well - the word is a
proxy for "satisfying gaming experience." It's in that sense that I think
control over outcome is a red herring, and control over process is key.
Consider an example. I could write an "interactive story" that has three
possible endings. In one ending, the protagonist achieves her goal; in
another, she lets go of the nominal goal when she discovers that something
else that she already has, but which she's in danger of losing because of
her obsessive pursuit of the nominal goal, is actually more important to
her; in the third, you get any other outcome you want, which the story
implements by having no text except a blank line where you write in the
ending you want. The choice of ending is presented at the very start of the
story: "if you want 'achieves the goal,' go to page 120 and start reading,"
and so on. No other choices are ever presented; you just choose at the
beginning which outcome you want, and you read one of the three possible
"story branches." This fully satisfies the "control over outcome"
definition of interactivity, but I'm confident that most people wouldn't
find it to be a satisfying interactive experience.
A different example: the computer game "Starcraft" (or most any other RTS
game; they tend to have the same sort of structure). The game is a series
of missions connected by a framing story. In each mission, the player
applies a set of rules to manage a set of resources to achieve the mission's
goal. The goal is fixed by the game design, but the exact steps you take to
achieve it are up to you. If you fail in a mission, you go back and try
again. Once you succeed at a mission, the story advances by one notch, and
you're on to the next mission. The story, like the missions, is a fixed
feature of the game design: you have no control over the outcome of the
story. But many people have found Starcraft to be a highly satisfying
interactive experience.
Control over outcome can be an ingredient in creating a satisfying gaming
experience, but I think my story example demonstrates that it's not a
sufficient ingredient, and games like "Starcraft" demonstrate that it's not
a necessary one. I think control over outcome is mostly tied up with
competition and randomness, and modern IF has moved quite deliberately away
from those elements. So I think we have to look elsewhere to understand
what consistutes satisfying interactivity.
--Mike
mjr underscore at hotmail dot com
M
JAN THORSBY <jtho...@c2i.net> wrote in article
<kb_na.1409$Y67.1...@juliett.dax.net>...
> There is a good reason why in static fiction every object is not
described
> in detail. People know what an ordinary table or an ordinary three looks
> like. And there are no real reason to describe these things in IF. Or
rather
> there is a reason if "examine" has been implemented.
This is an interesting idea. If 'examine' were not implemented, or
examinable objects were highlighted or otherwise made explicit to the
player, room descriptions could possibly be more impression-oriented (or
impressionistic, if you like), and less inventory-oriented, because the
author would not have to worry about the player "examining" every single
thing that the author mentions.
How about implementing a command that lists all examinable objects in the
room that are visible at present? That way the player could examine to his
heart's content, AND authors could write room descriptions without worrying
about the player trying to examine every little thing that he/she mentions.
Also, I feel that a 2D visual representation of the player's surroundings
could really simplify this whole problem. Not necessarily a drawing, more
like a flow chart: i.e. a simplified graphical representation of the room,
with each object's name inside a discrete visual object such as a circle.
Move your mouse over the circle and the object's description pops up.
> (There is another way around this problem. "Examine" could be a command
that
> takes up no game time.
I'm pretty sure that at least in Hugo there is a way to do this with any
verb. And it sounds like a great idea.
> Many games start off with the player character walking around picking up
> objects. Again I do not think this process is really interactive.
I have to disagree with this as a general, "always true" statement. It
*can* be interactive if it's an interesting process; it can be an
interesting process if, for instance, the objects are interesting, or if
the process of uncovering them feels like something the protagonist would
really be doing. So I have to say, it can be interactive or it can be
really boring and lame. It depends. A lot of it depends on the author and
the player and what each wants.
Thanks for an interesting post!
David A. Cornelson
news:kb_na.1409$Y67.1...@juliett.dax.net...
>
> Every time I, (like I assume many players), get to a new room in a game I
> read through the room description and then methodically examines every
item
> in the room.
You're wrong. Most players I know actually read the descriptions either
carefully or quickly depending upon their mood and determine, with their
_brain_, which is the likliest option that will provide advancement within
the game. They may go _back_ to examine more things, but they don't play
games like it's a checklist of examinations to cover. The point is to infer,
from the story, what you're supposed to do and act upon it.
Your method is like putting a robot mouse in a maze and waiting tediously
until the mouse has discovered the correct path. If you do that, you pretty
much miss the authors purpose. You miss any foreshadowing, timing, suspense,
intrigue, and humor that the author may have painstakingly implemented in
each description.
If you play IF like that, you're missing probably the entire point and
should really consider loading up PacMan.
Dave
Jim Aikin
> If 'examine' were not implemented, or
> examinable objects were highlighted or otherwise made explicit to the
> player, room descriptions could possibly be more impression-oriented (or
> impressionistic, if you like), and less inventory-oriented, because the
> author would not have to worry about the player "examining" every single
> thing that the author mentions.
I intuitively like this suggestion. The 'examinable' command would have to
be made context-sensitive in each room, however. If there's a partridge
hidden in the foliage of the pear tree, you don't want to have it listed
when the player first enters the room and types 'examinable' (which could
perhaps be abbreviated 'xbl'). You want it to be added to the examinable
list after the player searches the foliage, but during the period when
extracting the partridge from the pear tree is still an unsolved puzzle.
And of course, once the partridge is successfully taken, it has to be
removed from the xbl list again. The housekeeping could get a little messy.
Do other folks see problems with the concept above and beyond this?
--JA
Jim
self-recognition...
"JAN THORSBY" <jtho...@c2i.net> wrote in message news:<kb_na.1409$Y67.1...@juliett.dax.net>...
> Any important or interesting or funny information about an object can be in
> the room description.
>
When I think about the games I really enjoyed, a lot of them told the
back story through examining paricular items, especially items that
had nothing to do with puzzle solving. Dutch Dapper IV immediately
comes to mind (probably since I just played it.)
-Jim
J. Robinson Wheeler
> Jan Thorsby wrote:
> >
> > Every time I, (like I assume many players), get to a new room in a
> > game I read through the room description and then methodically
> > examines every item in the room.
>
> You're wrong. Most players I know actually read the descriptions
> either carefully or quickly depending upon their mood and determine,
> with their _brain_, which is the likliest option that will provide
> advancement within the game. They may go _back_ to examine more
> things, but they don't play games like it's a checklist of
> examinations to cover. The point is to infer, from the story, what
> you're supposed to do and act upon it.
Well, that kind of depends on the game, doesn't it?
> Your method is like putting a robot mouse in a maze and waiting
> tediously until the mouse has discovered the correct path. If you
> do that, you pretty much miss the authors purpose. You miss any
> foreshadowing, timing, suspense, intrigue, and humor that the
> author may have painstakingly implemented in each description.
>
> If you play IF like that, you're missing probably the entire point
> and should really consider loading up PacMan.
I don't know about that. I play IF exactly like this, to an extent.
Especially in the first part of a game, where there's not much to
do, usually, except poke around. I examine everything. Later, if
the plot is moving faster, I might do this somewhat less. But
generally, I like examining everything, and it is something of a
rote activity at that level.
Or, for example, when I was playing "The Mulldoon Legacy," it was
necessary to make progress. Not just examining everything (though,
as Jon Ingold reported earlier in the thread, he used default
messages as simple cues to non-interactivity), but deploying, in
an extremely mechanical fashion, a set of verbs on everything I
could think of (pushing, pulling, searching, moving, looking
behind and under), and trying every compass direction whether
there was an exit listed or not; when I failed to do this, I got
stuck, and when I kept doing this, I would always notice the one
little bit I needed to keep going.
I enjoyed the heck out of Mulldoon, as a huge puzzle game IF,
and it was not at all like Pac-Man, and I'm pretty sure I got
the point of it.
I recently played "Savoir-Faire", which also had me examining
everything I came in contact with, over and over again. But I
also recently started playing "City of Secrets", in which I soon
lost interest in examining everything because I became more
concerned about keeping the story moving. Until I got stuck,
that is, and reverted to examining everything, so that I
could figure out how to progress.
--
J. Robinson Wheeler Games: http://www.raddial.com/IF/
j...@jrwdigitalmedia.com Movie: http://thekroneexperiment.com/
Jason Melancon
(replies to <>) wrote:
> I think much of the exploring in IF
> is not really interactive. Particularly the use of the "examine" command. I
> think many games should not implement "examine".
I don't know about this. I examine stuff because I'm curious, and I
like to explore. I'd sooner not curtail this impulse by removing
object descriptions. If anything, games should strive to engage
players' curiosity in *more* ways, not fewer. My Z.02, at least.
--
Jason Melancon
Tim
>to be made context-sensitive in each room, however. If there's a partridge
>hidden in the foliage of the pear tree, you don't want to have it listed
>when the player first enters the room and types 'examinable' (which could
>perhaps be abbreviated 'xbl'). You want it to be added to the examinable
>list after the player searches the foliage, but during the period when
>extracting the partridge from the pear tree is still an unsolved puzzle.
>And of course, once the partridge is successfully taken, it has to be
>removed from the xbl list again. The housekeeping could get a little messy.
Reading this I (rather self-centeredly) though of the way Inevitable handles
'remember'. It should be possible - and actually not that hard - to have a
special form of 'examine' which deals with scenery and provides a
disambiguation list to choose from. Something like this:
>look
You are standing in the center of a fire-breathing dragon's den. Rocks
and gold litter the ground, with the odd human skeleton thrown in for
interest.
>scenery
... rocks, ground, or skeletons?
>> rocks
The rocks are black with soot.
It would also be easy to add to the list should examining one object
bring in more.
>> skeleton
The skeltons are covered in enourmously heavy looking plate armour.
>scenery
... rocks, ground, skeletons, or armour.
Of course, the usual 'x rocks' would also work without problem, and items
could be deleted form this list should the dragon vape them with her flame.
Would such a thing be of interest?
Eytan Zweig
[Snip a lot]
There are many problems with your suggestion already raised in other
people's posts on this thread - I especially agree with Mike Roberts about
the definition of interactivity - but there's one crucial thing I haven't
seen mentioned - information structure.
The look/examine split serves one very important purpose - it splits up
the information you recieve about each room to smaller, managable chunks.
It allows me as a player to process the information in whatever pace I
want. And it allows the authors to work around one of the constraints of
the medium; that is, the fact that it's hard to comfortably read more than
one screenful at a time, and it's hard to predict what a screenful is with
the variety of hardware and platform available these days. And the problem
is confounded with players like me who simply don't have a very good
short-term memory - I often have to reread a description several times
because I don't remember the details important the game. If I want to
refamiliarize myself with a particular object, do I have to get all the
information about the rest of the room/inventory at the same time?
Now, you could partially get around this by having very spartan
descriptions. But this means that you have to sacrifice a large amount of
atmosphere. You claim that everyone knows what a table looks like - but is
that indeed true? Does a dining room with a huge, immaculately clean,
metal table feel the same as one with a small, food-stained wooden table?
Without the liberty to write descriptions for anything he or she wants, an
author will probably be limited to describing only the information
critical for the game - thereby definitely reducing the "fiction" element
of IF, if not the interactivity as well.
Now, I'm not saying that it's impossible to write good IF without
implementing EXAMINE. Far from it - I believe that, in the right hands,
for the right setting, that could be quite an interesting device. But I
don't see how it could possibly be a better standard than the current
system - and how anyone whose description skills are mediocre or worse now
would not be harmed rather than helped by such a paradigm.
Eytan
Mark J Musante
> My advise to the authors, as a player, is don't describe an object, if
> it's ordinary, if everyone knows how it looks like.
Insert some mutterings here about demijohns and whatnot.
-markm
Jon Ingold
> > it's ordinary, if everyone knows how it looks like.
> Insert some mutterings here about demijohns and whatnot.
Or indeed, playing the Hitch-hiker's Guide when I was seven, I had to go and
find a dictionary to work out what a "receptacle" was.
Jon
Quintin Stone
> Another problem with "examine" is in situations with time limits. Lets
> say I am in a cave with a wolf who is getting closer. I know I am
> supposed to shoot the wolf with my silver bullet. But instead I examine
> the wolf. And I examine it's very sharp teeth. And I examines it's regal
> fur. And the wolf eats me. So I load my saved game. But I do not shoot
> the wolf. Instead I examine the stalagmites. And I examine the
> stalactites. And I examine the large rocks. And the wolf eats me again.
> So I load the game, examine the medium sized rocks, the small rocks and
> the puddle of water, gets eaten once again, load the game and then shoot
> the wolf. This is not only tedious, it totally ruins the excitement,
> since it is difficult to fear for the player character's life when he is
> constantly getting resurrected.
I think doctors refer to this as Obsessive/Compulsive Disorder.
Seriously. I sympathize that you have a behavioral imperative that forces
you to play these games a certain way, but frankly I disagreed with just
about every single thing you said. I would hate to play the style of game
you propose.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
J. Robinson Wheeler
> I intuitively like this suggestion. The 'examinable' command would
> have to be made context-sensitive in each room, however. If there's
> a partridge hidden in the foliage of the pear tree, you don't want
> to have it listed when the player first enters the room and types
> 'examinable' (which could perhaps be abbreviated 'xbl').
Hmmm, to me, there already is (or used to be) a command for this,
called >TAKE ALL. Once upon a time, I relied on it quite a bit as
a player, although modern authors seem eager to disable TAKE ALL,
at least as far as being helpful to distinguish what items are
just scenery and what items might be interactive.
As an author, I write my games to allow TAKE ALL to be used in
this way, but I have no idea if any players actually take advantage
of it. TADS tends to make it a little easier than Inform, but maybe
that's because I always use this TADS library of special scenery
class objects that allows me to control how they respond to broadly
inclusive commands.
For example, in the first location of First Things First, there
are a dozen or so scenery objects available -- the house, the
windows, the front door, the lock on the door, the footpath, the
nearby driveway, the moon, the sky, and so on, but if you do
>TAKE ALL it only lists the front door, the doormat, the path,
and some landscaping stones, which are the only objects the
player should concentrate on to make progress.
I have heard it argued that using TAKE ALL in this meta-
fashion is somehow mimesis-breaking. It never bothered me at
all, is all I can say. I suppose you could take this same
functionality at make it a separate verb if it really mattered
that much, because I do think things like this are helpful to
players -- especially in large puzzle games, where there's a
lot of information to process, especially in the first few
hundred turns.
Edmund Kirwan
> On Fri, 18 Apr 2003, JAN THORSBY wrote:
>
> > Another problem with "examine" is in situations with time limits. Lets
> > say I am in a cave with a wolf who is getting closer. I know I am
> > supposed to shoot the wolf with my silver bullet. But instead I examine
> > the wolf. And I examine it's very sharp teeth. And I examines it's regal
> > fur. And the wolf eats me. So I load my saved game. But I do not shoot
> > the wolf. Instead I examine the stalagmites. And I examine the
> > stalactites. And I examine the large rocks. And the wolf eats me again.
> > So I load the game, examine the medium sized rocks, the small rocks and
> > the puddle of water, gets eaten once again, load the game and then shoot
> > the wolf. This is not only tedious, it totally ruins the excitement,
> > since it is difficult to fear for the player character's life when he is
> > constantly getting resurrected.
>
> I think doctors refer to this as Obsessive/Compulsive Disorder.
> Seriously. I sympathize that you have a behavioral imperative that forces
> you to play these games a certain way, but frankly I disagreed with just
> about every single thing you said. I would hate to play the style of game
> you propose.
And - without reopening the IF-versus-simulation wound - is it not
pleasantly reassuring to know that a demented wolf, padding his way
towards you with business in his eye, really WOULD eat you (in real
life) if you ignored him and examined the bejaysus out of all and
sundry?
Don't dis the wold. Never dis the wolf.
.ed
/==================\
www.edmundkirwan.com
"It's not very good."
David Ploog
a80e1059.03042...@posting.google.com...
Not exactly. In real life you would take in all the wolf's pecularities
in an instant. You'd see it was a wolf *and* what it looked like at the
same time. And then you'd run - or climb a tree - or attack it or whatever.
The point is that examining the wolf wouldn't take the time it does in IF.
David
Quintin Stone
> Not exactly. In real life you would take in all the wolf's pecularities
> in an instant. You'd see it was a wolf *and* what it looked like at the
> same time. And then you'd run - or climb a tree - or attack it or
> whatever. The point is that examining the wolf wouldn't take the time it
> does in IF.
Well, no, not really. In real life, there would be many subtle layers of
examinations, from cursory to really in depth. GLANCE AT versus EXAMINE
versus STUDY, just to name some examples.
Mark J. Tilford
> Edmund Kirwan <ade...@eircom.net> schrieb in im Newsbeitrag:
>
>> pleasantly reassuring to know that a demented wolf, padding his way
>> towards you with business in his eye, really WOULD eat you (in real
>> life) if you ignored him and examined the bejaysus out of all and
>> sundry?
>>
>
> Not exactly. In real life you would take in all the wolf's pecularities
> in an instant. You'd see it was a wolf *and* what it looked like at the
> same time. And then you'd run - or climb a tree - or attack it or whatever.
> The point is that examining the wolf wouldn't take the time it does in IF.
>
> David
>
Gee, I'd probably notice its wolfish nature, general coloration, and
teeth. I probably wouldn't notice if it were wearing a collar or if
seemed to have trouble with one limb (at least, not until I had the chance
to climb a tree or get into a car and shut the door behind me).
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Jay T
> read through the room description and then methodically examines every
item
> in the room. (and then I often have to examine every new item that pops up
> in the descriptions of the first items).
>
> Many games start off with the player character walking around picking up
> objects. Again I do not think this process is really interactive. I am not
I think we're moving towards a solution here.
"Examine all" would be easy to implement, and since it would be used every
time
you enter a new room it could automatically happen right after the long room
description.
Then of course we might as well automatically implement the
"get all" command because that's the next thing every player is going to do.
This would require a little more sophistication that is initially obvious.
If getting anything causes you to instantly die, then the game should be
reloaded and the offending item dropped from the get list and then the
process retried. Also, there might be some order dependencies, so the get
all must be looped until no new items are obtained.
"Talk to all" would be implemented similarly.
Then of course "use all" would allow you to try to use each item in your
inventory against any puzzles in the room. Requiring any other verbs to
solve
the puzzle is obviously just a case of "guess the verb" and wouldn't be too
sporting, so we can conclude that the room is finished and the player hasn't
had to type anything, since we knew what he was going to do anyway.
All that's left is movement. I recall that an "exits" command has become
popular.
"Exit all exits" would form a list of possible exits and them perform a
recursive
depth first search until it found a winning solution.
At that point the game log would be sent to your printer so you could read
it
at your leisure.
> In the same way I think much of the exploring in IF is not really
interactive.
The "I" in "IF" stands for interactive?
Oh.
Never mind.
Andrew Plotkin
> "JAN THORSBY" <jtho...@c2i.net> wrote:
>> It has been said that a menu-based conversation system where
>> it is possible to go through the same conversation more than
>> once is not really interactive [because the player will eventually
>> see the whole thing anyway: why not just show it all in one go?].
> This definition - interactivity equals choice of outcome - has been proposed
> here before, but I disagree with it. I think it's way too narrow, and even
> more importantly, misses the point.
> I'd define interactivity as control over *process*, not outcome.
I agree with you -- even though I take the position Jan describes,
about menu conversations. (I pounded on it egregiously in my review of
_The Longest Journey_, for example.)
Is this a contradiction? Hmm. The menu conversations that bother me
are the ones where the process is shallow. If the menu gives you a
list of responses, and each response is exactly the same regardless of
what order you choose them in, then your control over process is
*boring*. You're rearranging a bunch of paragraphs, and they don't
even have any internal ordering connections -- they're written to be
read in any order.
_TLJ_ isn't that shallow, but I'd argue that it's only one step
deeper.
So, taking it back to Jan's example, I definitely agree that
mechanically EXAMINE-ing every noun in the room description is not a
desirable player experience. It's not fun and it provides no sense of
interactivity... *if* it's a purely mechanical action.
However, I think the IF world has some sense of this, even if it's
unspoken. Games generally *don't* require you to do this. They used
to; I remember playing _Unnkulia 1_ and feeling very worn down by the
"Have I examined everything? Pushed everything? Looked under and
behind everything?" mode of thought.
But these days we regard such games as retro, and not in a shiny
art-deco way. :) You mentioned _Mulldoon_ (or someone else did in this
thread). I wouldn't say that reviewers have slammed _Mulldoon_ for
being too puzzle-heavy, but they *are* careful to say that it's an
old-fashioned, poke-at-everything game. This is precisely because
that's become unusual.
The common mode nowadays is to give a strong sense of focus -- the
room's description should attract the player's attention to just those
things that the *protagonist's* attention is drawn to. By examining
those, you follow the protagonist's storyline of discovery. If you
examining irrelevant things, the game conveys that you're on the wrong
track, or at least a track which is irrelevant.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Harry
<snipped some interesting stuff I might respond to later>
>Every time I, (like I assume many players), get to a new room in a game I
>read through the room description and then methodically examines every item
>in the room. (and then I often have to examine every new item that pops up
>in the descriptions of the first items). I don't feel I have must choice in
>doing this, I can't risk missing out on any information I need to win the
>game. So it is not really interactive.
If you need to mechanically examine everything in a room then there is
no enjoyment. And if the object of the game is to 'examine everything'
then there is something wrong with the design.
A good game presents you with a puzzle and gives you incentive to find
a solution. Examining things helps you find clues to the solution and
gives you more info about the game world.
But you know all this. The thing is: most things you can examine are
scenery and therefor only important for scene setting. As I stated, a
good game presents you with a proper game goal which gives you a
reason to examine certain things.
I do agree with you that 'examine' should not take a turn. I find it
odd that actions like 'look', 'examine' and 'inventory' take time,
while they are merely a way to provide information we would naturally
posses in Real Life.
-------------------------
"Hey, aren't you Gadget?"
"I was."
(To send e-mail, remove SPAMBLOCK from address)
Andrew Plotkin
> I do agree with you that 'examine' should not take a turn. I find it
> odd that actions like 'look', 'examine' and 'inventory' take time,
> while they are merely a way to provide information we would naturally
> posses in Real Life.
"Examine" covers a broad range of information-gathering -- some of
which takes time.
With the advent of "undo" being available in just about every IF
interpreter, I think the issue has sort of evaporated. It may not be
mimetic, but you *can* look-and-undo if you really need to -- and how
many times per IF-playing-day do you really need to?
Dan Schmidt
| Hmmm, to me, there already is (or used to be) a command for this,
| called >TAKE ALL. Once upon a time, I relied on it quite a bit as a
| player, although modern authors seem eager to disable TAKE ALL, at
| least as far as being helpful to distinguish what items are just
| scenery and what items might be interactive.
The problem with disabling TAKE ALL is that sometimes you want to DROP
ALL and then it's tedious to pick everything up again by hand.
Maybe I could try keeping a 'Has the player dropped this object since
taking it?' property on objects and have TAKE ALL only pick those up.
People would probably find it pretty weird, though.
Dan
R. N. Dominick
news:3lbbav0qr0jo4j7u1...@4ax.com:
> I do agree with you that 'examine' should not take a turn. I find it
> odd that actions like 'look', 'examine' and 'inventory' take time,
> while they are merely a way to provide information we would naturally
> posses in Real Life.
If you are looking at a room in your own home, perhaps, or examining an
item that you've owned for quite some time -- and some items, not even
then. (Imagine a CD; you'd have to look at it to see the track listing,
right? At least, I can't remember the listings for all of my CDs.)
Usually in adventure games, the places and items you come across are new
to the player. Sure, I know a chest of drawers when I come across it, but
do I automatically count how many drawers it has? Not unless I'm
furniture shopping.
And I'm often taking inventory when out -- do I have my keys? my wallet?
did I put that book in my bag? where's that thing I just bought? where
are the directions to where I'm driving? which CDs do I have, and which
one do I want to play next? It takes time to do.
--
R. N. Dominick -- ur...@bookmice.net
Coffeehouse Software -- IF non-productivity in spades!
http://www.bookmice.net/coffeehouse/
Edmund Kirwan
> Harry <gad...@SPAMBLOCKhaha.demon.nl> wrote in
> news:3lbbav0qr0jo4j7u1...@4ax.com:
>
> > I do agree with you that 'examine' should not take a turn. I find it
> > odd that actions like 'look', 'examine' and 'inventory' take time,
> > while they are merely a way to provide information we would naturally
> > posses in Real Life.
>
This sounds a little - a very little - like the argument against
X-wings making those lovely, huge, roaring noises in space. Yes, it's
true: spaceships don't make noise in space because there's no
atmosphere to vibrate. But isn't it so much more exciting with the
X-wings roaring and squealing and throbbing and whirling?
The point being: good science is bad theatre.
Ok, in real life, you can, "Instaneously," absorb a wealth of
information without, "Time passing;" but what's so wrong with a game's
being slightly more difficult than reality?
If reality were the absolure ruler in these things, then we wouldn't
be playing the games in the first place.
PTN
Harry wrote:
> > I do agree with you that 'examine' should not take a turn. I find it
> > odd that actions like 'look', 'examine' and 'inventory' take time,
The assumption underlying this problem is that a turn is a measure of time.
But a turn counter is simply a way to keep track of the number of turns a
player takes to complete a game. It makes sense that everything gets
counted, and incremented by one, whether you are performing an action or
simply doing another >look so you can remember the room description. It
would no longer be a true measure of turns if it didn't.
On the other hand, this may be a problem in games that use time increments
instead of turns. One way to get around it is to assign specific time
increments for everything. Examining might just take fifteen seconds. Moving
between indoor rooms, thirty. Moving between outside locations, a minute or
more. And so on. Or you can just split the difference and call everything a
minute, which is simpler and manages player expectations, too.
-- Peter
Andrew Plotkin
> Harry wrote:
>> > I do agree with you that 'examine' should not take a turn. I find it
>> > odd that actions like 'look', 'examine' and 'inventory' take time,
> The assumption underlying this problem is that a turn is a measure of time.
> But a turn counter is simply a way to keep track of the number of turns a
> player takes to complete a game.
No, the "turn counter" -- in this context, whether "examine" should
take a turn -- is what ticks off encroaching game events.
Almost nobody cares how many turns it takes to win a game. (I've seen
people discussing the most efficient way to win _Witness_ -- that's
the only example.) The issue people care about is whether the wolf
eats you.
Jake Wildstrom
>Almost nobody cares how many turns it takes to win a game. (I've seen
>people discussing the most efficient way to win _Witness_ -- that's
>the only example.) The issue people care about is whether the wolf
>eats you.
Er, _Witness_? Really? Seems a silly example, since, like all the
Infocom mysteries, it involves timed events critical to the solution,
so even if you do everything necessary in the _first_ turn, you still
have to wait around for the timed events to happen.
Now, _Suspended_ -- there's an interesting game to try to solve quickly.
+-------------------------------------------------------------+
| D. Jacob Wildstrom -- Math monkey and freelance thinker |
| Graduate Student, University of California at San Diego |
| "A mathematician is a device for turning coffee into |
| theorems." -Alfred Renyi |
+-------------------------------------------------------------+
The opinions expressed herein are not necessarily endorsed by the
University of California or math department thereof.
Andrew Plotkin
> The Prophet Andrew Plotkin known to the wise as erky...@eblong.com, opened the Book of Words, and read unto the people:
>>Almost nobody cares how many turns it takes to win a game. (I've seen
>>people discussing the most efficient way to win _Witness_ -- that's
>>the only example.) The issue people care about is whether the wolf
>>eats you.
> Er, _Witness_? Really? Seems a silly example, since, like all the
> Infocom mysteries, it involves timed events critical to the solution,
> so even if you do everything necessary in the _first_ turn, you still
> have to wait around for the timed events to happen.
Nonetheless, it's the Infocom game winnable in the fewest turns.
Eighteen, I think it was.
Jake Wildstrom
>Eighteen, I think it was.
Yes, but most of those turns are "WAIT FOR <EVENT THAT DOESN'T HAPPEN
FOR SOME TIME>", which arguably is not a single-turn move.
PTN
> No, the "turn counter" -- in this context, whether "examine" should
> take a turn -- is what ticks off encroaching game events.
Well, I think a turn is a turn, regardless of context. The question, as to
whether "examine" should tick off a timer which moves forward game events,
is a seperate issue from whether it should take a turn, which I believe it
should because it is (a turn).
So, as to whether "examine" should tick off a timer which moves forward game
events or not, I suppose an author could tie different actions to different
amounts of time, as I mentioned in the previous post, to measure this more
exactly, though I have to be honest, it doesn't make much sense to me to do
it that way.
Take the example of the wolf. In the game a wolf is about to lunge on the
player character. In real life, a person would have a few moments to act and
then be lunch. In the IF world, the player can think about what to do for a
year before making each move. How do you put time pressure on a player in a
medium where there is no time pressure, ever, given the nature of the
command input? By restricting the amount of turns the player can take before
the wolf eats his character. EXAMINE might not take a lot of time in the
real world, but the player has a lot more time to think playing IF than they
would in the real world, too. Wolf attacks are rarely like chess, but in IF,
they are. So even in a time-based puzzle, what the game is really doing is
restricting the amount of turns a player has, not how much time a character
has. Depending on how difficult the author would like to make the puzzle,
they can make it a small amount of turns, a small amount of turns but not
counting identification actions as incrementing the timer, or just make it a
larger amount of turns. To complain about EXAMINE taking up time I think
misses the point. It takes up a turn.
Then again, the proceeding is a look at IF from very much so a game
perspective, not a fiction or simulation perspective. But IF is, at its
heart (or at least originally) a game, so many of the conventions of the
form are still based on game logic.
-- Peter
http://www.illuminatedlantern.com
Andrew Plotkin
> Depending on how difficult the author would like to make the puzzle,
> they can make it a small amount of turns, a small amount of turns but not
> counting identification actions as incrementing the timer, or just make it a
> larger amount of turns. To complain about EXAMINE taking up time I think
> misses the point. It takes up a turn.
But it doesn't change the state of the world (in general). Neither
does LOOK or INVENTORY.
If the puzzle is to accomplish a goal in a fixed number of turns,
these identification actions don't get you any closer to the goal.
They give you information on *how* to accomplish the goal -- and you
could very well already have that information. (From a prior
run-through, from typing RESTORE, from typing UNDO.)
The player's argument is that requiring turns to gather that
information *doesn't* make the puzzle any harder. It just makes it
more tedious, with more iterations of RESTORE or UNDO. The player has
a point.
The counter argument is that there are lots of timed situations that
*don't* have death at the end. (Events that you can restart (not
RESTORE, just ordinary in-game try-it-again.) Or events that are just
periodic.) And a game world is juicier if stuff happens around you as
you examine the room. If time freezes while you search stuff, it's
jarring -- and dull as well.
Even when puzzles are involved, it's more exciting to try something a
few times, learning more and becoming more efficient each time. The
complaint about EXAMINE taking a turn really only surfaces when the
game threatens to end.
So I guess one solution is to have EXAMINE and LOOK and INV take up a
turn *except* when you're in a timed deathtrap.
But the more elegant solution is not to have timed deathtrap puzzles
in which you need to stop and examine all sorts of crap. Let the
player get familiar with everything before the timer starts. Allow one
turn on the timer for INV.
If you're going to have timed deathtrap puzzles at all, I mean.
R. N. Dominick
news:b8cm4m$56$1...@reader1.panix.com:
> (I've seen
> people discussing the most efficient way to win _Witness_ -- that's
> the only example.)
I also remember quite a bit of competition about how quickly _Suspended_
could be won, back in the day.
Quintin Stone
> The player's argument is that requiring turns to gather that information
> *doesn't* make the puzzle any harder. It just makes it more tedious,
> with more iterations of RESTORE or UNDO. The player has a point.
Maybe so, except that the example given was an extremely poor one...
> But the more elegant solution is not to have timed deathtrap puzzles
> in which you need to stop and examine all sorts of crap. Let the
> player get familiar with everything before the timer starts. Allow one
> turn on the timer for INV.
>
> If you're going to have timed deathtrap puzzles at all, I mean.
...Because if you recall, in the original example, there was no need for
the player to stop and examine all sorts of crap. The poster knew exactly
what to do (shoot the damn wolf), but because of some sort of behavioral
imperative, could not force him/herself to do so until examining every
little object mentioned in the room desc. So unless someone has a better
example of a timed puzzle that actually *depends* on examining various
objects, I don't really see any need to chance the status quo.
Andrew Plotkin
> On Sat, 26 Apr 2003, Andrew Plotkin wrote:
>> The player's argument is that requiring turns to gather that information
>> *doesn't* make the puzzle any harder. It just makes it more tedious,
>> with more iterations of RESTORE or UNDO. The player has a point.
> Maybe so, except that the example given was an extremely poor one...
>> But the more elegant solution is not to have timed deathtrap puzzles
>> in which you need to stop and examine all sorts of crap. Let the
>> player get familiar with everything before the timer starts. Allow one
>> turn on the timer for INV.
>>
>> If you're going to have timed deathtrap puzzles at all, I mean.
> ...Because if you recall, in the original example, there was no need for
> the player to stop and examine all sorts of crap. The poster knew exactly
> what to do (shoot the damn wolf), but because of some sort of behavioral
> imperative, could not force him/herself to do so until examining every
> little object mentioned in the room desc.
Ah. Hrm. Yes, I recall that post now.
> So unless someone has a better example of a timed puzzle that
> actually *depends* on examining various objects, I don't really see
> any need to chance the status quo.
You can always find examples of whatever. If a specific puzzle is
well-written, obviously it doesn't need to be changed.
dreamfarmer
> ...Because if you recall, in the original example, there was no need for
> the player to stop and examine all sorts of crap. The poster knew exactly
> what to do (shoot the damn wolf), but because of some sort of behavioral
> imperative, could not force him/herself to do so until examining every
> little object mentioned in the room desc. So unless someone has a better
> example of a timed puzzle that actually *depends* on examining various
> objects, I don't really see any need to chance the status quo.
>
I vaguely remember a game that did something like respond to commands
to examine irrelevant details while being attacked with, "You can't
focus on that right now, as there's a wolf about to devour you." No
details on what game or even type of game it was, though.
It seemed like an entertaining solution, though.
Damien Neil
Quintin Stone <st...@rps.net> wrote:
> ...Because if you recall, in the original example, there was no need for
> the player to stop and examine all sorts of crap. The poster knew exactly
> what to do (shoot the damn wolf), but because of some sort of behavioral
> imperative, could not force him/herself to do so until examining every
> little object mentioned in the room desc. So unless someone has a better
> example of a timed puzzle that actually *depends* on examining various
> objects, I don't really see any need to chance the status quo.
The behavioral imperative is a desire to get the whole story. If the
author wrote descriptive text that can only be read during those few
moves, many players will want to read it, just in case it contains
something of interest.
Sometimes you have to do exactly this to find hidden parts of the game.
This problem is particularly noticable in console RPGs, where the
immediate reaction of any player finding herself in a burning house is
to go upstairs and search the cupboards.
- Damien
Quintin Stone
> The behavioral imperative is a desire to get the whole story. If the
> author wrote descriptive text that can only be read during those few
> moves, many players will want to read it, just in case it contains
> something of interest.
Did you read the original post? If so, you'd know that the example
presented has nothing like what you describe. That's why I asked for an
existing example of a puzzle where constant examining of scenery objects
during a timed puzzle was actually vital to solving the game. In any
event, why not simply write it off as a bad puzzle design? There are
certainly plenty of those and very few prompt a call to change fundamental
game components.
Here is relevant passage from the original post:
> Another problem with "examine" is in situations with time limits. Lets
> say I am in a cave with a wolf who is getting closer. I know I am
> supposed to shoot the wolf with my silver bullet. But instead I examine
> the wolf. And I examine it's very sharp teeth. And I examines it's regal
> fur. And the wolf eats me. So I load my saved game. But I do not shoot
> the wolf. Instead I examine the stalagmites. And I examine the
> stalactites. And I examine the large rocks. And the wolf eats me again.
> So I load the game, examine the medium sized rocks, the small rocks and
> the puddle of water, gets eaten once again, load the game and then shoot
> the wolf. This is not only tedious, it totally ruins the excitement,
> since it is difficult to fear for the player character's life when he is
> constantly getting resurrected.
This is not a desire to get the whole story. It's just bizarre, and
nowhere does he/she suggest that examining those things *after* shooting
the wolf is impossible.
Mark J. Tilford
>
> Did you read the original post? If so, you'd know that the example
> presented has nothing like what you describe. That's why I asked for an
> existing example of a puzzle where constant examining of scenery objects
> during a timed puzzle was actually vital to solving the game. In any
The Light: Shelby's Addendum, first puzzle, though I've heard later
versions toned it down a little; also, it's not a tightly timed puzzle.
PTN
"Andrew Plotkin" <erky...@eblong.com> wrote:
> Here, PTN <peternepstad@(removethis)gmx.de> wrote:
> > Depending on how difficult the author would like to make the puzzle,
> > they can make it a small amount of turns, a small amount of turns but
not
> > counting identification actions as incrementing the timer, or just make
it a
> > larger amount of turns. To complain about EXAMINE taking up time I think
> > misses the point. It takes up a turn.
>
> But it doesn't change the state of the world (in general). Neither
> does LOOK or INVENTORY.
That's true. But I think there is a difference between EXAMINE and LOOK or
INVENTORY. The latter two are just checking game state, sort of, providing
information you should already know but have forgotten, whereas EXAMINE
provides new detailed information that you wouldn't have had before. Some
text graphic hybrid games, and it would probably be possible using HTML
TADS, keep the LOOK text onscreen the whole time and only scroll the command
area, eliminating the need of a LOOK command entirely. Throw a list of
carried items in a sidebar and that would get rid of INVENTORY as well. You
can't do something like this with EXAMINE. Well, I guess the original poster
thought perhaps you could, but it doesn't really seem reasonable.
> If the puzzle is to accomplish a goal in a fixed number of turns,
> these identification actions don't get you any closer to the goal.
> They give you information on *how* to accomplish the goal -- and you
> could very well already have that information. (From a prior
> run-through, from typing RESTORE, from typing UNDO.)
>
> The player's argument is that requiring turns to gather that
> information *doesn't* make the puzzle any harder. It just makes it
> more tedious, with more iterations of RESTORE or UNDO. The player has
> a point.
Oh, I don't know. The puzzle is not made more tedious because of
RESTORE/UNDO per se, the puzzle is made more tedious only if it becomes too
hard for the player to figure out right away, and has to RESTORE over and
over again to get it right. But then, how is this different from any other
form of computer game? You play, you die, you restart, you re-do the same
tedious moves over again, you get a little farther, die again, and so on. As
you proceed you increase your skill at playing, die less often, and so on.
All action computer games, just like any sort of training you do in real
life, includes an element of repitition. If this sort of tedium is so
undesirable, why is it an element in almost all forms of game play?
Come to think of it, I think we mostly agree about this since you wrote in
your counter argument:
> Even when puzzles are involved, it's more exciting to try something a
> few times, learning more and becoming more efficient each time.
Maybe the difference is I don't see where getting killed when you fail and
having to restore is necessarily a problem, especially considering players
will often fiddle with a puzzle for a while, figure it out, then restore
anyway to solve it in less time.
I could imagine a well crafted puzzle which would require you, in a limited
amount of turns, to quickly find a solution out of a trap. It would work
best if the trap is triggered immediately upon entering a room. The door
shuts behind you, the floor starts sliding open. You are carrying your
trusty whip. There are stalagtites overhead, you think maybe....and type
EXAMINE STALAGTITES. One looks thicker and sturdier than the rest. You whip
it, swing across, then ask your companion to throw you the idol. In this
case the player is given a new room, with no prior information, has to think
about how he can escape given what is in his inventory, and what is in the
room itself. It's fun. Now, that's not to say that a player may die a few
times, first, going back, experimenting with other ideas, trying again. As
long as it is possible to solve in the amount of time alloted, that is, the
puzzle is "fair", then the number of times a player tries before succeeding
will vary based on the players skill level.
-- Peter
Quintin Stone
> Oh, I don't know. The puzzle is not made more tedious because of
> RESTORE/UNDO per se, the puzzle is made more tedious only if it becomes
> too hard for the player to figure out right away, and has to RESTORE
> over and over again to get it right. But then, how is this different
> from any other form of computer game? You play, you die, you restart,
> you re-do the same tedious moves over again, you get a little farther,
> die again, and so on. As you proceed you increase your skill at playing,
> die less often, and so on. All action computer games, just like any sort
> of training you do in real life, includes an element of repitition. If
> this sort of tedium is so undesirable, why is it an element in almost
> all forms of game play?
I'd have to agree. This all seems to be taking one particular type of
puzzle and isolating it without cause. Though I kind of agree with the
idea of a LOOK taking no game time, I consider EXAMINE to be a much more
thorough investigation.
Andrew Plotkin
> "Andrew Plotkin" <erky...@eblong.com> wrote:
>> The player's argument is that requiring turns to gather that
>> information *doesn't* make the puzzle any harder. It just makes it
>> more tedious, with more iterations of RESTORE or UNDO. The player has
>> a point.
> Oh, I don't know. The puzzle is not made more tedious because of
> RESTORE/UNDO per se, the puzzle is made more tedious only if it becomes too
> hard for the player to figure out right away, and has to RESTORE over and
> over again to get it right. But then, how is this different from any other
> form of computer game? You play, you die, you restart, you re-do the same
> tedious moves over again, you get a little farther, die again, and so on. As
> you proceed you increase your skill at playing, die less often, and so on.
> All action computer games, just like any sort of training you do in real
> life, includes an element of repitition. If this sort of tedium is so
> undesirable, why is it an element in almost all forms of game play?
In action games, you're actually getting better at something. Physical
skill runs by its own rules; the whole point of action games is that
intellectual knowledge is not the same as "muscle memory".
Even for less reflex-oriented games (stealth games, for example),
the game is dominated by tiny details that you might not get right.
(Edges of timing, etc.) Two run-throughs of the same scene can turn
out differently due to luck and skill.
The reason this is *interesting* is that skill can predominate over
luck -- if you get good enough.
None of this is relevant to typing "x bookcase, undo". You don't have
to be good at anything, or even clever, to think of that. It's a
boringly optimal solution.
"Hard" in an adventure game is a very different beast from "hard" in
an adventure game. I think even strategy games wind up in the latter
category, not the former.
Ricardo SIGNES
> "Hard" in an adventure game is a very different beast from "hard" in
> an adventure game. I think even strategy games wind up in the latter
> category, not the former.
Your words are too cunning for me to comprehend.
--
rjbs
Damien Neil
Quintin Stone <st...@rps.net> wrote:
> Did you read the original post? If so, you'd know that the example
> presented has nothing like what you describe. That's why I asked for an
> existing example of a puzzle where constant examining of scenery objects
> during a timed puzzle was actually vital to solving the game. In any
> event, why not simply write it off as a bad puzzle design? There are
> certainly plenty of those and very few prompt a call to change fundamental
> game components.
Why, yes, I did read the original post.
I could be snippy and ask if you read my post...oh, heck, I will be
snippy. Puzzles aren't the only reason to want to examine things
during timed situations (although they are /a/ reason). There may be
portions of the scene which are only visible during the timed event.
For example, the description of the wolf's very sharp teeth is likely
to be very different before and after the wolf has been shot. Many
players want to view every bit of text that may be seen in the game;
these people will find themselves examining rather than acting.
This isn't bizarre, either. If there is text which may only be seen in
those few turns, it's there because the game author put it there. I
don't see it as unreasonable to think that if the author thought it was
worth writing some text, it must be worth reading as well.
Finally, for an example of a puzzle where examining objects in a timed
situation is vital: _Hitchhiker's Guide to the Galaxy_; the sandwich.
- Damien
Ricardo SIGNES
> I could be snippy and ask if you read my post...oh, heck, I will be
> snippy. Puzzles aren't the only reason to want to examine things
> during timed situations (although they are /a/ reason). There may be
> portions of the scene which are only visible during the timed event.
> For example, the description of the wolf's very sharp teeth is likely
> to be very different before and after the wolf has been shot. Many
> players want to view every bit of text that may be seen in the game;
> these people will find themselves examining rather than acting.
>
> This isn't bizarre, either. If there is text which may only be seen in
> those few turns, it's there because the game author put it there. I
> don't see it as unreasonable to think that if the author thought it was
> worth writing some text, it must be worth reading as well.
The author should leave time for you to "EXAMINE WOLF"; if you can further
EXAMINE PAWS and EXAMINE TEETH and EXAMINE THAT LITTLE SKIN TAG ON THE WOLF'S
EAR, and those things change between the one turn in which the wolf arrives and
two turns later, the author is giving you a badly designed puzzle.
If the author thinks it's worth his writing and your reading, he will make sure
it can be seen -- unless it's an easter eggy thing that he expects you to have
to struggle for.
This seems to just go back to the question of "does this puzzle suck?"
I mean, it would be nice if you could define turn-costs for moves in a
context-sensitive way. I think we can live without it, though.
> Finally, for an example of a puzzle where examining objects in a timed
> situation is vital: _Hitchhiker's Guide to the Galaxy_; the sandwich.
HHGG is a lot of fun, but it's got some of the most contrary-to-good-design
puzzles ever. The sandwich and vending machine should be on everyone's Stuff
to Avoid list.
--
rjbs
PTN
"Andrew Plotkin" <erky...@eblong.com> wrote:
> In action games, you're actually getting better at something.
Usually, though, all you're really getting better at is playing the game.
You learn to respond to the rhythms of the game, how the controls handle,
what the forgiveness level is, how much risk-taking you can do. You can
learn these things whether it is an action game or strategy/puzzle game.
Solving one puzzle in a work of IF usually teaches you how to approach the
next puzzle in the same work.
> None of this is relevant to typing "x bookcase, undo". You don't have
> to be good at anything, or even clever, to think of that. It's a
> boringly optimal solution.
I don't think typing UNDO would ever be part of the optimal solution, since
its really more of a cheat. I could imagine a puzzle where there are plenty
of things a player can look at in a room, with a finite amount of time to
figure out what to do, being able to think through the puzzle, examine the
right things, then take action based on that knowledge, without having to
UNDO or RESTORE, might bring a certain satisfaction to the player. Then
again, it might not. So hard to read players these days. But anyway, this is
drifting far, far from the original posters point, which I forget exactly.
> "Hard" in an adventure game is a very different beast from "hard" in
> an adventure game. I think even strategy games wind up in the latter
> category, not the former.
Here we completely disagree. Surely strategy games wind up in the former
category, not the latter.
-- Peter
http://www.illuminatedlantern.com
Greg Ewing (using news.cis.dfn.de)
> I intuitively like this suggestion. The 'examinable' command would have
> to be made context-sensitive in each room, however. If there's a
> partridge hidden in the foliage of the pear tree, you don't want to have
> it listed when the player first enters the room and types 'examinable'
> (which could perhaps be abbreviated 'xbl').
Perhaps 'interesting' would be a better name for this, with
the idea that it's the set of objects that are both worth
examining and that the PC has reason to think might be
interesting given what's happened in the game so far.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Andrew Plotkin
> "Andrew Plotkin" <erky...@eblong.com> wrote:
>> In action games, you're actually getting better at something.
> Usually, though, all you're really getting better at is playing the game.
> You learn to respond to the rhythms of the game, how the controls handle,
> what the forgiveness level is, how much risk-taking you can do. You can
> learn these things whether it is an action game or strategy/puzzle game.
> Solving one puzzle in a work of IF usually teaches you how to approach the
> next puzzle in the same work.
I fear I no longer understand what this argument has to do with what
the thread was originally about.
>> None of this is relevant to typing "x bookcase, undo". You don't have
>> to be good at anything, or even clever, to think of that. It's a
>> boringly optimal solution.
> I don't think typing UNDO would ever be part of the optimal
> solution, since its really more of a cheat.
That's more or less what I was saying, except that "cheat" has moral
implications that probably aren't worth bringing up... I worry about
the breaking of the player's immersion, and I worry about wasted
keystrokes.
Gene Wirchenko
>"Andrew Plotkin" <erky...@eblong.com> wrote:
[snip]
>> None of this is relevant to typing "x bookcase, undo". You don't have
>> to be good at anything, or even clever, to think of that. It's a
>> boringly optimal solution.
>
>I don't think typing UNDO would ever be part of the optimal solution, since
"Paging Mr. Makane. Paging Mr. Makane!"
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Gene Wirchenko
>Just a very small point:
>
>> Then one has to write
>> descriptions for everything, because standard phrases like "you see
>nothing
>> special about that" is annoying.
>
>I disagree with this. As you say, a table is a table, a fork is a fork. When
>a player sees this message for the third time or so, he *stops reading it*
>and just takes it as a dismissal, so it uses up *no reading time*. And it
>allows the player to dismiss the object more easily.
>
>Actually, this is all a better argument for using "That's not important in
>the course of this game", because it makes the game world more manageable
>without any particular cost (assuming its not a game about exploring a tight
>environment, I suppose. It's the difference between a space-opera
>doorstopper and a Virginia Woolf novel).
You are in your cabin on board the U.S.S. Fancyname.
You can see your bed, your desk with a lamp on it, and the door out.
The door has been jammed open with a doorstopper.
>x doorstopper
It appears to be a Virginia Woolf novel.
Gene Wirchenko
>Andrew Plotkin <erky...@eblong.com> wrote in
>news:b8cm4m$56$1...@reader1.panix.com:
>
>> (I've seen
>> people discussing the most efficient way to win _Witness_ -- that's
>> the only example.)
>
>I also remember quite a bit of competition about how quickly _Suspended_
>could be won, back in the day.
I remember one Apple II adventure which had a contest for the
first person to solve it in the optimal number of turns. I only
played it a little and do not recall the title.
Gene Wirchenko
>"R. N. Dominick" <ur...@bookmice.net> wrote in message news:<Xns9366A6DC37FC...@65.24.2.12>...
>> Harry <gad...@SPAMBLOCKhaha.demon.nl> wrote in
>> news:3lbbav0qr0jo4j7u1...@4ax.com:
>>
>> > I do agree with you that 'examine' should not take a turn. I find it
>> > odd that actions like 'look', 'examine' and 'inventory' take time,
>> > while they are merely a way to provide information we would naturally
>> > posses in Real Life.
>This sounds a little - a very little - like the argument against
>X-wings making those lovely, huge, roaring noises in space. Yes, it's
>true: spaceships don't make noise in space because there's no
>atmosphere to vibrate. But isn't it so much more exciting with the
>X-wings roaring and squealing and throbbing and whirling?
The spoof I like is that explosions are louder in space, because
there is not all the air getting in the way.
>The point being: good science is bad theatre.
And often vice versa.
[snip]