Perhaps this is another issue where feedback would be very useful.
Currently, the input state information is propogated around the engine as messages, as LordIkon has stated. This is a global event subscribable by all engine systems. Every time the input system detects input state changes, this event handler is called with appropriate event types. The system is very similar to the Windows message pump, with the exception of message types being derived classes from a common interface type. Engine-level code would see something like:
public void MyMessageHandler(IMessage msg)
{
// Process message type and perform appropriate logic
}
To game code, this approach may become somewhat messy. However, this abstraction seems necessary to decouple the internal engine systems. To accomodate a more clean interface for game-level code, an input mapper will be created. This mapper will subscribe to and process input events, along with an internal key/button -> event name mapping, and maintain internal states. Game-level code will then be able to make calls like:
public void Update(GameTime gameTime)
{
if(inputMapper.IsEventActive(MyEvents.MoveForward)) // Key/button bound to "MoveForward" is being pressed/held.
{
}
if(inputMapper.IsEventJustFired(MyEvents.MenuItemActivate)) // Key/button bound to "MenuItemActivate" was just pressed this frame.
{
}
}
Clearly, input control is just one use of the messaging system.
Comments?
