Disambiguation protocols

[phkb]

I have, in my WIP, two pipes. One pipe is marked with "IN", the other with "OUT". When the player types in "x pipe" I've made the message say:

Which pipe are you referring to? The one marked "IN" or the one marked "OUT"?

Now, the problem is that the location where these pipes exist has an "out" exit. If the player types in "out" they leave the room.
So...(and this is where the question really starts)...do you think it would be OK to make the message say

Which pipe are you referring to? The one marked "IN" (use "in pipe"), or the one marked "OUT" (use "out pipe")?

Do you think that will break mimesis too much?

[adriftste]

Depending on what the pipes are for maybe consider avoiding the problem altogether by changing the names to inlet and outlet or inflow and outflow.

[phkb]

I think, even if I renamed them to inlet/outlet or inflow/outflow, I could still expect a player to use in/out when referencing the object. Given I can't really avoid the problem without (a) completely rewriting the puzzle, or (b) completely changing the map, the question is: Is it bad form to include specific phraseology in a disambiguity message, as I did above?

[P/o Prune]

I see what you're saying here...
But it also a matter of how far do we "authors" have to go to accomodate the players. If i came across an inlet and outlet pipe, I would use the word inlet or outlet, because that's how the object is described and not in or out. As authors we must expect a certain amount of common sense from the players. just my two cents...

[ralphmerridew]

When a word used for disambiguation is a valid command in its own right, it's going to be an overall ambiguous case.
If "X PIPE, IN" tries moving instead of disambiguating, I think that's generally viewed as acceptable limitation.

My advice is to give them the names "inlet pipe" and "outlet pipe"; add "in" and "out" as synonyms; if the player tries disambiguating with "in" or "out", that's just too bad.

(Try playing the Room In A Puzzle section of Zork III / Dungeon to see how this is handled in other systems.)

[ralphmerridew]

Going through the Inform library source:
- When Inform prompts for disambiguation, on the next line, it looks at the first word of input.
- If that word is a verb (there are any grammar lines for it), it will abandon the old input and treat the line as a new command.
- Otherwise, it will treat the line as an attempt at disambiguation and insert the words into the old input.

Inform treats directions as nouns, not verbs, so in the example, "EXAMINE DOOR" "NORTH" treats it as disambiguation (examining the front door); "EXAMINE ROPE" "JUMP" treats it as a new command (jumping).

Code: Select all

"disambiguation" by ralphmerridew
 
Foyer is a room.  "This is the foyer.  The front door is to the north and the kitchen to the south."
Kitchen is a room.  "This is the kitchen.  The foyer is to the north."
Porch is a room.  "You're on the porch.   The front door is to the south."
 
The front door is a door.  It is north of foyer and south of porch.  Understand "north door" as front door when player is in foyer.  Understand "south door" as front door when player is in porch.
 
The kitchen door is a door.  It is north of kitchen and south of foyer.  Understand "north door" as kitchen door when player is in kitchen.  Understand "south door" as kitchen door when player is in foyer.
 
The player holds a jump rope.  The player holds a nylon rope.

(This should be fairly easy to port to ADRIFT. The one tricky bit is creating four doors: A "south door" / "front door" in the porch, a "north door" / "front door" in the foyer, and so on. Whenever the player opens / closes one door, open / close its partner.)

[Campbell]

Thanks. I've added an item to prioritise the disambiguation response over the new command.

I guess the north/south door issue could be catered for by adding/removing alias names for objects which would need to be a new action.

[ralphmerridew]

Be careful about adding too many interpreter-level features; anything that the interpreter has to know about tends to get locked into all future interpreter versions. You're trying to match the power of a Tier 1 language without having your interpreter built on a Turing-complete core.

If you do try to put in the add/remove aliases, one particular pitfall to watch out for is to make sure that save files and the undo deque are aware of object vocabulary.

[Campbell]

You're trying to match the power of a Tier 1 language without having your interpreter built on a Turing-complete core.

The definition of a Tier 1 system, according to the FAQ is:

The most popular and/or powerful, these are currently used by a large number of people; many posts to rec.arts.int-fiction concern these systems and their use; games produced with these systems are guaranteed a relatively large audience.

By that definition ADRIFT is most certainly a Tier 1 system. Also, based on the fact that ADRIFT 5 does actually have If-Then-Else logic (tasks and expressions), one could argue that it is in fact Turing complete.

[ralphmerridew]

The defining feature of Tier 1 has always been power, not popularity. At the time that FAQ entry was written, the two statements were equivalent.

Let me rephrase my second comment:
TADS, Inform, and Hugo started with a Turing-complete core, then designed the rest of the language around that core. All features of the language can be accessed from that core.

ADRIFT appears to have been designed at the UI-level, with Turing-completeness being only an afterthought. (And I'm not sure whether ADRIFT is Turing-complete; I don't think it's possible to write programs that take arbitrarily long to run; I don't think it has looping constructs, and recursion can lead to stack overflow.)

To show a language is TC, write any TC problem within your language. (Writing a Brainf___ interpreter in a language is a popular one, with BF being a fairly simple language. (Simple from the POV of a person trying to make a BF compiler / interpreter. Not simple from the POV of a person trying to do anything in BF.))

- Should be able to run an arbitrary BF program on arbitrary input. (Exact mechanism for entering a program and input are up to you. For example, you might have the user open the program in Developer, put the program and input into various strings, then start the program in runner).

- Should be able to run programs that take arbitrarily long to run.

- Behavior on edge cases (reading a "<" at memory location 0, reading a ">" at the greatest memory location, programs where brackets aren't balanced) is implementation defined. Do whatever's convenient. (Most of the complexity of my BF extension was handling those cases nicely.)

http://pastebin.com/rZBZzGmD http://pastebin.com/rZBZzGmD (BF extension and samples for I7. Was written quickly, may be rough around edges)