I’m trying to implement a system of supporters that would over-ride the standard supporter/item scheme of the Libraries.
Example 1: Let’s say the PC is in a swanky ballroom, holding a cup of tea, and the player types DROP CUP. I want the game to recognise that a cup can’t be dropped to the floor (or whatever the text beneath the room description listing “loose” items refers to), but must be placed on top of a suitable supporter. The game should search for such a supporter in the current location, and not finding one inform the player that the action could not be performed.
Example 2: The PC is standing in the pantry, holding a length of saussage. There are shelves in the pantry as well as a hook in the ceiling. When the player types DROP SAUSSAGE I want the game to automatically hang the saussage on the hook. To place the saussage on the shelves, the player must type PUT SAUSSAGE ON SHELVES. Should the player decide to leave the pantry holding the saussage, go to the music room and attempt to PUT SAUSSAGE IN TROMBONE, the game must disallow such a beastly action. Putting a pack of cards inside the trombone is fine though.
I’ve tried implementing this with a lot of react_before routines. While the result is semi-functional, it is also utterly inelegant. So what I’m looking for are guidelines (examples in I6 would be appreciated) for this kind of scheme, perhaps using classes and inheritance?
Been a while since I tried this stuff in I6… you really want before routines on the items, rather than react_before. You can supply these through inheritance. Create a swanky_item class with appropriate before code, and give the objects some property that identifies the appropriate kind of supporter.
The only tricky part is if you want an individual object to have its own before:Drop routine. Before clauses stack, but the object’s own code runs before inherited code. To reverse that order, you’d have to write a specific before routine that invoked the general before routine.
Standard handling in the before routine should be able to cover all of this. react_before is really for when some OTHER object in the room needs to react before an action occurs.
If the silver tea tray is movable, then before Drop: would have to look around to see whether the tray is in the location – something like this (untested, and my I6 is rusty):
before [;
Drop: if (tea_tray in location) {
move self to tea_tray;
"You set the cup gently on the silver tea tray.";
}
else "If you drop the cup on the floor, it will surely break.";
],
Actually, that “else” isn’t needed, is it?
BTW, “sausage” is spelled with only one ‘s’ in the middle.
That places the emphasis on the items that you’re dropping. That approach is fine if you have only a few items that you need to drop. However, if you have a lot of items that might be dropped, then the emphasis should be on the supporter objects.
Imagine this:
Class catcher
with
react_before[;
Drop: move noun to self;
"Oh no! Dropping ", the (noun), " on the floor just wouldn’t do. You place it carefully on “, (the) self, " instead.”;
];
Object sballrm “Stanky Ballroom”
with
description “A stinky place where people dance. Fun!”,
has light;
Catcher tray “silver tray” sballrm
with
name ‘silver tray’ ‘tray’,
has supporter;
Object doshrip “day-old shrimp” sballrm
with
name ‘shrimp’;
This is fairly crude as the Catcher items will prevent ANYTHING from being dropped in their location, which may not be what you want. Some things, like say, a handkerchief, might be able to be dropped on the floor. In that case, you’d need to do an (ofclass) in the react_before for the Catcher class.