Analytical Perspectives in Game Design
Text processing scenario
[ Home ] [ Up ] [ Game initialisation scenarios ] [ Text processing scenario ]

This scenario describes the process undertaken when a line of text is entered into the computer. The data is processed in batch. (That is a person types in the line of text, visually checks it, and then hits the enter key. No processing is performed until the enter key is pressed.)

preconditions:

1. input text string
2. enter key pressed (enter key pressed event fired)

Examples:

In this example: the user enters a command that is ambiguous. The system responds to clarify the command. The user makes a clarification and the system applies the command.

In the scenario: the user wants to push the large red suitcase against the door to stop it from being opened from the other side. There is also a small blue suitcase in the room.

At the user interface the interaction looks like this:

1. User: Push the port against the door.
2. Computer: Which port (the big, red one or the little, blue one)?
3. User: The red one.
4. Computer: Moving the red port. --> the description of the room is subsequently updated.

Step 1: command parser objectifies the input string. The command parser takes the string "Push the port against the door." and converts it into a set of equivalent objects. [I] [push] [by my self] [port] [against] [door]. Note that the system is presumed to use the personal I when there is an ambiguity as to who is to perform an action.

Step 2: cultural effects applicator removes cultural effects from the input objects. The cultural effects filter changes the objects from an external, culturally keyed view to the internal game representation. In this case, the program converts the item port to suitcase. We now have [I] [push] [by my self] [suitcase] [to] [door].

Step 3: environmental effects filter applies environmental effects to the input objects. In this case there are no environmental effect to be applied to the input objects are passed on, unmodified.

Step 4: command analyser converts the input objects into a command object. This analyser creates a command object. The command object is: Object(I) > [command: push] > Object[#suitcase] > [command: to destination] > Object(#door). (#suitcase, symbolises a category, not a specific thing)

Conundrum: The user has not specified which suitcase. Should the game just push the nearest, or should it clarify? I have assumed it should clarify. There are no good reasons for this decision.

Step 5: game core responds to command object. The game object "I" (actually the player thing) attempts to process the command push: #suitcase only to discover that, in the current context, there are 2 suitcases. It parses the suitcases to determine the differentiating characteristics and fires a request to the object view to handle this new request. The new request is: Request ([clarification], [#suitcase], [[red|blue],[big|small]],Command (Object(I) > [command: push] > Object[#suitcase] > [command: to destination] > Object(#door))).

Step 6: object view generates output objects. The object view converts the internal, command based, representation into an object representation. [clarify] [#suitcase] [big, red|blue, small] [*predecessor is [I] [push] [by my self] [$insert] [suitcase] [to] [door]].

Step 7: environmental effects filter applies environmental effects to output objects. There are no environmental effects to make a modification, so the output objects are passed on unmodified.

Step 8: cultural effects filter applies cultural effect to output objects. The cultural effects filter changes the output objects from the internal representation, to the external, culturally keyed representation. The request is now: [clarify] [#port] [big, red|blue, small] [*predecessor is [I] [push] [by my self] [$insert] [suitcase] [against] [door]]

Step 9: lexical view generator converts the output objects into output strings. The internal object representation is changes into a string representation: The request is now: [clarify] [big, red port] [or] [blue, small port] [*predecessor is [I] [push] [by my self] [$insert] [suitcase] [to] [door]].

Step 10: textual view generator converts the output strings into an output string. The textual view generator sends an English formatted output string to the string display device and primes the input string device with the predecessor command. The output string is "Which port (the big, red one or the little, blue one)?". The input command device receives [clarify] [big, red port] [or] [blue, small port] [*predecessor is [I] [push] [by my self] [$insert] [suitcase] [to] [door]].

Step 11: player enters a new response. The player at this stage could enter a string that is an answer to the question, a string that is rather ambiguous or enter some completely different response. If the player enters a completely different response, then the command set is dropped and a new command processing sequence is initiated. If the command response is ambiguous, say "the small red port", then the processor should request further clarification. If the response is one of the choices, then the processing is to insert the solution into the command string sequence. If the user types "the red one" this results in the new command [I] [push] [by my self] [red] [port] [against] [door].

Step 12: Steps 2 to 4 above are reprocessed. This results in the new command set Object(I) > [command: push] > Object[#suitcase(red)] > [command: to destination] > Object(#door).

Step 13: game core responds to command object. The game object "I" (actually the player thing) attempts to process the command push. This time the suite case is suitably clarifiable by the adjective red. The game core now executes the command push. This checks that a suitable path exists from the current location to the new location and, assuming that there is, modifies the location attribute of the containership of the suite case within the room to reflect the changes.

Step 14: game core fires a change event to the viewer. The attribute change is advertised to the view generator. The view generator creates a view update string from the change. [update view] [#suitcase(red,large)] [#moved] [near #door]

Step 15: environmental effects filter applies environmental effects to output objects. There are no environmental effects to make a modification, so the output objects are passed on unmodified.

Step 16: cultural effects filter applies cultural effect to output objects. The cultural effects filter changes the output objects from the internal representation, to the external, culturally keyed representation. The request is now: [update view] [port(red,large)] [moved] [near door].

Step 17: lexical view generator converts the output objects into output strings. The internal object representation is changes into a string representation: The request is now: [update view] [red large port] [has moved] [to] [near door]

Step 18: textual view generator converts the output strings into an output string. The textual view generator sends an English formatted output string to the string display device and primes the input string device with the predecessor command. The output string is "The large red port has moved to near the door.".

Things to do:

• The command parser needs to hand out command IDs. This would allow the user to press escape and have the command abort. Presuming that it has not already been processed beyond the stage where it cannot be aborted. This stage is when the command has hit the command core. If the command requires clarification, then the view generator can abort the action.
• The steps 14 to 18 should really say who moved the port. It should also derive a different string depending on if it is "I" who moved the port or some-one-else.

21/11/99

See also: [Role Playing Games] [Game Engine]
© 1998, 1999 Brian Yap. These pages are available under the GNU licence.