Silent failure. The worst kind.

I am introducing joystick and gamepad support. Seemed like an easy job at first.

The Problem

I have two joysticks. One of them works fine, the other one does not work at all with my Unity WebGL build. No sign of life. 50% is not encouraging. Both joysticks work fine with the browser and the Gamepad API, as proven by a simple hardware tester web page.

I tried trouble shooting and searching for info, but could not get it to work. There may be a good Input System solution out there but I reached my patience limit before I found it.

What i think is happening (again, patience ran out) is that a procedure called layout matching fails to match the particular vendor/productid combination to any predefined layout of axes and buttons. For that reason the Unity Input System decides to silently ignore the device.

The Solution

I did the sensible thing: revert to the legacy Input Manager. This works fine with both my joysticks and I’m confident it will work with any joystick the Gamepad API can detect. Problem solved.

Really?

How could Input System (which is a somewhat mature major redesign compared to the legacy Input Manager) go wrong? Wrong to the extent that I feel the need to abandon it in favor of Input Manager?

The Unity Input System (AKA “The new input system”) is an ambitious multi-layer attempt to generalize controllers and user actions. Isn’t player interaction a perfect candidate for generalization? I think it is, considering the plethora of devices on the market, the expected differences in end user setup and recurring player actions.

Still it went wrong. I’m a fan of constructive feedback, so let’s not only rant. Here are some suggestions for Input System (or its successor):

1. Clarify the device-layout-action-input-effect-matching process in code and documentation.
2. Add mechanisms to easily monitor and hook into every step of the process. If no usable joystick is currently connected it must be easy to figure out why. Failed device matchings should be reported as debug info by default. Don’t you think developers and users want to know there is a Gamepad API reported device but it can’t be used even though the game takes joystick input?
3. Get the most common use cases right by default. It is very easy to access devices from the Gamepad API, which is supported by all major browsers. It is equally trivial to get values from the axes and buttons. Admittedly the index and format of some axes, like hatswitches, are not standardized, but the most basic ones are. Axis 0 means horizontal, axis 1 is vertical. That goes a long way.

“The new input system” is BTW a great example of bad naming. What happens when the next generation input system is launched? Or you just assume the “new input system” is so perfect no replacement will ever be needed? How many similar assumptions in the tech world have held for a long time?

I think the Input System suffers from a misguided approach to generalization. It is related to abstraction, a corner stone of any programming. Getting it right is key.

Hiding unnecessary details is good. Dumbing down things by giving it a cuter name is not.
Providing a high level API is good. Removing access to the lower level is not.

Example of dumbing down

In a Swedish MS Windows installation the DHCP setting is called “Skaffa IP-adress automatiskt”. Googling that (Binging?) will not necessarily give you the info you need. Googling “Windows DHCP” likely would. If you mean DHCP, please write DHCP. It sets your users on the right path to learn more.

Example of good abstraction

Kubernetes is known to have a bit of learning curve because there are many abstract terms and concepts. The good news is that every concept is clearly defined and is used consistently throughout user interfaces and documentation. All the info about your running system is available on the abstraction level you choose. Getting started is not so bad and once you are passed the basics it’s a very pleasant system to work with.

“Hide what you have to hide
Tell what you have to tell”
- Policy of truth, Depeche Mode