Most Input System writeups cover the same ground — Action Maps, Bindings, PlayerInput setup. Two things worth knowing that don't show up until you're past the tutorial stage:
The double-subscription bug. With the direct script method, inputActions.Player.Jump.performed += OnJump in OnEnable() needs a matching -= OnJump in OnDisable(). Skip it, and if OnEnable() fires again — scene reload, object re-enable — you're subscribed twice, and one button press runs your jump logic twice. No error, no warning, just a subtly wrong behavior that looks like a physics bug until you check your event subscriptions.
The migration trap. If you're moving an existing project off the old Input Manager, Active Input Handling has a "Both" mode specifically for this — old Input.GetAxis() calls and the new system coexist while you migrate file by file. Switch to "Input System Package (New)" before every old call is gone, and you get a wall of null reference errors all at once, because the old API is now silently dead. Stay in "Both" until migration is actually complete, not "mostly complete."
One structural point worth internalizing early: Action → Binding → Action Map → Input Action Asset is the whole mental model. Your code only ever reads the abstract action ("Move", "Jump") — never which physical key or button caused it. Once that separation actually clicks, gamepad/keyboard/touch support stops being three separate code paths and becomes one.
Full setup with both the PlayerInput ("Send Messages") and direct-reference methods, plus the old-to-new migration table: https://digitaltoolify.blogspot.com/2026/06/unity-input-system-explained-complete.html
Anyone still on the old Input Manager for a shipping project, or has it fully replaced GetAxis/GetKeyDown for you at this point?
Top comments (0)