How to handle inputs?

The control situation of a game can be represented as a state machine. Eg:

Each state has different requirements, in the menu state, WSAD won’t do anything, in the game state, clicking in the middle of the screen won’t quit.

One way to deal with this is to have each object able to check the control state: ie polling some dictionary of active inputs, and having a player module determine what object is currently polling the control system, but then it can’t handle transitions from playing to the menu easily. This is what most blender games use (I think)
This is ‘object in control’

Another way is to have the game state integrated into the control system, So for instance, there is a global property called ‘gamestate’, which can be set to ‘menu’ or ‘car’ or ‘human’ (or ‘dead’). The control system then mind-controls the objects and gets them to move.
This is ‘game in control’

The problem with both of these is that they require tight coupling. In the first method, the player needs to know about the control system. In the second method, the control system needs to know about the player.

So, the question is:

As far as I can see, there are multiple parts:

  • Mapping keys to abstract ‘actions’ (eg ‘SPACE_KEY’ → ‘shooting’)
  • Mapping actions to physical activities (eg ‘shooting’ → ‘addObject(bullet)’)

Both of these need to be changed for each ‘game state,’ and I’m getting confused about how to handle all this.

Note that I am talking at a very abstract level. I’m not asking for code, but rather system design.

I think I’ve got it. There are actually multiple stages in handling input.

First is a global level state machine, selecting if it’s in the menu or if it’s in the game.
Then there’s a second state machine to select what the game does with the control - after abstraction from keyboard to events.

Both of these are controlled by the game, which has to know what object is being controlled, and whether the menu is displaying anyway.

Note that the ‘game control module’ translates keypresses to actions, and the ‘game module’ contains the state of the actual game (eg kills, deaths, etc)

None of the objects need to know if they’re being controlled, nor does the keymapper need to know who it’s controlling. That’s handled by who should know about it: the game itself.