Input management techniques in large games

Question

Is there a standard technique for managing input in large games. Currently, in my project, all input handling is done in the game loop, like so:

while(SDL_PollEvent(&event)){
            switch(event.type){
                case SDL_QUIT:
                    exit = 1;
                    break;
                case SDL_KEYDOWN:
                    switch(event.key.keysym.sym){
                        case SDLK_c:
                            //do stuff
                            break;
                    }
                    break;
                case SDL_MOUSEBUTTONDOWN:
                    switch(event.button.button){
                        case SDL_BUTTON_MIDDLE:
                                //do stuff
                                break;
                            }
                    }
                    break;
            }

(I am using SDL, but I expect the main practice applies libraries and frameworks as well). For a large project this doesn't seem the best solution. I may have several objects all wanting to know what the user has pressed, so it would make more sense for those objects to handle input. However, they can't all be handling input, as after one gets an event, it will be pushed off the event buffer, so another object won't receive that input. What method is most commonly used to counteract this?

Answer 1

Since asked by the thread starter, I elaborate on event managers. I think this is a good way to handle input in a game.

An event manager is a global class which allows to both register callback functions to keys and to fire off those callbacks. The event manager stores registered functions in a private list grouped by their key. Each time a key gets fired, all registered callbacks are executed.

The callbacks could be std::function objects which can hold lambdas. The keys could be strings. Since the manager is global, components of your application can register to keys fired from other components.

// in character controller
// at initialization time
Events->Register("Jump", [=]{
    // perform the movement
});

// in input controller
// inside the game loop
// note that I took the code structure from the question
case SDL_KEYDOWN:
    switch(event.key.keysym.sym) {
    case SDLK_c:
        Events->Fire("Jump");
        break;
    }
    break;

You could even extend this event manager to allow passing values as additional arguments. C++ templates are great for this. You could use such a system to, say, for a "WindowResize" event pass the new window size, so that listening components don't need to fetch it themselves. This can reduce code dependencies quite a bit.

Events->Register<int>("LevelUp", [=](int NewLevel){ ... });

I've implemented such an event manger for my game. If you are interested, I'll post the link to the code here.

Using an event manager, you can easily broadcast input information within your application. Moreover, this allows for a nice way to let the user customize key bindings. Components listen to semantic events instead of keys directly ("PlayerJump" instead of "KeyPressedSpace"). Then you can have an input mapping component that listens for "KeyPressedSpace" and triggers whatever action the user bound to that key.

Answer 2

Split this into several layers.

At the lowest layer you have raw input events from the OS. SDL keyboard input, mouse input, joystick input, etc. You might have several platforms (SDL is a least-common-denominator lacking several input forms, for instance, which you might later care about).

You can abstract these with a very low-level custom event type, like "keyboard button down" or the like. When your platform layer (SDL game loop) receives input, it should create these low-level events and then forward them on to an input manager. It can do these with simple method calls, callback functions, a complicated event system, whatever you like best.

The input system now has the job of translating low-level input into high-level logical events. Game logic does not at all care that SPACE was pressed. It cares that JUMP was pressed. The input manager's job is to collect these low-level input events and generate high-level input events. It is responsible for knowing that the spacebar and the 'A' gamepad button both map to the logical command Jump. It deals with gamepad vs mouse look controls and so on. It emits high-level logical events that are as abstract as possible from the low-level controls (there are some limitations here, but you can abstract things away completely in the common case).

Your character controller then receives these events and processes these high-level input events to actually respond. The platform layer sent the event "Key down spacebar." The input system received that, looks at its mapping tables/logic, and then sends the event "Pressed jump." The game logic / character controller receives that event, checks that the player is actually allowed to jump, and then emits the "Player jumped" event (or just directly causes a jump to happen), which the rest of game logic uses to do whatever.

Anything dependent on game logic goes into the player controller. Anything OS dependent goes in the platform layer. All the rest goes into the input management layer.

Here's some amateurish ASCII art to describe this:

-----------------------------------------------------------------------
Platform Abstraction | Collect and forward OS input events
-----------------------------------------------------------------------
                          | |
                          | |
                         \   /
                          \_/
-----------------------------------------------------------------------
    Input Manager    | Translate OS input events into logical events
-----------------------------------------------------------------------
                          | |
                          | |
                         \   /
                          \_/
-----------------------------------------------------------------------
Character Controller | React to logical events and affect game play
-----------------------------------------------------------------------
                          | |
                          | |
                         \   /
                          \_/
-----------------------------------------------------------------------
      Game Logic     | React to player actions and provides feedback
-----------------------------------------------------------------------