I've always used to expose all current user input in a singleton called InputManager, which has it's state updated on every frame. On every frame, i poll SDL input for changes, and update the state of InputManager. Then, all my game objects are able to ask it for the state of keys like this:
InputManager.isKeyDown('A');
InputManager.isKeyDown('Left');
I've always used to expose all current user input in a singleton called InputManager, which has it's state updated on every frame. On every frame, i poll SDL input for changes, and update the state of InputManager. Then, all my game objects are able to ask it for the state of keys like this:
InputManager.isKeyDown('A');
InputManager.isKeyDown('Left');
InputManager.isKeyDown('Right');Do you guys think this is a good way of handling input? How do you do it in your engines?
Hiya Vinny
My preferd way of handling input would be event driven. I just think its a much better and cleaner way of handling inputs and events all togheter. Then again thats my opinion and maybe someone else has better points on handle keyboard input.
If you need some examples check http://lazyfoo.net/tutorials/SDL/index.php Lesson 3 for event and Lesson 4 for keyboard handling
SDL is already event driven. I'm actually referring to the way your game engine handles input... do you have a singleton, which is openly read by all subsystems? Or do you have an observer pattern laying around, with objects subscribing to the proper event pipelines, or... something else? That's the purpose of the thread.
If you want to keep your game code clean, don't ask for a "keyDown" of a "mouseMove", and certainly don't ask for a specific key like "A" of "Shift", it hard codes your input check inside the game code, and makes you dependant on only those input devices.
Instead, have a layer of key bindings which translates these events into game specific actions, like "MoveUp" or "Shoot".
My attempts to do this resulted in having a low level input system, a keybinding system and a high level input dispatcher. The low level system gathers input events from the OS (you can use it to filter only input specific SDL events) and prepares them for collection by a higher system. The keybinding system then collects these and transforms them into game specific actions (in your case, each SDL event would be mapped into one game action). Then the high level input dispatch sends these game actions to all game objects that were registered as input receivers.
My implementation is butt ugly, and i'm rewriting it, but it's the general idea that matters, where you do these three things in sequence as the "check input" part of the game loop.
And keep in mind that you really don't need singletons for any of this. If you need a single instance, create a single instance. If you need global access to it, think twice about why, and realise that you don't. :)
So, what do you actually do with the high level system? You're injecting it into your game objects? Or are the game objects event listeners who register themselves to the input?
I call update() on my systems from my game loop (well, somewhere within the game loop). The systems do what they are supposed to do, and optionally send messages to other systems, which consist of marking an entity as being included or excluded from being updated by that system.
The game objects know nothing about systems. They're just a collection of data, however you want to represent it (via a plain old ID or a bag of components), that gets modified by the systems when the game logic tells them to.
In a top down view, the game logic sits at the top, followed by the systems, followed by game object data and the low level subsystems or services (like the raw input gatherer, renderer, audio provider, networking, etc). Lower levels know nothing about the higher ones (this is good for reducing dependancies), and the higher ones should know only about the ones just 1 level beneath them, with exceptions where that's not possible/practical. :)
A great article right here on gamedev:
This is a great article, although i don't really like the callback based input system. I usually prefer to write clean logic:
if someIputIsPressed
do something
