Regarding giving complex instructions to an NPC, I find myself wondering if there are any parser games out there with support for writing multi-line scripts in-engine, so instead of entering a single command line with clunky syntax, you can present an NPC with a list of instructions written in a more natural language way.
Though for the OP example, I feel like the ideal situation would allow you to omit the get rock and the NPC would automatically grab the rock before putting it on the table and you would only need to specify getting the rock in situations where the stone isn’t somewhere the NPC is aware of or can’t just be picked up. Did interpret that complex command as being all for Bob.
I didn’t vote on comparison C because “JUMP THEN BOB, JUMP.” seems like such odd phrasing. If I had to try to come up with an interpretation that made sense, I guess I’d go with “Jump. Bob, jump.” (unless “bob” is also implemented as a verb, in which case it would be even more confusing), but would a player really type it that way and expect it to be understood? This feels like something you’d only type if you were trying to test the limits of the parser. I wouldn’t necessarily expect the parser to understand it.
Edited to add: It would seem natural to me to not allow separate instructions to the player character and to an NPC in the same sentence. There would need to be a “.” separating them so that it was clear which character you meant.
I’ve added some clarifying text to the initial post.
EDIT: Also, for these comparisons, the answer does not take the form of one version or the other, because the question is whether the two commands should be interpreted the same (i.e. result in the same sequence of actions) by an “ideal” (in your opinion) parser.
It seems as though there are some mutually exclusive principles at play. I’m curious about which options below are preferred in the abstract.
Principle 1 - Distinction between command delimiters
Which of the following is more aligned with your intuition about ideal behavior?
The word ‘THEN’ (or a semantic equivalent) should always be interpreted the same as a ‘.’ (period/full stop) under all circumstances. The parser should make no distinction between them whatsoever.
The word ‘THEN’ (or a semantic equivalent) should under some circumstances have different significance than a ‘.’ (period/full stop) in the same place.
(Something else not listed above.)
0voters
Principle 2 - Significance of command delimiters
(If you answered “make no distinction” for Principle 1, then skip this question.)
Which of the following is more aligned with your intuition about ideal behavior?
The word ‘THEN’ should always be interpreted as a delimiter of commands to act but should not change the actor being instructed. A ‘.’ (period/full stop) should always be interpreted as signalling a new actor being instructed, defaulting to the PC if not followed by a new NPC command preamble.
The word ‘THEN’ should always be interpreted as a delimiter of commands to act but should not change the actor being instructed. A ‘.’ (period/full stop) should be interpreted as signalling the possibility a new actor being instructed, defaulting to the previous actor context if not followed by a new NPC command preamble.
(Something else not listed above.)
0voters
Principle 3 - Interpretation of command preambles
Which of the following is more aligned with your intuition about ideal behavior?
An NPC command preamble must be given only at the start of the entire line of input, and all subsequent commands to act should be interpreted to be instructions to that NPC.
One more NPC command preambles can be given in a single line of input, with commands to act being considered as applying to the most recently specified NPC.
(Something else not listed above.)
0voters
Principle 4 - Action governance with respect to game time
Which of the following is more aligned with your intuition about ideal behavior?
If an actor is given multiple commands to act in the same line of input, that actor should take the same number of game turns to complete them as if individual commands to act were issued over multiple lines of input.
If an actor is given multiple commands to act in the same line of input, that actor should take a single turn to complete them all.
(Something else not listed above.)
0voters
Principle 5 - Parallel vs. linear interpretation
Which of the following is more aligned with your intuition about ideal behavior?
If multiple actors are given commands to act in the same line of command input, the parser should treat this as equivalent to a series of individual command lines, each with a single command to act directed to the applicable actor.
If multiple actors are given commands to act in the same line of command input, the parser should treat this as equivalent to issuing instructions to each actor simultaneously, such that responses to the command to act can be executed by multiple actors in parallel.
There’s a puzzle in Enchanter that relies on it. An NPC can go through a dangerous passage that you can’t, but the other end of the passage is full of noisy machinery, so they can’t hear you once they’ve gotten there. The solution is NPC, EAST. TAKE SCROLL. WEST.
And no, I never would have solved this without a walkthrough. I’m certain some implementor found a quirk in the parser and decided to turn it into a puzzle.
My take:
The word ‘THEN’ should always be interpreted as a delimiter of commands to act but should not change the actor being instructed. A ‘.’ (period/full stop) should be interpreted as resetting the actor to the PC unless it is followed by a new NPC command preamble.
Exception: If the game is such that the player needs to give multiple commands to an NPC in a row, there could possibly be special syntax to handle this, maybe specific to the game. For example:
The player types “Instruct Bob.” Every sentence and command after that is treated as if it begins with “Bob,” until the player types something that turns off this mode (like “Stop instructing Bob.”)
or
The player types “Bob:” (with a colon) and then every sentence after that is treated as if it begins with “Bob,” until the player hits enter/return, and at that point it resets the actor to the PC.
My take:
One or more NPC command preambles can be given in a single line of input, with commands to act applying to the NPC mentioned in the preamble to that particular sentence (sentences being separated by “.”) or, if there is no NPC preamble in that sentence, the command applies to the PC.
(This might be what you meant by option 2, though?)
I’m impressed by your dedication in trying to pin down the specifics of each player’s interpretation here. Just out of curiosity, is there a specific goal you’re doing this in pursuit of?
My own intuition is that THEN and . are different delimiters and can behave differently. But the prospect of explaining this to players feels like a UX catastrophe in the making.
If I were making a game where players need to think about this stuff, I would back up and redesign so that they don’t. (Yes, that means changing Enchanter.)
Certain programming issues that have caught my attention initially seemed very simple to “correct” but on closer study appear to revolve around questions like these, which are at least to some degree matters of opinion. In offline discussions, various viewpoints and associated models have been presented, each of which seems justifiable.
I was curious what the public sentiment would be regarding the underlying assumptions. My hope was that the data would show a strong enough preference for a consistent set of features provided by one or the other of the various models under discussion, or that it would point the way to something new.
It also seemed like it might be a topic of general interest. Right now I’m intrigued by the fact that there is so much variety in the responses.
I like parsers but instructing people in parsers sounds hellish. Glad I don’t play games that make me have to think about that.
Yeah imagine trying to explain these nuances to a newb. I would die. If you think your game needs this fiddly complexity no it doesn’t, or there’s a much better way to do it
That’s kinda what I’m working on. The idea being that instead of composing a single barrage of orders the player is essentially enumerating high-level goals or objectives, and the NPC AI takes care of assembling them into a plan of action.
Basically the way NPC behavior works is that every turn they evaluate a list of possible actions and pick one. They do this by sorting the list by numeric priority and picking the highest-priority action that’s marked as active for this turn.
Under the hood all NPCs have a basic set of activities “built-in”, like examining things, taking things, and moving to locations. Their numeric priorities rank those actions in that order. And (in general) they’re marked as active if there are objects in scope relevant to the task.
So if the player tells Alice to get a pizza, that pushes an “obtain a pizza” objective onto the stack. If Alice finds herself in a location where she can obtain the pizza, she’ll do so. If she’s not in a location where there’s a pizza available, she can path to the nearest location where she believes a pizza can be obtained. If she’s pathing to a place she expects to find a pizza and on the way sees a pizza, she’ll automagically attempt to obtain that pizza—because the “take an object” task has a higher priority than the “move to a location” task.
And if at the start of the task she doesn’t know where to find a pizza, if there’s a “request information” task whose priority is between that of the “take an object” and “move to a location” tasks, then she’ll ask the player (or possibly other NPCs) if they know where to obtain a pizza.
And so on. This is a trivial example, but the central idea is to build behaviors not by attempting to explicitly enumerate a step-by-step list of commands to be followed by rote, but instead by enumerating high-level objectives that can be broken down into “atomic” steps.
In general this makes complex tasks easier to script and makes them less brittle (by preventing transient interruptions from breaking the overall script).
In an idealized parser, I’d say, “Hey Bob, can you take the rock and put it on the table, and jump afterward?” and he’d reply, “Sure, Hidnook, I can do that. Do you want me to take the bucket, too, or try to take the rock without first taking the bucket?” and I’d respond, “Take the bucket with the rock, and hold on to the bucket. Can you take the apple from the table while you’re at it and drop it in the bucket?” and he’d do it.
In my opinion, the parallelism depends on the type of game: If it’s nothing timing sensitive, them I’m completely OK with a “then” relationship between the NPC commands for Alice and Bob. But e.g. if there was a fight or something, I’d like the commands to be interpreted in parallel.
It looks as though public intuition is running about 2 to 1 in favor of a generic default model in which:
a single command line can contain blocks of commands to multiple actors (including the PC)
command blocks to individual actors are extended via ‘THEN’ and separated by full stops
each individual command to act in a command line should be executed in linear sequence, as though an appropriate command for each had been entered on its own command line
each command to act takes a normal game turn to complete
Perhaps at this point it will become useful to start discussing how various actual languages/systems handle these matters. The only one that I’m qualified to speak about is Inform, but I would love to hear analyses of other systems.
In Inform (6M62, but I believe 10.1.2 is the same):
The word ‘THEN’ and a period/full stop are always considered identical in meaning.
Multi-part actions are handled one command to act at a time, each taking a game turn. (Multiple turns can elapse between command prompts.)
It is possible to issue commands to the PC followed by commands to a single NPC in the same command line, e.g. >JUMP THEN BOB, JUMP works as most people seem to expect (if they expect it would work at all).
It is not possible to issue commands to a single NPC followed by commands to any other actor in the same command line. An attempt to issue a later command to the PC will be interpreted as applying to the NPC, because periods/full stops carry no extra significance. An attempt to issue a later command to a second NPC will have a probably-unexpected result: conversion to an answering it that action containing the balance of the command line. For example, >BOB, JUMP. ALICE, JUMP. will cause 1) Bob jumping followed by 2) answering Bob that "Alice, jump.". (@jwalrus, FYI.)
With respect to @zarf’s point, it does not seem that Inform’s current handling is particularly easy to explain or understand.
I am very intrigued by the fact that the relative proportions of answers above suggest that a significant fraction of people intuit both that >BOB, TAKE ROCK. ALICE, TAKE APPLE. should result in simultaneous execution (i.e. both NPCs acting on the same turn) and also that >BOB, JUMP. JUMP. or >JUMP. BOB, JUMP. should result in sequential actions over two turns.
Am I reading the results correctly? Does someone who voted for both of those outcomes care to explain the reasoning?
Yeah imagine trying to explain these nuances to a newb. I would die. If you think your game needs this fiddly complexity no it doesn’t, or there’s a much better way to do it