I've been trying to research both input systems Unity has made (the legacy input manager and the new input system package) and decide which one I should use in my game. Some info about my game; it's going to be a four player split-screen multiplayer game that I'd like to release on Steam (and the Nintendo Switch, if at all possible), and I've already written a script that reads input values from the legacy input manager (via GetAxis and GetKey) and then invokes Unity Events with said values (though I haven't implemented a way to remap/save remapped controls yet). But from what I've seen, the new input system looks like it's more intuitive and has more features (hence why I'm considering switching over). These are my main concerns/questions when it comes to switching/not switching Like I said above, I've already written a system that works great for reading input based around the legacy input manager, and I'm not quite sure what would be the best way to re-write it to work with the new input system. I've seen some stuff about ReadValue<T> and ReadUnprocessedValue<T>, but I'm not sure about the best way to get a reference to a control to do that. How would you make sure that every player's character moves separately? Is that handled automatically? Would I have to use their "PlayerInput" component to do that? I haven't really been able to find out anything about that in the manual. One of the assets I'm using (Naninovel), says that the minimum supported version of the new input system package is 1.1, which isn't verified with my version of Unity (2020.3.19f1). Is it a big deal to use a version of a package that isn't listed as verified? If I don't switch over, I'd need to figure out a good way to let the players remap their controls (I don't think that I'd have any problem figuring out how to save it once I figured out how to do the remapping). Would I need to make 112 input axes in the input manager? (28 input axes to choose from in the drop-down in the input manager X four joysticks/players) Also, I've noticed that there are some axes that respond to the same things on the controller that I've been testing with, and there are others that don't seem to respond to anything, and so I'm not sure if I should exclude those axes from any input checks, or if it would respond differently depending on the controller/platform. For example, my setup is an Xbox controller on Windows, and the 3rd axis responds with a negative value when I press the LT on my controller, while the 9th axis responds with the same number only positive, but if someone had, say, a Playstation controller on a Mac, would the 3rd axis still respond with the inverted value of the 9th axis when they press their controller's equivalent of the left trigger? Or could it correspond to, say, up/down on their D-Pad? The whole thing of just assigning inputs to things like "axis 15" or "axis 5" instead of something more like "right stick left/right" makes me a little worried about that sort of thing. I've seen something under the limitations section of the manual for the new input system that says "PlayerInput split-screen support does not work with Cinemachine virtual cameras". I'm using Cinemachine virtual cameras in a split-screen setup, so will the new input system not work with that? If I don't switch over, is there any way to make the controllers vibrate/rumble with the old input manager? Do both the legacy input manager and the new input system package work with Steam and the Nintendo Switch? Does one work better with the aforementioned platforms than the other, or are they both about the same when it comes to compatibility? With either system, what would be the best way to show controls on-screen? Something like "Press B to jump" when using a controller and "Press spacebar to jump" when using the keyboard. In short, is it worth it to switch over to the new input system package even though I've already got a (sort of complete) system built on the legacy one?