Planning input architecture

I've created an InputAdapter as an insulation between bmInputConsumer and the Puck. On the north side I attach an input controller, network interface or AI controller, and on the south side a puck. Though, I'm not entirely sure where this goes.

The first problem is coming from a bmInputFrame in PuxGame::InputUpdate to a PuckInputFrame directed at a specific puck. I want to support hotseat play for two pucks, which means that I have to put in at least one switch for player 1 or player 2. In that case, I might as well put in switches for reading network packets, or taking AI commands. The AI thingy is something else, since it will synthesize its own PuckInputFrames. Perhaps it would make sense to subclass all three from a common base, all with different interfaces on the north side, but with common output on the south side? The network class will know that it's sitting on a network input adapter, the AI will know what it's doing, and the keyboard adapter is naturally in InputUpdate(). No need for polymorphism here.

So, they need a common outlet (a Puck) and a time step-driven dispatch. Since I have to apply the updates synchronously, I can have all the input sources queue up frames in the adapter, collate them, and then do common dispatch in the PuxGame::Update method.

Alright, so then I have the data path setup. Input frames would be subsets of the bmInputFrames with a keymap (for commands), and a command-hit value. However, I have a dream about being able to ramp direction input weights over time.

This would work as a multiplier on input weights for each direction based on time. So, by timing the time from keydown and mapping that to a value in (0, 2] or so, I can have short input bursts be more prominent for panic redirections.

The real setup would be based around creating two input adapters in BaseLevel and making both InputConsumers, and then setting the adapters to player 1 and 2 respectively.