Hi Everyone,

I’m starting to learn about the new Input system with Input actions and I wanted to check what are the difference between this and writing an Input.GetKeyDown()? Is there any benefits in using one of the other?

Many thanks.

It’s two different systems. Input.GetKeyDown() is the old system.

Personally I am still using the old system for ALL of my games because it just works.

The only exception is for my VR game where I had no choice since the oculus kit requires you to use the new system, at least AFAICT

So, at first glance, all the YouTube videos will gush about it, and show you the first 45 minutes worth of setting up an ActionMap and call it a day. That really can’t give anyone a good understanding of the system or its benefits. And it definitely doesn’t highlight all the little nagging issues that come from having such a new and overengineered spaghetti of beta code that is still being worked out.

I had to do a deep dive into writing a bit of code at the low end of the Input System to start to appreciate the structure a bit more.

At the very lowest level, it’s almost identical. And you can use them in almost identical ways, with just some funny names.

#if ENABLE_INPUT_SYSTEM
    if (Keyboard.current.cKey.wasPressedThisFrame)
#else
    if (Input.GetKeyDown(KeyCode.C))
#endif
The “.current” there gives a hint at one big strength of the InputSystem. Multiple controllers may be active. Doing Couch Coop or want someone to be able to switch from Gamepad to Keyboard seamlessly? The new system wraps every button, potentiometer, joystick and gyro into InputControl, and an InputDevice is just a collection of InputControl elements.
Some controls are really ambiguous, when you get down to it. The DPad of a Gamepad is registered both under a 2D Joystick-like control and also a set of four buttons simultaneously, so you can respond to either one depending on what would make your code make more sense.
The ActionMap is just a structured collection of bindings. The Input System is saying “okay, for every current device, for every binding in the current action map, save that state and notify any/all code that has been subscribed to the events.” I do wish there was a better way of aggregating ActionMaps so you don’t have to repeat your bindings for global keys in all of your specialized maps like walking, driving, swimming, flying, but the idea that all of the bindings are in these groups helps make things more flexible to users’ preferences and accessible for handicap play.
And saving and loading and letting users re-map their bindings is all pretty much a single line of code.
At the highest level, there is still a lot of rough edges and things I still find overburdensome and annoying. The PlayerInput class is finicky and has changed a lot in the last several iterations of public releases. The good news is, if you don’t like it, you don’t need to use it. You can work with ActionMaps directly, or you can work with InputControls directly.
 halley:
So, at first glance, all the YouTube videos will gush about it, and show you the first 45 minutes worth of setting up an ActionMap and call it a day. That really can’t give anyone a good understanding of the system or its benefits. And it definitely doesn’t highlight all the little nagging issues that come from having such a new and overengineered spaghetti of beta code that is still being worked out.
I had to do a deep dive into writing a bit of code at the low end of the Input System to start to appreciate the structure a bit more.
At the very lowest level, it’s almost identical. And you can use them in almost identical ways, with just some funny names.
#if ENABLE_INPUT_SYSTEM
    if (Keyboard.current.cKey.wasPressedThisFrame)
#else
    if (Input.GetKeyDown(KeyCode.C))
#endif
The “.current” there gives a hint at one big strength of the InputSystem. Multiple controllers may be active. Doing Couch Coop or want someone to be able to switch from Gamepad to Keyboard seamlessly? The new system wraps every button, potentiometer, joystick and gyro into InputControl, and an InputDevice is just a collection of InputControl elements.
Some controls are really ambiguous, when you get down to it. The DPad of a Gamepad is registered both under a 2D Joystick-like control and also a set of four buttons simultaneously, so you can respond to either one depending on what would make your code make more sense.
The ActionMap is just a structured collection of bindings. The Input System is saying “okay, for every current device, for every binding in the current action map, save that state and notify any/all code that has been subscribed to the events.” I do wish there was a better way of aggregating ActionMaps so you don’t have to repeat your bindings for global keys in all of your specialized maps like walking, driving, swimming, flying, but the idea that all of the bindings are in these groups helps make things more flexible to users’ preferences and accessible for handicap play.
And saving and loading and letting users re-map their bindings is all pretty much a single line of code.
At the highest level, there is still a lot of rough edges and things I still find overburdensome and annoying. The PlayerInput class is finicky and has changed a lot in the last several iterations of public releases. The good news is, if you don’t like it, you don’t need to use it. You can work with ActionMaps directly, or you can work with InputControls directly.
Hi Halley,
Thank you very much for the detailed answer, at this I only tried when Importing a small game to Android following a course on Udemy and for simple tasks like moving and simple attacks I did see any difference in using the Input System, however as soon as I get on more intermediate level I will give it a go, thank you.
              
I really like new system because it only listen when you hit button and not in update method and also you set your binding for specific action e.g. Jump and you map it for all input controllers. Gamepad,Keyboard or whatever and then in your script you just work with the action not with a specific key. That is much better then old system.
              
@Vandereck  There is a page in the manual which I wish I head read before diving into the new input system. It actually gives a nice overview and tells you that you can completely bypass the input actions if you so desire. Maybe it will help you to get oriented.
https://docs.unity3d.com/Packages/com.unity.inputsystem@1.5/manual/Workflows.html
Hi Everyone,
I’m starting to learn about the new Input system with Input actions and I wanted to check what are the difference between this and writing an Input.GetKeyDown()? Is there any benefits in using one of the other?
Many thanks.
If you are using the keyboard there is no difference. But now let say you need to also check that the gamepad South (A) button has been pressed. With Input.GetKeyDown() no deal, you will need to use Input.GetButton(). With the new input system you can bind your key and your gamepad button to the same InputAction and then check it with either:
if (controls.myAction.wasStartedThisFrame) // started
if (controls.myAction.wasPerformedThisFrame) // continuing
if (controls.myAction.wasReleasedThisFrame) // stopped
Or you can have calls like that:
        controls.myAction.started += myAction;
        private myAction(CallbackContext context)
          //...
I recommend watching samyam’s videos on Youtube if you want to learn more about the new input system, she covered it pretty well.