We want players to be able to focus on gameplay and puzzle-solving, rather than being frustrated by a rigid command system. Our parser should be able to handle a variety of inputs to ensure a smooth user experience.
Goal
Intended output is an array of strings, ordered like so:
Rolling our own
It may be easier/more lightweight for us to create our own POS tagger from scratch. One benefit is that we can distill tagging categories to just what we need to separate wheat from chaff in our context.
Step 1: ID tags and build lexicon
POS
tag
examples
Action
ACT
use, look, take
Item
ITM
key, table, door
Particle
PRT
at, on, with
[x] Lexicon for "actions" includes aliases
[x] Particles can be used to determine targets from other objects. this ended up working inconsistently and being kind of extraneous anyway; attaching expected object-target ordering to a given action verb works better for MVP purposes
[x] Irrelevant text (anything not defined in the lexicon) can be disregarded.
Step 2: build out tokenizer and functions to tag tokens based on lexicon
[x] tokenizer
[x] tagger
[x] alias parsing
Step 3: create rulesets & functions to separate object/target, etc.
[x] determine target item vs object item based on position relative to particle expected ordering of items for a given action verb
[x] create response object to feed into parser
[x] flag inappropriate command structures (ex. more than two items, more than one action, etc.) for error feedback to user -- added a couple of basic things, will probably expand in separate card
Step 4: unit test and integrate
[x] implement remaining actions/aliases into lexicon
[x] lexicon for "items" pulls names directly from Mongo docs for items not strictly necessary, prob going to make a separate card for the stretchy stretch
We want players to be able to focus on gameplay and puzzle-solving, rather than being frustrated by a rigid command system. Our parser should be able to handle a variety of inputs to ensure a smooth user experience.
Goal Intended output is an array of strings, ordered like so:
Variable inputs with the same intent should consistently reproduce the same output (and, therefore, the same behavior from the game).
Considerations
Example edge cases base command: use key door
Resources Natural NLP -- supports POS tagging
Rolling our own It may be easier/more lightweight for us to create our own POS tagger from scratch. One benefit is that we can distill tagging categories to just what we need to separate wheat from chaff in our context.
Step 1: ID tags and build lexicon
[x] Lexicon for "actions" includes aliases
[x]
Particles can be used to determine targets from other objects.this ended up working inconsistently and being kind of extraneous anyway; attaching expected object-target ordering to a given action verb works better for MVP purposes[x] Irrelevant text (anything not defined in the lexicon) can be disregarded.
Step 2: build out tokenizer and functions to tag tokens based on lexicon
[x] tokenizer
[x] tagger
[x] alias parsing
Step 3: create rulesets & functions to separate object/target, etc.
[x] determine target item vs object item based on
position relative to particleexpected ordering of items for a given action verb[x] create response object to feed into parser
[x] flag inappropriate command structures (ex. more than two items, more than one action, etc.) for error feedback to user -- added a couple of basic things, will probably expand in separate card
Step 4: unit test and integrate
[x] implement remaining actions/aliases into lexicon
[x]
lexicon for "items" pulls names directly from Mongo docs for itemsnot strictly necessary, prob going to make a separate card for the stretchy stretch[x] build out tests for each action type