Right, so I’m back in the thick of it. I spent tonight working on the InputManager, which is fairly rudimentary at the moment, but the overall plan is for each game context to be able to process input from a controller that abstracts away the specific hardware being used (which, for an iPhone, is keyboard, pointer, location, compass, socket and accelerometer). It should be trivial, for example, to switch between controlling a game character with touch or tilt, without having to change any code in the game character entity itself (this makes prototyping much more fun; I wouldn’t expect you to offer that switch to the user in production however).
The other goal of the InputManager is to give game contexts and game systems controlled access to input controllers. For example, when a particular game context is active, it may require exclusive access to touch. In other circumstances, several game systems and contexts may use touch simultaneously (as would be the case when implementing game entity control with touch and overlaying a HUD that contains buttons that may be pressed). I want to avoid the usual technique of having entities, contexts and systems query the input devices directly, so that’s taking a bit of thought and hacking to figure out.
I expect I’ll be a day or two on this, and then will move onto entities.
3 Comments
I usually borrow the event bubbling idea from javascript, so new game classes register callbacks for input events in order (or by specifying a priority). When each handler gets called in turn it then returns true or false to indicate whether to continue passing down the chain.
ie:
MyClass::MyClass()
{
this->onTouch( &MyClass::handleTouch, );
}
bool MyClass::onTouch( TouchEvent event )
{
if( ) return true;
else return false;
}
Problem is making sure everyone’s priorities don’t get clobbered, a file containing the orders for all your systems helps to get a good overview (we did a similar thing in IZF for the UI). You can also deregister / reregister for events as need be to change the priority around at run time.
coool :D
Sounds good @cameron, but I’m not sure that event-based input is ideal when all entities, contexts and systems get update() calls anyway (which means you might get cleaner code with a system that polls input). Also, I want to cook the raw input with controllers, to make it easier to plug-and-play different input methods. I think I’ll need to do some experimentation; I’ll have a go at an event-based system first, methinks. Oh, did I say I’m trying to write a base game engine, and that I’ll specialise an iPhone engine and a PC engine from that? So I’m thinking about mice, XBOX controllers and keyboards too.
Post a Comment