In probably every game a developer has to somehow deal with input, may it be simple keyboard and mouse events, touch events or something as accelerometer input. This input directly of indirectly effects objects in the game. Sometimes the same input can effect diffent objects. Now I've been thinking about how to model this. The way I see it there are two different approaches.

  • Let the game object itself handle it, subscribe to the events and call it's own methods. This has the advantage of letting the game-objects themselves decide which inputs cause which action. A disadvantage seems to be that the input code gets mangled with the "core" game object code. Also the game objects are unaware of the state of the rest of the game, and should sometimes maybe not act upon input events. This doesn't seem right.

  • Have a general input-controller take care of all the input and make decisions about who gets to handle what event. This seems to separate concerns better, but tighly couples the input-controller class to the game-objects. It somehow need to know who wants to receive which event and in which state. This doesn't seem right either.

What strategies are you using to handle this?


3 Answers 3


I recommend separating input events from game objects so you can quickly change/upgrade input methodologies without having to edit and debug 10 object classes. Examples being shifting over from keyboard-only controls to mouse+keyboard, or simply reassigning keys.

Instead of tightly coupling input to the individual game objects, call only one method per unique input signal on the game object, and let it decide the way to execute it.

Use an input controller to keep track of input state:

Up press event   -> dir = up
Down press event -> dir = down

Whenever input state changes, evaluate if game objects are ready to be modified:

set dir  ->  if gamestate != paused && battlemode == false
             ->  character.changeDir(dir);

Implement general methods on your game objects, that can be called by the input controller, or other game objects, as needed:

changeDir (dir)
setSpeed (walk/run)

I recommend the MVC approach. In MVC the game objects only have to worry about modeling the game system, and provide a high level interface like move_left. Then have a controller object that worries about mapping input to model calls. Not only does it allow for easy change of controls, it gives a good interface for AI they are just another controller.

In your second option I would split up the input-controller in to two parts, one that handles the actual device touch, keyboard, accel, whatever else you can throw at it, have it map them into a generic set of inputs. Then have a second part that maps generic inputs to game specific inputs. Say the keyboards up arrow maps to input1 then touching the top of a touch screen also maps to input1 as well now you write a second piece that maps input 1 to jump. You can now map any IO device as well as stored playback or AI inputs to this generic input system and have a small game specific part that loads what input1 one means to the model.

  • 5
    \$\begingroup\$ There's plenty of discussion elsewhere on this site about why MVC is generally not an appropriate pattern for games; what stonemetal describes isn't even MVC, it's just abstraction; and "Use MVC" is not an answer, since MVC is a description of a whole class of architectures and not a particular way to separate concerns (nor the only way to do it). \$\endgroup\$
    – user744
    Nov 18, 2010 at 19:06
  • 2
    \$\begingroup\$ MVC should give him A) a wikipedia article to read B) a number of variations on how to approach the solution that have been shown to work C) I mention the way I would set it up where the model exposes a high level interface that the controller maps low level input(real or synthetic) to high level action and directly manipulates the model rather than some eventing system. \$\endgroup\$
    – stonemetal
    Nov 18, 2010 at 19:21

I would suggest to make your game (the Model) define a list of possible input events (implemented as enums or objects with a base interface in common). Things such as MovingRightStarted, MovingRightStopped, FiredWeapon1, Escape, etc ...

The game defines a data structure (for instance a queue) that your input code (the Controller) can fill with input events.

Then your game can poll the data structure to get the input events.

This way, you can plug different kind of controllers to feed the model:

  • Keyboard only
  • Keyboard + Mouse
  • Joystick
  • Touchscreen
  • Artificial Intelligence

You just have them to push input events to the model.

  • \$\begingroup\$ I think I understand what you mean, except for you choice of a queue as datatype to store this. Could you explain why? \$\endgroup\$ Nov 19, 2010 at 9:04
  • \$\begingroup\$ Well between 2 input event polling from the model, the controller may have pushed several action events, and it's important to keep the order of user input. That's why I chose a FIFO data structure. Actually you may also need to specify at what exact time the input happened. \$\endgroup\$
    – Splo
    Nov 19, 2010 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .