A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'New Input System' started by runevision, Apr 12, 2016.
@runevision I haven't seen any news on the new New Input System, probably because there hasn't been any news yet but I'd like to know whether Microsoft Ink-like Pen / Stylus input is being thought about.
With the current Input System we're unable to (easily) get input from a Pen / Stylus because those usually disable Touch input and are dependent on the pressure applied to the tip of the Pen / Stylus. Something that is quite easily done in Android (Java) or UWP app.
Among Unity's most fundamental and necessary features for a game to function (not AR or VR or other niche features), its input manager is absolutely abhorrent and unacceptable. I have never used an engine which had an input manager as inflexible as Unity's. I can't even easily write my own input handler, which I would gladly do (and tried to with partial success), because, while Unity does expose all keyboard, mouse and joypad buttons via Input.GetButton, it does not have an equivalent for joystick axes. I'm not asking for anything obscure or uncommonly used like guitar hero controllers, this is something as absolutely ubiquitous as a GAME PAD. Name any system, it probably has dual axis controllers available for it, yet I cannot access even the so-subsumed standard Xbox 360 controller's axes through code. I cannot even assign cross-platform actions for the Xbox 360 controller because the axes change between operating systems, which could be solved through #if directives except I can't access axes period. Unity should handle these cross-platform problems internally, but instead they leave it up to the game developer using their engine, who is crippled by their inability to access the input manager's API or axes at all.
There are bare-bones frameworks with better controller support than Unity. At least with a framework I can figure out my own solution relatively easily. With Unity I am at the mercy of the developers who, for some reason, after 12 years of work put into Unity, still cannot muster the organization and motivation to implement a proper input manager for their engine. More mind-boggling is how nobody at this company had enough forward thinking to realize how the input manager in place today would be insufficient for anything but the most basic functionality, it's little more than a placeholder for the real input manager which has been put on the back burner perpetually for what are apparently more important features. Even still more mysterious is why nobody at this company will bother to complete Unity's API for accessing joysticks; I don't even need an input manager if I could just get access to this, and I know Unity has the functionality implemented to access joysticks if it can do so through the input manager. Developers simply refuse to do anything about it. Because more important features, or something. It would look something like this: Input.GetJoyAxis(Axis axis, JoyNum joyNum) BADDA BING BADDA BOOM that's all that's needed, I can figure out everything else from there.
The current "solution" is to either go around Unity and try to access controllers yourself (or buy an input manager that does this for you), or to write to the input manager every single possible virtual axis for how ever many local players you'll have in the game, which is a lot of unnecessary work. Only then may you write your own input manager and then, when the player wants to reassign their controls, you would access one of the total possible axes and associate it with another virtual virtual axis that can be reassigned at runtime. That looks like this, for example: Input.GetAxis("4thAxisJoystick1"), along with a big list of bad design--I mean, a big list of possible axes in your input manager, multiplied by local players. Good god. For a basic setup, that's: 2x left axis, 2x right axis, 2x dpad (Windows has no dpad button support and Linux has dpad button support only sometimes), 2x triggers, and with a local game that features 4 players, you're looking at 8 x 4 = 32 entries into the input manager, not including virtual axes that need to exist for systems besides the target OS.
One would get the impression that the people developing Unity are not game developers themselves, or develop mobile/web games exclusively that only use touch/pointer controls. It shouldn't be necessary to purchase a component to give Unity functionality it should come with as standard, esp. when that solution sits on a component that needs to be placed in every single scene you want your controls to work (???); it's like having to purchase your own steering wheel because the car you bought only steers to the right--sure, you can eventually get where you're going taking nothing but right turns, but it wastes time and energy and should be standard that the functionality be complete. I can't help but think Unity is incentivized to do things this way for the purpose of collecting a cut from the asset store from developers who are tired of the default input manager and need a real solution to input handling.
I'm going back to MonoGame, at least until Godot 3 is released. Godot has cross-platform action mapping with as many buttons and axes per action as your heart's content, and each action can be reassigned during runtime--this is a standard feature of this engine. Hey, you can even create actions on the fly during runtime, if you want--not sure why you'd want to but you can (maybe you're developing some kooky moddable game where custom actions would be useful to the player?) It's about as close to ideal as you can get. I strongly encourage you to emulate them. Wouldn't take you long to literally copy their design. IMO, the best system is the one created programmatically: one for loop, four iterations, assign all possible inputs per player in one sweep; save a config file to disk with each player's desired settings, modify it when necessary, move on to develop the rest of your game.
I hope that Unity will not forget that 99% of their user base don't care about AR/VR, they just want to spend less time fighting engine bugs, editor bugs and lack of basic features, like a real input system.
I'm still using Unity only because there are no serious competitors for 3D on mobile. We don't really like the engine, it's more of a lack of choice. The day a new big competitor appears, I think that Unity can lose a lot of their users pretty quickly. It's sad because many parts of the engine are well made, but the fundamentals are missing.
What's your definition of a serious competitor? Because off the top of my head both Godot and UE4 run on mobile.
So... do we have any information on the NEW New Input team? Sounds like y'all got disbanded in September; Is the new team picking up where you left off, or is this system being scrapped and restarted?
I'll second the frustrations expressed above. I've been following this thread since it was started last year and would love to get an update on the progress. A solid input API really is far more important and fundamental than the VR novelties that has been misguidedly pushed on developers and players for the past several years.
I'm so sad... I'm working on "up to 8 or 10" local multiplayer game... This asset could have saved my ass >___<
Will let you know!
Why we doesnt have similar for nested prefabs yet?
Well there is one for UI... but that got launched!
René posted an Input System Update here: https://forum.unity.com/threads/input-system-update.508660/
Can I persistently save/load key bindings in runtime?