I found this an intuitive concept for input handling. I wouldn’t go to the same level of depth as outlined in the system just yet, but it will be useful for any future development.
In short, it features event “contexts” which describe a situation within which events are available. Instead of having an active entity (Vehicle/Player) which polls events from the input layer, the input manager will select the active event context and push events through a callback. I thought this quite effective.
Your example is slightly missing the point of callbacks. The idea is that the movement code resides on the spaceship/player and that particular object will have its own callbacks to register to the input manager. Whenever you switch between the two, the disabled object unsubscribes from the input manager. Similar, but not exactly so, to the article’s method.
You can also poll state directly. To be honest, it depends upon your design preference. But, I would advise the following:
- Separate the input polling from the BGE. That way, you could for example performing game replays by simply providing recorded inputs to the game instead of player inputs. You can still use a global singleton class for this, though most recommend against it, instead it is better to provide the input state whenever you update the gamestate.
for entity in entities:
However, given that in many games, there will also be NPC characters and other entities which do not handle input from the player, it would be cumbersome to have to write a separate update loop, and foolish to provide useless state by the same method as players.
In the interests of code-reuse, I prefer the UDK method which encourages the use of player “controller” which handles the interface between the actuator (player) and the sensor (inputs) to allow either players or NPCs to control the same player object “Pawn”.
So, instead I prefer the callback-based approach.
I originally wrote a small code sample, then implemented a dummy system.
Press E to disable the player (by setting the context active state to False), WSAD to move around.
Notice that the controller just handles inputs. The entity itself would be a class with its own additional functionality (i.e shoot_weapon) that builds upon the KX_GameObject features.
scene.blend (559 KB)