I’m trying to make a puzzle involving taking the batteries out of one device and putting them into a different one. I have the objects “remote control” and “garage door opener,” and each of them needs to have a part of it that acts as a container to hold the batteries. If I name them “remote control battery compartment” and “garage door battery compartment,” I end up running into lots of “which do you mean” questions – not only between the two battery compartments, but between, say, the remote control battery compartment and the remote control itself. And since the entire name of the remote control is included in the name of the remote control battery compartment, it then becomes impossible to specify that you want to refer to the remote control.
I know I could probably beat this into submission with enough “does the player mean” rules, but does anyone have any tips on naming/organizing objects in a sensible way so I can avoid getting into this situation in the first place? It’s a problem I run into frequently.
I find that avoiding the need for disambiguation at the authorial level whenever possible is ideal. In this case, do you really need a separate object for the compartments, or can you just make the items themselves containers? Something like:
[code]A battery-powered thing is a kind of container. A battery-powered thing can be switched on. The remote control and the garage door opener are closed openable portable battery-powered things.
Some batteries are a thing. Check inserting the batteries into something which is not a battery-powered thing: instead say “Those can only go in something that need batteries.” Check inserting something which is not the batteries into a battery-powered thing: instead say “[The noun] can only contain batteries.”
Instead of switching on a battery-powered thing: if the batteries are not in the noun, say “Nothing happens-- must need batteries.”; otherwise say “It works!”[/code]
I considered that, but I thought that requiring the player to “open remote control” would be somewhat unintuitive, since it’s not an object that’s obviously openable. But I suppose maybe I could just mention the battery compartment in the description, and then understand “compartment” as either the remote control or the garage door opener depending on the context…
That might get you back into a lot of disambiguation questions (“which do you mean, the remote control or the garage door opener” in response to “open compartment” when the player is holding both devices). However, if you specify the open/closed state of the opener and the remote control in their respective descriptions, that should give players enough of a clue that they are openable (in which case you could skip the battery compartments (either as “real” objects or as synonyms for the two devices) altogether.
I’m OK with that question, as it makes sense under the circumstances and is answerable, but you’re probably right that the “compartment” step is unnecessary.
In that case, is there an easy way to disable printing “(closed)” after the names of these objects, at least before the player has examined them and noticed that they can be opened? I know I could just set a custom initial appearance, but in the case of the remote control, that’s not ideal. It’s one of several objects sitting on a table, so I’m currently getting a message like: “On the coffee table are a coaster, a TV Guide, and a remote control (closed).” I’d like to retain that, but just hide the “(closed)”.
Check the documentation under “activities” – there is, if I recall correctly, a discussion of various rules relating to printing the name of an object under various circumstances (e.g., as part of a room description, when taking inventory, etc.). Those rules should allow you to control what shows up when the name of the remote control or the opener is generated automatically.
Robert Rothman
Edit: If the documentation isn’t clear and nobody else posts some sample code, I will try to do so when I get home tonight. I’ve used an object which is an openable container, but it is not obvious at first glance that it is such; the code for that may be useful to you.
I’m using the Epistemology extension and doing this:
Rule for printing the name of the remote control while the remote control is unfamiliar:
say "remote control";
omit contents in listing.
which seems to give me the effect I want.
Of course, now I’m also running into problems differentiating between the garage door opener and the garage door. Sigh. Maybe I’ll just make the name of the garage door opener “opener” and have “garage door opener” be a printed/understood name?
I suppose I could do, but I kind of prefer not to reveal the batteries until the player specifically checks for them.
Now I’m realizing that it’s not realistic for the garage door opener to be empty (it should just have dead batteries in it), but implementing two pairs of batteries, one alive and one dead, seems like a nightmare as well (i.e. you shouldn’t know the dead batteries are dead until you’ve tried to use them in something, but that means you have two pairs of batteries that at first appear to be identical, so what do I do if the player tries to take the batteries out before testing the device, etc.). And this seemed like such a simple idea for a puzzle!
I don’t think it would be a major blow to mimesis if there are no old batteries inside. A common “trick” is to say when the player opens the thing the first time that you find dead batteries inside and discard them, or if it’s the PC’s own device say that the batteries died a week ago and you threw them out then but didn’t remember to buy new ones yet.
The latter is probably what I’ll end up doing. It just feels like such a cheat to me. Admittedly, I have a tendency to try to model everything in the game world in much more detail than the story actually requires (which is probably part of the reason I never seem to finish any games).
You can use my extension Numbered Disambiguation Choices to ensure that at the very least, the confusion between “garage door” and “garage door opener” will never break the game for your players (although you’re still risking that I7 will misunderstand parts of your code)
I’d still go with non-overlapping terms, even if it seems not quite how you’d describe things in a static story: maybe “garage door,” “garage remote,” and “TV remote,” or (to avoid disambiguation entirely) “garage door,” “pocket clicker,” and “remote control.”
You may be able to adapt the following fragment of Code to your purposes. It implements a telephone, which acts as a container. However, the parentheticals indicating the open/closed status are supressed, so that it is not obvious that it is openable until the player actually opens it.
Robert Rothman
[code]A telephone is on the desk. The telephone is a closed openable opaque container. The telephone is fixed in place. Understand “phone” as the telephone. The description of the telephone is “Just your standard garden-variety telephone. [if the telephone is open]It is open.[otherwise]A small catch is barely visible near the bottom.”.
Rule for printing room description details of the telephone:
If the telephone is closed:
stop;
Otherwise:
continue the action.
Instead of opening the telephone, say “How do you plan to do that?”.
A small catch is part of the telephone. The description of the small catch is “It looks like you could probably move it.”.
Instead of pushing the small catch:
Say “The telephone springs open[if something is in the telephone], revealing [a list of things that are in the telephone][end if].”;
Now the telephone is open.
[/code]