fernandojsg
commented
6 years ago I admit I was thinking initially about going for 3 but then I thought I could be a bit overengineering using callback for each button. As you comment it will be hard to use as it's not just data so we'll end up mixing data (like labels for each button, or buttons names) and functions. Also harder to modify the mapping.
Of course it will be more powerful, but I'll vote for going simple (1) right now and let the tracked-controls generate common events, like trackpad/joystick-left,right,up,down, and leave the more advanced processing to the application itself on each action callback.
If we find that most of the applications needs a lot of custom interpretation of the event data we could come back to decide if we go all the way to 3.
johnshaughnessy
machenmusik
netpro2k
Looking into options for #1 I wanted to think through the general issue of extensibility. There are going to be more things people want configure about their input mappings. I thought through this for a bit and came up with 3 options:
1. Do Nothing
The scope of this component remains simply mapping a set of named events for a specific set of controllers in a set of states, to another set of named events. Any customization beyond that should be handled outside of this component.
For the dpad case this means either creating a separate component to handle listening to controller events and broadcasting a different set of events (as I did above), which can then be mapped by the input-mapping-component, or simply moving this functionality into the relevant controller components themselves (similar to how triggers, touchpads, etc are handled now). The later seems somewhat preferable otherwise each of these such components might needs ways to detect different controllers and configure behavior between them.
➕ The advantage of this approach is simplicity, this component focuses on doing one simple thing well, and doesn't do anything else beyond that. ➖ The big disadvantage is it means some of your controller mapping code may need to live other places. There are already several layers of remapping happening with tracked-controllers, vive-controllers, etc, so maybe this is not a big leap.
2. Extend the mapping schema
Pick and choose specific cases and extend the mapping schema with case specific values to handle any special cases. In the dpad example this might be something like:
And for another example, binding a shake gesture might be:
➕ The advantage of this is that it keeps all the input configuration in one place. You can simply look at the input map and determine everything about how each input device mapped and configured in your application ➖ The big disadvantage here is that the schema becomes more complicated and it can be difficult to decide what specific options make the cut
3. All mappings are function handlers
All mappings just become a mapping from an event to a function that handles that even (and typically broadcasts another event). For convenience the default handler could be used for strings to keep the simple format for one to one mapping as exists today.
Simplest example being:
The dpad and shake cases might be handled by included or third party convenience functions that generate handlers for you. For example (semi-psudo-code)
➕ The main advantage of this is that the core component remains very simple while allowing pretty much infinite flexibility for higher order handlers. You can imagine some of these handlers coming bundled with the library and others being created by third parties or bundled with other relevant components. ➖ The main disadvantage here is that the mappings are no longer just data, they can now do arbitrarily complicated things, which makes the contract less simple.
I personally like options 1 and 3 the most, option 2 feels like it would get out of hand very quickly. There is something really nice about the flexibility of option 3, but the loss of "it's just data" bothers me a bit.
Tangentially related, I opened #3 to discuss a possible alternative to the schema format that I considered while looking into these 3 options. It should work just as well with any of them.
Anyway, large brain dump, would love other pepople's thoughts and other proposed options.