Custom inputs?

[ironchestgames]

Hi,

I really like this lib, nice work!

I propose an addition to the API/doc - a way to add custom inputs.

This is useful for when having the same game played on mobile.

[niklashigi]

Thanks, Fredrik! I'm glad you enjoy using Contro. I have thought about your suggestion and while I've shied away from adding mobile support in the past and still think that it should not be part of the core library, I agree that allowing developers to add their own input types would make sense.

Currently, it is technically possible to add custom input types since you can just create a class that has a bunch of methods returning Control's and passing these controls to or should return a control that when queried returns the expected value but the label will probably not be correct since or currently only "prefers" Gamepad controls.

What I'm saying is that:

• your custom mobile input would need some way to tell or that it is available
• there should be a way for you to specify the priority order of the input types (so that if both mobile and gamepad inputs are available, you can specify which ones Contro should prefer)

I'm not sure how to implement this because there are a lot of different ways. I am, however, sure that this should be implemented in some way. What do you think? What would you expect this API to look like?

[daedalius]

Hi Niklas! Just found your awesome work!

Here are my thoughts about the "label" method:

As far as I concerned, this library provides an abstraction over different input types. Idea is to program the "controls" object. The programming is about:

• defining a "control"
• enumeration of buttons (gamepad/mouse/keyboard) that may "activate" that control
• define a logical relation (or/and) between the buttons to "activate" that control Then you may call the "query" method in some loop to check if the defined logical relation is "active/true".

Then it is a tricky point for me. You provide the "label" method to determine... what and why? Maybe I miss something, but it ruins the abstraction you are building. If we are talking about commands/actions what the point to figure who activated them? The only way I saw the label() method usage is debugging. If so I'd just remove it and close issue #3

[niklashigi]

Hey @daedalius, the idea behind the labels is that they change depending on which input devices are available. This way you can show gamepad controls to gamepad users and keyboard controls to keyboard users. You can test this by opening the demo without a gamepad connected (you'll see keyboard-specific labels on the buttons) and then connecting a gamepad and pressing any of its buttons (the labels will change to be gamepad-specific).

Admittedly the current implementation of this feature isn't very extensible as it only differentiates between gamepads and everything else and it also ignores use cases where developers want to show the labels in some different way (for example with icons). I'd probably implement this differently nowadays, but I'm no longer working on this project a lot. That said, you seem to have a good understanding of how the library works, so if you want to contribute any improvements, you're absolutely welcome to!