Jump to content
  • Advertisement
Sign in to follow this  
NathanRidley

Unity Concept for an input library - thoughts?

This topic is 1230 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

I'm thinking of building a small input library which would streamline the way input events are managed and make it a lot easier to observe complex input event combinations. The library would be designed to be plugged into whatever input source is desired, i.e. if you're using GLFW, or RawInput on Windows, or whatever, you would just point any events fired at this library and it would take care of the rest.

Conceptually, usage of the library would look like this:
 
// fires on ctrl+A, followed by ctrl+B, then ctrl+C, with a maximum of 1000ms between keypresses
auto observer = input::observe("ctrl+a,ctrl+b,ctrl+c", 0, 1000);

// fires when the mouse is moved
auto observer = input::observe("mouse:move");

// fires when the left mouse button is clicked
auto observer = input::observe("mouse:lclick");

// fires when the right mouse button is clicked while shift is down, followed by the space bar being pressed
auto observer = input::observe("shift+mouse:rclick,space");

// fires when the A key is pressed followed by a specific delay of between 500-2000ms, followed by B, then C
auto observer = input::observe("a,delay(500,2000),b,c");

observer.then([&](state) {
    // respond to input state here (the state object can be queried for any arbitrary keyboard/mouse/etc. state)
});

I haven't actually started writing any code yet, as I wanted to (a) see if anyone else has already written (and open-sourced) something similar, and (b) get some feedback on the idea. I'd be happy to open source this if others feel it might be useful to them.

Edit
Some extra thoughts:
  • The library could easily adapt to different platforms, e.g., you could add gamepad events and so forth
  • The library could be implemented as a template class allowing you to define your own event object that is passed when an event is triggered, and internally the library would provide an opportunity for the host application to add the input state object to the templated event argument object before it is passed to an observer, meaning that your event argument object could contain information such as the window handle where the event was triggered, and anything else (your game context object, game time class, whatever).
  • Registering an input observer could provide the option to ignore input of a given type, e.g. to handle situations where a key sequence is being observed irrespective of mouse state.
  • Gestures could hypothetically be supported as a future development...
Edited by axefrog

Share this post


Link to post
Share on other sites
Advertisement


get some feedback on the idea. I'd be happy to open source this if others feel it might be useful to them.

A simple to use lib would be pretty cool, just some thoughts. It would be nice if such a library

1. would be able to forward events.

2. would hold the current state of buttons, mouse position etc

3. would be able to hold the current input string/stream.

 

I love single-header only libs, it could work for a small header like this. If you make it open-source, think about the license. GPL/LGPL are restrictive, whereas others like MIT are more flexible.

Share this post


Link to post
Share on other sites

A simple to use lib would be pretty cool, just some thoughts. It would be nice if such a library
1. would be able to forward events.


Could you describe what you think this might look like, as opposed to the sample code I suggested above? What sort of scenarios are you envisioning that would require what you're describing?

2. would hold the current state of buttons, mouse position etc


This would be the purpose of the event argument object, which would be passed when you subscribe to the observer that is returned. It would contain the current state of the keyboard, mouse, etc. In many cases you wouldn't need to pay any attention to it, because the fact that the event fired would imply that your original input combination was already satisifed.

3. would be able to hold the current input string/stream.


That would be included in the state object.

I love single-header only libs, it could work for a small header like this.


Yeah I agree, and that's the approach I'd take.

If you make it open-source, think about the license. GPL/LGPL are restrictive, whereas others like MIT are more flexible.


I hate GPL and its derivatives. The license I choose would be BSD-compatible. i.e. do whatever the hell you want; I don't care.

Share this post


Link to post
Share on other sites

Sometimes it is necessary to track all events and not just the state.

 

Eg. if you have low FPS and hit three times a key and you need to execute an action three times, then the state alone (keyboard has been clicked at time X) would not be enough. One simple test would be to write a keyboard input string reader only based on a keyboard state, once the fps go down your key-press starts to go over board. But the same could be valid for mouse buttons etc., it is just annoying to have the feeling that pressing a button is not registered by the application.smile.png

Share this post


Link to post
Share on other sites

Sometimes it is necessary to track all events and not just the state.
 
Eg. if you have low FPS and hit three times a key and you need to execute an action three times, then the state alone (keyboard has been clicked at time X) would not be enough. One simple test would be to write a keyboard input string reader only based on a keyboard state, once the fps go down your key-press starts to go over board. But the same could be valid for mouse buttons etc., it is just annoying to have the feeling that pressing a button is not registered by the application.smile.png


The way it would work is that you would control when input events are passed from their source to the input manager, so it would synchronise with your game loop. If you want to implement a debounce and drop some events before you pass them to the library, you can. If you want to debounce in your event handler on the other end, you can do that too. In essence, you'd pass in an input event, that event would be applied to any observable patterns you've defined, and any that have their sequence matched would then trigger for any subscribers. More than likely I would provide the ability for you to tell the library how much time has passed since the previous tick, rather than trying to handle that myself, as people are generally using their own game timers that handle that kind of thing. As a result, if you want your game timer to flex a bit when you have frame-rate lag, you could do that. Edited by axefrog

Share this post


Link to post
Share on other sites

You'd usually want to separate the low-level hardware events and high-level logical events.

Gameplay code shouldn't care if you hit Space or not. It cares if the user pressed Jump or not. Which matters for multiple platforms, because Jump might be Space or it might be the A button on a controller or an up-swipe gesture on a touch phone. And which matters especially on PC because users like to be able to rebind keys in a configuration dialog, so the user might even decide to move Jump from Space to Alt or some such.


I am a fan of keeping libraries tightly-focused for maximum flexibility when integrating with existing code. For this library, my thought was that the mental mapping between some combination of input events and a particular game-related intent would be up to the developer. You would watch for your input sequence and then do whatever you want in response. If that means funnelling the input event into a queue, you'd simply write a single event handler again the library's global observable, and in your handler you could perform the insertion into your queue.

I believe something like this would address your concerns:
 
// You know what's important to your game, so define your own structure containing the information you want in an
// input event, and probably also include the original input state object

struct YourGameInputEvent
{
    // your own properties
    MyGameContext *context;
    PlayerIntent intent;

    // the state object provided by the library
    InputState *inputState;
}

// construct your input sequencer with a custom function that will be called any time an input sequence event is
// about to be fired, allowing you to construct and populate the input argument with data that you care about

input::Sequencer<MyGameInputEvent> myInput([&](InputState& state, const std::string& inputSequence) {
    YourGameInputEvent data;
    data.context = yourGameContext; // captured via closure
    data.state = &state;
    return data;
});

myInput.observe("up,up,left,right,space", [&](YourGameInputEvent& arg) {
    // here you'd fill out the event argument data for this input sequence
    arg.intent = PlayerIntent::PERFORM_DONKEY_FATALITY;
});

// this would be called after any individual input sequence has been handled
myInput.observeAll([&](YourGameInputEvent& arg) {
    // here you could add all captured events to your own event queue
    arg.context.input_queue.push_back(arg.intent);
});

Note that I'd provide the ability to observe on more complex sequences (think AND/OR, etc.) when calling observe, if desired, as an overloaded alternative to just providing a string argument.

Thoughts? Edited by axefrog

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!