T3: Implementing a Rope
Jim Aikin
find anything that implements an extensible, attachable rope as an object.
Before I roll up my sleeves and drive myself crazy trying to model a
rope, I figured I should ask: Has anyone done that yet? The LRM points
out some of the inherent problems associated with making things
Attachable, so I'm not keen to try it if someone else has already done
it (and undoubtedly better than I would).
--Jim Aikin
Mike Roberts
No one's written a rope module, as far as I know. The closest I've come is
individual ropes or rope-like objects in a few games, and those I managed
only by making them *extremely* constrained - I've never even really tried
to come up with anything generalized. I can't think of anything rope-like
in Return to Ditch Day to look at, although I might be forgetting something.
It's pre-tads 3, but there's a rope-like firehose in The Plant; also, I
think there's a very simple rope in Ditch Day Drifter.
--Mike Roberts
Jim Aikin
>
> No one's written a rope module, as far as I know. The closest I've come is
> individual ropes or rope-like objects in a few games, and those I managed
> only by making them *extremely* constrained - I've never even really tried
> to come up with anything generalized.
Well, maybe we could kick some ideas around a little and try to figure
out what a generalized Rope class might look like. And 'rope' would
naturally include garden hoses, electrical cable, kite-string....
For starters, I was thinking vaguely about having a MasterRope object
that wouldn't necessarily be in the game world at all, but that would
encapsulate the functionality of the various portions of the rope that
were visible to the player in various situations -- the ends, the
middle, etc. ropeLeftEnd would then have a myMasterRope property, and
would query myMasterRope in order to determine what to do in response to
various commands.
Here's a preliminary list of stuff that one might want to think about
whilst devising rope:
1. A rope has, potentially, two separate ends, either of which can be
attached to other things. The other things might be in the same room, or
different rooms. They might be fixed, or movable.
2. It can be coiled or extended. If it's coiled, by definition it's not
attached to anything. Conversely, if it's attached to something, then
one end is in one location and the rest of the rope is in at least one
other location (which may be the same room), so at that point it isn't
coiled. That is, the 'coil of rope' visible object has been removed from
play temporarily.
3. It can be extended from one room to another, or potentially through
several intervening rooms. For convenience, we might assume that it can
only be extended if one end is attached to something that remains behind
when you leave the room. So, for instance, we might 'tie rope to
grommet' (without dropping the rope) and then 'n', after which the body
of the rope is in the North Room and the end that's attached to the
grommet is in the South Room. However, we could then 'drop rope', 's',
'untie rope', after which the rope would STILL be extended from the
North Room into the South Room even though it's no longer tied at either
end. If the far end is not tied to anything, we might (for convenience)
assume that 'untie rope' responds, "You untie the rope from the grommet
and coil it up." (Note the implicit 'take' action there. You're now
holding the coil, and the ends have been removed from the game world.)
4. The rope could potentially be tied at both ends, and the ends in
different rooms. It might flow through an intervening room between the
two ends. In this case, 'take rope' in the Middle Room would have to
respond, "You tug on the rope, but it seems to be attached at both ends."
5. As the foregoing will suggest, we now have potentially at least three
_different_ objects representing one rope -- the two ends and the
middle. Depending on the length of the rope, there might be several
middle objects. (For example, we might be implementing Ariadne's
solution to the Labyrinth, which would require dozens of middle
objects.) By definition, only one middle object would be located in any
given room -- and a middle would never be in the same room as an end.
6. If the rope is not attached, it should respond to the word 'end', as
in 'tie end of rope to grommet'. This should work whether it's coiled or
extended, but not if the only rope present in the room is a middle-rope
object.
7. If the rope is extended through 2 or more rooms but not attached at
either end, 'take rope' should retrieve all of it into a coil.
8. The results of 'pull rope' depend (a) on whether the other end (the
end you're not holding) is attached to anything, and if so, whether the
thing it's attached to is movable.
9. A rope can dangle (from a tree limb, for example), but only if its
upper end is attached. If it's dangling, you may be able to swing from
it or climb it. (Also, the bough might break, but that's a special case.)
10. If the rope is attached at one end but not the other, and you're in
a middle room, 'take rope' should bring the free end into your inventory
(and get rid of the middle-rope object), because you're essentially
pulling on the free end to retrieve it. It's hard to see why you would
'take rope' in the middle room if you didn't want this to happen.
11. You might be able to tie the rope to a movable object, go north
(while holding the free end), and then 'pull rope', thus bringing the
movable object into the room. Or, when you tie the rope to the movable
object and go north, the object might travel with you. Depends on the
length of the rope.
12. You've tied the rope to something, dropped it (the rest of it, that
is), and now you type 'take rope'. What should happen? Is that an
implicit 'untie' action, or are you taking the loose end? Probably the
latter. But if you've tied both ends to things, 'take rope' means
something different. It means 'untie (and take) the end'. Of course, you
might tie both ends to objects in the same room, in which case this
command would be ambiguous. To disambiguate, the parser would need to
know, "Do you want to take the end of the rope tied to the billy goat,
or the end of the rope tied to the grommet?" Or it could just say, "To
take the rope, you'll need to untie it from something first." That would
be easier.
Would anyone care to elaborate on or simplify this list?
--JA
Ron Newcomb
>
> --JA
Speaking as a player, please allow:
> TIE BILLY GOAT TO GROMMET
without having to mention the rope in the command at all. A recent IF
Comp game irritated me by not understanding this.
Speaking as an adventurer:
> GET ON ROPE. WALK ON ROPE.
...when it's tied horizontally, as a tightrope.
Speaking as a physics minor:
> LOOP ROPE OVER/AROUND TREE/PULLEY
which, upon PULL ROPE, moves the attached thing to the pulley thing
first.
Is good?
-Ron
Stephen Gorrell
> 2. It can be coiled or extended. If it's coiled, by definition it's not
> attached to anything. Conversely, if it's attached to something, then
> one end is in one location and the rest of the rope is in at least one
> other location (which may be the same room), so at that point it isn't
> coiled. That is, the 'coil of rope' visible object has been removed from
> play temporarily.
Not necessarily. If I tie one end of a long coiled rope to a post, the
bulk of the rope is still in a coil.
Also to consider:
- Examining the end of a rope should describe what it's tied to, if
anything. Examining something with a rope tied to it should mention
the rope. You might want to derive from the TADS3 Attachable class as
a starting point.
- You should be able to specify a maximum length (max number of middle
sections) beyond which the rope can not be extended.
- If you backtrack while extending the rope you would need to remove
the middle sections as you backed up. If you backtrack while moving
along a rope you would not want to remove them. For example:
There's a coil of rope and a post here.
>get rope. tie end to post.
>w. e. (rope extends and retracts)
There's a rope tied to the railing above you. The free end swings
within easy reach.
>get end. up. (rope doesn't retract)
- Doorways would have to be aware of the rope pasing through them and
prevent their doors from closing
- What happens if you go in a circle and re-enter a room the rope is
already in -- while wandering in a maze perhaps? Now you do have an
end and a middle section in the same room.
Given the complexities already described I would try to define a
reasonable subset to handle the most common cases and go with that.
--Steve
Jim Aikin
>> 2. It can be coiled or extended. If it's coiled, by definition it's not
>> attached to anything. Conversely, if it's attached to something, then
>> one end is in one location and the rest of the rope is in at least one
>> other location (which may be the same room), so at that point it isn't
>> coiled. That is, the 'coil of rope' visible object has been removed from
>> play temporarily.
>
> Not necessarily. If I tie one end of a long coiled rope to a post, the
> bulk of the rope is still in a coil.
Of course you're right in a real-world-modeling sense. Perhaps for
"coil" I should substitute "unattached bulk". Whether it's coiled or
lying in a tangle is a different question.
And of course, "untangle the rope" is an interesting command, or
possibly a puzzle.
Then there's the whole question of knots: 'tie square knot', 'tie
bowline', 'tie half-hitch'.... No, maybe just 'tie knot' is enough. If
it's needed at all. But it might be needed -- for instance, suppose
you're feeding the rope through a hole, and you want a knot to be so
massive it will stop at the hole.
> Also to consider:
>
> - Examining the end of a rope should describe what it's tied to, if
> anything. Examining something with a rope tied to it should mention
> the rope. You might want to derive from the TADS3 Attachable class as
> a starting point.
That's what I'm attempting to do, yes.
> - You should be able to specify a maximum length (max number of middle
> sections) beyond which the rope can not be extended.
True.
> - If you backtrack while extending the rope you would need to remove
> the middle sections as you backed up. If you backtrack while moving
> along a rope you would not want to remove them.
Right. I may have been aware of that, but it's good to have it pointed out.
> - Doorways would have to be aware of the rope pasing through them and
> prevent their doors from closing
That I hadn't thought of! I'm sure TADS would allow TravelConnectors to
be modified to check if a rope is passing through them....
> - What happens if you go in a circle and re-enter a room the rope is
> already in -- while wandering in a maze perhaps? Now you do have an
> end and a middle section in the same room.
Yeah, or you could cross a room from east to west and later from north
to south, and then there would be two middles in the room. Ariadne be
damned -- I'd rather be eaten by the Minotaur.
--JA
Eric Eve
news:fsphll$lms$1...@aioe.org...
I certainly haven't attempted implementing a general-purpose rope,
but you might want to take a look at the way the hawser is
implemented in the Attachables sample game that's included in the
set you can download from
http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm (specifically
from http://users.ox.ac.uk/~manc0049/TADSGuide/SampleGames.zip if
you haven't already downloaded them).
-- Eric
Jim Aikin
>
> I certainly haven't attempted implementing a general-purpose rope,
> but you might want to take a look at the way the hawser is
> implemented in the Attachables sample game that's included in the
> set you can download from
> http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm (specifically
> from http://users.ox.ac.uk/~manc0049/TADSGuide/SampleGames.zip if
> you haven't already downloaded them).
I'll take a close look at that -- it may do what I need, or get me on
the right track. Last night after I went to bed I started to think that
maybe a MultiLoc would be a good way to implement a rope that stretches
from one room to another. The comments in the library specifically
caution against this, but I'm not entirely sure why.
In the case of a very long table or conveyor belt that stretched from
room to room, a MultiLoc would be awkward, because anything sitting on
it would be visible and takeable in all of the rooms. Likewise, I
suppose, if a rope is tied to a tree in one room, the default
description would mention that it's tied to the tree even if you're in
another room. But that could be overridden.
--JA
David Fisher
> Stephen Gorrell wrote:
>>
>> - What happens if you go in a circle and re-enter a room the rope is
>> already in -- while wandering in a maze perhaps? Now you do have an
>> end and a middle section in the same room.
>
> Yeah, or you could cross a room from east to west and later from north to
> south, and then there would be two middles in the room.
You are in a square room, with exits an all four cardinal directions.
You are holding the end of a piece of thick rope, which is trailing off to
the south.
A section of rope goes from the east to the north. Two sections go from the
west to the south. Another section goes from east to west.
>pull rope
The east-to-west section of the rope moves east. The two sections from the
west to the south move in opposite directions. The east-to-north section
moves north, pulling a large piano into the room.
>cut rope
Which part of the rope do you mean, the section trailing off to the south,
the east-to-west section, the west-to-south section that moved towards the
west, the west-to-south section that moved towards the south, or the section
tied to the piano?
>east-to-west
No.
David Fisher
stu...@animats.net
<davidfis...@australiaonline.net.au> wrote:
> "Jim Aikin" <midigur...@sbcglobal.net> wrote in message
I think I'm starting to understand why readers of novels don't enjoy
interactive fiction as much as we would like.
Stuart
Jim Aikin
>>> cut rope
>> Which part of the rope do you mean, the section trailing off to the south,
>> the east-to-west section, the west-to-south section that moved towards the
>> west, the west-to-south section that moved towards the south, or the section
>> tied to the piano?
>>
>>> east-to-west
>> No.
>
> interactive fiction as much as we would like.
That sort of mess is a factor, certainly. It's avoidable, however, if
the author is careful (and writes clever "you can't do that" messages).
You don't want to open up a lot of weird states that the game might get
itself into -- you want to constrain each object in sensible ways, so it
will _seem_ realistic and yet not get you into trouble.
--JA
stu...@animats.net
I have no doubt that with a bit of thought and constructive discussion
an excellent implementation of a rope could be made. I guess what this
makes me realise is that there is definitely a type of interactive
fiction that is for the boffins only. Every time I attempt to convince
my wife that she would enjoy IF, it is the point where the story stops
and the complex object manipulation starts that she loses interest. I
think complex object-based puzzles are something a certain type of
person enjoys (and I'm certainly one of them), while another group of
people really find them way too technical to be enjoyable when you
really just want to get on with the story. Puzzle-less IF exists, as
does fiendishly-clever technical IF, and that's good. It's just that
some things make it easier to see things through other peoples eyes.
Stuart
Nikos Chantziaras
> I have no doubt that with a bit of thought and constructive discussion
> an excellent implementation of a rope could be made. I guess what this
> makes me realise is that there is definitely a type of interactive
> fiction that is for the boffins only. Every time I attempt to convince
> my wife that she would enjoy IF, it is the point where the story stops
> and the complex object manipulation starts that she loses interest. I
> think complex object-based puzzles are something a certain type of
> person enjoys (and I'm certainly one of them), while another group of
> people really find them way too technical to be enjoyable when you
> really just want to get on with the story. Puzzle-less IF exists, as
> does fiendishly-clever technical IF, and that's good. It's just that
> some things make it easier to see things through other peoples eyes.
Let's not forget the gaming-side of IF though. It's meant to be played,
not only read. Without the puzzles and object manipulations, it
wouldn't be a game anymore but rather just a bunch of text with a ">"
under each paragraph.
I think your wife might be more interested in CYOA-type works rather
than text-adventures.
jon.i...@gmail.com
> stu...@animats.net wrote:
> > Every time I attempt to convince
> > my wife that she would enjoy IF, it is the point where the story stops
> > and the complex object manipulation starts that she loses interest. I
> > think complex object-based puzzles are something a certain type of
> > person enjoys (and I'm certainly one of them), while another group of
> > people really find them way too technical to be enjoyable when you
> > really just want to get on with the story. Puzzle-less IF exists, as
> > does fiendishly-clever technical IF, and that's good. It's just that
> > some things make it easier to see things through other peoples eyes.
>
> Let's not forget the gaming-side of IF though. It's meant to be played,
> not only read. Without the puzzles and object manipulations, it
> wouldn't be a game anymore but rather just a bunch of text with a ">"
> under each paragraph.
How strongly can I put this? :) I totally disagree. I say, let's write
IF for his wife. Object-manipulation is for programmers. A great
juggler doesn't make the audience care about throwing and catching but
about pretty pictures in the air. Grr. Tear down those walls!
jon
stu...@animats.net
It think its an interesting problem, and it *is* one about tearing
down walls. I say that I try to convince my wife she would enjoy IF
because I enjoy it and I want her to see what I see in it, but she
doesn't. She does love reading stories though and I see bridging the
gap between a story reader and a game player quite a challenge. I
don't think there is anything wrong with having different types of IF
for different audiences, but I don't think that means we should give
up on trying to make something that is both a story and a game. Its
just that the game part needs to be fun, not tediously technical if
certain types of people (ie, the main stream (oh dear, that's a can of
worms)), are going to enjoy it.
It makes me wonder though what percentage of people who play IF also
create it. I get the impression that playing IF is so much like
programming that it is mostly programmers who play it.
Stuart
David Fisher
>>>
>>>> cut rope
>>> Which part of the rope do you mean, the section trailing off to the
>>> south,
>>> the east-to-west section, the west-to-south section that moved towards
>>> the
>>> west, the west-to-south section that moved towards the south, or the
>>> section
>>> tied to the piano?
> That sort of mess is a factor, certainly. It's avoidable, however, if the
> author is careful (and writes clever "you can't do that" messages). You
> don't want to open up a lot of weird states that the game might get itself
> into -- you want to constrain each object in sensible ways, so it will
> _seem_ realistic and yet not get you into trouble.
So in this particular case, maybe the rope could be limited to being only
long enough to have a "beginning", "middle" and "end" in separate rooms (ie.
no multiple middles in separate rooms).
But it is still tricky if rooms (& passages between rooms) are different
sizes ... maybe rope "middles" are more trouble than they are worth?
And if there is more than one rope-like object in the game, the PC could tie
them together and create the original problem again.
David Fisher
stu...@animats.net
wrote:
> "Jim Aikin" <midigur...@sbcglobal.net> wrote in message
Putting my gaming hat back on, it seems that most of the rope puzzles
that have been implemented in the past have really only needed a rope
that stretches between two locations. To have the rope be more
completely implemented would be nice, but it seems like it is a case
of complexity increasing beyond the benefits once the rope gets longer
than stretching from one location to another. And, as you say, you
would need to be careful about some locations being a fair way apart
compared to others. It isn't uncommon in an outdoor game for a
location to be many hundreds of metres away from its neighbour.
Maybe it would be better to put the effort into somehow modeling the
space within a single location?
Stuart
Mike Roberts
> Nikos Chantziaras <rea...@arcor.de> wrote:
>> stu...@animats.net wrote:
>> > Every time I attempt to convince my wife that she would enjoy
>> > IF, it is the point where the story stops and the complex object
>> > manipulation starts that she loses interest.
>>
>> not only read. Without the puzzles and object manipulations, it
>> wouldn't be a game anymore but rather just a bunch of text with a ">"
>> under each paragraph.
>
> How strongly can I put this? :) I totally disagree. I say, let's write
> IF for his wife. Object-manipulation is for programmers. A great
> juggler doesn't make the audience care about throwing and catching
> but about pretty pictures in the air. Grr. Tear down those walls!
Well... I think the situation is subtler than that. I can't speak for
Stuart's wife in particular, but I have observed a fair number of non-IFers
playing IF, and the problem I've seen isn't so much that they don't like the
object manipulation, it's that they want to manipulate objects on their own
terms. They have no interest in the tedious details of precisely which
centimeter of the rope needs to be cut, but they are terribly interested in
dissecting the frog and get frustrated that the game doesn't understand
their efforts to do so.
If you can find a way to make a game entirely on the player's terms, that's
great, but in my experience the player's terms always seem to boil down to
Reality. The traditional IF approach has always been to *pretend* that
everything's on the player's terms, and let them find out otherwise along
the way. I think that's a big source of the frustration Stuart's talking
about. Emily Short has written about a third path, of *not* pretending that
everything's on the player's terms, but making up for it by letting the
player know early and often what the game's terms are, and being consistent
about those terms. You don't just implement random things in extreme detail
on an ad hoc, per-puzzle basis; you implement *one* thing in extreme detail,
and you use that one detailed mechanism over and over, and you make it clear
from the start that this mechanism is central to the game.
--Mike Roberts
Personman
Simulation (http://emshort.wordpress.com/writing-if/my-articles/issues-
in-simulation-older/). It has this to say:
<quote>
Links and Ties.
The Ultimate Rope. This is one of those things that has received so
much attention that it almost seems pointless to recount the variety
of the challenges associated therewith. First of all, a rope has two
ends, so you have to remember the state of each (and disambiguate
between the player's references to them, of course.) Then there's
marking what the rope can be tied to; the possibility of cutting the
rope in the middle, making multiple ropes of new lengths; the problem
of using the rope as a fuse, of tying it to something in one room and
then carrying the other end, of tying the ends together, etc., etc.,
etc. Ultimately I think the very trickiest part of all this is the
disambiguation problem, ie, figuring out exactly what the player means
when he says >TIE ROPE TO X (which end? Do we untie something that's
already tied, if both ends are in use?) But it's all pretty grotesque,
frankly.
</quote>
Then there are things like dangling something tied to a rope into a
lower room - and then cutting the rope; tying an NPC up with a rope,
or tying them to a stationary object, limiting their range of
movement; making a loop in the middle and tying it around itself,
creating a third end; swinging the rope as a whip, in combat, or to
knock unreachable things down; attaching the rope to levers and
switches so that they can be activated from other locations; using the
rope as a lasso, to catch NPCs or to snag it on something otherwise
unreachable; using the rope as a noose; etc, etc.
Not that you have to do all these things or anything; I'm sure a
fairly reasonable rope can be practically implemented. But it's a
pretty tricky issue, and there will always be something you player
wants to do with it but can't.
Personman
Jim Aikin
>
> It think its an interesting problem, and it *is* one about tearing
> down walls. I say that I try to convince my wife she would enjoy IF
> because I enjoy it and I want her to see what I see in it, but she
> doesn't. She does love reading stories though and I see bridging the
> gap between a story reader and a game player quite a challenge.
Musing about this last night, it occurred to me that one could release
two versions of a game -- one for gamers and one for readers.
The only difference, which would be pretty easy to code, would be this:
The version for readers includes the verb 'solve'. When confronted by a
puzzle, any puzzle, the reader simply types 'solve', and the puzzle is
solved. As long as there's only one puzzle per room, you don't even need
to specify the object.
This would leave the reader free to wander around, converse with the
characters, and so forth, thus enjoying the story without ever needing
to open up and grapple with the hints.
> It makes me wonder though what percentage of people who play IF also
> create it. I get the impression that playing IF is so much like
> programming that it is mostly programmers who play it.
It would be interesting to try to do a "census" on this point.
--JA
Jim Aikin
> Putting my gaming hat back on, it seems that most of the rope puzzles
> that have been implemented in the past have really only needed a rope
> that stretches between two locations. To have the rope be more
> completely implemented would be nice, but it seems like it is a case
> of complexity increasing beyond the benefits once the rope gets longer
> than stretching from one location to another.
I agree. I'm still working on one of my ropelike objects, and it only
has to extend from one location to an adjacent location. There's a
slight complexity, which is that location 1 is _above_ location 2 (it's
a FloorlessRoom), so if you drop the rope after attaching it at the
upper end, it dangles down into location 2.
The tricky bit is that the rope object is only ever _in_ one location.
When the player goes up, the software sneakily moves the rope up to the
top location, and vice-versa. The rope's description is contoured to
reflect its attachment status and where the player is. Since there's
only one way to get to the top location, this is pretty simple to code.
If there were other routes, it would get a bit more convoluted, as you'd
always have to make sure the rope was there when the player tried to
manipulate or inspect it.
--JA
Personman
> stu...@animats.net wrote:
>
> > It think its an interesting problem, and it *is* one about tearing
> > down walls. I say that I try to convince my wife she would enjoy IF
> > because I enjoy it and I want her to see what I see in it, but she
> > doesn't. She does love reading stories though and I see bridging the
> > gap between a story reader and a game player quite a challenge.
>
> Musing about this last night, it occurred to me that one could release
> two versions of a game -- one for gamers and one for readers.
> --JA
It's funny you mention - I just began playing Blue Lacuna, one of the
Spring Thing entries, and one of the first things it does (after
analyzing your play style in the introduction) is offer you the choice
between 'story mode' and 'puzzle mode'. I'm playing in puzzle mode,
'cause I like puzzles, but story mode offers de-emphasized, easier, or
avoidable puzzles in favor of a more uninterrupted interactive
narrative. The game is extremely pleasing so far, I highly recommend
showing story mode to anyone on the edge of being interested in IF.
-Personman
stu...@animats.net
Well this sounds like a good way to implement what Jim was suggesting.
I feel that this probably needs a separate thread so people can get
only an talk about implementing a rope, but just quickly...
It has often occurred to me that one of the major benefits of software
is the ability to configure it to personal taste. We (as a group)
often have theoretical discussions about the best way to do things
that end with the conclusion that it is all a matter of taste. I think
it makes sense for a piece of IF to start with the opportunity to
chose between puzzles or story, menu based conversation or ask/tell
etc. I've even been thinking, to address the point Nikos made, about
having a CYOA interface that can be turned on that issues commands to
a full IF backend.
In relation to what Mike was saying, I have often thought about is how
IF has a very unknown interface. What I mean is that each game
implements a slightly different set of verbs in a slight different
way, with varying levels of detail from object to object. I can't help
but envision a particular form of IF where the verbs and level to
which objects are implemented is fixed, and the author of the story
only has control over the way to combine these fixed elements. That
way when someone plays a piece of 'Standardised' IF, they will know
exactly what to expect and can use the knowledge they gained in the
first game they played in the second. A 40 move game of chess, for
example, has more combinations of posibilites than there are atoms in
the known universe, but players know exactly what moves are available
to them before the game begins. Can you imagine playing a game where
you weren't explicitly told the moves you are allowed to make? I think
this idea is very similar to what Emily suggests should happen within
a game, only on a broader scale.
Stuart
Eriorg
> > create it. I get the impression that playing IF is so much like
> > programming that it is mostly programmers who play it.
>
> It would be interesting to try to do a "census" on this point.
>
> --JA
There was a survey in 2005:
Almost all the people who responded to the poll had some programming
experience. But they were all RAIF members, so maybe it's biased...
Mike Roberts
> In relation to what Mike was saying, I have often thought about is how
> IF has a very unknown interface. What I mean is that each game
> implements a slightly different set of verbs in a slight different
> way, with varying levels of detail from object to object. I can't help
> but envision a particular form of IF where the verbs and level to
> which objects are implemented is fixed, and the author of the story
> only has control over the way to combine these fixed elements. That
> way when someone plays a piece of 'Standardised' IF, they will know
> exactly what to expect and can use the knowledge they gained in the
> first game they played in the second.
There's been discussion on and off for a long time on a related topic, not
quite the same but close, which is whether you could solve some of the
"interface of mystery" problem by disclosing all of a game's verbs up front.
A "standard IF" interface would have this feature implicitly, since you'd
know that only the standard verbs are used. There's always been a strong
consensus here that this disclosure is harmful, since a visibly limited verb
list conflicts with the essential illusion of complete freedom of action. I
think the same would be true of trying to standardize the deeper aspects of
the model, maybe even moreso.
(I've converged in my own games on a sort of compromise where I give the
player a list of all the *necessary* verbs - i.e., the game is winnable
without any verbs beyond those listed - but I also let them know that the
game understands many other verbs as well, and that they're free to
improvise. It's been pointed out that even this degree of disclosure is
harmful to some games, because they require an unusual *action* - something
that's easily expressed in ordinary words once you think of it, but which
would be obviously special if included in a word list.)
--Mike Roberts
stu...@animats.net
I like the idea of just revealing the essential verbs, but unusual
verbs are always a bit of a give-away. In the JACL interpreter I used
readline for the command prompt where hitting tab on the first word
completes again verbs and after that it completes against the names of
objects in scope. Of course readline being readline, double tapping
tab from an empty prompt just gives you a complete list of verbs. :)
Stuart
Nikos Chantziaras
> I like the idea of just revealing the essential verbs, but unusual
> verbs are always a bit of a give-away. In the JACL interpreter I used
> readline for the command prompt where hitting tab on the first word
> completes again verbs and after that it completes against the names of
> objects in scope. Of course readline being readline, double tapping
> tab from an empty prompt just gives you a complete list of verbs. :)
The problem here is that it won't work on systems where the verbs aren't
in the interpreter but rather in the game itself. At least not without
non-trivial effort. But the idea is quite good; sort of command-line
auto-complete for IF. Though I could list a lot of cases where it would
backfire horribly.
>x [tab]
: table, Bob, dead body, a central and very important clue you're not
supposed to find yet, glass of water...
stu...@animats.net
The verbs in JACL are in the game, not in the interpreter. The
interpreter just builds a list of verbs to use for auto completion
when it loads the game. There is also the ability when you write your
game to exclude objects from appearing in tab completion because they
are either trivial and always present, or need to be hidden because
they haven't been revealed yet. The works because readline requests a
list of words at the exact moment when tab is pressed, not a static
list up front.
I was also trying to get out of Andrew whether it is possible to have
something in the GLK API that allows the interface to query the
interpreter for a list of words that should be used for tab completion
at any given time. That way the verbs live in the game (where they
belong) and the interpreter simply passes the list is builds onto the
interface.
Anyway, now we're miles from making ropes :)
Stuart
Blank
I think that's great - the coding equivalent of "sod it, where's the
walkthrough".
--jz
Blank
I'd say have a "show verbs" command which lists all of the *currently
applicable* commands. So it wouldn't include "eat" for example if there
happened to be nothing edible in scope.
yes, of course players could keep typing "show verbs" and watch how the
list changed, but I'd suggest in that case the player has already lost
confidence in the author's fairness/abilities, so there wouldn't be much
of a loss of immersion. I think that just like typing "topics" during a
conversation, the extra overhead would mean that players only used the
verbs command when they needed a bit of a hint.
-jz
ccon...@yahoo.com
> Speaking as a player, please allow:
>
> > TIE BILLY GOAT TO GROMMET
>
> without having to mention the rope in the command at all. A recent IF
> Comp game irritated me by not understanding this.
I assume you mean Fox, Fowl and Feed. FWIW, I added that ability into
the updated release I posted recently. (And yes, I agree that it
probably should have been there to begin with.)
Fortunately the scope of FFF was small enough that I didn't have to
worry about most details, like the length of the rope. (I
deliberately left it ambiguous in the game; the usage is limited such
that you never need to think about it -- and, in my view, it never
seems unreasonable in what it allows you to do.) A general-purpose
rope would be an order or two of magnitude harder to program, I would
imagine.
It's been a while since I played Zork 1. Anyone remember how fully
implemented that rope was? Could you tie it to things other than the
one railing you needed it for?
-Chris C.
Ron Newcomb
> On Mar 30, 11:45 pm, Ron Newcomb <psc...@yahoo.com> wrote:
> I assume you mean Fox, Fowl and Feed. FWIW, I added that ability into
> the updated release I posted recently.
Oh nice! And yes, I did.
> Fortunately the scope of FFF was small enough that I didn't have to
> worry about most details, like the length of the rope.
And it worked very well for the scope of the game, too.
-R
PS: did you add a custom response to SHOOT DUCK? Oh, no reason....