Jump to content
  • Advertisement
Sign in to follow this  
Toolmaker

Building an Input Manager system

This topic is 4832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Right now, I'm trying to develop a re-usable system for input management around Direct Input so I can re-using it throughout my game(s). I came up with a system that uses delegates(One of the glorious things in C#). The InputManager class has a reference to DirectInput and holds a list of key-bindings. When starting the InputManager, AddCommand(string cmd, EventHandler eventHandler) needs to be called, which adds the commands to the list. Binding a key is then done via calling Bind(Key key, string cmd). (bind escape quit). Then, when the input manager detects a keypress, it looks up the keybinding in the list and triggers the accompanying delegate. Now, although the system is pretty well thought out(Or so I think), I have a problem with using it throughout several parts of my game. I can't use these bindings in the menu, and similar. So, I'm looking on some feedback about how to handle those cases. Toolmaker

Share this post


Link to post
Share on other sites
Advertisement
Here's how I set my system up, I'm still working on it, but that's a problem totally not dealing with it. I have limited time to work on due to an increase in work and house releated stuffs.

The WndProc fires events off to my System Task for input (keyboard only right now) and the System task will dispatch the event messages to the proper task depending on what they are. As of right now, they are only keyboard events, so all the events get dispatched as a KeyboardEvent and then the Input Task checks for KeyboardListeners that match the Keycode from the event.

The listener handles firing off the bound commands, and it also has an active state toggle which is changed when a key is pressed and then released. The listeners are setup when the Input Task is created. I'll eventually read in a configuration file, and then use that to setup the bindings. I plan on using a similar system with my Mouse as long as everything works out with no kinks.

Share this post


Link to post
Share on other sites
Well why doesn't the input handler work for menus?

It seems well enough thought out. When the menu is created, push bindings for the menu. When the menu is deleted, pop the bindings, restoring the old.

I don't know how your gamestates change or how you handle that orginization, so implimenting that simple mechanism might vary greatly.

Share this post


Link to post
Share on other sites
Hmm, I technically could place the bindings in a class or struct of itself, and indeed, push/pop those into a sort of stack like system.

My gamestate is a stack of itself, but this system should work completely independant of it, but implementing it as a stack itself, would be a great idea.

Also, a system like this would also allow for secondary bindings(Such as a lot of games have). Binding/unbinding would be easy. I still need to figure out how I'm going to update the system, but I probably place an Update(float deltaTime) function into it, and have the engine update it.

Toolmaker

Share this post


Link to post
Share on other sites
Thats the same thought I use in my input system. I have a class that maps input to actions and sends messages to my game when needed. Add for a menu, that's a mix of things, after all a menu selection is just input and responding to it, you need to have different input "modes" If you select a menu you get a menu mode. If you're dealing with a mouse and clickable events what I do is loop through what was is clickable send the apropriate messages and process the information, this in turns trickles down to update the game state, rendering engine.

Share this post


Link to post
Share on other sites
dunno if it helps, but heres how i do it:

i catpure keypresses and mouse motion through the win32 api, which is wrapped by a window class. this class contains a data structure and a memberless function pointer. every frame, if there is input, the window class populates this data struct with the collected data and passes its reference to the function pointer. this function pointer is assigned by the host engine to a member function in the input system. this is done by using a base memberless function pointer in the window system (and input manager), and a derived overloaded member function pointer in the engine. this way, both sub systems are independant of one another; instead the interrelational code is in the container engine, where it should be.

anyway, the member function in the input system takes in the input struct and maps it to a predefined key index list (ie mouse_btn1, keypad_1 etc). another list is stored that contains a likesized list of memberless function pointers, which are fired whenever the related key is struck. these can be bound via a bind function that takes in the key index and function to map to, as well as other random stuff like repeat rate etc.

the real problem is what these memberless function pointers point to, where these fnctions are, and how they should interact with the rest of the system. the answers to those questions are usually implementation specific, but typically involve the notion of a command processor of sorts, with which systems regsiter functionality which can be bound to.

a good example is in the q2 source code. hope that random ramble helped a bit :)

Share this post


Link to post
Share on other sites
I'm using the exact same system with great success.

Any GUI element can also hook into the InputManager to listen for specific keys. So if I create a Quickslot Bar, it tells the InputManager it wants to receive a notification when buttons 0-9 are pressed / held / released (at the GUI element's discretion).

This lets you "bind" specific keys to specific GUI actions.

All with the magic of delegates, as you already pointed out. ;)

Share this post


Link to post
Share on other sites
This is one of the reason I definitley prefer C# over C++. With C#, I get to use the glorious delegates, no need to bother about memory leaks, no more DLL hell, no more header files and the horribleness of missing headers, cyclic inclusion or (worse) dependencies.

Anyway, I'm going to develop this system right now(As I just got home from a weekend at my gf's place), and I'll release a little demo app later on or so(Or not).

Toolmaker

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!