Ropes, it has been noted many times by many authors, are difficult to do well in IF. Here is a compilation of notes, tips, and ideas from old raif postings: For an attempt to consolidate this into the beginnings of a pattern, see IntFicRope.
[First off, some tips from the most recent post (8/26) by Ivan Cockrum:]
- It's better to put all the code in the rope object, rather than the tie-to points, to centralize all your code.
- Let the rope object know what it's tied to, rather than just telling it that things are tied at top and bottom, otherwise you'll have a heck of a time telling the player what the rope is tied to, i.e. "rope.top := kettle"
- (using the TadsLanguage): In WorldClass, be sure to check out its Attachable and Attachpoint classes.
[Gareth Reese posted the following quote:]
"Interview at the end of the universe: Mike Gerrard meets Infocom's Dave Lebling" [Atari ST User, May 1987]
"We use a very high-level language and you can learn the rudiments in a few hours. From then on it's just a question of when you get in a sticky spot you come to someone else, like myself or Steve Meretzky, and say 'Well, I've got this rope...how do I do a rope? It can be in two rooms at once if you tie it to something and take the end with you, and can you tie things up with it and drag them around with you?'
"Then we'll stop and think and say, 'You don't want to have a rope in your game,' and that makes it much easier for the new writers, you see.
"My new game has a chain in it, and it's even worse than a rope in almost every respect you can imagine and it's caused me no end of horror... the number of bugs that have come in on this chain alone would stack from here to there and back again".
[From the same Gareth Reese post:]
The way to write the rope [in the InformLanguage - LS] is to have two objects. One is `found_in' the two locations. When the player picks it up, that rope is given the attribute `absent' and is swapped for another rope that can be carried around.
(Among the puzzles that never made it into the released "Christminster" was 405 lines of bug-ridden rope puzzle including no fewer than seven objects representing different states that the rope could be in!)
[From a post by Neil DeMause? about implementing ropes in the TadsLanguage:]
Two things: First, anything you want to be able to tie the rope to should have the line:
verIoTie(actor)={}
If you want to be able to tie the rope to anything, you can put this line in the thing class. More likely, you'll do something like this:
class tieable:thing
verIoTie(actor)={}
;
Then add "tieable" as one of the parent classes of anything you can tie the rope to.
Also, TADS calls the Io routine for verbs that take prepositions, not the Do routine. So you should either put your code in the ioTie routine of the indirect object, or define it like so:
ioTie(actor,dobj)=dobj.doTie(actor,self)
(Again, you'd probably want to do this in the "tieable" class, or whatever you wind up calling it.)
[Paul O'Brian noted this bug regarding a rope in a game that shall remain (here) anonymous:]
(try tying a rope to the frame, then tying something to the rope, then walking away holding the tied object -- works mighty easily!)
[then again, in a different game:]
(one must again "throw rope over hook" but cannot stand on the table or hamper, lasso the hook, simply "throw rope", "put rope on hook", or even "throw rope onto hook".)
[Chuan-Tze Teo, in an article about his experiences with his own game 'Fear':]
...it transpired that the tying code was still horribly broken, and no amount of hacking would fix it. The next weekend, I took the plunge and rewrote the entire thing into its present form, which gives each object two tieable ends. (How do the other games containing ropes handle this? I would be very interested to know.)
[In a plea for help by Cable Hicks:]
I am trying to make a rope. What this rope does, is the player can carry it, and tie the rope's ends to certain objects in adjoining rooms. So what I have is a set of variables in the rope object that store the object names that it is attached too.
The character can walk around these two rooms and tie the ends to objects. He can see what the rope is attached to by looking at his inventory ( invent overide ) or by dropping the rope in a room ( describe overide ).
What doesn't happen, is that when the player enters a room where one of the ends is tied when the player has the rope, there is no descibe called for the rope. The player doesn't know that the rope is attached to anything in the room without looking at his inventory. Not good.
The only solution I can think of would be to do something along the lines of modifying the found_in list, but I haven't found anyway to change that. If anybody knows how to change it or can think of an alternate solution, please email me.
[Rob Wheeler, noting the implementation of a rope in GrahamNelson's 'Sherbet':]
I've just been playing through "Meteor...stone...sherbet" recently, and I noted the use of a rope as a prop, capable of being tied at one or both ends, first to an object, then to the player, or, failing that, to just dangle on its own. Untying it often untied both ends at once, which I assume smoothed out some of the programming.
[Rob then asked for help implementing his own rope.]
[James Cole, responding to Rob's post:]
WorldClass has 'attatchable' and 'attatchpoint' classes which should (though I've never had a go at implementing something like this) do what you want.
[Julian 'Jools' Arnold, also responding to Rob about the HugoLanguage:]
Have a look at Hugo, which provides a powerful attachables class in the standard library. I'm not entirely sure how it all works yet (:P), and there are some bugs in it that prevent it working correctly with other complex objects (ie, identicals), but it's still useful, and should give you some ideas for TADS.
[Rob Wheeler again, in a followup post:]
Phase two [of coding his rope] is baffling me: The player oughtn't be allowed to walk out of a room if he's carrying the rope (or is tied to it) and the rope is tied to a fixed object in the room. Small tied objects should scoot behind (or be, by default, added to the player's inventory).
I'm not sure where I can interrupt the moving-around code in order to start checking for rope attachments. The other problem might be that my rope is considered "tied to" an object by just kind of having a pointer to the object, which means that the other object has no clue that there's a rope tied to it or not.
I think I recall in some game or other (Curses?) that the rope is automatically untied from whatever as the player exits, to avoid this confusion, but that still leaves me not sure where to trap the exiting-a-room code, or the delicate, proper way to do so.
[Rob Wheeler once more, talking about his final solution to his rope problems:]
...It is occurring to me that there are a lot of players who will find the rope and then carry it around all over the place, tying it to everything in sight and perhaps getting weird responses. (At one point, a shaft of light appeared, and naturally you were able to tie the rope to it. And when it disappeared, the rope still claimed to be "(tied to the shaft of light)." Sigghhhh.)
[Julian Arnold responded to that,...]
Put in a check that will only allow the rope to be tied to specific objects (ISTR you're using Inform):
before [;
Tie:
if (second has tieable) {
print "You tie the rope to ", (the) second, ".^";
[...rope tying code...]
return false;
}
else
"You can't tie the rope to that.";
],
[Mary Kuhner also responded to Rob, taking a different tack:]
...(I crashed one of the competition games with "tie rope to me", a command that seemed quite reasonable at the time.)...
...A rope is such a damnably useful object that it is natural for the player to apply it willy-nilly, and it's really hard to see why "tie rope to bedpost" should fail. I'd be inclined to try to part the player from the rope ASAP, or else give the rope a second use. Objects which seem really useful but only do one thing exasperate me as a player.
The classical answer to ropes is to use them to climb down and then be unable to untie them, like the one in Sherbet. Or you could break them, though even a bit of rope might be a pest.
[Will Gzranich also noted:]
The rope problem seems to get to you...why not give the rope a property which only allows it to be tied to a few things? Most players probably won't get angry because you won't let them tie a rope to everything vaguely post-like...
[But Aapo Haapenen responded to that,...]
I would get angry. I like to tie ropes to everything.
[Derek Feddon asked another rope question about why his code wasn't working:]
Essentially, I want to store the name of the object successfully tied to by the rope into an array, so that it may be printed in both inventory listings and in the rope's description.
[And Andrew Plotkin recommended:]
Don't use arrays for this. Store the object number itself, and just call PrintShortName? on it whenever necessary.
[Arlo Smith talks about his own rope code:]
I took a rope. Split it in two when it's tied to a tree, the rope end moved to the player, the rope tied to the tree. Now what?
Well, the end of the rope can be carried or thrown into an adjacent room, assuming thatthe rope is long enough to stretch that far. For laughs, I even have it so if the player continues carrying the rope to next room after that, beyond the range of the rope, the rope end slips out of his hand! So the rope remains tied to the tree in one room, and the rope end lays on the floor in the adjacent room. When the player comes back to pick it what fell, he can pick up the rope end. The possibilities are many. Suppose the player walks back to the tree, unties it, all the while leaving the rope end on the ground in an adjacent room? Now the rope is in his hand, but not the whole rope! Until he picks up the ubiquitous rope end, the rope remains in two pieces. Or suppose he ties the rope to the tree, the rope end in his hand, and then drops the rest of the rope, so the rope end and the rope are both in the same room. In that case the rope can be melded into one as soon as it's dropped.
If I really want to get silly, I could arrange it so the player can toss the rope end, while the rope is tied to the tree, IN the tree. If I really really want to get silly, I can have it so the player can tie the other end to the tree as well, and then untie the first end, so that the rope end is tied to the tree, and the rope is in his hand!!! Actually in that case, I whatever he unties would be the rope end, and the rope would remained tied. Confusing! ha ha.
[David Burke posted his solution to the tied rope problem:]
I had the same problem, and created two objects. Rope1 and Rope2. Rope2 starts of life without a parent. When Rope1 is tied to the hook, and dropped over the edge of the cliff, the before routine, moves rope2 to the lower location. The "Take" part of the after routine for Rope1, also removes Rope2. Rope2 cannot be taken, replying that is attached to the parent of Rope1.
['FemaleDeer?' talks about her own rope code [using the InformLanguage:]
I have used a location "On the Rope" after you drop the rope over the edge of something and climb down it. I also move the rope into your possession as a separate object. If you drop it, you fall.
Use number and some other property to be able to tie it to two things. This is simplified:
Rope "rope"
has supporter enterable
endone 0,
endtwo 0,
before
[; Tie : if (endone~=0 && endtwo ~0) "There is no free end
of the rope to tie.";
if (endone~=0) endtwo=second;
else endone=second;
print_ret "You tie one end of the rope to ", (the) second, ".";
];
[Dan Knapp responded:]
Bear in mind that the ends of a rope are distinct objects. So they should indeed be implemented as such - if one end of a rope is burned, the other is not necessarily. But for a plain ol' climbing rope, it shouldn't be a problem.
[To which Richard G. Clegg responded (sillily, but it does illustrate another possible bug):]
Um... you mean you could burn one end of the rope and have a single ended rope. Hey, cool and then you could just measure the length you wanted, cut it and have as long a rope as you needed. I wonder if rope manufacturers are wise to this?
[And Dan Knapp replied:]
:-)
No, I mean I could burn one end of the rope and have a rope with two ends, one burned, and be able to refer to them separately, ie "Tie the burned end of the rope around the duck's neck."
Compilation started by LucianSmith
CategoryIntFic
EditText of this page
(last edited August 27, 1997)
FindPage by searching (or browse LikePages or take a VisualTour)