Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Systemize Targeting #203

Open
DavidRieman opened this issue Dec 7, 2024 · 0 comments
Open

Systemize Targeting #203

DavidRieman opened this issue Dec 7, 2024 · 0 comments
Labels
enhancement This task is adding new behavior or performing other refactoring improvements.

Comments

@DavidRieman
Copy link
Owner

DavidRieman commented Dec 7, 2024

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).
@DavidRieman DavidRieman added the enhancement This task is adding new behavior or performing other refactoring improvements. label Dec 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This task is adding new behavior or performing other refactoring improvements.
Projects
None yet
Development

No branches or pull requests

1 participant