It is partially a matter of taste but I would heavily recommend against mapping of any kind.
That may work fine for event-based systems such as standard applications, but not for games.

Firstly, let’s say you have mapped a key to an action. B to jump.
But now you are in water. Remap the key to “swim”? Keep the key on “Jump” but add code to check if you are in water during a jump?

The player presses pause. Send a message to all game objects to unbind? Add code to all the action functions to check if the game is paused?
To what end?

The way input is handled varies from game-to-game, and any kind of overspecialization such as a binding mechanism is not only cumbersome but limiting. It makes it a chore to manage what should be bound when, and makes debugging extremely clunky.

I would recommend instead that you simply buffer the input for a given duration into the past and expose the buffer to any objects that need it.
That would be the menu manager/HUD, plus the class that drives the game logic and can cause jumping or other actions to happen on any object.

Just keep a record of the last X seconds of input and let the rest of the game use the data as it pleases.


L. Spiro

Firstly, let’s say you have mapped a key to an action. B to jump.
But now you are in water. Remap the key to “swim”? Keep the key on “Jump” but add code to check if you are in water during a jump?

What you described is simple to do with an input mapping system.

The player presses pause. Send a message to all game objects to unbind? Add code to all the action functions to check if the game is paused?
To what end?

There are multiple ways to go about that, but what you just described doesn't even take advantage of an input mapping system. Since the system is centralized you could simply freeze all input from every reaching its intended target. This would allow animations to continue, but would freeze the game to player input.

I would recommend instead that you simply buffer the input for a given duration into the past and expose the buffer to any objects that need it.
That would be the menu manager/HUD, plus the class that drives the game logic and can cause jumping or other actions to happen on any object.

How would you implement priorities in the system? Which objects get first crack at the data? These are all questions that can be easily answered with an input mapping system. In fact, it is pretty standard in the game industry to use such a system.

Back on topic, mmurphy, I recommend you check out ApochPiQ's article on Designing a Robust Input Handling System for Games; he was even gracious enough to provide code for once you are done reading.

There are multiple ways to go about that, but what you just described doesn't even take advantage of an input mapping system. Since the system is centralized you could simply freeze all input from every reaching its intended target. This would allow animations to continue, but would freeze the game to player input.

Actually there are much more graceful and logical ways to freeze the game which are unrelated to input processing. They are completely unrelated subsystems, meaning that when the game is paused, input or not, the game characters can’t move.

The question here is about how to distribute the input. You wouldn’t “freeze” input, you would redirect it to the pause menu, which would allow selecting the options button or unpausing the game, etc. In other words, changing the context of the input.


My post was meant to illustrate that a rudimentary just-map-a-key-to-an-action system is not the way to go.


I have no qualms with the system explained by ApochPiQ. Conceptually, my system ends up doing exactly the same thing, but is less automated by the engine and more by the game itself.
I have been considering moving this automation over to the engine (where it does need to be), only to be held back by concerns of that rare edge case in which my system would not be able to handle something the game needs.
I am thinking about touch input. Strokes all of natures, for iOS devices. Accelerometers, etc.

I have a few ideas but I am not focused on input for now.

For the topic poster, I recommend just going the way described by ApochPiQ.


L. Spiro

I know there are multiple ways to handle the situation, hence the "there are multiple ways to go about that..." I was simply demonstrating a hypothetical example in which there is a paused "state," and not a menu of any kind. Futhermore, in direct contradiction to what the OP was looking for, you recommended against mapping of any kind in your previous post.

The code I wrote uses a simpler version of the file format than full-blown XML; you can read about the decision behind that here and find the appropriate data files here.