Feedback / First Impressions

I'm switching over a relatively large project from the old to the new input system. I'd like to give a bit of feedback, hopefully to be read by the Unity devs, on what that feels like. I have had little exposure to the new input system before this. I've been using Unity since the stone age, back when it didn't support Windows. Yes, I'm a dinosaur.


First, I very fast got the impression that the new input system is powerful and flexible.

Second, I really like how I can double-click on the actions SO and it'll open up this nice editor where I can set up everything. That's very well done and comfortable.

Third, using events is a good way to have things in a central place.

Four, while it seems powerful, some of the things that were the most easy with the old input system seem to me a complicated mess in the new one. Two examples are simply detecting that the user pressed a button. OnButtonDown(). Not possible. You need to subscribe to the event and then filter on performed. Even the built-in "Press" interaction which sounds like it would do that still pushes out TWO events that in 90% of the use cases nobody cares about. Second example: Detecting a mouse over or mouse click on a 3D scene object. OnMouseEnter/OnMouseDown. Different calls now, plus adding an interface, plus ensuring the camera has a physics raycaster added - ok, can live with that. Except it doesn't work. Well, worked once, then not anymore, and absolutely no way to debug that. No clue what's wrong and don't even know where to start looking for the issue.

Five, saving and loading of bindings. There is a sample that shows how it's done. Except it doesn't work. I see it in the playerprefs, I see it reloading it, I don't see the input map changing. And again, everything is hidden behind API calls and no way to properly debug. Again, this should be built-in not require messing around.

Six, internationalization. When using a non-US keyboard, the "Listen" button in the beautiful setup wizard detects them as if I was using a US keyboard. But in-game (e.g. using the code of the Rebind sample) it shows them properly (i.e. my keyboard). Why does it understand non-US keyboards in one place, but not in the other?

Seven, events. It's great that the system can directly send out Unity and C# events. It's a mess that they work differently, and that you can't just hook up a function to a key press, but need to receive and parse the InputAction.CallbackContext.

Eight, cool that I can query at runtime the names of inputs I have configured (again, the rebinding sample shows well how that's done). Stupid that I can't assign my own names. For example, when I set up a value/axis control, it is always "negative" and "positive". Being able to give this a display name would make it so easy to have these controls show to the player as, e.g."rotate left" and "rotate right", with the full control being in the input manager. No luck, more code and manual handling and if statements are needed to handle that. Please add a displayName to bindings.


In summary, I think it's a big improvement in general, and a few steps back in some of the easiest and most common use cases. Looking forward to the next versions and improvements. I especially would wish for making easy use cases easier to implement and more transparency into what's going on inside the system at runtime to debug issues.

 

I want to add one more unnecessary headaches:

The rebind example doesn't work with the generated C# class. That really could've been mentioned somewhere.

 

One more about the PlayerInputUI component:

Why do SendMessage, Unity Events and C# Events all work COMPLETELY DIFFERENT ?

SendMessage wants an InputValue parameter on the method to call. Unity Events want InputAction.CallbackContext that you then parse for phase, etc. and C# events can't trigger on the action directly but subscribe to a specific phase.

 

9 days later, it is time to update my first impression. What I'm about to say may sound harsh, but I am actually trying to be mild and civil. What I'd really like to say is quite a bit unsuitable for writing.

Avoid the new input system at all cost

I regret moving over. I regret wasting two weeks on it. I regret the damage I've done to my players, my game's review score and my own sanity. I'm now going to buy Rewired and burn every last piece of new input system code I have in my project to the ground. In half a year of working on my game, my motivation has never been lower, my frustration has never been higher, and never before have I seriously thought about dumping Unity and using Unreal Engine for future projects. And I've been using Unity since version 2.0 over 10 years ago.

The only good thing I have to say about it is that the window for assigning inputs (the one that opens when you double-click an input bindings asset) is sweet. It's well done and easy to use.

Everything else about the new input system is a trainwreck. Things break randomly. Things don't work for my players despite me having extensively tested them. I've done four tiny builds (just a menu) and given it to players to test, and for some of them it works and for some of them it doesn't. A stupid menu that consists of a few standard UI buttons. How is that even possible? I've submitted a bug report and not heard back.
Even the input handling itself is crap. And I mean crap compared to the OLD input system. Simple things like WASD movement suddenly feel off, keys stick for maybe half a second after releasing them, the right mouse button registers as clicked when you start a scene in the editor and the mouse cursor is outside the editor view when the scene actually starts (but only the right button, not the middle or left) and a whole bunch of other oddities.
The documentation is the worst I've seen in the Unity sphere. The main Unity documentation is excellent. Really great, one of the best I know. The documentation for the new input system is incomplete, misleading, difficult to understand and on the level of abandoned hobby projects.

I've tried to work around things, re-worked how I use the system multiple times, watched a metric ton of YouTube videos, read at least a dozen articles by other people explaining how to use the system and experimented a lot. I still can't get basic stuff to work reliably. I've pushed out a dozen updates to my players with various attempts to fix all the issues that switching introduced, and some of them worked for some people, but none of them ever worked for all of them.

It's impossible to make a game with that kind of obscure failures. Maybe it's possible for a large game studio that can put one or two coders aside to figure all this out, or maybe to internally fork the system and fix its flaws or whatever. For a one-man indie show, the input system is the biggest failure and setback that my game has experienced.

Avoid the new input system at all cost. You've been warned.

 

Another week later, I'll close this with a final remark:

I made the terrible mistake of switching a live game to the new input system, and the price I've paid is devastating. My game went from largely positive to mixed reviews on Steam, player count dropped to half, and this episode - two weeks of broken input handling - may have well sunk the game.

I can't stress enough that everything worked in testing for me, both in editor and in build, and broke for the majority of my players. That is inexcusable, it's impossible for a small indie dev without a dedicated testing team with a variety of hardware to catch.

I'm heartbroken. Trying out the new input system on a live game is the biggest mistake I've made in 25 years of game development.