A database of question-asking mechanisms found in interactive fiction—parser-based, choice-based, and hybrid. Each entry describes what the mechanism is and how it works, with examples. Answers to examples appear in invisible ink (highlight to reveal).
How the player engages with objects and characters through language. In IF, all interaction is mediated by text—both the player's input and the system's response. The mechanisms here govern the vocabulary of that exchange: what the player can say, what the system understands, and what happens when the two don't align.
The player knows what they want to do but must discover which word the parser accepts. Is it PRY? LEVER? FORCE? USE CROWBAR ON GRATE? The puzzle is not about the game world but about the game's language. Good design minimizes this by implementing synonyms generously and making verbs discoverable through context ("The grate looks like it could be pried open"). Bad design treats verb-guessing as legitimate difficulty. The failure mode has nothing to do with understanding and everything to do with hitting the right keyword.
EXAMPLE: > OPEN GRATE THE PLAYER HAD THE RIGHT IDEA ON EVERY ATTEMPT; ONLY THE THIRD MATCHED THE PARSER'S EXPECTED VERB
You can't open that.
> PRY GRATE
I don't know the word "pry."
> LEVER GRATE WITH CROWBAR
The grate swings open!
EXAMINE (or X) is the primary information-gathering verb in parser IF. It asks the game to describe an object in more detail than the room description provides. The command produces no change in game state—it is pure observation. Its output ranges from a single dismissive sentence ("You see nothing special about the rock") to a paragraph that contains a crucial clue. Experienced players examine everything; the mechanism rewards thoroughness and punishes haste. Some games hide information behind multiple examinations of the same object, or behind examining a part of a previously examined thing.
EXAMPLE: > EXAMINE PAINTING THE SECOND EXAMINE REVEALS WHAT THE FIRST ONLY HINTED AT
A portrait of a stern woman. One corner of the frame is slightly crooked.
> EXAMINE FRAME
Behind the crooked frame, you notice a small lever.
The player converses with NPCs by typing ASK [CHARACTER] ABOUT [TOPIC] or TELL [CHARACTER] ABOUT [TOPIC]. The character responds (or doesn't) based on whether the topic is in their knowledge table. This model preserves the open-ended feel of the parser—the player must think of what to ask about rather than choose from a menu. It also means most topics produce a default shrug. The player is prospecting for the few keywords that produce real responses, which can feel like a conversation or like a guessing game depending on how well the author anticipated likely queries.
EXAMPLE: > ASK MERCHANT ABOUT SWORD "SWORD" IS IN THE MERCHANT'S TOPIC TABLE; "WEATHER" IS NOT
"Fine blade. Dwarven make. Three hundred gold."
> ASK MERCHANT ABOUT WEATHER
The merchant shrugs.
A branching menu of utterances: the NPC says something, and the player selects a response from a numbered or linked list. Common in choice-based IF and graphical RPGs that use IF-like conversation. The tree can be shallow (one exchange, then done) or deep (nested menus several layers in). Unlike ASK/TELL, the player never has to generate a topic—all options are visible. The design challenge is making the options feel meaningfully different rather than cosmetically varied paths to the same outcome.
EXAMPLE: "Why are you following me?" she asks. EACH OPTION LEADS TO A DIFFERENT BRANCH OF THE CONVERSATION; SOME MAY CLOSE OFF LATER OPTIONS
1. "I need your help."
2. "I'm not following you."
3. Say nothing.
> _
A middle ground between ASK/TELL and dialogue trees. The game presents a list of available topics ("You could ask about the war, the missing girl, or the old mine") and the player selects one. New topics unlock as the conversation progresses or as the player discovers information elsewhere. The mechanism gives structure to conversation without reducing it to a fixed tree—the set of available topics is itself dynamic, reflecting what the player knows and what the NPC is willing to discuss.
EXAMPLE: The inspector waits for your question. ASKING ABOUT ONE TOPIC UNLOCKS ANOTHER; THE CONVERSATION EVOLVES
Available topics: the body, the locked room, the missing key.
> ASK ABOUT THE BODY
"Found at dawn. No marks. The doctor says poison."
New topic available: the doctor.
The player attempts something and the game says no. "You can't go that way." "Violence isn't the answer to this one." "I don't think the duchess would appreciate that." Every refusal is an edge of the world model. The wording of the refusal matters: a generic "You can't do that" tells the player their action is outside the simulation. A specific "The door is nailed shut" tells them the action is recognized but blocked by a particular obstacle—potentially a solvable one. The character of a game is often best read through its refusals.
EXAMPLE: > BREAK WINDOW BOTH ARE REFUSALS, BUT THE SECOND IMPLIES A BOLT THAT MIGHT BE REMOVABLE
That would attract too much attention.
> TAKE PAINTING
It's bolted to the wall.
What the game says when it has nothing specific to say. "You see nothing special about the lamp." "That's not something you can take." Default responses mark the boundary between the implemented world and the unimplemented void. They are the system's admission that the player has reached an edge. In a well-implemented game, defaults are rare because the author anticipated most reasonable interactions. In a sparse one, defaults are everywhere, and the player quickly learns to read them as "stop looking here." The quality of default responses shapes how alive or hollow the world feels.
EXAMPLE: > EXAMINE CEILING THE FIRST TWO ARE DEFAULTS; THE THIRD IS IMPLEMENTED—THE DIFFERENCE TELLS THE PLAYER WHERE TO FOCUS
You see nothing special about the ceiling.
> EXAMINE WALLS
You see nothing special about the walls.
> EXAMINE FLOOR
Scratches in the stone suggest something heavy was dragged toward the east wall.
Answers to examples are in invisible ink after each question (highlight to reveal)
Like this