Mitigating Code Bloat with Input Handling

[CakeJamble]

I want to provide controller support, so I added a gamepadpressed function to my file. As the game grows in size, I am essentially doubling the lines of code for handling input. How do you mitigate this kind of code bloat? In order to keep things focused rn, we can assume that I don't really care that users can use both forms of input at once to cause unintended behavior.

Ex:

Code: Select all

function character_select:keypressed(key)
  if key == 'right' then
    character_select:set_right()
  end
  statPreview = character_select:setStatPreview()
end;
  
function character_select:gamepadpressed(joystick, button)
  if button == 'dpright' then
    character_select:set_right()
  end
  statPreview = character_select:setStatPreview()
end;

As I add game states and classes, this seems like it can quickly get out of hand:

Code: Select all

--[[ Hierarchy of keypressed chain:
  1. 
    combat:keypressed -> characterTeam:keypressed
      characterTeam:keypressed -> each character:keypressed
        character:keypressed -> offenseState:keypressed OR defenseState:keypressed
  
  2. combat:keypressed -> actionUI:keypressed
]]
function combat:keypressed(key)
  self.characterTeam:keypressed(key)
  
  if self.actionUI then
    self.actionUI:keypressed(key)
  end

end;

How do you usually organize your input handling when dealing with OOP and multiple gamestates? Or do you usually not even sweat this kind of stuff?

[MrFariator]

Effectively, the way I like to do it:
1) love.keypressed, love.gamepadpressed and similar callbacks take note of the button pressed, and put it in a table. Use a time-stamp or something too, if you want to know how long ago a button was pressed (for example, to implement "repeating" inputs after enough time).
2) Have some configuration that maps each game input ("attack", "jump", "accept", "cancel", "pause", "left", "right", etc) to specific buttons. Use separate mappings for keyboard and controller; probably a good idea to allow players to tweak these mappings (either in-game, or directly messing with a configuration file). For keyboards, it's better to use scancodes than the key literals (because of different keyboard layouts like QWERTY and AZERTY).
3) During love.update, have some code that goes through those button mappings. For each detected event (press, release), update the status of these game inputs (press, hold, repeat, release). You can minimize this by making your code only check the last input device (like if keyboard was last used, only check keyboard mappings).
4) Provide some interface for the rest of your game's code to check the status of a given button. You could for example either do this with an observer pattern (your input code says "hey, this button was pressed on this frame", and whatever object listening in responds to it), or have some set of functions that returns the status of buttons as determined in step 3 (like "isAttackPressed", "isJumpPressed", "isJumpReleased", etc).

After that setup is done, your player class, menus or other things you can interact with would just check the status through whatever method you chose in 4. The idea is basically to have those love callbacks (love.keypressed, love.gamepadpressed, etc) do as little work as possible, more or less detecting the events and pushing them to be handled on next available frame. Your input handling code as such doesn't really care what other places might be tracking its or various buttons' status.

This of course assumes a single-player game. You'll likely have more considerations for multiplayer (like keeping track of multiple input devices separately).

As far state management goes, I usually let each state define a callback for a given received input. For example, player class might check if "attack" is pressed (while looping through all the relevant buttons in a way or another), and if yes, it will call the corresponding "attack" function in the current state. The state is then free to implement if it should or should not act upon that button being pressed. If you transition from one state to another, you may optionally choose to drop all other inputs (to prevent certain actions from happening on the same frame, like maybe rolling and attacking).

This may duplicate some code in the player class, but that's usually not that big of a deal if the amount of potential states or state transitions is small enough. If in doubt, can always setup a common function that certain states then use for that specific input, if appropriate. Ultimately this part is wildly going to depend on how your player class might control (are states exclusive? can you be in multiple states at once? etc).

For menus you may consider having a "stack" hierarchy, where only the top-most active menu has control, and then anything below it sits idle. This could be achieved with a simple table keeping track of currently active menus, but only checking inputs inside the top-most menu. Relinquishing control as such is akin to popping and pushing whatever menus within the stack/table. This way each menu can implement its own input logic as necessary, if not use a common one.

[dusoft]

Yup, abstraction here is the only way to go. You might like to check how this library handles it (see the simple movement definitions), it's well done:
https://github.com/tesselode/baton?tab= ... g-controls