Question about describing room exits
Lelah Conrad
Hi,
C.E. Forman disliked (I think!) obviously noted exits in a
number of competition games. On the other hand, I recall reading a
response or two where people were complaining about the exits not
being noted. Which one is it? Do people want exits just sort of
"hinted at"? Would someone please expand on this discussion, or point
me to a previous discussion on this topic? Thanks,
Lelah
"Dummy, Newbie, whatever"
Irene Callaci
I would like to see this discussed as well. I'm slowly
learning Inform and putting together my first attempt
at interactive fiction, and one of the most difficult
parts of this whole process is turning out to be the
room descriptions! I cannot seem to write a decent
room description that indicates obvious exits without
falling into a sing-song rendition of "you can go
this way and that way and this way and that..."
There are points in my game when I WANT the player to
feel lost (in the woods, for example). On the other
hand, I really dislike games where I have to use trial
and error to find my way around, especially after I've
already visited a location.
I am experimenting with a combination of SmartCantGo
(which lists available exits only if the player enters
an invalid direction) and a compass rose on the status
line, as well as trying to write interesting and
helpful room descriptions. But I am finding it tough
going and would appreciate any and all comments on
this subject.
irene
Neil K.
lco...@lane.k12.or.us (Lelah Conrad) wrote:
> C.E. Forman disliked (I think!) obviously noted exits in a
> number of competition games. On the other hand, I recall reading a
> response or two where people were complaining about the exits not
> being noted. Which one is it? Do people want exits just sort of
> "hinted at"? [...]
I think it's one of those "you can't please everyone" situations. :)
The convention in most IF is simply to list all the compass-rose
directions possible in the room description. No matter how you do it,
however, it gets clunky, simply because there are only so many ways you
can say "to the east is...". In fact, I think it's one of the main reasons
IF prose tends to be less interesting than conventional prose, because
with conventional prose you aren't hamstrung by the need fairly to inform
the player of directions - especially not with a formalized absolute
compass system.
A compromise might be to be a little vague about the actual compass rose
directions, but supply an "exits" command that lists all visible exits a
player can take. That method can be more aesthetically pleasing, but will
also annoy a lot of players, who'll object to having to type "exits" the
first time they enter a room. You could also avoid the compass rose in the
first place, and have people refer to nouns in the description instead
("board train", "enter the brick building") but then that annoys people
who are used to compass rose directions.
Or you could be bold and strike out in new directions - such as trying to
formulate a relative direction system that actually works. That territory
is fraught with hazards, however, and few have ever returned alive. In
large part because of the tremendous difficulty of dealing with
ambiguities. Do you implement some sort of internal grid system to permit
commands like "stand next to the table" or "walk forwards three metres"?
Do you take on the daunting task of permitting your game to understand all
kinds of complex commands like "turn around and go the other way"?
I'm sweating in terror at the thought of some of that - so like most of
us I safely stick to our good friend the compass rose, with an exits
command and occasional support of "enter building"-type commands to cover
my ass. Boring, but easy to implement and comprehensible by most players.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Philip Bartol
In article <fake-mail-110...@van-52-1641.direct.ca>, fake...@anti-spam.address (Neil K.) wrote:
>first time they enter a room. You could also avoid the compass rose in the
>first place, and have people refer to nouns in the description instead
>("board train", "enter the brick building") but then that annoys people
>who are used to compass rose directions.
In converting the "Dog Star Adventure" from the C64 to Inform (and adding my
own little touches like this in the process), I've turned a simple "up"
direction into a mini-puzzle (as a side note) and give the player two options
for entering the tunnel.
In the game you're in a rest-room. There are pipes that go up throught the
ceiling. In the original game the compass directions are listed in each room,
and in that room, "up" is listed which takes you into a "maze of pipe
tunnels". In my Inform version I've made the pipes (in the rest-room) a door,
the door direction is "up", so you can type "up" or "enter pipes" to get into
the maze... and to clearify the whole picture, when you examine the pipes
(which are scenery and refered to in the room description) you are told there
is a hole big enought to fit through where the pipes go throught the ceiling
(which reminds me, I'll need to make it referable as a hole now too...).
It would add to the code quite a bit (and I'm sure make the final game file
bigger) but it makes it a little more interactive if you use major objects as
doors in this way. For instance, if you're standing in a parking lot in front
of a building, your description for the parking lot might be something like:
You are standing in a parking lot. Tall lamp poles provide light only to the
edge of the lot, darkness lies beyond. To the east is your office building,
inviting you to come to work.
Or something like that.... if you make the "office building" an object of the
parking lot as in: Object -> building "office building" and make it a
door, with a door direction of "east_to", assign the "east_to" in the parking
lot Object to "building" you can enter the building in the following ways...
> E
or
> ENTER BUILDING
both will let you into the building.
Working direction descriptions into a room description requires a bit of
thinking (and a little creativity) but I'm sure in *most* cases you can do it
with little problem... for instance:
If you can go east or west in a hallway, the description might say "You are in
an East-West hall". If you are at the end of a hall, and the rest of the hall
is to the east, you could describe it like: "You are in the West end of an
East-West hall" (the frontal lobe does a spring off the board, a double twist
in the air and what a nice land on the mat [little bit of mental gymnastics
later]) you can figure out that the rest of the hall lies east.
While I've enjoyed playing the Scott Adams adventures, the "obvious exits
are:" in the room description looks a bit odd after playing the Infocom
games...
just my 2 cents worth...
PHIL
Brock Kevin Nambo
There's an .h file somewhere on gmd that implements an "exits" verb, which
tells you which ways are goable-to. It's called dirs.h....
...and very useful.
>>BKNambo
--
http://come.to/brocks.place | World Domination Through Trivia!
oah123 (in chatquiz, 12/27/97): "did you guys know during the SPIN cycle the
clothes are like being spun really fast? LOL i just found that out!"
Rick Dague
Neil K. wrote:
> I think it's one of those "you can't please everyone" situations. :)
How about letting the user type "exits on" which would list exits as
part of cant_go and the Look command list exits. That is:
>look
Garage
Ack! Look at all this clutter! The street is to the north and the
door to the kitchen is west.
>east
You can't go that way.
>exits on
Exit listing is now on.
>east
You can only go north or west.
-- Rick
Mary K. Kuhner
Lelah Conrad <lco...@lane.k12.or.us> wrote:
> C.E. Forman disliked (I think!) obviously noted exits in a
>number of competition games. On the other hand, I recall reading a
>response or two where people were complaining about the exits not
>being noted. Which one is it? Do people want exits just sort of
>"hinted at"?
I was one of the reviewers who complained about exits not being
noted, so I'll try to explain my preferences.
To my tastes, you can get away with not listing exits if the
geometry of the situation is quite clear. For example, if you
tell me I am on the south side of the house, looking at the
front door, I am happy to guess that it is north of me. On
the other hand, if you just say "You are in front of your house"
I am *not* happy, as I'll have to blunder about trying to get
in, which breaks the mood something fierce.
The more time-critical the situation, the less subtle you can
afford to be with the exits: in "Phred Phontious" I got very
frustrated with dying in the graveyard because I couldn't figure
out which ways I could go, not even how to get back where I was
before, and kept dying as a result. In a more mellow situation
you don't have to be as explicit.
Conversely, I do understand Foreman's impatience with room
descriptions like "You are in the living room, with exits to
the east, south and west." This is really bland, and if there
are a lot of rooms like this it becomes quite obtrusive--the
scenery turns into a minimalist map, not a real place.
Trying to give the player an overall grasp of the geometry can
help a lot. "The hall runs off to the east, with doors on both
sides." You don't have to say "A door in the north and a door
in the south".
Embedding the exits more imaginatively in the text can help too.
One idea is to write the description first, then look for ways to
incorporate the directional information. If you write the directions
first and then try to hang text around them, it may not come out
as well (whatever you do first tends to determine tone).
You can also get some mileage out of non-directional commands
such as "ENTER DOOR", and the system in Madame L'Estrange is
worth looking at--I was very happy not to have to map the city.
Mary Kuhner mkku...@genetics.washington.edu
Andrew Plotkin
As I've said, I'm a traditionalist, and I don't like mechanical-looking
exit lists (either in the status window or at the bottom of the room
description.)
My approach, inasmuch as I have an approach, is that all the nearby
locations are *interesting objects* and therefore have a place in the room
description. Then I toss in phrases like "to the east" or "south, ..." to
make the topology clear.
A room description, generally, should mention everything you can
interact with, right? That includes places you can get to -- "go to" is
an interaction.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Joe Mason
In article <69ck1q$m4n$1...@gte2.gte.net>, Philip Bartol <phi...@gte.net> wrote:
>
>It would add to the code quite a bit (and I'm sure make the final game file
>bigger) but it makes it a little more interactive if you use major objects as
>doors in this way. For instance, if you're standing in a parking lot in front
>of a building, your description for the parking lot might be something like:
>
>You are standing in a parking lot. Tall lamp poles provide light only to the
>edge of the lot, darkness lies beyond. To the east is your office building,
>inviting you to come to work.
Which reminds me, I used the exact same system for EVERY exit in my last game,
(in fact I completely disabled the compass), and it worked fine because all
my locations were single-room buildings and it was easy to see that "enter
store" would go in, for instance. I'd like to keep doing this, but I have
to make it work for extensive interior layouts like hallways, for instance.
Does anyone have any suggestions?
I've been thinking of using "follow hallway" and "enter room", which is pretty
English-like, but it could get confusing at junctions. Should I try naming
all the hallways? Or does anyone have any other ideas?
Joe
Mary K. Kuhner
In article <EMor8...@undergrad.math.uwaterloo.ca>,
Joe Mason <jcm...@undergrad.math.uwaterloo.ca> wrote:
>Which reminds me, I used the exact same system for EVERY exit in my last game,
>(in fact I completely disabled the compass), and it worked fine because all
>my locations were single-room buildings and it was easy to see that "enter
>store" would go in, for instance. I'd like to keep doing this, but I have
>to make it work for extensive interior layouts like hallways, for instance.
>Does anyone have any suggestions?
>I've been thinking of using "follow hallway" and "enter room", which is pretty
>English-like, but it could get confusing at junctions. Should I try naming
>all the hallways? Or does anyone have any other ideas?
Do you *need* the hallways and junctions, or are they just there out
of habit or convention? If there is nothing to see or do in the
halls, I'd just abstract them:
Genetics Building, Second Level
You are in a passageway which loops around the building,
offering access to the Felsenstein Lab, the Hall Lab, and
the Fangman Lab. The building core contains an elevator
and a stairway.
>go felsenstein lab
You make your way down the corridor and enter the cluttered,
computer-ridden rooms of Felsenstein and his research associates.
[description omitted]
>out
You are in the looping passageway.
>go elevator
You summon the elevator and step inside.
And so forth. I don't think this situation necessarily needs
a corridor map and layout with compass directions, unless the
spatial relationships actually have some role to play in the
game (a chase scene through the halls, say, where it's important
to know that you can double back through Hall Lab and get
behind your pursuer).
If the player types >N you might respond:
You can visit the Felsenstein, Hall, or Fangman labs, or
take the stairs or the elevator to another floor.
I think I would prefer this to trying to name all the dull
halls in the building--for that matter, than trying to
map and traverse them. "Aardvarkbarf" used a ton of
halls to represent its campus, and I got very tired of them.
(The building where you were crawling around in the
ventilation system was much more interesting than the
others, just because you could concentrate on the
meaningful rooms.)
Mary Kuhner mkku...@genetics.washington.edu
Neil K.
Rick Dague <tri...@geocities.com> wrote:
> How about letting the user type "exits on" which would list exits as
> part of cant_go and the Look command list exits. That is:
>
> >east
> You can only go north or west.
Mm. I like it. :)
David A. Cornelson
In article <34b8fe9b...@news.efn.org>,
> number of competition games. On the other hand, I recall reading a
> response or two where people were complaining about the exits not
> being noted. Which one is it? Do people want exits just sort of
> me to a previous discussion on this topic? Thanks,
I ran into this problem too where one beta-tester complains about lack of
directional descriptions and another will complain about too much of it.
I believe the issue is making sure the player understands their
surrounding well enough in text so that writing exit directions are not
necessary. For instance:
Kitchen The kitchen contains the usual appliances and utensils along with
an island of pots and pans in the center a freezer on the south wall next
to a door and an open firepit next to the hallway leading east.
This is by no means a good example, but the idea is to relate exits to
objects in the location, not as objects themselves. You certainly know
you can either open the door to the south or head east to the hallway. No
other options seem valid.
Outside examples are easier and this is where people hate the obvious
directional text.
Atop this hill a wide view of the surrounding countryside is visible. A
farmhouse and silo can be seen to the northwest while larger hills
cascade across the southern landscape. At the bottom of the hill, to the
north, is an east-west road that extends out of sight in both directions.
This description gives you some ambiguous feedback. Can you go directly
to the farmhouse to the northwest? You certainly should be able to try.
Can you head east or west on the road or do you have to go down to it
first? What about the hills. Can they be reached from here?
When you create a location description, make sure you give enough
information so that the player a relatively good idea of which directions
are plausible. Then, you can handle leave the non-plausible directions to
the parser. However, ambiguous directions should have either a specific
response or a valid connecting location.
In the hill example, I would "help" the player along. even if "east"
isn't a valid direction, I would move them down the hill to the north,
and skip that location, automatically moving them to whatever is east of
the "bottom of the hill". When they typed "east", you could make the
assumption that they meant to travel on the road, so let them...
> E
You scramble down the hill to the north, before heading east...
East of the Hill
You are east of a little hill....
If they tried to head south, answer with a simple blocking comment like...
> S
The southern landscape doesn't seem to provide any viable passage towards
the larger hills.
> NW
You scramble down the hill and follow the road west...
West of Hill You are on an east-west road, west of a small hill. A
farmhouse is directly north and a silo can be seen to the northeast.
There! You've covered all of the amiguities and helped the player respond
with assumptions. This is what people mean by good directional
descriptions.
Rules:
1) Don't hit players over the head. Try to write a sentence about the
surrounding area that includes relative references to directions.
2) Ambiguities are okay, as long as you create viable responses to them.
3) Help the player make correct decisions. If they "think" they can do
something, then help them do it, instead of blocking them.
4) Add to #3. Don't block ambiguous directions. This is probably what
pisses people off the most. In the case of my southern hills, if I would
have let the parser handle it, "You can't go that direction.", this is
sort of rude, since people will ask, "Why did you write about the damn
southern hills if you weren't going to let me "go there"!.
There....this is my opinion, but I claim to be an ametuer. I'm keeping a
close eye on the better games to learn what others have done and I would
recommend this as an important task in anyone's I-F "how to" list.
David A. Cornelson
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Joe Mason
In article <69e4jf$bte$1...@nntp5.u.washington.edu>,
Mary K. Kuhner <mkku...@evolution.genetics.washington.edu> wrote:
>
>Do you *need* the hallways and junctions, or are they just there out
>of habit or convention? If there is nothing to see or do in the
>halls, I'd just abstract them:
>
>Genetics Building, Second Level
>
>You are in a passageway which loops around the building,
>offering access to the Felsenstein Lab, the Hall Lab, and
>the Fangman Lab. The building core contains an elevator
>and a stairway.
You know, you're right - they're just there out of convention. I could just
rethink my whole layout... [A gleeful look enters Joe's eye] But I plan
chase scenes (fairly detailed ones, possibly) which might need detailed hall
maps. Still, thank you for pointing out a blind spot I was missing.
>And so forth. I don't think this situation necessarily needs
>a corridor map and layout with compass directions, unless the
>spatial relationships actually have some role to play in the
>game (a chase scene through the halls, say, where it's important
>to know that you can double back through Hall Lab and get
>behind your pursuer).
Yeah, that. Here's a thought:
Hallways
A set of dingy, smoke-blackened corridors tunnelling through the bowels of
the castle, broken at intervals by doors and archways leading to various rooms.
In your wanderings, you find entrances to the kitchens, a storeroom, and a set
of stairs winding up towards ground level.
> GO TO KITCHEN
You walk down the halls past several junctions until you reach the kitchen.
Halls Near Kitchen
You stand outside the open door of the kitchen, from which you can see
firelight and smell herbs. Nearby is a door to the wine cellar, or you can
plunge back in to the maze of hallways.
Hmm, that didn't quite convey what I was hoping for - that saying "GO TO xxx"
would take you to the halls near that area, which would have more branches. I
think I would have to ignore any single "Hallways" area. I could have "Hall
Near Kitchen", "Hall Near Storeroom", "Hall Near Stairs", etc. and I don't
think it would get too monotonous since each hall would have a feature
associated with it.
Joe
Andrew Plotkin
> Hallways
> A set of dingy, smoke-blackened corridors tunnelling through the bowels of
> the castle, broken at intervals by doors and archways leading to various rooms.
> In your wanderings, you find entrances to the kitchens, a storeroom, and a set
> of stairs winding up towards ground level.
> > GO TO KITCHEN
> You walk down the halls past several junctions until you reach the kitchen.
See, here's the problem. I look at this and I think "I have to type
*what*?"
Just about all games have some running around, and I'm used to doing that
with single keystrokes. If the keyload rises by a factor of ten, it will
bother me.
Darren Sparrow
I would have to say that having played adventure games since 1982, that a
description of the room you're in is good. But when you don't have any clue
as to the exits available to you then it gets annoying. Yeah, a description
first and then something at the bottom of the text stating possible exits,
eg, Possible exits are:- North, East. You know that sort of thing. Some say
it's not professional to do this, I would say that it is needed for those
of us who don't wish to reread a description just to know where the exits
are!
You sorts out your problem then you moves on, that's it.
Darren.
spa...@alsofiction.com
www.alsofiction.com
Joe Mason
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>> > GO TO KITCHEN
>> You walk down the halls past several junctions until you reach the kitchen.
>
>See, here's the problem. I look at this and I think "I have to type
>*what*?"
>
>Just about all games have some running around, and I'm used to doing that
>with single keystrokes. If the keyload rises by a factor of ten, it will
>bother me.
Hmm, I never even thought of that problem. Of course, I like to use verbose
sentences in examples. In the game it would be slimmed to "GO KITCHEN" or
even "KITCHEN". But it certainly wouldn't be as quick as "N. N. E" On the
other hand, it would be easier to remember WHERE you're going.
Joe
David A. Cornelson
In article <EMqpH...@undergrad.math.uwaterloo.ca>,
This reminds me of my first week in the tiny little computer room at
Juneau High School in Milwaukee where a guy, Chuck Brough I believe, was
showing me the game DUNGEO (Zork I+II+III to all of you).
He had already helped me complete ADVENT and DUNGEO was brand new to all
of us at the time (1980) and I started taking notes.
He asks, "What are you doing?", to which I replied, I'm starting a map.
"What fun is that?", he says, "This is a game. A large puzzle. I think
half the fun is remembering everything in your head. If you write
everything down, you're just ruining all of the fun."
---
This goes back to other people complaining about locations that have no
meaning and mapping that doesn't make sense. I believe that I-F is a
puzzle with very good writing hiding the puzzleness.
I agree with Andrew....simple oridinary compass-rose mapping is the best
way to "move about". This "GO KITCHEN" stuff removes the level of detail
that we despise in other mediums, such as badly written graphical games.
I for one like to wander around in someone's world. It's the next best
thing to reading a really good book.
I generally don't create maps for games that I play. In this way, I get a
very good "visual" of the author's creation.
David A. Cornelson, Chicago
Den of Iniquity
On Tue, 13 Jan 1998, Joe Mason wrote:
>Hmm, I never even thought of that problem. Of course, I like to use verbose
>sentences in examples. In the game it would be slimmed to "GO KITCHEN" or
>even "KITCHEN". But it certainly wouldn't be as quick as "N. N. E" On the
>other hand, it would be easier to remember WHERE you're going.
Hmm, but if you move entirely by GOING TO what sort of mental map would
you be drawing up in your head. :-/
--
Den
Michael Straight
On Tue, 13 Jan 1998, Joe Mason wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >> > GO TO KITCHEN
> >> You walk down the halls past several junctions until you reach the kitchen.
> >
> >See, here's the problem. I look at this and I think "I have to type
> >*what*?"
> >
> >Just about all games have some running around, and I'm used to doing that
> >with single keystrokes. If the keyload rises by a factor of ten, it will
> >bother me.
>
> Hmm, I never even thought of that problem. Of course, I like to use verbose
> sentences in examples. In the game it would be slimmed to "GO KITCHEN" or
> even "KITCHEN". But it certainly wouldn't be as quick as "N. N. E" On the
> other hand, it would be easier to remember WHERE you're going.
Well, you could make it less of a problem if you allowed the player to
type "go to kitchen" from anywhere in the building once the kitchen had
been found. That could be an improvment over
"n.w.w.push button.enter elevator.push 1.exit elevator.e.e.s.e"
SMTIRCAHIAGEHLT
John Francis
In article <Pine.A41.3.95L.980114...@login3.isis.unc.edu>,
This seems, initially, like a really great idea. In fact something like
this has been around for ages - in the original mainframe Zork, for example,
you could type "HOUSE" from many of the outside locations, and end up at
the house. Even ADVENT had several additional travel verbs - did you know
that you could get into the secret canyon with 100% predictability if you
typed "SECRET", rather than the 8% (or whatever it was) probability of
ending up there if you just entered the move direction?
But, to get back to the original topic, you run into problems if you try
and add this as a general feature. What if there is more than one path?
What if getting to the kitchen requires you to go through a security
gate, but you don't have the passcard? What if the state of an obstacle
has changed, but the player doesn't know?
Up till now this can be handled by remembering the world in two states;
As it is now, and as it was the last time the player saw it. Side note;
this not only lets us type "GO KITCHEN" - it lets us type "GO BREADKNIFE".
Or, even more complicated, "FETCH BREADKNIFE", which will presumably take
us to where we last saw the breadknife, pick it up, and return here.
But I think this only ends up shifting the problem up one level (which
is an improvement, to be sure, but not a solution). What if we have
never tried to go through the security gate without the passcard, but
we no longer have it? What if we've been in a strong magnetic field,
so we've accidentally erased the passcard? We need to keep track of
what the character *knows*, not just what he has seen. This opens up
a whole new area of pitfalls for the unwary game designer. If you ever
played "Return To Zork", you will be familiar with the sort of thing
I mean - actions producing a particular result if and only if you
have discussed some particular topic with a specific NPC. This can
lead to some odd responses if you accidentally try and do the right
something before the game expects you to.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
Joe Mason
In article <Pine.SGI.3.95L.98011...@ebor.york.ac.uk>,
Den of Iniquity <dms...@york.ac.uk> wrote:
>>Hmm, I never even thought of that problem. Of course, I like to use verbose
>>sentences in examples. In the game it would be slimmed to "GO KITCHEN" or
>>even "KITCHEN". But it certainly wouldn't be as quick as "N. N. E" On the
>>other hand, it would be easier to remember WHERE you're going.
>
>you be drawing up in your head. :-/
Well, the point is I would list only nearby areas. So you would still know
where things are in relation to each other (especially if I clarify with words
like "opposite the kitchen is..."). One other technique I plan to use is to
bring back "left" and "right": I'll just make sure I state at the beginning
of the description what exit you're facing as you read:
"You stand just outside the kitchen door, peering though at the activity
within. Yo your left is the door of the wine cellar, and to the right is
a staircase leading up."
I should mention, BTW, the "ENTER" will be a complete synonym for "GO TO". So
"ENTER KITCHEN" and "GO TO KITCHEN" will do the exact same thing. This may
break mimesis slightly in situations where they don't quite correspong, but
consistency is also a good thing.
(Actually, not a complete synonym: you can use "ENTER" on vehicles, stalls,
crates, etc. but not "GO TO". "GO TO" is a subset of enter.)
Joe
Daryl McCullough
erky...@netcom.com says...
>> > GO TO KITCHEN
>> You walk down the halls past several junctions until you reach the kitchen.
>
>See, here's the problem. I look at this and I think "I have to type
>*what*?"
>
>Just about all games have some running around, and I'm used to doing that
>with single keystrokes. If the keyload rises by a factor of ten, it will
>bother me.
What if each room were given a number, in addition to the name? Then
you could just type 12 (or whatever) to get to the Kitchen, which I
think would be even quicker than typing N,N,E,S.
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Edan Harel
OK, here's a question to those of you who prefer the compass to the
"go to xxxx" meathod. What is you have a game that takes place in 1 (or only
a few) rooms, but that location in the room is important. For example,
if you're standing next to a window, you're more likely to notice something
that happens outside than if you're not. Or in order to search the desk,
you would need to be sitting at it. (Of course, one could allow for
"look out window" to move you to the window, or search desk to move you
to the seat next to it and make you sit). Certainly a "go to" would be
better than deviding the room up into seperate rooms (such as the ball room
in suspect). After all, my room is smaller, and contains less things in it.
Edan Harel
--
Edan Harel edh...@remus.rutgers.edu McCormick 6201
Research Assistant Math and Comp Sci Major Computer Consultant
USACS Member Math Club Secretary
Joe Mason
In article <69jaaf$iil$1...@remus.rutgers.edu>,
Edan Harel <edh...@remus.rutgers.edu> wrote:
>to the seat next to it and make you sit). Certainly a "go to" would be
>better than deviding the room up into seperate rooms (such as the ball room
>in suspect). After all, my room is smaller, and contains less things in it.
Check out Piece of Mind for an example of subdividing a bedroom into smaller
areas. I found that it made me feel extremely small: I felt that the bedroom
had a giant scale.
Joe
Andrew Plotkin
I think that the syntax of the moving command isn't relevant here. What
gives a sense of scale is the *scoping* -- how well can you see and
interact with objects in the far corner of the room?
Once that's decided, I don't think it matters whether you get there by
"go to mirror" or "sw". Not to me, anyway.
(Although "go to mirror" sort of *implies* that you can refer to the
mirror from across the room. I'd be pretty happy if "go to mirror"
worked, and I'd be thrilled if "touch mirror" caused an *implicit* move
there. But I'd like "sw" to work regardless.)
Alan Conroy
On 14 Jan 1998 19:17:57 GMT, jfra...@dungeon.engr.sgi.com (John
Francis) wrote:
>>Well, you could make it less of a problem if you allowed the player to
>>type "go to kitchen" from anywhere in the building once the kitchen had
>>been found. That could be an improvment over
>>"n.w.w.push button.enter elevator.push 1.exit elevator.e.e.s.e"
>
>This seems, initially, like a really great idea. In fact something like
>this has been around for ages - in the original mainframe Zork, for example,
>you could type "HOUSE" from many of the outside locations, and end up at
>the house. Even ADVENT had several additional travel verbs - did you know
>that you could get into the secret canyon with 100% predictability if you
>typed "SECRET", rather than the 8% (or whatever it was) probability of
>ending up there if you just entered the move direction?
>
>But, to get back to the original topic, you run into problems if you try
>and add this as a general feature. What if there is more than one path?
>What if getting to the kitchen requires you to go through a security
>gate, but you don't have the passcard? What if the state of an obstacle
>has changed, but the player doesn't know?
[snip of good points]
I still think the "go to x" is valid, so long as it is implemented
well. What I mean by that is, it shouldn't move you directly to the
destination, but calculate a path from where you are to where you are
going (taking into consideration only those rooms which you have been
to), and then take you step by step there. If you run into a snag, it
stops at that point. If there is more than one valid path, the game
should choose the shortest one. If you've never been to the location
in question, indicate that you will need compas points. For example:
You are in a small fenced-in yard behind a yellow house.
> go to kitchen
Side of house.
Front of house.
Living room.
Kitchen.
>
------------
In the case of a failure:
You are at the end of a dead-end street. To the southeast is a
fenced-in estate.
> go to kitchen
In front of security gate.
The security gate blocks your way.
> Open gate with passcard
The gate opens.
> continue
Driveway.
In front of mansion.
The security door blocks your way.
> Open door with passcard.
For some reason, the security door no longer seems to honor your
passcard.
>
> go to kitchen
- Alan Conroy
I wanna be a firetruck when I grow up...
Nir Levy
In rec.arts.int-fiction, erky...@netcom.com (Andrew Plotkin) saw fit to bestow on us:
>I think that the syntax of the moving command isn't relevant here. What
>gives a sense of scale is the *scoping* -- how well can you see and
>interact with objects in the far corner of the room?
>
>Once that's decided, I don't think it matters whether you get there by
>"go to mirror" or "sw". Not to me, anyway.
>
>(Although "go to mirror" sort of *implies* that you can refer to the
>mirror from across the room. I'd be pretty happy if "go to mirror"
>worked, and I'd be thrilled if "touch mirror" caused an *implicit* move
>there. But I'd like "sw" to work regardless.)
>
Jumping our my head with this, because I'm really to green at IF, but:
For, Inform, there is a moveclass.h library that allows you to specify
a location for an NPC and moves him/her/it to the location, passing through
the room on every turn (using a deamon(?)). I believe this can be changed
so that >GO TO THE KITCHEN will make the player *go* to the kitchen,
not be trasported there ((s)he will pass throu the normal route...)
>GO TO KITCHEN
you leave to the south
Main Hall
you can see a torch here
you leave to the east
Corridor
you open the northen door
you leave to the east
Kitchen
>
The only major modification for the library is to chnage the "deamon
section 2" to a loop that keeps on until the object have been reaced or
the path is blocked."
anyone thinks (s)he's up to it? Neil?
/NL
--
Nir Levy, The above opinions are my own,
nlevy @ usa.net not my employer's.
--
I didn't do it; Nobody saw me do it;
You can't prove anything; -Bart Simpson
--
Edan Harel
nl...@usa.net.TO_EMAIL_REMOVE_THIS (Nir Levy) writes:
>>(Although "go to mirror" sort of *implies* that you can refer to the
>>mirror from across the room. I'd be pretty happy if "go to mirror"
>>worked, and I'd be thrilled if "touch mirror" caused an *implicit* move
>>there. But I'd like "sw" to work regardless.)
>Jumping our my head with this, because I'm really to green at IF, but:
>For, Inform, there is a moveclass.h library that allows you to specify
>a location for an NPC and moves him/her/it to the location, passing through
>the room on every turn (using a deamon(?)). I believe this can be changed
>so that >GO TO THE KITCHEN will make the player *go* to the kitchen,
>not be trasported there ((s)he will pass throu the normal route...)
I know of that. But that doesn't work when you have a bunch of locations
with*in* a room. "Go mirror" can't work unless each location is a seperate
room. (course, you could just move the location of the person, but that's
cheating ;-)).
Edan Harel
jfra...@dungeon.engr.sgi.com (John Francis) writes:
[snip]
>>Well, you could make it less of a problem if you allowed the player to
>>type "go to kitchen" from anywhere in the building once the kitchen had
>>been found. That could be an improvment over
>>"n.w.w.push button.enter elevator.push 1.exit elevator.e.e.s.e"
>This seems, initially, like a really great idea. In fact something like
>this has been around for ages - in the original mainframe Zork, for example,
>you could type "HOUSE" from many of the outside locations, and end up at
>the house. Even ADVENT had several additional travel verbs - did you know
>that you could get into the secret canyon with 100% predictability if you
>typed "SECRET", rather than the 8% (or whatever it was) probability of
>ending up there if you just entered the move direction?
>But, to get back to the original topic, you run into problems if you try
>and add this as a general feature. What if there is more than one path?
>What if getting to the kitchen requires you to go through a security
>gate, but you don't have the passcard? What if the state of an obstacle
>has changed, but the player doesn't know?
Well, two things. One, if the game is designed to be player-proof (like
a lucas-arts game) where it's impossible to lose important items, etc,
you could have the following:
You go north.
You arrive at the security gate.
You find that you have misplaced your security card. You take it from
the location outside the building where you put it and use it [and maybe
you put it back again?]
You enter the building.
etc.
Of course, this probably assumed you've been inside before, otherwise you
would have to solve the puzzle the first time. And theres a move library
which handles this (with a few changes). (merely stoping at the gate,
presumably to allow input).
The player might not know that the states have changed, but the computer
will, and will stop the player from going (and presumably tell him why, as
well).
Aquarius
Daryl McCullough <da...@cogentex.com> wrote:
Bleah!
What if you're playing Erden? :-)
Aquarius
--
------------------------------------------------------------------------
aqua...@cryogen.com | http://www.cryogen.com/aquarius/ | Running on Mac
I do believe in God. And the only thing that scares me is Keyser Sosek
------------------------------------------------------------------------
John Francis
In article <69kui7$n4$1...@remus.rutgers.edu>,
Edan Harel <edh...@remus.rutgers.edu> wrote:
[snip, snip, snip]
>The player might not know that the states have changed, but the computer
>will, and will stop the player from going (and presumably tell him why, as
>well).
I obviously didn't explain things very well. I can see how that would work.
Where it gets complicated is if there are two or more paths from where you
are to the specified destination, and one (the shortest, most direct route)
goes through a "locked door".
It is not sufficient to determine whether the character has a working key
(information known to the computer) - you need to determine whether the
*player* knows that the key works (or inexplicably fails to work). That's
one more piece of information to keep track of. The computer can't give
away information to the player by suddenly taking the long way round
because *it* knows that the key has been demagnetised - it must take the
player to the door, try the key, and fail (with an appropriate message).
But it should only do this the first time - from then on it should never
try and use the door unless explicitly ordered to do so.
Nir Levy
In rec.arts.int-fiction, fake...@anti-spam.address (Neil K.) saw fit to bestow on us:
> nl...@usa.net.TO_EMAIL_REMOVE_THIS wrote:
>
>> anyone thinks (s)he's up to it? Neil?
>
> Which one?
>
> - Neil K.
Neil James Brown, the author of moveclass.h.
Jeff Hatch
Joe Mason wrote:
[snip]
> Well, the point is I would list only nearby areas. So you would still know
> where things are in relation to each other (especially if I clarify with words
> like "opposite the kitchen is..."). One other technique I plan to use is to
> bring back "left" and "right": I'll just make sure I state at the beginning
> of the description what exit you're facing as you read:
>
> "You stand just outside the kitchen door, peering though at the activity
> within. Yo your left is the door of the wine cellar, and to the right is
> a staircase leading up."
Wow! You've adopted nearly all of my ideas about movement. There's one
thing I'd add immediately--"forward" and "back" can be much more
convenient than "follow hall" etc., especially if you give the Forward,
Back, Left and Right commands keyboard shortcuts.
The concept of a "room" as defined in traditional IF could be replaced
with something more continuous, but that's a more difficult task.
Neil K. wrote:
> It seems to me that the problem with relative directions is that they're,
> well... relative. If you're going to use left and right it'll likely get
> extremely confusing very quickly. Because if you walk inside your kitchen
> and turn around the door and staircase will suddenly reverse positions.
> Players would have to re-read the entire room description each time to
> make sure they had their lefts and rights correct.
Yeah, I have that same problem. When I want to brush my teeth after a
meal, I have to look around the kitchen carefully to figure out which
side the bathroom is on *this* time. :-)
Seriously, I think relative movement could work quite well. I played
plenty of maze-based RPG computer games when I was younger, and I never
had to study the screen or refer to a compass to remember what was in
which direction. I think IF players would get used to relative movement
quickly, too.
-Rúmil
Daryl McCullough
In article <34BF6...@hatch.net>, Jeff says...
>
>Joe Mason wrote:
>[snip]
>> "You stand just outside the kitchen door, peering though at the activity
>> within. Yo your left is the door of the wine cellar, and to the right is
>> a staircase leading up."
>
>[snip]
I think that there is a problem with using "left" and "right". To
use them correctly, you need to know what direction the player is
facing. Maybe you could say "If you face the door to the kitchen,
then to your left is..."
Joe Mason
In article <fake-mail-140...@van-52-1821.direct.ca>,
Neil K. <fake...@anti-spam.address> wrote:
>
> It seems to me that the problem with relative directions is that they're,
>well... relative. If you're going to use left and right it'll likely get
>extremely confusing very quickly. Because if you walk inside your kitchen
>and turn around the door and staircase will suddenly reverse positions.
>Players would have to re-read the entire room description each time to
>make sure they had their lefts and rights correct.
There was a game called "Battlestar" which used relative directions (forward,
backward, left, right) until the player found a compass later on in the game.
I downloaded a copy from GMD last night (there are versions in
/int-fiction/games/pc and /int-fiction/games/amiga, and source in
/int-fiction/games/source) but I haven't had a chance to look at it yet. I
don't know if it was done well, but either way it should give me some pointers.
Joe
Jeremy A.Smith (not affiliated with Rancid the Elf)
Nir Levy <nl...@usa.net.TO_EMAIL_REMOVE_THIS> wrote in article
<34bf254c....@news.ibm.net.il>...
> In rec.arts.int-fiction, fake...@anti-spam.address (Neil K.) saw fit to
bestow on us:
> >
> > - Neil K.
>
> Neil James Brown, the author of moveclass.h.
I thought he just updated it to Inform 6?
I tried using this but it's mind-boggling to understand. I'm writing my own
instead. ;-)
--
Jeremy A.Smith
To reply by Email, change the 'z' in lwtcdz to i
"I will not stop... I will not stop... I will not stop..."
Robert De Niro to Al Pacino in Heat.
What the hell?
Read the hell?
http://www.homeusers.prestel.co.uk/lwtcdi/all/
Neil Brown
At 22:08:02 on Fri, 16 Jan 1998, Jeremy A.Smith (not affiliated with
Rancid the Elf) wrote:
>Nir Levy <nl...@usa.net.TO_EMAIL_REMOVE_THIS> wrote in article
><34bf254c....@news.ibm.net.il>...
>> In rec.arts.int-fiction, fake...@anti-spam.address (Neil K.) saw fit to
>bestow on us:
>> > Which one?
>> >
>> > - Neil K.
>>
>> Neil James Brown, the author of moveclass.h.
Erm, what? Hello? Sorry, I haven't been paying this thread much
attention. What was the question?
[Nir Levy wrote...]
> Jumping our my head with this, because I'm really to green at IF, but:
> For, Inform, there is a moveclass.h library that allows you to specify
> a location for an NPC and moves him/her/it to the location, passing
> through the room on every turn (using a deamon(?)). I believe this can
> be changed so that >GO TO THE KITCHEN will make the player *go* to the
> kitchen, not be trasported there ((s)he will pass throu the normal
> route...)
Yes, I imagine it would be fairly easy to alter moveclass in order to
calculate a pathway for the player and then move them every turn. The
only major issue would be, how does the player stop this process? Which
commands should be taken as a sign that the player no longer wants to
continue on the pathway? There would also be the issue of events
disrupting the player's progression, but the author would have to deal
with this. The code would check a routine every time, written by the
author of the game in question, and if it returned false, the game would
stop moving the player.
I'll see about adding this feature to moveclass when I get the time.
Thanks for the idea. :)
>I thought he just updated it to Inform 6?
No, that was "follower.h". Moveclass is my own work - I created it for a
project which has gone into limbo for the time being, but I also used it
in "Lost Spellmaker" to handle the movements of Daisy and the Reverend.
Moveclass was written to work with follower, if follower was being used.
>I tried using this but it's mind-boggling to understand. I'm writing my own
>instead. ;-)
...Which will be just as mind-boggling, no doubt. :)
I wrote a short demonstration file for moveclass, which currently
resides on my web page (http://www.highmount.demon.co.uk/demo.inf).
Maybe that would help in making moveclass easier to understand. I
suppose I ought to download that to GMD.
- NJB
Joe Mason
In article <dYkzjHAn...@highmount.demon.co.uk>,
Neil Brown <ne...@this.address.is.fake> wrote:
>
>Yes, I imagine it would be fairly easy to alter moveclass in order to
>calculate a pathway for the player and then move them every turn. The
>only major issue would be, how does the player stop this process? Which
>commands should be taken as a sign that the player no longer wants to
>continue on the pathway? There would also be the issue of events
>disrupting the player's progression, but the author would have to deal
>with this. The code would check a routine every time, written by the
>author of the game in question, and if it returned false, the game would
>stop moving the player.
How did Moonmist handle this? I recall being fairly impressed with that part
of it - strange that no other game implemented something like that. (Or were
there any?)
Joe
Jeff Hatch
If I recall correctly, it interrupted the player any time a "demon" or
"fuse" generated text. Which happened whenever the a dinner bell rang,
or you met another character in the hallway, etc. A simple, effective
method.
-Rúmil
Julian Arnold
In article <34C1C5...@hatch.net>, Jeff Hatch
<URL:mailto:je...@hatch.net> wrote:
> If I recall correctly, it interrupted the player any time a "demon" or
> "fuse" generated text. Which happened whenever the a dinner bell rang,
> or you met another character in the hallway, etc. A simple, effective
> method.
Hugo implements this with the event_flag global. Whenever a fuse or
daemon or other event does something it should set event_flag. For
example, by default a "wait" command actually waits for 3 moves (you can
also "wait <number>"). Each turn though, if event_flag > 0, the routine
KeepWaiting is run. This simply asks "Do you want to keep waiting?" and
breaks the cycle if the answer is no.
For added functionality, replace KeepWaiting from HugoLib.H with this:
replace KeepWaiting()
{
if event_flag = 1 {
Message(&KeepWaiting) ! "Keep waiting?"
GetInput()
return YesorNo()
}
event_flag = 0
}
Now if you set event_flag to 2 the wait loop will automatically be
broken without asking the player.
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
JC
On Wed, 14 Jan 1998 17:22:24 GMT, jcm...@undergrad.math.uwaterloo.ca (Joe
Mason) wrote:
[...]
>I should mention, BTW, the "ENTER" will be a complete synonym for "GO TO". So
>"ENTER KITCHEN" and "GO TO KITCHEN" will do the exact same thing. This may
>break mimesis slightly in situations where they don't quite correspong, but
>consistency is also a good thing.
>(Actually, not a complete synonym: you can use "ENTER" on vehicles, stalls,
>crates, etc. but not "GO TO". "GO TO" is a subset of enter.)
As I found out when I implemented such a destination based movement system,
having "ENTER" as a synonym for "GO TO" can cause some confusion.
Say you've got the back yard of a house as a room and just outside the back
door as another. In this case "go to house" brings you to the back door,
but what does "enter house" mean? What if you can't enter the house?
Another thing. "Go to toilet" is ambiguous.
';';James';';
JC
On Mon, 19 Jan 1998 08:05:30 GMT, jrc...@netspace.net.au (JC) wrote:
That should have been:
>Say you've got the back yard of a house as a room and just outside the back
>door as another
(which is named "back of house" or "house")
> In this case "go to house" brings you to the back door,
>but what does "enter house" mean? What if you can't enter the house?
>
';';James';';
Jeremy A.Smith (not affiliated with Rancid the Elf)
Jeff Hatch <je...@hatch.net> wrote in article <34C1C5...@hatch.net>...
> Joe Mason wrote:
> >
> > In article <dYkzjHAn...@highmount.demon.co.uk>,
> > Neil Brown <ne...@this.address.is.fake> wrote:
> > >
> >
> > How did Moonmist handle this? I recall being fairly impressed with
that part
> > of it - strange that no other game implemented something like that. (Or
were
> > there any?)
Knight Orc by Level 9, and all the other KAOS games. I'm attempting an
Inform library that could do something like those.
> If I recall correctly, it interrupted the player any time a "demon" or
> "fuse" generated text. Which happened whenever the a dinner bell rang,
> or you met another character in the hallway, etc. A simple, effective
> method.
Yup.