You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A lot of commands will target something / someone / etc. That is, to find a given mob, and/or item, and/or exit, and/or furnishing, and/or player... We also want to have target disambiguation systems as per our World Interaction user journey design doc. So, we want any given command that expects a target to have a reusable way to decide which things are potential targets for the command. From there, a command could proceed automatically if there was only one high-probability target, else defer to the target disambiguation process.
We'll need to start with thinking deeply on the architecture that will set this up. Then build it and adjust the few stock commands we have (like examining things) to use the system. Some considerations to have in mind:
Multiple words may be used for targeting and may strengthen towards a single match, e.g. "get short sword" may help reduce to a single target).
Resolved target lists if they don't result in a command that runs, will probably store those target options to the user connection (replacing any previous target disambiguation list, if any).
Numeric targets can probably assume to resolve via the target disambiguation list (if any), e.g. "drop 2" may use the slot 2 from the last disambiguation list to try to drop a thing.
Resolving a target may have additional requirements like "must be in the user's current room", "must be in the user's inventory", etc.
A saved target list may have a target become invalid since saving. E.G. the mob might have moved or died, the player may have moved from the room, the item has disintegrated or been stolen, etc. The system should probably be designed so that the saved targets are weak references, and should be designed so that the target numbers do not change if any others become invalid: They're meant to be stable no matter what. But the command should fail if the target is no longer valid.
Want to think about the priority order and how to customize that per command; is it separate API or some argument to customize things? e.g. Some commands may favor things on the ground in the room over the player's inventory, mobs over players, etc. But probably usually if there are multiple valid targets we may want to shift to target disambiguation.
A MUD admin might prefer to not use a target disambiguation at all (favoring the commands just always auto-target the single most likely / first target). Ideally we could rig such decisions globally (perhaps checking an app.config setting in the global targeting system code) without having to then adjust all commands!
We'll want the system to be expandable with future improvements (e.g. "targeting pronouns" and "ordinal numeral targeting" will be tracked as a separate linked stories depending on this one).
The text was updated successfully, but these errors were encountered:
A lot of commands will target something / someone / etc. That is, to find a given mob, and/or item, and/or exit, and/or furnishing, and/or player... We also want to have target disambiguation systems as per our World Interaction user journey design doc. So, we want any given command that expects a target to have a reusable way to decide which things are potential targets for the command. From there, a command could proceed automatically if there was only one high-probability target, else defer to the target disambiguation process.
We'll need to start with thinking deeply on the architecture that will set this up. Then build it and adjust the few stock commands we have (like examining things) to use the system. Some considerations to have in mind:
The text was updated successfully, but these errors were encountered: