ADRIFT Forum


The place to discuss the ADRIFT Interactive Fiction toolkit

Disambiguation protocols

The place to chat about ideas, writing, this forum, or anything related to Interactive Fiction that isn't specific to ADRIFT.

Please also visit the Interactive Fiction Community Forum for further discussions.

Disambiguation protocols

Postby phkb » Fri Sep 02, 2011 3:27 am

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?
My IF-related stuff can be found here
User avatar
phkb
 
Posts: 376
Joined: Thu Jan 06, 2005 3:27 am
Location: Sydney, Australia

Re: Disambiguation protocols

Postby adriftste » Fri Sep 02, 2011 6:40 am

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.
adriftste
 
Posts: 453
Joined: Fri Aug 22, 2008 12:43 pm
Location: England

Re: Disambiguation protocols

Postby phkb » Sat Sep 03, 2011 3:06 pm

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?
My IF-related stuff can be found here
User avatar
phkb
 
Posts: 376
Joined: Thu Jan 06, 2005 3:27 am
Location: Sydney, Australia

Re: Disambiguation protocols

Postby Po. Prune » Sat Sep 03, 2011 4:34 pm

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...
D-Day V.5 in progress 79Kb so far (slowly getting there)
Anno 1700 in progress 111Kb
User avatar
Po. Prune
Moderator
 
Posts: 3953
Joined: Mon Jun 24, 2002 8:18 am
Location: Denmark

Re: Disambiguation protocols

Postby ralphmerridew » Sat Sep 03, 2011 8:30 pm

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.)
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2501
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri

Re: Disambiguation protocols

Postby ralphmerridew » Wed Sep 07, 2011 11:44 pm

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).

adrift 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.)
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2501
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri

Re: Disambiguation protocols

Postby Campbell » Thu Sep 08, 2011 7:34 am

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.
ADRIFT Developer developer.
User avatar
Campbell
Site Admin
 
Posts: 4570
Joined: Sun Jun 23, 2002 11:05 am
Location: Edinburgh, Scotland

Re: Disambiguation protocols

Postby ralphmerridew » Fri Sep 09, 2011 2:46 am

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.
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2501
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri

Re: Disambiguation protocols

Postby Campbell » Fri Sep 09, 2011 7:57 am

ralphmerridew wrote: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.
ADRIFT Developer developer.
User avatar
Campbell
Site Admin
 
Posts: 4570
Joined: Sun Jun 23, 2002 11:05 am
Location: Edinburgh, Scotland

Re: Disambiguation protocols

Postby ralphmerridew » Fri Sep 09, 2011 8:37 pm

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)
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2501
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri


Return to General IF

Who is online

Users browsing this forum: No registered users and 6 guests