Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on an input system (in C#) and now I'm wondering, what is the best place to put input functionality?

Currently what I was coding was a bunch of delegates which act as callbacks (i.e. onkeypress, onmouseclick, etc) and the idea is when the input manager checks for input it invokes these delegaetes.

However this means that input is updated when the input manager updates and not when a game class has its own update function called.

The way I see it is moving input functionality out of a classes update function and deferring them would forecefully reduce the codes complexity (particularly the update function) but on the other hand I'm thinking it might be a better idea to move update and input to the same place as it would give the coder more freedom to work with the input systems.

Anyone have any ideas on this matter?

share|improve this question
You might want to check out… and also accept previous answers. – The Communist Duck Apr 17 '11 at 12:42
up vote 2 down vote accepted

This answer implies using the xna framework with c#.

I generally create an input manager class that has its own update method to update the current state of the keyboard/mouse/gamepads. I create an instance of this class and register it as a service so it's available to any class in the game.

At the beginning of the game's update, I call the inputManager's update. At this point the current & previous states of the keyboard, mouse, & gamepads are available to all classes that can access services.

My input manager also has stand alone methods to check for key or button presses and/or clicks which can also be accessed from anywhere and can pass in whatever key/button they are concerned about.

share|improve this answer

I'd recommend a good clear separation of input and the rest of your game. I'd also recommend a layer that allows you to map different inputs onto different results (i.e. press key A maps to Left, S to Right). If you tightly couple the game with the input you won't easily be able to handle people remapping keys to suit their tastes, you also would have trouble adapting to maybe using a controller (i.e. 360 pad) instead of the keyboard later, or even being able to use something like Kinect to control input with enough abstraction.

In a driving game for example, I would have something that parses the current input state from the device currently in use (i.e. keyboard, pad, wheel, etc) and use the values I retrieve to build up a structure more suitable to my specific need, i.e. turn the values I parse into a steering value, an accelerator pedal, a brake pedal, etc. This structure could then be passed around to systems without having to worry about what input method had generated these values or whether they used analogue sticks, d-pad or keyboard.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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