Vespers3D: The Adventure of Text Parsing
by Rubes · 03/09/2006 (11:32 am) · 21 comments
The Adventure of Text Parsing in TGE
When I decided to incorporate text parsing into a 3D FPS game, I soon realized that one of the most challenging tasks was going to be determining all of the different ways commands could be entered by the player. In a pure text game, except in certain situations, each command needs to explicitly state direct and indirect objects:
But a 3D game provides something that text games generally lack: visual and spatial reference. And since I have also incorporated object selection into the game, players can also provide an "unstated" reference to specific objects in the game world. Together, these make for some new ways of interacting with objects in the game world, along with interesting new challenges for a parsing engine.
For instance, in the text version of Vespers (the game upon which I am basing this 3D/IF experiment), there is an alms box in the entrance hall of the monastery with which the player can interact. Of course, there's not much you can do with it besides the following:
However, in the 3D version of this game, these actions must all be able to be done from a variety of player perspectives. For instance, a player might walk up to the alms box, such that it's directly in front of him, and want to examine it. How might this be done? Cue the imagery!
1. Just by typing "EXAMINE ALMS BOX". Of course, most players won't know what the alms box is just by seeing it in the game, since there is no elaborate room description (like in the text version), which alerts the player to the presence of an "alms box".
2. By typing "EXAMINE IT" without selecting anything. After all, the player has walked right in front of an object worth examining, should we always force him to select the object first? In this case, the engine has to look in front of the player for an object that would appropriately substitute for "IT".
3. By clicking on the alms box (to select it) and typing "EXAMINE" (or "EXAMINE IT"). In this case, the engine has to see that the EXAMINE command has no object (or just the pronoun IT) and know that he is referring to the object that is currently selected.
4. By clicking on the alms box (to select it) and clicking the right mouse button. The right mouse button can be set to any of a number of different verbs (like EXAMINE or TAKE), so clicking the right mouse button needs to trigger the entry of a command (in this case, EXAMINE) linked to the currently selected object (in this case, the alms box). The text command EXAMINE ALMS BOX is then created and sent to the parser.
(Note how the alms box becomes highlighted when it becomes the "selected object" -- thanks to John and TLK for that nice implementation.)
And the same, of course, is true for the rest of the commands that can be performed on the alms box. What was a relatively simple implementation in a text game (EXAMINE ALMS BOX or EXAMINE IT) becomes a bit more challenging in the 3D world to accommodate the different approaches that players might expect in this setting.
This then becomes slightly more challenging for verbs that require both direct and indirect objects, like the UNLOCK CHEST WITH RED KEY command above. If the player has the red key in his inventory and walks right up to the chest, it should probably be expected that he can type "UNLOCK WITH RED KEY" and be assured that the engine knows he wants to unlock the chest with the red key. But since the direct object is missing from the command, it has to know that it must search for an object to insert into the command structure. These are the kinds of things that have kept me up nights.
But visual and spatial referencing introduces a new little twist to text commands. Should players be allowed to perform actions on objects without actually facing them? What if a player walks right in front of that alms box, turns around 180 degrees, and types "OPEN ALMS BOX"? Do we allow that? Technically speaking, we shouldn't, but will this frustrate players if they get a message back saying "You need to be facing the alms box to do that"? My belief is that players would probably prefer the consistency of a world that requires you to face objects you want to interact with...but that now means that most verbs that perform actions on objects now need to perform these multiple checks on the object before carrying out the action:
- Is the object close enough to the player to allow the action? Players shouldn't be able to perform some actions on objects that are visible, but too far away.
- Is the object actually in the player's line-of-sight? Players shouldn't be able to perform an action on an object if there is a wall, pillar, whatever between them and the object.
- Is the object within the player's field of view? Players shouldn't be able to perform actions on obejcts that they are not able to "see".
Of course, none of these are issues that need to be dealt with in text IF, since visual and spatial referencing never really comes into play (except perhaps for things like objects contained within other objects).
But that brings up another important issue. What about objects that don't exist in the game world as individual models, or things that can't easily be selected? Things like:
- parts of a room (floor, walls, window, etc)
- non-selectable scenery objects (snow, etc)
- sub-objects of other selectable objects (eyes or skin of individuals, etc)
- "game" objects (like "game" in "save game")
These have to be implemented as "nouns", just like selectable objects, but they need to be handled differently by the parser since they can't be selected. I ended up using the basic scriptable simobject resource for these, so they can exist as script objects like regular nouns without being associated with DTS models. Instead of regular nouns, I call these noun objects "floating nouns". So the engine now knows when it's dealing with a noun that's not associated with a world model, and deals with it appropriately.
Then, of course, are all of the little (but not really so little) features of text parsing that seem simple enough but cause all sorts of havoc when you try to implement them:
- pronouns (IT, HIM, HER, THEM)
- possessives (HIS, HER -- also a pronoun, ITS, THEIR)
- numbers (splitting or grouping objects into different numbered groups is a beast)
- disambiguation ("Which key did you mean, the blue key or the red key?")
- multiple commands (TAKE KEY AND UNLOCK CHEST WITH IT).
Pronouns are now implemented, and possessives are not far behind. Fortunately, in the text version of Vespers there are no situations where numbers are needed, so that can safely be put off indefinitely. As for disambiguation and multiple commands, well, those are a little trickier. I'll probably have to implement disambiguation since it's such a widely accepted feature of text parsing engines. Multiple commands can be a real pain, but fortunately my understanding is that this is not widely used in the text IF world, so its absence would probably not be felt.
So I'm happy to say that most of the text parsing engine is actually done and is working pretty well. All it really needs now is implementation of actual game objects. Most verbs in the game pass the action to be performed to the object itself, so that each game object can determine the result of an action performed on it.
So I'm excited that, now that the meat of the text parser is done, I can get to work making Vespers3D actually look and feel like Vespers. Now we're talking.
When I decided to incorporate text parsing into a 3D FPS game, I soon realized that one of the most challenging tasks was going to be determining all of the different ways commands could be entered by the player. In a pure text game, except in certain situations, each command needs to explicitly state direct and indirect objects:
> READ BOOK or > UNLOCK CHEST WITH RED KEY
But a 3D game provides something that text games generally lack: visual and spatial reference. And since I have also incorporated object selection into the game, players can also provide an "unstated" reference to specific objects in the game world. Together, these make for some new ways of interacting with objects in the game world, along with interesting new challenges for a parsing engine.
For instance, in the text version of Vespers (the game upon which I am basing this 3D/IF experiment), there is an alms box in the entrance hall of the monastery with which the player can interact. Of course, there's not much you can do with it besides the following:
The alms box hangs closed beside the door. >EXAMINE ALMS BOX It used to be filled with alms. Now, mostly cobwebs. >SEARCH ALMS BOX You can't see inside, since the alms box is closed. >OPEN ALMS BOX A single coin sparkles at you from the bottom. >CLOSE IT You close the alms box.
However, in the 3D version of this game, these actions must all be able to be done from a variety of player perspectives. For instance, a player might walk up to the alms box, such that it's directly in front of him, and want to examine it. How might this be done? Cue the imagery!
1. Just by typing "EXAMINE ALMS BOX". Of course, most players won't know what the alms box is just by seeing it in the game, since there is no elaborate room description (like in the text version), which alerts the player to the presence of an "alms box".
2. By typing "EXAMINE IT" without selecting anything. After all, the player has walked right in front of an object worth examining, should we always force him to select the object first? In this case, the engine has to look in front of the player for an object that would appropriately substitute for "IT".
3. By clicking on the alms box (to select it) and typing "EXAMINE" (or "EXAMINE IT"). In this case, the engine has to see that the EXAMINE command has no object (or just the pronoun IT) and know that he is referring to the object that is currently selected.
4. By clicking on the alms box (to select it) and clicking the right mouse button. The right mouse button can be set to any of a number of different verbs (like EXAMINE or TAKE), so clicking the right mouse button needs to trigger the entry of a command (in this case, EXAMINE) linked to the currently selected object (in this case, the alms box). The text command EXAMINE ALMS BOX is then created and sent to the parser.
(Note how the alms box becomes highlighted when it becomes the "selected object" -- thanks to John and TLK for that nice implementation.)
And the same, of course, is true for the rest of the commands that can be performed on the alms box. What was a relatively simple implementation in a text game (EXAMINE ALMS BOX or EXAMINE IT) becomes a bit more challenging in the 3D world to accommodate the different approaches that players might expect in this setting.
This then becomes slightly more challenging for verbs that require both direct and indirect objects, like the UNLOCK CHEST WITH RED KEY command above. If the player has the red key in his inventory and walks right up to the chest, it should probably be expected that he can type "UNLOCK WITH RED KEY" and be assured that the engine knows he wants to unlock the chest with the red key. But since the direct object is missing from the command, it has to know that it must search for an object to insert into the command structure. These are the kinds of things that have kept me up nights.
But visual and spatial referencing introduces a new little twist to text commands. Should players be allowed to perform actions on objects without actually facing them? What if a player walks right in front of that alms box, turns around 180 degrees, and types "OPEN ALMS BOX"? Do we allow that? Technically speaking, we shouldn't, but will this frustrate players if they get a message back saying "You need to be facing the alms box to do that"? My belief is that players would probably prefer the consistency of a world that requires you to face objects you want to interact with...but that now means that most verbs that perform actions on objects now need to perform these multiple checks on the object before carrying out the action:
- Is the object close enough to the player to allow the action? Players shouldn't be able to perform some actions on objects that are visible, but too far away.
- Is the object actually in the player's line-of-sight? Players shouldn't be able to perform an action on an object if there is a wall, pillar, whatever between them and the object.
- Is the object within the player's field of view? Players shouldn't be able to perform actions on obejcts that they are not able to "see".
Of course, none of these are issues that need to be dealt with in text IF, since visual and spatial referencing never really comes into play (except perhaps for things like objects contained within other objects).
But that brings up another important issue. What about objects that don't exist in the game world as individual models, or things that can't easily be selected? Things like:
- parts of a room (floor, walls, window, etc)
- non-selectable scenery objects (snow, etc)
- sub-objects of other selectable objects (eyes or skin of individuals, etc)
- "game" objects (like "game" in "save game")
These have to be implemented as "nouns", just like selectable objects, but they need to be handled differently by the parser since they can't be selected. I ended up using the basic scriptable simobject resource for these, so they can exist as script objects like regular nouns without being associated with DTS models. Instead of regular nouns, I call these noun objects "floating nouns". So the engine now knows when it's dealing with a noun that's not associated with a world model, and deals with it appropriately.
Then, of course, are all of the little (but not really so little) features of text parsing that seem simple enough but cause all sorts of havoc when you try to implement them:
- pronouns (IT, HIM, HER, THEM)
- possessives (HIS, HER -- also a pronoun, ITS, THEIR)
- numbers (splitting or grouping objects into different numbered groups is a beast)
- disambiguation ("Which key did you mean, the blue key or the red key?")
- multiple commands (TAKE KEY AND UNLOCK CHEST WITH IT).
Pronouns are now implemented, and possessives are not far behind. Fortunately, in the text version of Vespers there are no situations where numbers are needed, so that can safely be put off indefinitely. As for disambiguation and multiple commands, well, those are a little trickier. I'll probably have to implement disambiguation since it's such a widely accepted feature of text parsing engines. Multiple commands can be a real pain, but fortunately my understanding is that this is not widely used in the text IF world, so its absence would probably not be felt.
So I'm happy to say that most of the text parsing engine is actually done and is working pretty well. All it really needs now is implementation of actual game objects. Most verbs in the game pass the action to be performed to the object itself, so that each game object can determine the result of an action performed on it.
So I'm excited that, now that the meat of the text parser is done, I can get to work making Vespers3D actually look and feel like Vespers. Now we're talking.
Torque 3D Owner Rubes
Good luck!