[Inform] Multiple Doors on One Wall
Daryl McCullough
door (think of "Let's Make a Deal" if you're old enough to remember
that game show). I wanted to have three doors all on the same wall.
But it seems that Inform makes an assumption that there can only
be at most one door in a given compass direction. Does anybody
know of an easy way around this?
Something else that I discovered about the Inform library:
<Enter south-door> does not always behave the same as <Go south>.
It seems to me that they should be synonyms, in the case that
there is only one door in the south wall.
--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Will Grzanich
>
> I was trying to code a toy game that involved guessing the right
> door (think of "Let's Make a Deal" if you're old enough to remember
> that game show). I wanted to have three doors all on the same wall.
> But it seems that Inform makes an assumption that there can only
> be at most one door in a given compass direction. Does anybody
> know of an easy way around this?
The only thing that occurs to me is to have each door be a bit
different, so the player can refer to each one by an attribute unique to
it - e.g., "enter white door" or "enter lion door". Then you'd have to
trap the Go action for each door, and directly move the player to the
desired location using PlayerTo() (since the Enter action applied to
doors results in a Go action on a direction, which won't help us here).
I think, anyway.
-Will
Neil Cerutti
>I was trying to code a toy game that involved guessing the right
>door (think of "Let's Make a Deal" if you're old enough to remember
>that game show). I wanted to have three doors all on the same wall.
>But it seems that Inform makes an assumption that there can only
>be at most one door in a given compass direction. Does anybody
>know of an easy way around this?
You can trap the <<Go s_obj>> action in a before routine in the
room and tell them they must pick a door to enter instead.
>Something else that I discovered about the Inform library:
><Enter south-door> does not always behave the same as <Go south>.
>It seems to me that they should be synonyms, in the case that
>there is only one door in the south wall.
Yes. <<Enter door>> generates an Enter action which gets
converted to a <<Go door>> action by the EnterSub routine. It's
is next handled by the GoSub routine as a special case of Go.
<<Go dir_obj>> generates a Go action which is handled directly by
the GoSub routine, which converts it to <<Go door_dir>> and then
handles it in *another* special case. All this confusion helps
keep all the movement in one routine: GoSub.
--
Neil Cerutti <cer...@together.net>
Kaia Vintr
>I was trying to code a toy game that involved guessing the right
>door (think of "Let's Make a Deal" if you're old enough to remember
>that game show). I wanted to have three doors all on the same wall.
>But it seems that Inform makes an assumption that there can only
>be at most one door in a given compass direction. Does anybody
>know of an easy way around this?
Do what the manual says in the "Doors" section, except use non-standard
direction properties:
Object ChoiceRoom "Room of Three Choices"
with description "^There is nothing remarkable about this room except
for the three
coloured doors on the south wall.",
green_door_to GreenDoor,
red_door_to RedDoor,
yellow_door_to YellowDoor,
cant_go [;
if(noun==s_obj) "You have to choose a particular door!";
"You can't go that way.";
]
has light;
Object GreenDoor "green door" ChoiceRoom
with name "green" "door",
door_to GreenRoom,
door_dir green_door_to,
has static door openable;
Object RedDoor "red door" ChoiceRoom
with name "red" "door",
door_to RedRoom,
door_dir red_door_to,
has static door openable;
Object YellowDoor "yellow door" ChoiceRoom
with name "yellow" "door",
door_to YellowRoom,
door_dir yellow_door_to,
has static door openable;
You could probably use the same names for the door objects and their
direction properties to make things simpler.
Note that it would be really easy to hack the library so that it only needs
a "door_to" property for each door and no special properties in the room
object.
- Kaia
Kaia Vintr
>You could probably use the same names for the door objects and their
>direction properties to make things simpler.
Oops! Should have tried that first. Compiler won't let you, even though
they're all just numbers underneath.
- Kaia
Daryl McCullough
says...
>
>Daryl McCullough posted:
>>I was trying to code a toy game that involved guessing the right
>>door (think of "Let's Make a Deal" if you're old enough to remember
>>that game show). I wanted to have three doors all on the same wall.
>>But it seems that Inform makes an assumption that there can only
>>be at most one door in a given compass direction. Does anybody
>>know of an easy way around this?
>
>You can trap the <<Go s_obj>> action in a before routine in the
>room and tell them they must pick a door to enter instead.
But the problem is that <<Enter dragonDoor>> gives rise to
<<Go s_obj>>, and so that would produce the message, also.
>Enter dragon door
You need to specify which door you want to enter: the dragon door,
the unicorn door, or the lion door.
TenthStone
wrote:
>I was trying to code a toy game that involved guessing the right
>door (think of "Let's Make a Deal" if you're old enough to remember
>that game show). I wanted to have three doors all on the same wall.
>But it seems that Inform makes an assumption that there can only
>be at most one door in a given compass direction. Does anybody
>know of an easy way around this?
Well, everyone else has given you the procedure for hacking the
Inform library, but if you can get away with it there's a convention
that's more convenient to the player: use northwest, north, and
northeast. If you write the description right, the player will
understand the geometry anyway.
Neil Cerutti
>In article <slrn95kb5n...@fiad06.norwich.edu>, cer...@together.net
>says...
>>
>>Daryl McCullough posted:
>>>I was trying to code a toy game that involved guessing the right
>>>door (think of "Let's Make a Deal" if you're old enough to remember
>>>that game show). I wanted to have three doors all on the same wall.
>>>But it seems that Inform makes an assumption that there can only
>>>be at most one door in a given compass direction. Does anybody
>>>know of an easy way around this?
>>
>>You can trap the <<Go s_obj>> action in a before routine in the
>>room and tell them they must pick a door to enter instead.
>
>But the problem is that <<Enter dragonDoor>> gives rise to
><<Go s_obj>>, and so that would produce the message, also.
Actually, as I wrote, <<Enter door>> is translated into <<Go
door_obj>> by EnterSub, so it won't be a problem. It only gets
translated to "go south" internally in the GoSub routine.
--
Neil Cerutti <cer...@together.net>
Adam Biltcliffe
> Daryl McCullough posted:
>
> >In article <slrn95kb5n...@fiad06.norwich.edu>,
cer...@together.net
> >says...
> >
> >>You can trap the <<Go s_obj>> action in a before routine in the
> >>room and tell them they must pick a door to enter instead.
> >
> >But the problem is that <<Enter dragonDoor>> gives rise to
> ><<Go s_obj>>, and so that would produce the message, also.
>
> Actually, as I wrote, <<Enter door>> is translated into <<Go
> door_obj>> by EnterSub, so it won't be a problem. It only gets
> translated to "go south" internally in the GoSub routine.
Actually, Daryl is right ... EnterSub translates the Enter action into a
Go action, but the object of the Go action is the compass object (in
this case s_to) whose door_dir property matches that of the door object.
The GoSub routine always takes a noun that is a compass object.
You might be able to achieve the desired effect by giving each door a
before routine that sets a certain flag before returning false. In the
s_to property of the room, you then check which flags have been set,
move the player to the corresponding room and print a message if none
are set (ie the player simply typed >S), making sure to reset the flags
after each turn.
HTH, jw
Kaia Vintr
>Actually, Daryl is right ... EnterSub translates the Enter action into a
>Go action, but the object of the Go action is the compass object (in
>this case s_to) whose door_dir property matches that of the door object.
>The GoSub routine always takes a noun that is a compass object.
>
>You might be able to achieve the desired effect by giving each door a
>before routine that sets a certain flag before returning false. In the
>s_to property of the room, you then check which flags have been set,
>move the player to the corresponding room and print a message if none
>are set (ie the player simply typed >S), making sure to reset the flags
>after each turn.
Or just invent your own direction properties, e.g. dragon_door_to, as I
suggested.
Someone implied that this was "hacking the library" but I don't see why.
Would that person care to elaborate? If there's a problem with this
technique then I'd like to know about it.
- Kaia
Neil Cerutti
>Neil Cerutti <cer...@together.net> wrote:
>> Actually, as I wrote, <<Enter door>> is translated into <<Go
>> door_obj>> by EnterSub, so it won't be a problem. It only gets
>> translated to "go south" internally in the GoSub routine.
>
>Actually, Daryl is right ... EnterSub translates the Enter
>action into a Go action, but the object of the Go action is the
>compass object (in this case s_to) whose door_dir property
>matches that of the door object. The GoSub routine always takes
>a noun that is a compass object.
You're wrong. I've struggled with making doors behave
ergonomically for a long time. It would be *nice* if what you say
is true (sort of, if I substitute s_obj for s_to), but the
library doesn't work that way. I just use before routines in the
room to trap <<##Go dir_obj>> if I need to trap folks
entering doors.
Here's some evidence in case you aren't convinced. If you need
more, read the EnterSub routine from parserm.h:
(The following is from Ditch Day Drifter)
>ACTIONS
[Action listing on.]
>GO NORTH
[ Action Go with noun 7 (north wall) ('cen') ]
You can't, since the tunnel door is in the way.
>ENTER DOOR
[ Action Enter with noun 107 (tunnel door) ]
[ Action Go with noun 107 (tunnel door) (from < > statement) ]
You can't, since the tunnel door is in the way.
I now return you to your regularly scheduled copyright
thread.
--
Neil Cerutti <cer...@together.net>
Daryl McCullough
>
>Adam Biltcliffe posted:
>>Neil Cerutti <cer...@together.net> wrote:
>>> Actually, as I wrote, <<Enter door>> is translated into <<Go
>>> door_obj>> by EnterSub, so it won't be a problem. It only gets
>>> translated to "go south" internally in the GoSub routine.
>>
>>Actually, Daryl is right ...
>You're wrong.
Well, maybe I didn't understand what you meant. What I hoped would
be the case is that I could do this
---------------Begin sample code------------------
Object HallOfDoors "Hall of Doors"
has light
with description
"This room has three doors on the south wall: the dragon door,
the unicorn door, and the lion door.",
s_to "You must say which door you want to enter.";
Object unicornDoor "unicorn door" HallOfDoors
has door static scenery open lockable
with name "unicorn" "door" ,
door_dir s_to,
door_to UnicornRoom;
Object dragonDoor "dragon door" HallOfDoors
has door static scenery open lockable
with name "dragon" "door",
door_dir s_to,
door_to DragonRoom;
Object dragonDoor "lion door" HallOfDoors
has door static scenery open lockable
with name "lion" "door",
door_dir s_to,
door_to LionRoom;
----------------------End sample code------------------------
Unfortunately, this doesn't work. The message "You must say which door you want
to enter." no matter whether you say "Enter dragon door" or "Go south". So
what exactly was your suggestion? The main annoying point is that it seems
I must put in something for s_to in the room, even though anything I put
there will be redundant with code found in the three doors.
Of course, it works to simply not have the dragon door, etc. be
doors at all, and treat them like teleportation booths.
--
Daryl McCullough
Neil Cerutti
You're stuck by a different problem. The GoSub routine is running
your s_to routine, which it does because that's the door_dir on
your door(s). Use a before routine instead of s_to, and you need to
use a sneaky trick to make s_to return the correct value. Here's
one solution:
Object HallOfDoors "Hall of Doors"
has light
with
description
"This room has three doors on the south wall: the dragon door,
the unicorn door, and the lion door.",
south_doorway nothing,
before [;
Go:
if (noun == s_obj)
"You must say which door you want to enter.";
Enter:
self.south_doorway = noun;
],
s_to [;
return self.south_doorway;
],
;
Object unicornDoor "unicorn door" HallOfDoors
has door scenery open
with
name 'unicorn' 'door',
door_dir s_to,
door_to UnicornRoom,
;
Object dragonDoor "dragon door" HallOfDoors
has door scenery open
with
name 'dragon' 'door',
door_dir s_to,
door_to DragonRoom,
;
Object lionDoor "lion door" HallOfDoors
has door scenery open
with
name "lion" "door",
door_dir s_to,
door_to LionRoom,
;
Object UnicornRoom "Unicorn Room"
has light
with
n_to HallOfDoors,
description "You are in a room.",
;
Object DragonRoom "Dragon Room"
has light
with
n_to HallOfDoors,
description "You are in a room.",
;
Object LionRoom "Lion Room"
has light
with
n_to HallOfDoors,
description "You are in a room.",
;
It also works, as someone else posted, to just invent your own
direction properties and declare them in the HallOfDoors and
return them in the door_dir properties of your doors.
Object HallOfDoors
...
unicorn_to UnicornRoom,
lion_to LionRoom,
dragon_to DragonRoom,
...
;
Object unicornDoor
...
door_dir unicorn_to,
...
;
I like your idea of making them teleportation booths
better. ;-)
--
Neil Cerutti <cer...@together.net>
Adam Biltcliffe
> Adam Biltcliffe posted:
> >Neil Cerutti <cer...@together.net> wrote:
> >> Actually, as I wrote, <<Enter door>> is translated into <<Go
> >> door_obj>> by EnterSub, so it won't be a problem. It only gets
> >> translated to "go south" internally in the GoSub routine.
> >
> >Actually, Daryl is right ... EnterSub translates the Enter
> >action into a Go action, but the object of the Go action is the
> >compass object (in this case s_to) whose door_dir property
> >matches that of the door object. The GoSub routine always takes
> >a noun that is a compass object.
>
> You're wrong. I've struggled with making doors behave
> ergonomically for a long time.
> It would be *nice* if what you say
> is true (sort of, if I substitute s_obj for s_to),
My mistake, I meant s_obj.
> but the
> library doesn't work that way. I just use before routines in the
> room to trap <<##Go dir_obj>> if I need to trap folks
> entering doors.
Oops, I read GoSub again after posting (I read it before a couple of
times, but forgot to look at EnterSub as well ... serve me right for
taking the DM's word for anything) and you're right. But what I was
mainly arguing was that your code wouldn't work because of GoSub giving
up when it found that the room's s_to property being a string, which you
already posted a workaround for elsewhere in the thread.
jw
Neil Cerutti
>It also works, as someone else posted, to just invent your own
>direction properties and declare them in the HallOfDoors and
>return them in the door_dir properties of your doors.
>
>Object HallOfDoors
> ...
> unicorn_to UnicornRoom,
> lion_to LionRoom,
> dragon_to DragonRoom,
> ...
>;
In order to jive with the Inform documentation, that ought to be:
Object HallOfDoors ...
...
unicorn_to unicornDoor,
lion_to lionDoor,
dragon_to dragonDoor,
...
;
because of the way doors must be self-referential.
--
Neil Cerutti <cer...@together.net>
Daryl McCullough
>Here's one solution:
>
>Object HallOfDoors "Hall of Doors"
> has light
> with
> description
> "This room has three doors on the south wall: the dragon door,
> the unicorn door, and the lion door.",
> south_doorway nothing,
> before [;
> Go:
> if (noun == s_obj)
> "You must say which door you want to enter.";
> Enter:
> self.south_doorway = noun;
> ],
> s_to [;
> return self.south_doorway;
> ],
>;
Thanks for the solution! But that seems awfully baroque:
1. The user types "Enter unicorn door" (having the side-effect
of making south_doorway = unicornDoor).
2. The interpreter looks up the door_dir for unicornDoor, and
finds out it is s_to.
3. The interpreter looks up the s_to routine in HallOfDoors,
and finds out that the return value is unicornDoor.
4. Finally, the interpreter looks up the door_to value on
unicornDoor to find out where the door goes to.
Steps 2 and 3 seem bizarrely redundant. After step 1, the interpreter
already knows that the player is entering the unicornDoor. So, why
does it need to check s_to in the room? A funny possibility here is
that step 3 might return a *different* door, other than the unicorn
door. So, typing "enter unicorn door" could cause the player to go
through the *dragon* door.
What would make more sense to me, even though it would involve
a change to the library, is if the room itself had no direction
information. The direction information would just be in the
door's door_dir parameter. Then typing <Go south> when there
is more than one door on the south would just be a parsing
ambiguity, just as <Take ball> is ambiguous when there is more
than one ball around.
Kaia Vintr
Daryl McCullough wrote in message <93n7r...@edrn.newsguy.com>...
>What would make more sense to me, even though it would involve
>a change to the library, is if the room itself had no direction
>information. The direction information would just be in the
>door's door_dir parameter. Then typing <Go south> when there
>is more than one door on the south would just be a parsing
>ambiguity, just as <Take ball> is ambiguous when there is more
>than one ball around.
Here's a seven-line patch for verblibm.h which allows you to just say:
Object unicornDoor ... HallOfDoors
...
door_to UnicornRoom
...
with none of that cross-referencing between the room and the door.
(This patch can't possibly break any existing code because it only affects
door objects that have no "door_dir", which is not allowed with the
unmodified library.)
------------------------------------------
Added lines indicated with '+' at the beginning
------------------------------------------
[ GoSub i j k df movewith thedir old_loc;
if (second ~= 0 && second notin Compass
&& ObjectIsUntouchable(second)) return;
old_loc = location;
movewith=0;
i=parent(player);
if ((location~=thedark && i~=location)
|| (location==thedark && i~=real_location))
{ j=location;
if (location==thedark) location=real_location;
k=RunRoutines(i,before); if (k~=3) location=j;
if (k==1)
{ movewith=i; i=parent(i);
}
else
{ if (k==0) L__M(##Go,1,i);
rtrue;
}
}
+ if(noun provides door_dir){
thedir=noun.door_dir;
if (ZRegion(thedir)==2) thedir=RunRoutines(noun,door_dir);
j=i.thedir; k=ZRegion(j);
if (k==3) { print (string) j; new_line; rfalse; }
if (k==2) { j=RunRoutines(i,thedir);
if (j==1) rtrue;
}
if (k==0 || j==0)
{ if (i.cant_go ~= 0) PrintOrRun(i, cant_go);
rfalse;
}
+ }else{
+ j=noun;
+ if(noun hasnt door || ~~(noun provides door_to)){
+ return L__M(##Go,2);
+ }
+ }
---------------------
- Kaia
Juhana Sadeharju
Daryl McCullough <da...@cogentex.com> wrote:
>But it seems that Inform makes an assumption that there can only
>be at most one door in a given compass direction. Does anybody
>know of an easy way around this?
I just joined this newsgroup. I'm more interested in how the adventure
engine works --- and I now know how the engine in Inform works...
To answer to your question: Inform with various compass directions
is not a modern approach anymore. The compass directions should be
removed entirely and brought to the game only if the game designer
needs them (and even then not all directions in a room are necessary).
Also the textual user interface is an oldish one, and should be
removed. Within a couple of days ago I tried to play a few zcode/inform
games, but I simply had to quit because the hardest buzzle were to find
out the needed verbs. Typically the game designers forget to put the most
common verbs, and therefore the playing is very, very frustating.
However, textual interface has one good point with respect to Gabriel
Knight 3 type graphical system: player has to think what to do. I suggest
that textual games would include a word book which from player could
check what verbs are available if themost common choise is not an option.
-*-
By the way, what would be best open source graphical game engine available
at the moment?
Regards,
Juhana
Andrew Plotkin
> In article <93ctk...@edrn.newsguy.com>,
> Daryl McCullough <da...@cogentex.com> wrote:
>>But it seems that Inform makes an assumption that there can only
>>be at most one door in a given compass direction. Does anybody
>>know of an easy way around this?
> I just joined this newsgroup. I'm more interested in how the adventure
> engine works --- and I now know how the engine in Inform works...
> To answer to your question: Inform with various compass directions
> is not a modern approach anymore. The compass directions should be
> removed entirely and brought to the game only if the game designer
> needs them (and even then not all directions in a room are necessary).
A game designer can get rid of them with one #define. And I don't
think it's a bad decision to have standard direction be the *default*.
Most games do, in fact, have them -- modern or not.
> Also the textual user interface is an oldish one, and should be
> removed.
Ah, no. That would kind of annoy all the people who like it.
Perhaps you want to play some kind of game other than text adventures.
> Within a couple of days ago I tried to play a few zcode/inform
> games, but I simply had to quit because the hardest buzzle were to find
> out the needed verbs. Typically the game designers forget to put the most
> common verbs, and therefore the playing is very, very frustating.
The list of "common verbs" really hasn't changed since 1990. Just
about all the text games I've played use the same ones, for just about
every puzzle.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Darren Holmes
don't offer much in the way of solutions.
What would be your approach?
Thanks,
Darren
Juhana Sadeharju <maj...@uta.fi> wrote in message
news:954bo0$ghm$1...@baker.cc.tut.fi...
Matthew Russotto
Juhana Sadeharju <maj...@uta.fi> wrote:
>
>Also the textual user interface is an oldish one, and should be
>removed. Within a couple of days ago I tried to play a few zcode/inform
>games, but I simply had to quit because the hardest buzzle were to find
>out the needed verbs. Typically the game designers forget to put the most
>common verbs, and therefore the playing is very, very frustating.
Are we being trolled?
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Jeff Coleman
While I don't agree with most of the views of the original poster, I have
often felt that games could often do with a bit more flexibility in terms of
being able to "GO" to a room that I've been to before. For example, when
I'm in my bedroom, it's easier for me to navigate if I can type "GO
BATHROOM" "GO DOOR" "LEAVE", or "GO HALLWAY", assuming that the rooms called
Bathroom and Hallway are adjacent--I have stronger mnemonic recognition of
those words, as opposed to remembering the cardinal directions. I do feel
compass directions speak more of the "mapping an unknown area" type of
game, and in games where that's the case, I think it's indispensible. But
when it's a familiar environment, or the adjacent rooms are given clear
titles, I think it's fair to want to type "go bathroom" when the room
description clearly says "The bathroom is to the east."
I don't even mean directions should be turned off explicitly, just that it
would be nice to have the other option.
It's good that the standard words are solidly standard, that aids the
usability of text as an interface. But, for example, in some games you can
find many very straightforward things that are not easy to do, because it's
tough to find the right verbs. That's frustrating, especially if the
feedback from the game itself doesn't help much.
Jeff Coleman
charm is real, progress is power!
www.handofgod.com
"Darren Holmes" <darren.take.t...@thinkup.com> wrote in message
news:Jhkd6.7695$f5.1577482@news...
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>Juhana Sadeharju <maj...@uta.fi> wrote:
>> Within a couple of days ago I tried to play a few zcode/inform
>> games, but I simply had to quit because the hardest buzzle were to find
>> out the needed verbs. Typically the game designers forget to put the most
>> common verbs, and therefore the playing is very, very frustating.
>
>The list of "common verbs" really hasn't changed since 1990. Just
>about all the text games I've played use the same ones, for just about
>every puzzle.
The point is still a valid one, I think: the "list of common verbs"
is something you learn rather quickly, but for a beginning player it's
still a bit short. I suppose the best introduction to text adventures
is really to play them together with somebody who's already familiar
with the conventions, who can tell the beginner what kind of commands
are useful and which are not ("No, I'm afraid you can't just ask the
game 'Why can't I take the apple?'; you must 'examine apple'...)
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Darren Holmes
(perhaps depending on what authoring system you use?).
D
Jeff Coleman <jcol...@NOSPAMhandofgod.com> wrote in message
news:4Iod6.17339$cN.9...@bgtnsc07-news.ops.worldnet.att.net...
Daniel Barkalow
> While I don't agree with most of the views of the original poster, I have
> often felt that games could often do with a bit more flexibility in terms of
> being able to "GO" to a room that I've been to before. For example, when
> I'm in my bedroom, it's easier for me to navigate if I can type "GO
> BATHROOM" "GO DOOR" "LEAVE", or "GO HALLWAY", assuming that the rooms called
> Bathroom and Hallway are adjacent--I have stronger mnemonic recognition of
> those words, as opposed to remembering the cardinal directions.
Platypus supports that, actually. "GO TO <FOO>" will take you to the
room named <foo> if your character knows how to get there. By default you
have to explore the way there the first time, but that's relatively easy
to change. It can also interrupt you (or distract you, for that matter) if
something interesting happens on the way.
> I do feel compass directions speak more of the "mapping an unknown
> area" type of game, and in games where that's the case, I think it's
> indispensible. But when it's a familiar environment, or the adjacent
> rooms are given clear titles, I think it's fair to want to type "go
> bathroom" when the room description clearly says "The bathroom is to the
> east."
Incorporating info from the room description into the set of places with
known paths would be useful, yes. (i.e., I know the bathroom is to the
east, even though I have never actually been there, because I can tell
from the adjacent room what's through the doorway).
> I don't even mean directions should be turned off explicitly, just that it
> would be nice to have the other option.
Directions are actually useful, sometimes, for getting a clear picture of
the place you're talking about.
> It's good that the standard words are solidly standard, that aids the
> usability of text as an interface. But, for example, in some games you can
> find many very straightforward things that are not easy to do, because it's
> tough to find the right verbs. That's frustrating, especially if the
> feedback from the game itself doesn't help much.
Perhaps each object should have a list of verbs the game knows which are
obvious to the PC? I.e., in the case where the PC should know how to use
the item, but the player doesn't know what the game expects the action to
be called. Any actions that should be non-intuitive to the PC simply
wouldn't be listed even if they did something potentially useful, so this
wouldn't give away anything meant to be a puzzle.
> VERBS DIAL
Obvious things to do with the washing machine dial:
SET DIAL TO number
PRESS DIAL
> VERBS BOW
Obvious things to do with the crossbow:
LOAD BOW
COCK BOW
SHOOT BOW AT noun
Automating this information could be tricky, though, since it has to undo
parsing somewhat. I'm not entirely sure how to implement it off the top of
my head.
-Iabervon
*This .sig unintentionally changed*
David Welbourn
Daniel Barkalow <iabe...@iabervon.org> wrote:
> Perhaps each object should have a list of verbs the game knows which are
>
> > VERBS DIAL
> Obvious things to do with the washing machine dial:
> SET DIAL TO number
> PRESS DIAL
Change "VERBS" to "USE" to be more intutitive, and I think you might have an
idea worth implementing in a game someday.
-- David Welbourn
Andrew MacKinnon
This is getting off-topic, but for some reason I don't think that is practical.
It would spoil many puzzles, and it seems, well, unpractical.
--
Andrew MacKinnon
andrew_mac...@yahoo.com
http://www.geocities.com/andrew_mackinnon_2000/
Daniel Barkalow
> In article <rcId6.21343$9v2.4...@quark.idirect.com>, "David Welbourn"
> <dsw...@look.ca> wrote:
> Actually, I thought the most sensible way to approach it would be to make the
> suggestion after one (or perhaps more) failed attempts to interact with the
> object.
>
> I don't, however, believe that there is any feasible way to automate it. You
> would have to specifically list the verbs (or actions) that you want to
> suggest for each object (or class). E.g.:
>
> known_verbs "SET DIAL TO number" "PRESS DIAL"
obvious_actions ##SetTo ##Push
might be sufficiently easy to code. The supporting code would take the
first Verb line that generates each action and suggest it, with the
short_name of the noun filled in and "something" in place of other
variables. Some actions might be automatically included by the
library: open and close for things which are openable, search for
containers, lock and unlock for things which can be locked, etc.
That way the game could suggest a bunch of actions you might try that
won't necessarily be at all helpful, but which you might be trying to
figure out how to phrase.
I'm not sure if I like "use" as the command; that seems like it should
pick the single obvious one and actually do it, rather than being a
metagame command to find out how the game wants you to phrase
something. The indirection also prevents the player from going through the
game just saying "use <x>" all the time and not thinking about what the
items are or do.
Of course, surprising or innovative uses of objects (which make for
interesting puzzles) wouldn't be listed, and would have to be figured out
by the player. Likewise, this would give no real hints for puzzles where
the interesting aspect is using the right combination of objects. "You can
PUT objects IN THE FURNACE" doesn't really give anything away, aside from
spelling out what to type to get an effect suggested by the object
description.
Jeff Coleman
"Daniel Barkalow" <iabe...@iabervon.org> wrote in message
news:Pine.LNX.4.21.01013...@iabervon.org...
> On Tue, 30 Jan 2001, Jeff Coleman wrote:
>
> > when I'm in my bedroom, it's easier for me to navigate if I can type "GO
> > BATHROOM" "GO DOOR" "LEAVE", or "GO HALLWAY", assuming that the rooms
called
> > Bathroom and Hallway are adjacent--I have stronger mnemonic recognition
of
> > those words, as opposed to remembering the cardinal directions.
>
> Platypus supports that, actually. "GO TO <FOO>" will take you to the
> room named <foo> if your character knows how to get there. By default you
> have to explore the way there the first time, but that's relatively easy
> to change. It can also interrupt you (or distract you, for that matter) if
> something interesting happens on the way.
That's good, I think that's useful! I'm going to check out the game. I was
playing a Scott Adams adventure recently and I realized that may be one
source of my affection for being about to "go jail" or "go saloon" when the
description clearly states there's a Jail and a Saloon here. In fact, it's
often not possible to get to the jail or saloon using compass directions.
Basically I think it would be very nice if both options were available.
Give the room a noun and a compass direction, and the user can type either
"go <foo>" or "north" to get there.
> > I do feel compass directions speak more of the "mapping an unknown
> > area" type of game, and in games where that's the case, I think it's
> > indispensible. But when it's a familiar environment, or the adjacent
> > rooms are given clear titles, I think it's fair to want to type "go
> > bathroom" when the room description clearly says "The bathroom is to the
> > east."
>
> Incorporating info from the room description into the set of places with
> known paths would be useful, yes. (i.e., I know the bathroom is to the
> east, even though I have never actually been there, because I can tell
> from the adjacent room what's through the doorway).
I'm not sure what you mean here--an "intelligent" system that would attempt
to fill in the blanks about what the room is to the east, based on what I
know from the other room?
I'm not sure that would be very easy to understand or to implement, but it's
not something I'd considered before. It definitely wasn't what I meant--I
was referring mainly to being able to use both nouns and compass directions
to go somewhere.
I think one of the things that happens in an IF game is that we abstract up
to a certain level for the commands we give the computer. We don't need to
type "Pick up left foot. Move left foot forward. Pick up right foot", &c,
we don't even need to type "Walk south" or "Lean over and pick up rod". We
give nouns to the objects we encounter so it makes sense to me to give nouns
to the rooms, in addition to the compass directions.
> > I don't even mean directions should be turned off explicitly, just that
it
> > would be nice to have the other option.
>
> Directions are actually useful, sometimes, for getting a clear picture of
> the place you're talking about.
The use of the word "actually" above seems to imply you're disagreeing with
me, but I think we're saying the same thing. I definitely find directions
useful for getting a picture of the area you're in!
> > It's good that the standard words are solidly standard, that aids the
> > usability of text as an interface. But, for example, in some games you
can
> > find many very straightforward things that are not easy to do, because
it's
> > tough to find the right verbs. That's frustrating, especially if the
> > feedback from the game itself doesn't help much.
>
> Perhaps each object should have a list of verbs the game knows which are
> obvious to the PC? I.e., in the case where the PC should know how to use
> the item, but the player doesn't know what the game expects the action to
> be called. Any actions that should be non-intuitive to the PC simply
> wouldn't be listed even if they did something potentially useful, so this
> wouldn't give away anything meant to be a puzzle.
>
> > VERBS DIAL
> Obvious things to do with the washing machine dial:
> SET DIAL TO number
> PRESS DIAL
I think it would be a nicer interface if it fit in smoothly with the
description or the response messages given from trying to manipulate the
object.
>x dial
You see a washing machine dial here, which can be set to rinse or to cycle.
The dial can be pressed in to activate the washer.
For a familiar object like a washing machine, the descriptions could even
tell what the settings can do. But most important is that the actual verbs
that you use to manipulate the object are either given in the the object's
description, or responses are tailored to the object.
Here's a couple of alternative transcripts:
>wash clothes
You'll need to put some clothes in the washing machine and choose a setting
first.
>Put clothes in machine
Done.
>Choose setting
To choose a setting, set the dial to rinse or to cycle.
>Set dial to rinse
Done.
>wash clothes
The washing machine begins to hum as your clothes wash.
I've played games where this kind of thing can be agonizing, where you could
try every verb you can think of, examine every object in the game, without
realizing that you need to do something like "press dial" to start the
washing machine going. It drives me crazy when there's something
agonizingly hard to do in a game that's extremely simple and/or common in
real life.
I personally would find the above much more enjoyable to play than the
following:
>wash clothes
I don't know how to wash the clothes!
>x machine
It looks like an ordinary washing machine. It has a dial on it.
>x dial
It's a washing machine dial. A label above it says "Rinse" and "Cycle"
>set dial to rinse
I don't know how to set the dial!
>Turn dial to rinse
The dial is now set to rinse.
>Wash clothes
I don't know how to wash the clothes!
>Push button
I don't see any button!
>close lid
I don't see any lid
>push dial
I don't know how to push the dial
>press dial
The machine starts to hum as your clothes wash.
>screw you!
You have lost your mind.
Jeff Coleman
charm is real, progress is power!
www.handofgod.com
> Automating this information could be tricky, though, since it has to undo
Jeff Coleman
"Anson Turner" <anson@DELETE_THISpobox.com> wrote in message
news:anson-E5A15A....@news.efortress.com...
the
> suggestion after one (or perhaps more) failed attempts to interact with
the
> object.
>
> I don't, however, believe that there is any feasible way to automate it.
You
> would have to specifically list the verbs (or actions) that you want to
> suggest for each object (or class). E.g.:
I agree that a "verbs" command or process would be unwieldy and
counter-intuitive.
See my reply to David's previous post for a suggestion on a nicer
alternative to this. Not a new system or a new command or anything--just
the idea that authors pay careful attention to the verbs they choose, make
sure that any verbs outside the very very standard are hinted or described
in the object description, game responses, and so on.
Basically, tell them when they're wrong that they're WRONG, tell them when
they're close that they're CLOSE, and tell them when they're right that
they're RIGHT. You can tell someone they're close without giving away the
puzzle, likewise with telling someone they're wrong.
>
> known_verbs "SET DIAL TO number" "PRESS DIAL"
>
> or something fairly similar, with appropriate supporting code.
>
>
>
> Anson.
David Welbourn
Andrew MacKinnon wrote:
> David Welbourn wrote:
>
> > Change "VERBS" to "USE" to be more intutitive, and I think you might
have an
> > idea worth implementing in a game someday.
>
> This is getting off-topic, but for some reason I don't think that is
practical.
> It would spoil many puzzles, and it seems, well, unpractical.
Fair enough. Here's another approach: simply have VERBS list every possible
verb in the game. Don't associate VERBS with an object at all. Is that
better?
-- David Welbourn
Andrew Plotkin
> Basically, tell them when they're wrong that they're WRONG, tell them when
> they're close that they're CLOSE, and tell them when they're right that
> they're RIGHT.
Yes. Yes. All sorts of yes.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Gore won the undervotes:
http://www.gopbi.com/partners/pbpost/news/election2000_pbgore.html
Juhana Sadeharju
>Most games do, in fact, have them -- modern or not.
The compass directions are good in giving an idea of the space, but
I feel they are not that necessary as a method to move around.
My own approach would be to move around with commands such as
"enter door", "enter library", "use staircase". The compass directions,
if needed, would be mentioned in the engine output: "library door can be
seen at the north wall". (It doesn't have to be that boring, though.)
>> Also the textual user interface is an oldish one, and should be
>> removed.
>
>Ah, no. That would kind of annoy all the people who like it.
OK, it looks like it was a troll afterall. ;-)
The textual interface should be more robust in the games.
It is so frustating to try out to "pour water" while only "empty"
works (and I didn't want to empty the bucket, I wanted to keep some
water in the bucket). And there are a lot of more of this kind of
word problems. A verb list would help in these cases.
I'm also looking if, as a backup system, the objects could be handled
at the data structure level. It would allow to express the idea of action
in terms of simple data structure operation with basic knowledge of
the engine data structure. (Well, because I don't want to implement
either textual or graphical interface to my own engine as a first thing,
I should be able to control the game with data structures directly.)
>Perhaps you want to play some kind of game other than text adventures.
I want to play a game which can be controlled. If most of the time
I have to think how to write the action in words because most common
words doesn't work, the game itself is not a great experience.
The documentation I have read tells quite directly that the textual
interface grows up the code size enermously, specially if the system
is made more robust. That means that if people would program graphical
games a la GK3, the programming would be simpler. I feel the extra
work needed in making the graphical content can be distributed to
other people more easier (I know a few people who can paint but nobody
who can program with Inform, for example).
Yes, I would like to see more freely available graphical games.
Perhaps the remakes of well-known games: adventure, curses, etc.
Are there any project aiming at a freely available, open source
graphical game for Linux? Should we start now?
Juhana
Daniel Barkalow
>
> "Daniel Barkalow" <iabe...@iabervon.org> wrote in message
> news:Pine.LNX.4.21.01013...@iabervon.org...
> >
> > Platypus supports that, actually. "GO TO <FOO>" will take you to the
> > room named <foo> if your character knows how to get there. By default you
> > have to explore the way there the first time, but that's relatively easy
> > to change. It can also interrupt you (or distract you, for that matter) if
> > something interesting happens on the way.
>
> That's good, I think that's useful! I'm going to check out the game. I was
> playing a Scott Adams adventure recently and I realized that may be one
> source of my affection for being about to "go jail" or "go saloon" when the
> description clearly states there's a Jail and a Saloon here. In fact, it's
> often not possible to get to the jail or saloon using compass directions.
>
> Basically I think it would be very nice if both options were available.
> Give the room a noun and a compass direction, and the user can type either
> "go <foo>" or "north" to get there.
What Platypus supports by default is "go <foo>" for places you've been
before, whether or not you're adjacent to them (if you're not adjacent, it
takes multiple turns to get there).
> I'm not sure what you mean here--an "intelligent" system that would attempt
> to fill in the blanks about what the room is to the east, based on what I
> know from the other room?
What I meant was adding "go <foo>" for cases where <foo> is mentioned in
the room description. You'd have to also mention it in the code, but then
the player doesn't actually have to visit the bathroom to be able to type
"go bathroom" after being in the room next to the bathroom which mentions
the bathroom door. This doesn't just add all adjacent rooms, because the
game might not want you to know what room is to the east.
> > Perhaps each object should have a list of verbs the game knows which are
> > obvious to the PC? I.e., in the case where the PC should know how to use
> > the item, but the player doesn't know what the game expects the action to
> > be called. Any actions that should be non-intuitive to the PC simply
> > wouldn't be listed even if they did something potentially useful, so this
> > wouldn't give away anything meant to be a puzzle.
> >
> > > VERBS DIAL
> > Obvious things to do with the washing machine dial:
> > SET DIAL TO number
> > PRESS DIAL
>
> I think it would be a nicer interface if it fit in smoothly with the
> description or the response messages given from trying to manipulate the
> object.
I'm thinking more of instructions for the player rather than instructions
for the character. This would be primarily for new players who don't guess
the traditional verb. A separate meta verb would list verbs for all of the
obvious actions in the game (i.e., "get" but not "xyzzy"). The other
useful aspect is that it could handle cases where the author relies on the
library to implement the actions involving the object (i.e., "has
container") and may not specify any uses in the description:
>i
You are carrying:
a canvas rucksack (which is open but empty)
>x rucksack
It looks oddly like a rucksack you once took with you to Paris on holiday,
but perhaps all rucksacks look that way.
No info is given on the use of the rucksack, and it wouldn't fit in the
description very well, but a beginner might not guess the
verbs. Experienced adventurers would infer that the object is a container
from the inventory listing, although not necessarily from initial or
description.
> I've played games where this kind of thing can be agonizing, where you could
> try every verb you can think of, examine every object in the game, without
> realizing that you need to do something like "press dial" to start the
> washing machine going.
I've used washing machines like that, too, actually. Ah, well...
Jeff Coleman
"Daniel Barkalow" <iabe...@iabervon.org> wrote in message
news:Pine.LNX.4.21.01013...@iabervon.org...
> On Wed, 31 Jan 2001, Jeff Coleman wrote:
> > "Daniel Barkalow" <iabe...@iabervon.org> wrote in message
> > news:Pine.LNX.4.21.01013...@iabervon.org...
> What I meant was adding "go <foo>" for cases where <foo> is mentioned in
> the room description. You'd have to also mention it in the code, but then
> the player doesn't actually have to visit the bathroom to be able to type
> "go bathroom" after being in the room next to the bathroom which mentions
> the bathroom door. This doesn't just add all adjacent rooms, because the
> game might not want you to know what room is to the east.
Ah, I see, I was misunderstanding--I think that would be a useful feature!
> > > Perhaps each object should have a list of verbs the game knows which
are
> > > obvious to the PC? I.e., in the case where the PC should know how to
use
> > > the item, but the player doesn't know what the game expects the action
to
> > > be called. Any actions that should be non-intuitive to the PC simply
> > > wouldn't be listed even if they did something potentially useful, so
this
> > > wouldn't give away anything meant to be a puzzle.
> > >
> > > > VERBS DIAL
> > > Obvious things to do with the washing machine dial:
> > > SET DIAL TO number
> > > PRESS DIAL
> >
> > I think it would be a nicer interface if it fit in smoothly with the
> > description or the response messages given from trying to manipulate the
> > object.
>
> I'm thinking more of instructions for the player rather than instructions
> for the character. This would be primarily for new players who don't guess
> the traditional verb. A separate meta verb would list verbs for all of the
> obvious actions in the game (i.e., "get" but not "xyzzy"). The other
> useful aspect is that it could handle cases where the author relies on the
> library to implement the actions involving the object (i.e., "has
> container") and may not specify any uses in the description:
I agree a list of standard verbs would be a good thing. I remember Eamon
had "I'm sorry, I only understand THESE words..." But my main reaction is
that careful handling by the reponses on the part of the author would
improve the whole situation, because it would given in language of the game
itself.
> >i
> You are carrying:
> a canvas rucksack (which is open but empty)
>
> >x rucksack
> It looks oddly like a rucksack you once took with you to Paris on holiday,
> but perhaps all rucksacks look that way.
>
> No info is given on the use of the rucksack, and it wouldn't fit in the
> description very well, but a beginner might not guess the
> verbs. Experienced adventurers would infer that the object is a container
> from the inventory listing, although not necessarily from initial or
> description.
I disagree that it wouldn't fit in the description well. The fact that it's
describe as "open but empty" tells us that we can OPEN and CLOSE it and
mostly likely PUT x IN IT and TAKE x OUT OF IT, since those are the most
natural standard verbs used. A verb list might be nice to accomodate those
unfamiliar with the text adventure in general, but for more complicated
objects that require or support nonstandard means of manipulation, the best
thing I think an author can do is think carefully about the verbs that
people might use. Even some that you wouldn't think they'd use. You can
tailor the responses both to fit in the game, and to guide the player toward
the correct means of using the given object. Even to the level of:
>use washing machine
To use the washing machine you must first put clothes in it, set the dial to
rinse or cycle, and press the dial to turn it on.
This for an object you're familiar with.
>use nuclear subtronic vivificator
The nuclear subtronic vivificator is a vast, enormous machine. You're not
sure how to make it do anything, but there is a small screen with some
numbers on it, several levers that can be pulled, and a giant helmet that
hangs from a wire just in front of the screen.
In this example we haven't given anything away, we haven't ruined the
puzzle, we've just described it well enough to give more clues about what to
do.
>turn on vivificator
The vivificator has no obvious "on" switch, just a screen, several levers
and a giant helmet.
That could create a more pleasing effect than
>turn on the vivificator
I don't know how to turn that on!
> > I've played games where this kind of thing can be agonizing, where you
could
> > try every verb you can think of, examine every object in the game,
without
> > realizing that you need to do something like "press dial" to start the
> > washing machine going.
>
> I've used washing machines like that, too, actually. Ah, well...
Agreed! :)
> -Iabervon
> *This .sig unintentionally changed*
Jeff Coleman
Alan Trewartha
> > the room description. You'd have to also mention it in the code, but then
> > the player doesn't actually have to visit the bathroom to be able to type
> > "go bathroom" after being in the room next to the bathroom which mentions
> > the bathroom door. This doesn't just add all adjacent rooms, because the
> > game might not want you to know what room is to the east.
>
> Ah, I see, I was misunderstanding--I think that would be a useful feature!
>
I had an idea about how this might be achieved. The basic idea is to leave
the compass as the fundamental orientation of rooms, but to change the
compass objects so that their "name" includes names of the objects that
they lead to. All you have to do is make sure that the 'name' property of
the rooms are set up correctly.
Here's what I did in a little experiment. First I hacked English.h so that
the CompassDirection class reads as...
Class CompassDirection
with article "the", number 0,
parse_name [ i;
i=LeadsTo(self,location);
if (i)
{ i=Redirect_PN(i);
if (i) return i;
}
return -1;
],
has scenery;
Where LeadsTo provides the object/room that would be returned by going in
that direction (self) and Redirect_PN is...
[ Redirect_PN i j k l;
l = wn;
j = NextWord();
while (Refers(i, wn-1))
{ k++;
j=NextWord();
}
wn=l;
return k;
];
This worked! I think this could be quite a fruitful way to go. An obvious
elaboration of this would be to see if the object has been visited. If not
then change parser_inflection to a new property (usually "name") called
(say) "external_names" and do Redirect_PN. If it has been visited then
do it again with parser_inflection='name' as well.
Any better suggestions? How could I avoid hacking the library directly?
Should I make this into a little library extension?
below is the example adventure file I tried this with:
! --------------------------------------------------------------
Constant Story "SHELL";
Constant Headline "^An Interactive Skeleton^";
Constant DEBUG;
Include "Parser";
Include "VerbLib";
Include "MoveClass"; ! provides LeadsTo
[ Redirect_PN i j k l;
l = wn;
j = NextWord();
while (Refers(i, wn-1))
{ k++;
j=NextWord();
}
wn=l;
return k;
];
Object Red_Room "Red Room"
class Room
with description
"Red everywhere. The green room is north. The blue room is east.",
name "red",
n_to Green_Room, ! "go green" works
e_to Blue_Room ! "go blue" works
has light;
Object Green_Room "Green Room"
class Room
with description
"Green everywhere. The red room is south.",
name "green",
s_to Red_Room ! "go red" works
has light;
Object Blue_Room "Blue Room"
class Room
with description
"Blue everywhere. The red room is west.",
name "blue",
w_to Red_Room
has light;
[ Initialise;
location = Red_Room;
"^^^^^Welcome to the...^";
];
Include "Grammar";
OKB -- not okblacke
<snip>
>I had an idea about how this might be achieved. The basic idea is to >leave
>the compass as the fundamental orientation of rooms, but to change >the
>compass objects so that their "name" includes names of the objects >that
>they lead to.
Coincidentally, I have written a library (Adjacent.h) that provides this
functionality, although I never got around to releasing it. It provides three
kinds of "go to" stuff:
1. You can set up certain rooms that can be "gone to" from anywhere in the
game.
2. You can set up certain rooms which serve as jumping points from which
certain other rooms can be "gone to".
3. You can set up certain rooms from which certain other rooms can NOT be
"gone to". (This lets you make exceptions to #1.)
The method used is different than what you suggest (and perhaps a bit less
syntactically intuitive), but seems to work in the limited testing that I've
done. If anyone's interested in using this, email me and I'll send it along.
(I may upload it to GMD soon now that my memory about it has been jogged.)
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown