Managing the user input

Question

I'm studying a good number of articles about this topic and seems to me that there is just one way to do this: a signal/slot design.

I was also looking at some more complex async examples but I don't think I will adopt this, the tradeoff is not convenient in my opinion.

The classic C++ code that I have read until now is done with a template design and adopt a signal/slot logic, now my question: there is a better way to handle the input from the user? Is there a good pre-packed library for this?

I'd like to handle a broad range of different inputs: mouse, keyboard, gamepad, maybe also touch screen gestures, on several different platforms. My system should also be user-configurable.

Answer 1

You don't need any kind of complexity for this. You don't need signals/slots for input.

For most games, simply polling the input state works. How to do that exactly is up to you, but this usually means you'll fill one table of inputs per-player each time your game updates:

• An option is to define you inputs for one platform & input device only. For instance let's say the Xbox 360 is your development platform: you'll have a map of the Xbox 360 buttons. Then whatever code makes your character jump just polls for the "A" button state. This makes input handling quick and easy on the programming side, but starts to get messy as soon as you want some configurablity (either for designers or for users).

• A more advanced option is to have a map of "actions" that are defined per-platform as combinations of button presses, or some other kind of input (gestures, voice...). Then whatever code makes your character jump just polls for the "jump" action's state. Actions state should probably be a float or any kind of range, but not a boolean, so it can handle analog inputs (stick, gesture "match factor"...). The upside of this is that it's easy for you (and your user) to redefine which action is associated with which input. The downside is that this kind of actions map tend to grow very quickly to a point they start to be unmanageable.

• Compatible with both option: instead of redefining your inputs for each controller type, it's a good idea to pick a default one, and then just define a correspondence.

You can also use a very simple messaging system. Maybe combine it with a publisher/subscriber model, but that's not necessary.

That said, if you're set on signals and slots, Boost has an implementation, which is itself based on libsigc++.