So I was not sure how to structure this title, feel free to edit it.

My question is: When I have a Game Loop, I have 3 main blocks. Handle Events, Update game state, and draw. Let's say for example I check for keyboard/mouse events, and I want to move my character when buttons are pressed. Whenever KEYDOWN event occurs, should I immediately call Player.move? Or should I toggle move_left/move_right bools, and then call Player.move when I'm in the Update game state block.

I was wondering this becouse, for example a function performs a long algorithm and I call it when an event occur's, calling the function will take some time, and meanwhile I might press more button's/events. I think I will lose some of those events becouse in that time the algirthm function was runing.

Or, I can toggle a bool when the event occurs, and after checking for ALL events, I perform functions based on the bools.

PS: Feel free to edit this post in a more constructive question.

3 Answers 3


Well, simply put:

  • if you go with the "toggle booleans" way you risk "losing" user inputs. The user will sometimes click 3 times in order for his click to be "acknowledged" by such an input handling mechanism. For something like a fighting games which supports combos and such the effect would be very pronounced.

  • if you do something where the input event handler alters your game state directly (ignoring the game loop) is bad for several reasons: your code will no longer be nicely separated; even though technically there's no user input event that is skipped it mays STILL look like that to the human player as some input state changes can happen so fast the graphics rendering doesn't take them into account (imagine a red-blue, fast-blinking light, which changes color when the player pushes a button)

  • using an input queue is probablly the best way to go. Something like:

    function processInput() {
       while(!inputEventsQueue.isEmpty()) {
            //you may decide to cap the maximum number of events delt with in one step
            InputEvent e = inputEventsQueue.pop();
            for(Entity e:gameEntities) {

    //game loop
    while(...) { processInput(); updateState(); updateGraphics(); }


You must not skip valid user inputs. If your game function is supposed to respond to a single input, then you have no choice but responding to that input immediately. You can queue user inputs and play them in sequence as soon as you can. This would work when you are playing a single player game. Another option is to lock the input device (keyboard, etc.) until the function is processed after indicating that the system is processing the previous input. In all cases, try to optimize the long running function. Chances are with today's computers, you can do that with some work.


It depends on the type of game you are making.

For an FPS you want to respond to what the user is doing right this second. In such a case yes I would process all events and determine what the user is doing right now. Then do that in the update function.

For an RTS the meaning of current input depends on previous input. Skipping to only track the last action would royally screw stuff up. i.e. Select unit 1, attack unit 3, select unit 2, attack unit 4, drop the select unit 2 because it wasn't the last action on the event queue, now unit 1 is attacking unit 4, unit 2 isn't doing anything, unit 3 is still alive and not engaged.

For your game what would dropping input mean? It could mean your game stays responsive even if the frame rate stutters. It could mean you screw up input state because one event depends on an earlier event in the stream.

  • Even for FPS this may not work. Input which involves holding down a key/button would be ok, but stuff like the user tapping the grenade button real quick 3 times in a row might result in between 1 and 3 grenaded being thrown, as one or two of the key up envents might register without the corresponding keydown events, so the game logic cannot know how many times the key was up. Oct 8, 2013 at 13:22
  • @ShivanDragon I can't think of a FPS in existence that allows you to throw more than one grenade per frame(or perform any action multiple times in one frame really.) So using an event queue to implement keystate checking isn't going to hurt anything in practice.
    – stonemetal
    Oct 8, 2013 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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