Command failure customization suggestion

[Omikhleia]

It came to my notice that the "I didn't understand that." message when a command failed is located in player-controller.js (where all command processing is currently done).

It is thus the only "in-game" message (excepting internal errors, that's obvious and ok) that cannot be customized.

There's however more that could be done, depending on the user input, e.g. checking if objects were matched despite no verb being found, or checking if an ambiguous result was met, for suggesting help, etc.

I have first considered adding a onPlayerCommandFailed() hook on the 'system' object, with the current "hard-coded" message being used only if the hook doesn't exist. This does work on my testing code base, allowing for more precise messages and game-specific decision on what to do, so it's pretty cool, IMHO.

Nevertheless, I wonder whether a yet better approach / a step further woudn't be to also have the whole verb execution logic from player-controller.js moved to world-object-proxy-builder.js.

It would thus be exposed to the in-game context (after all, as are, already the matchObjects() and matchVerb() methods).

Two example use cases for this:

• A testing item with a "use to force to " command, which requires parsing and executing on the target.
• A sales room location supporting the verbMissing property and delegating commands to appropriate NPCs, if present (with the room not knowing which commands are available).
  To achieve this so far in my world demo/testing code, in both cases I've just ended up replicating almost(*) exactly what player-controller.js does in its runCommand() method, so there could be an interest having the whole verb execution logic available for use in-game.

(*) "almost" : the command dispatching for the NPC doesn't test for verbMissing, obviously, or there could be an infinite loop.

[doughsay]

You've partially solved this, but I agree with your second point at the end. I'd like to try and move more of the player command parsing completely into the game world, rather than have the engine be solely responsible for it. Let's leave this issue open a little longer as a reminder...

[doughsay]

closing in favor of #144