In a concept I'm working on, the player can move from one position in a grid to the next. Once movement starts it can't be changed and takes a predetermined amount of time to finish (about a quarter of a second).

Even though their movement can't be altered, the player can still press keys (perhaps in anticipation of their next move). What do I do with this input?

Possibilities i've thought of:

  • Ignore all input during movement.
  • Log all input and loop through them one by one once movement finishes.
  • Log the first or last input and move when possible.

I'm not really sure which is the most appropriate or most natural. Hence my question:

What do I do with player-input during movement?

  • 1
    \$\begingroup\$ Seem that anything other than ignoring the input would cause really weird/unexpected behavior if the user were to spam button during the animation. \$\endgroup\$ – ClassicThunder Aug 21 '14 at 20:29

Reaction to your proposed methods:

  • valid choice, but your the controls may feel unresponsive - player has to wait before he can do next step.
  • Imagine what would happend if he smashed the keyboard(cat walked over it): half a hour of uninterruptable random movement.
  • Sound ideal, doesnt it? Controls are responsive and no trips all over map are included. You are probably best with the last input. I would probably choose this as a player.

It all comes down to your very own game/project AND playtest results.

If your game mechanics aren't strictly affected by this, ignoring input would be the best solution in terms of Occam's razor: "the simplest solution is probably the best one".

However, evaluate your game mechanics and If you're able to develop the three approaches, run a playtest process to each one, see the reactions, ask questions to your players and see the results.


If your game is real-time:

You should make sure that as soon as a movement is completed, if a key is currently pressed, the character will immediately start moving in that direction. This ensures that the game does not require the player to have exact keypress timing to move efficiently, which in my experience is very frustrating.

There are two possible ways to do this:

  1. Any time there is no movement in progress, check the movement keys' state and start another movement if one is down. (If you only have key events, then remember the last one seen for a movement key.)

    This is sort of like "ignoring input", but note that it will not ignore a key which was pressed before movement finished but is still down when it does finish.

  2. Any time a movement key is pressed, remember its direction. Any time there is no movement in progress, use the single recorded keypress to start a new movement.

The difference between these two cases is whether a key which is pressed and released before movement becomes possible will still cause another movement. I recommend trying both to see which feels better.

If your game is turn-based:

I recommend, for turn-based games, that you take your second approach: use all the keypresses you got, in sequence. Furthermore, if you have keypresses buffered like this, speed up your animations. This allows the player to quickly move through parts of the game they're replaying without it getting tedious.

If it is infeasible to speed up the game when there is buffered input, then you should either ignore input or buffer exactly one keypress (first or last doesn't matter much).


Process the input immediately. Start the animation and ignore further input for gameplay-affecting commands (but let the player inspect objects or do other things that aren't gameplay commands). Once the animation is complete (if it ends abruptly and has a clear point) or nearly complete (if it has a "softer" ending), allow new inputs.

Also be absolutely sure to communicate the input state to the user via the UI. If a button can't be clicked, draw it differently to signify this. Change the mouse cursor. Highlight objects when moused over differently. Make it very, very clear when you are ready to accept new input and when you aren't. 100% absolutely unquestionable clear.

You want to accept new commands in a timely manner but not absurdly early. e.g., if a character is animating movement along 12 steps, accepting new input as the animation is completing the last step may be acceptable. Better to just have a clear animation (and a clear UI) so the player knows when to enter more input.


Logging all user input for movement could create problems. An easy work around to that problem would be to put a cap and simply stop logging input if there is too many logged already.

However, I would simply ignore input while they are moving, or just ignore the input oof certain keys.

  • \$\begingroup\$ Logging all users input is not such a big deal, since it gets discarded as soon as it is processed. For that specific scenario, what might be a problem is that if processing can not keep up with speed of new input coming. \$\endgroup\$ – Kromster Aug 22 '14 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.