I agree that a keyboard-only mode would be ideal, and what I was proposing was more or less an attempt to get a first step towards that.  The problem with using a key as the left mouse button is that that effectively would lock in that key as doing exactly what the left mouse button would do, which seems like a suboptimal way to operate.  Instead, it seems to me that we should split the two up, and in cases where it makes sense to have the key do the same thing as the left mouse button, then we can just have the game respond to both the left mouse button *and* the key, instead of a more hacky solution along the lines of making the key actually *cause* a mouse press.

In fact, now that I'm thinking about it, it occurs to me that putting the vector length thing in KeyboardHelper also seems logically wrong.  MouseHelper doesn't understand anything about what a mouse click *does* vis-a-vis game mechanics; all it does is report state, and then whoever cares about that state can react to it.  I think much better would be to just have a thing in KeyboardHelper saying things like "a directional key was pressed", or "the run key was pressed", or "the continue key was pressed", and then in Location it can figure out what to do about it.  Otherwise I feel like we set a bad precedent whereby actual game responses to keyboard input can start to become separated from the portions of the game engine that actually intend to respond to that input, which could create messy code that could be more difficult to maintain.

Personally, to sum up, I feel that the design should be changed in two ways:

1. KeyboardHelper should be modified such that it only keeps and can be queried for state, and have Location actually handle what to do about that state; and

2. KeyboardHelper should not be modifying the mouse state; instead, we should create a keyboard state that has a similar function to the left mouse button being clicked, and then places where we check for a mouse click should also check for that key being pressed, where it makes sense to do so.

This seems to me to have two primary benefits:

1. It maintains the segregation of user input with game responses to that input, resulting in more logical and maintainable code; and

2. It creates a framework by which additional keyboard input can begin to become supported in a fairly easy way - e.g., what if we wanted up and down key presses to select a conversation option?  As it is right now, that would be difficult, since the directional key presses are exposed as a movement vector, whereas if we just exposed state, then we could hook into that in the Encounter class if we know the player is using the keyboard and could respond to the keyboard state just the same as the way in which Location does to move the player character around.

Does this make sense?