Why you should switch to Unity's New Input System (and how easy it is)
HTML-код
- Опубликовано: 22 май 2024
- prf.hn/l/dlXmbpN - Asset Store Black Friday Sale!
Use Code - JASONWEIMANNBF22 for additional 10% off (cart must be over $100 for it to apply)
www.kenney.nl/ - Check out the KennyNL Assets
game.courses/beginner/ - Free GameDev Course for Beginners
bit.ly/3sKGagG - Game Architecture Course - Advanced Course
unity3d.group - Join the Group (facebook)
/ @unity3dcollege - Join the Channel
I think now's a perfect opportunity to leave a copy of a comment I posted on one of Brackeys' New Input system videos several months ago (note that this implementation is built around the "Generate C# class" option and interfacing with your input directly in code like what Jason did in his previous New Input system video when it was still in preview):
I'm sure there are at least a few users watching this wondering how to go about setting up multiple unique controllers for co-op/local multiplayer, and keeping any given input asset instance from receiving input data from EVERY SINGLE active device. Having struggled to figure this out myself months ago, especially since I also wanted to make it work with the auto-generated C# class feature as well to take advantage of all the safety features C# provides when working with it, I thought I'd share the solution I came up with, which uses a lesser-talked about feature of the New Input System called Input Users (note that in my example, "InputReference" is the name of the input action asset and by extension the C# class):
using UnityEngine.InputSystem;
using UnityEngine.InputSystem.Users;
public class Player
{
public readonly InputReference Input;
private InputUser User { get; }
public Player(params InputDevice[] devices)
{
Input = new InputReference();
User = InputUser.CreateUserWithoutPairedDevices()
User.AssociateActionsWithUser(Input);
for (int i = 0; i < devices.Length; i++)
InputUser.PerformPairingWithDevice(devices[i], User, i == 0 ? InputUserPairingOptions.UnpairCurrentDevicesFromUser : InputUserPairingOptions.None);
}
public void Decommission()
{
User.UnpairDevicesAndRemoveUser();
}
}
With this class, I could create a unique Player object for each active player. Notice in the constructor that in addition to the input action asset instance, an InputUser is also created, with which the input asset instance is then paired. Once that's done, each input device passed in to the constructor (the params keyword allows for any number of devices, letting me pass in, say, either a single controller, or a keyboard and mouse as a pair), is also paired to the InputUser. Now, the input asset instance will only receive events from those specific devices_, which lets me register for a specific player's move/jump/whatever as opposed to _every player's move/jump/whatever and then needing to figure out which device it originated from.
Note there's also a decommissioning method, to clear the user and pairings out if you need to deactivate a player. This will ensure device pairings, input user entries, and other behind-the-scenes things get cleaned up when you no longer need them.
I'm currently working on exactly such a game and the new inputsystem was a huge pain. The inputmanager from unity bugged out on me so often and i eventually wrote my own eventsystem for ui navigation. Your method however sounds better. Well, good to know for my next game
And who's reading all that
I tried using it, but I kept running into issues that I couldn't figure out. I got frustrated after like 4 days of trying to resolve a simple issue. Granted I'm newer to unity development, but it felt like the old input system was much friendlier and easier to use for a new developer.
The "new” input system is definitely a great improvement. Porting games to consoles with different controllers is great. Just add inputs to the actions and it should work as the code is just interested in the actions. I was involved in adding hand tracking to a VR-game recently where we created a virtual controller that translated gestures to button and sticks, then mapped that in the input system along with the ordinary control inputs.
Thank you very much, saw a few other tutorials before and this was very straight forward to me. Been so used to the old input system but the new one seems very powerful to customize and use for multiple inputs
The new input system looks great. Would love a video going more in-depth on the other features.
Thanks for this! Would love to see a vid on a deeper dive of the new input system!
Nice video ! Would love to hear more about the other more advances options too !
I switched to the new input system a couple of years ago and I really love having all the input actions and bindings in one place. Also if you want to support keyboard and gamepad controls, it is incredibly useful as you can also define a deadzones for the gamepad sticks and don't have to do this every time per code.
Having the actions defined in a single place also allows for easier rebinding and displaying of the bindings. There is a tool for the new input system I made on the asset store, called Input Icons for TMPro which allows you to easily display your action bindings in textmesh pro texts. It is quite handy as it automatically updates the displayed icons when you switch devices.
Definitely curious about the player input manager system you mentioned!
Thanks for a great and succinct walkthrough of this. Quick and to the point and helped me get cut over to the new input system, which is way better for a number of reasons IMO. Much appreciated!
Thank you for explaining this in a detailed and simplifying way. I'm developing a 2d narrative stealth adventure which has a lot of different inputs in a lot of scripts and managers, not just player movement and the documentation and other tutorials were totally over my level of development skills. This helped me a lot, due to the fact that my inputs are fairly simple but I just wanted to have an universal gamepad button layout. Cheers!
It's very interesting and awesome stuff, as always. Thanks, Jason!
Amazing, Thanks for showing how simple it is!
Thank you for this video!
Brackeys had a video on this, but it's from 4 years ago and the system seems to have worked a bit differently back then.
Thanks! It's the trigger I needed to take a closer look :) Seems to be useful!
I'll have to take your word for it, investing in some assets from black friday sale.
Would be really cool to see your take on a Input Manager class using the New Input System, something that handles inputs for the entire game.
It's not a great design when one class does something for all the contexts of the entire game, unless it's a really basic utility.
Inputs in menu, world, inventory, puzzles, dialogue, name it - all could make use of different adapters for engine's Input System - there's hardly any need for a layer in-between.
@@DungeonNumber5 Not sure if it's exactly what you're looking for but in my latest tutorial series on how to make Defender in Unity I created a UserInput class that implements a IUserInput interface which allows me to "mock" user input in my unit tests but it essentially handles ALL user input for the game and it's used everywhere in my game.
@@midniteoilsoftware cool idea, I'll definitely watch (I had it on watch later already 😆), personally I unit test only the domain, but for that I decouple unity from the domain so that's a bit more complicated than usual in term of dev code
One annoying problem I ran into on the new Input System is gated controls, what I mean by that is, for example, ctrl+S. If you have a control which uses S for something, and you have one which uses CTRL+S, if you press CTRL+S it doens't block the S control from working, so basically two actions happen at the same time.
You can code it yourself by locking the controls off using IF statements to make sure the S only control doesnt fire if CTRL is being held, but the new system should do this itself.
I like the new input system, makes mobileinput a lot easier. A video on coop and splitscreen would be nice.
100% interested in the player input manager system. would like to see as much as I can on the input system. it seems very powerful but there is only so much content on its alternate use cases.
THX allot for the simle infrmation - so many ways to do the new input system but you nailed it for me. thx. i a working right now on space shootter with net code/ didnt kniw the newinout can help me with multy players an i would be thankfull for you showing us how !
The new unput system takes a little bit of getting used to for me , but I think it makes handling different controllers and platforms a lot easier. I would love to see how you approach handling gyroscope input for mobile alongside touch. This has been bugging me for a while. Also be great to have a way of testing mobile gyroscope input in the editor.
We have to switch from Xinput to something platform agnostic for MotorCubs RC. This is exactly the video I was looking for.
Jason, I was at Target a few days ago and saw a guy who looked just like you, he had two little boys with him. He looked at me for a bit as he was leaving. Of course this is in Minnesota. I seriously want to know if it was you. I hope you had a great Thanksgiving. You're so awesome Jason.
Largeast barrier of NIS is overcomplicated binding options which is hard to distinguish each other, and similar names which hard to distinguish each other.
I did this months ago, now I learning FMOD.
Please create a video on the UI Input Module! It sounds very useful
Let's dive into input system's other features. Would love to learn more.
thank you
Dude I think a video on split screen would be legendary!
i tried to switch a couple of weeks ago but was a mess in my head, i mix all the different methods , if u can explain in a really easy way i will be grateful :)
Very impressive!
Will there be any tutorials on this? So far I'm not convinced to switch yet because I still don't know what any of it means and how can I set up for my own personal projects, especially for gamepad support.
The problem I have with the new input system is that it turns three lines of code into a 1 line + 5 setup steps in unity. It seems to be ideal for some use cases but I don't see how that workflow makes the overall development experience better. Maybe it makes way more sense if you need the new features.
the big reason for using it for me is that it makes it way easier to change controls like keybinds or changing to a controller and back. it also handles the headaches you get when doing that via the old system, such as making the keyboard inputs not work when your actively pressing the buttons on the joystick, but if you let go of the joystick it all flips. you will find out that the couple of extra lines that you have to write, will save you a heap of lines down the track when you get into setting up keybinds. i don't think you would get much advantage if your building for mobile but.
More setup at start: WAY less headache later. Yeah I’ll take more setup
@@nemesis8508 never really had a bad time with the old system, probaby due to the architecture that I use, but I might give it a try. Maybe the other modes fit my use case better.
Great tips Jason, so I will preface this by saying it has been a while since pulling up unity's new input system. When I did the last time it felt so complicated and over engineered compared to the traditional system I immediately forgot about it.
I still happen to find the way Playmaker handles input super simple and convenient to use. That being said, it looks like Unity have been making improvements. Of course when all is said and done, 'Rewired' shines as the most convenient and robust and sensibly engineered input system there is to date for Unity. Overall great job 👍
It gives options, but sometimes you also need to dig deep to make some configurations work, like two people on one keyboard, or that everyone can use mouse for UI until game starts (don't remember exactly, but it messed with player joining). Sometimes it looks like you need to write your own input manager, and this kinda defeats the point of new input system. And also it has issues with some hardware for some reason, that I hear was not an issue made in projects in Rewired. But for non local coop, it's great.
Is there any settled position on whether generating a C# class or just using the SendMessage system in the video above is more performant? I've been generating my own class, but honestly it seems like a pain in the rear compared to just using the Player Input component as seen above. Is there any obvious downside to using the Player Input compnent?
Have you talked about the visual scripting in unity before? I found it a lot easier to code with then c# for a beginner, and it allows editing in real time with the game, which is pretty cool.
That actually does look super simple and easy now, I remember trying it when brackey covered it 4 years ago and it looked like a mess
Thanks Jason. Its frustrating that I have to keep relearning unity sloppy messes like this. I'm really wishing I would have bitten the bullet and learned C instead. I feel like dragging unity along is adding more work than just doing it the hard way the first time.
@Unity3dCollege been playing around with this since I saw you video, how do I go about having two different jumps, for a platformer in the old system it was easy to have a variable height difference with getbuttondown or getbuttonup etc, how do you do this with this?
Hi Jason thanks for making these videos
really appreciate it
So with the Unity Starter Assets FPS Controller I got the FPS Controller in my game, and on my smartphone.
But the Move sprite to move around forward and back, stays in place where it is, and so does the look pad sprite.
I noticed from Playing Call of Duty Mobile that the move sprite, and the look pad sprite appear anywhere on the screen depending where you place your finger on the screen, on your smartphone.
Can you adjust the settings on the FPS Controller in the Inspector panel to make the sprites appear when you place your finger on the screen instead of the move and look sprites being fixed in one place on the screen, like a joystick float
If not is this something that has to be coded in C# for the sprites to appear on the screen when the player presses their finger on the touchscreen on their smartphones?
Jason is aging 20 years every 3 months
Babies... :) they age u quick lol. And I really need to shave soon :)
Or he’s been messing with the Physics time step. That does things to a person.
Like Dude I haven't been watching for almost a year and I come back to find someone who looks like their training to have gandolf's beard
@@Unity3dCollege haha thats great Im only 19 and i feel this my daughter is 2 and i feel like im 100 already
Thats the way i feel
that local multiplayer input module is very interesting
tbh, I think most legit game devs have some sort of custom input system they are completely comfortable with. Also it's good to have an easy dirty way for prototype purposes. If the initial setup is too involved, then nothing gets going and ideas just stagnate. Blank file equals zero entry barrier :D jk, but you better have a boiler-plate/template you are comfortable with, to get things going.
I want to hear more about split screen please!
Interested in the split screen UI part
does it still use the Vertical and Horizontal?
it's easier to use joysticks like that..
Im interested in a Player Input Manager video.
hi guys, hi Jason, i had a question...back to the birds game V2, if a add an in-game button to change _launchForce by a +100 (and another for -100)... how do i change the serial field with an input on the new script, that affects the other script (or affects the bird gameObject)... because is not as simple as call function, so i'm lost. Unless I create a function in Bird, then the Button script calls out for that function. mmm be right back. 🤔... Yeah that worked😅... now when tried to add the lower force it stopped🤣
Id love to know more in split screens. Theres just simply not enough couch coop these days and id like to do that in my game.
I'm still pretty new to programming, but I usually do move input in fixed update and send the movement through update. Was that the mistake? It doesn't seem like it would make that much of a difference. It might feel a little laggy though
Well that was weird, you answered that as soon as I unpaused the video hah
Can you make a video on new input system how to use it for mobile games...I am kinda confused in that
The problem with new input system, it not works with webgl build. Should I roll back to old one? Its not possible to disable new new one! So bad
Is there a way to make it work when the Game tab doesn't have the focus?
Unity Sponsorship ,congrats.
The problem with the PlayerInput component is, if you have a couch coop game, and you plan on having two playerinput components in a given scene, one of them will basically not work. So I find it way more interesting to have unity generate a C# class for your input map and use the provided interfaces to hook up the events
Do you have a tutorial on how to do that?
@@timeSlidrGaming Sorry, I don't, I just looked into how unity generates the C# class for the inputs, I recommend you open a blank project and experiment with input schemes, input controls and what not :)
How do i tie the new input system with on-screen virtual joysticks? I'm working on a mobile twin stick shooter and need my joysticks to detect drag and quick taps separately.
There are onscreen button and joystick scripts that you add to existing ui elements and then connect those to input actions in input system.
Unrelated; but what is everyone's opinion of the new UI Toolkit. I switched over to the new UI system for the reasons you and others have shown, but it seems like the UI Toolkit is still too young or not good enough yet to switch over as well?
Thank you for creating such a good Content. I wish you turn this guide into a series, to implement the NEW Input System in our Games, for any use case. 🎮👍🏻
Based on my previous experience, (and what I've learned from some GameDev courses): it's much easier to First Prototype your game with the Old Input System, because it's easier to Test and Debug by just invoking a line such as Input.GetKeydown(number) (or something similar).... in the Update() methods of any Script... The biggest Pro of the Old Input System is it's simplicity in terms of lines of code in our Scripts,... (and that we're already used to it)
...THEN: when your Prototype has been Tested, Balanced and reaches a state of 'almost ready, now we're Polishing...adding some GAME JUICE' you should use the New Input System, and re-test, Re-Debug the new features you're adding (such as last moment VFXs, SFXs, Game Juice, etc.). Testing the New Input System Implementation, at least for 1 week, is necessary for getting rid of last moment Bugs.
yeah I gotta say I'm having an absolutely miserable time trying to get the new input system working because so many tutorials and examples use the old system (including unitys own examples of a character controller), but also because so many of the tutorials on the new system use it in completely different ways. Its crazy how different they all are, and somehow so far after 5 hours I haven't been able to use any of them to actually do what I want (just move a third person character around without using physics/rigidbody)
I'm always discouraged when my project files become too big I'm always focused on organizing rather then making something how do I keep motivated when it's just too much to process?
It's like you are cooking but then you cannot continue doing stuff because everything becomes a mess. The right way around it is by refactoring and architecturing your game to scale and receive more features. Unfortunately no one really teaches how to do that.
Is new imput system better than the rewired for console setup?
How does the new input system compete against Rewired?
My issue with the new input system has to do with holding down a key. The action will only call the function three times, start, performed, and stopped. There is no continuous hold event from what I can see. You can check if it is being performed but there isn't an event being called while its being performed. Meaning you have to run some sort of coroutine or while loop to check if it is being performed do a continuous hold which is very tedious. This was the case when I first tried the new input system about a year ago, if the new versions have fixed this that would be amazing.. If anyone has a solution to that Id appreciate it.
The best solution I know is to have a boolean variable to track if the button is down. Set it to true on performed, then back to false on stopped. That at least helps you avoid polling for the input every frame. Your comment is from 7 months ago so you probably already found a solution.
I tried the new input system and i can say it is really good. But just like many others, I prefer to code my own input system with keybindings that players can do on their own at runtime. It just feels like I have much more control that way
Samyam has a Video on how to build a Player controlled rebind System for the New Input System, which works well :)! Not saying you or anybody needs to switch, but there are awesome resources on it out there.
I havent done it myself but I am pretty sure you can do runtime keybindings with the input system as well.
You have a LOT of control with the new input system. Feels like a waste of time making your own at this point
Yeah, same here. Of course keybindings can be done with the new one, too, but the Action Maps don't allow enough control of how every single key overlaps/is prioritised. I prefer doing such things in code. I guess it all depends on what kind of game one makes..
The new input system works as a charm to me when I'm making gamepad controlled game, I can switch from keyboard to gamepad in any moment and call events when this happen, even working with local coop. It needs more previous knowledge but once you learn enough, it totally worth it.
transform.Translate(new Vector2(horizontalInput * Time.deltaTime * 3, 0));
transform.Translate(new Vector2(0, verticalInput * Time.deltaTime * 3)); I this for movement how can i add on move and onlook () to it.
Good content, so here's your like and engagement...
The new input system fixed the right stick issue on my PS4 controller because when I used the old input system with my PS4 controller it got stick drift
The new system uses dead zones by default, while the old one only used dead zones on in the outer I believe (i.e. not when the stick is idle)
"If you like this obscure feature hit the like button", lol
Before the new input system, I bought Rewired because it was necessary. Since the new input system, I use Rewired because I find it's still superior and easier to use. Now please don't mistake me - I'm not poo-poo'ing on the new input system; it is INFINITELY better than what was there before, and if you don't have the money for Rewired, I don't think it's a necessary addon. However, if you have some disposable income and love you some QOL plugins, I highly recommend.
It takes too much time to set it up. With the old input system, I just type. As someone who develops in Unity, I wish it would just stay out of my way and let me make games.
Does it work well if you also have controller support?
absolutely yes
I think anyone serious with good input will just buy Rewired.
I wrote this comment to let you know that I'm curious about the "Player Input Manager System".
The mistake is, that it should use fixed delta time instead?
Jason is starting to look like Rick Rubin
Anybody noticed the nodepad at the end? :P
the old system makes so much more sense to me argghh
Yeah idk if I like the new input system. I'm trying to learn C#, so any step away from C# and towards whatever unity is trying to build is kind of contradictory to my goals.
Hell, I was having trouble trying to figure out how to use Unity's BoxCast function, couldn't figure it out so I made my own lol
That's the benefits of core programming.
The cons though, is my BoxCast isn't as good as Unity's. When you walked into a wall to the right, you coulnt then walk up and right forcing your character up. You could only walk up.
Ive since learned Unity's BoxCast and I know the mistake in my old code was, but that was quite an adventure.
It sounds like this would be better for complex 3D games. I'm only working with 2D at the moment, so I'll keep this in mind for later. Maybe it's better for 3D
@PitiIT and @Samyam have awesome Tutorials on the New Input System! I absolutely recommend giving their Videos a watch as well if you're interested in the New Input System =) There are a lot of ways to implement the System and I love the flexibility it brings.
New Input system is realy great. But I had to return to the old one because two years after realese New Input system is still not compatible with Unity Remote 5. So if you are working on mobile games - think carefully before switching to the new system.
Wait I thought this was the cooking guy
you need to add the package Input System before using it in the new Unity project ...
Is this how you gonna look like when you're working 20+ years in the gaming industry?
That vector operation order really hurts
Am I the only who thinks that vector * modifier * deltaTime makes more sense? I know it casts all terms to vector3 but it doesn't really hurt performance noticeably unless you heavily overdo it.
The new input system is great, but dear lord it needs work when it comes to local multiplayer support.
I personally don't use the new input system for very good reason
Unlike the old input system the New input system don't support therd party controller the last time I checked
...what are they doing? The legacy version is a lot simpler. Input.getkeydown(keycode), done, I really hate that they are pushing the new one
It's working on the editor but NOT on the build. Breh.
I do not like the new system, as it has so much problems/bugs. I do get the point, that this could help users without writing code, but this could be done with another script, too. I do not get the point why to use this.
What bugs did you run into?
It's not a bad system, I like the versatility
Biggest reason to use new input system is less latency. It provides "frame independent movement."
just seems like a pointless complication for a system which was simpler and worked fine already, if they had made it as easy I would accept the change for increased functionality
Unless I see someone make an actually game with the new input system, I'm not using it. Too risky.
Converted my game to input system and I was able to get 2 frames of input lag. With Input manager it is always at least 3, more if you use vsync.
No.
Time.deltatime in physics? kkk No. =)
It auto uses fixeddeltatime in fixed update, was there some other issue I missed in the example though?
@@Unity3dCollege My point here was not fixeddeltatime, but the use of time.deltatime in anything in physics is a bit meaningless, in general.
When you apply a force, you can choose any value you like, including Time.deltatime, but the reason for time.deltime here is not the frame difference.
If you don't use it, the worst case scenario is to change the speed value, after all, speed * time.deltatime is just a value. this is not a bug, but an inappropriate use of time.deltatime (not a bug, after all, I can use any value here - physics2d takes care of that problem). The physics engine takes care of extrapolating the values between frames to add force or make movement. This is not the case if movement was by Transform.Position.
Lastly, I didn't see the Vector in addforce, being a float. I didn't understand what value, in the end, Unity considered to compile, because in my head I should expect at least one Venctor2. What will be the vector2 he used? (sorry about using some help from Google translator) =)
This is the most annoying part of unity. You are starting to learn unity with all those old system tutorials, but oh wait there is a new input system, a new UI system, new viewport, new things etc.
People are always trying to duck and dodge new and improved systems rather than "waste" (as they perceive it) 10 minutes of their time reading about how to use the new one, lol. Just like people ducking URP and HDRP and clinging to BIRP (built-in render pipeline) and plenty other examples ... when I decided to write an input layer I literally browsed the documentation for about 10 or 15 minutes, I was like OK this is easy, I pulled in an example configuration and looked at that a few minutes and then I made my own new version and had it working right away. In total, maybe _30 minutes_ and that's only because I'm a really cautious and thorough researcher and decision-maker. That's been a long time ago now, and I couldn't imagine using all the old soon-to-be deprecated junk to avoid migrating to better things ... that's supposed to be a _desirable_ feature of an engine: the developers replace old junk with better and more modern things and provide regular updates. If you're not taking advantage of it, there are _much_ simpler, old engines out there that use DirectX9 and very simple scripting languages that would probably be better for you, lol
Time.fixedDeltaTime and yes, please do a video on multiplayer ui and camera setup with the input system
3:18 Time.fixedDeltaTime :)