New Input System overview in Unity - Deep Dive

Overview - New Input System overview

What is it?

The New Input System in Unity is a modern way to handle player controls and input devices like keyboards, mice, gamepads, and touchscreens. It lets you easily read and respond to player actions in your game or app. Unlike the old system, it supports many devices and complex input setups in a clean and flexible way. This system helps you manage inputs from different devices without writing complicated code.

Why it matters

Before the New Input System, handling multiple input devices was hard and messy, often requiring custom code for each device. Without it, games would struggle to support new controllers or complex input schemes, making player experience frustrating. This system solves that by providing a unified, easy-to-use way to manage inputs, so developers can focus on gameplay instead of device quirks. It makes games more accessible and adaptable to many platforms.

Where it fits

You should know basic Unity concepts like GameObjects, Components, and scripting before learning this. Understanding the old Input Manager helps but is not required. After mastering the New Input System, you can learn advanced input topics like input actions, control schemes, and integrating input with UI and gameplay logic.

Mental Model

Core Idea

The New Input System treats all input devices as sources of player actions, letting you define and respond to those actions in a flexible, device-independent way.

Think of it like...

It's like a universal remote control that can operate any TV, DVD player, or sound system without needing a different remote for each device.

┌─────────────────────────────┐
│       Input Devices         │
│ Keyboard, Mouse, Gamepad... │
└─────────────┬───────────────┘
              │
      ┌───────▼────────┐
      │ New Input System│
      │  (Input Actions)│
      └───────┬────────┘
              │
      ┌───────▼────────┐
      │ Game Logic & UI│
      └────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Input Devices Basics

Concept: Learn what input devices are and how they send signals to a computer or game.

Input devices include keyboards, mice, gamepads, touchscreens, and more. Each device sends signals when buttons are pressed, sticks moved, or screens touched. The game needs to listen to these signals to know what the player wants to do.

Result

You can identify different input devices and understand that they produce signals representing player actions.

Knowing what input devices do helps you appreciate why a system is needed to handle their signals in a unified way.

2

Foundation

Old vs New Input Systems in Unity

Concept: Compare the old Input Manager with the New Input System to see why the new one was created.

The old Input Manager uses fixed names and limited support for devices, making it hard to add new controllers or customize inputs. The New Input System uses input actions and maps, allowing flexible, device-independent input handling.

Result

You understand the limitations of the old system and the benefits the new system brings.

Recognizing the old system's limits clarifies why the new system's design is a big improvement.

3

Intermediate

Input Actions and Action Maps Explained

🤔Before reading on: do you think input actions are tied to specific devices or are device-independent? Commit to your answer.

Concept: Input Actions represent player intentions like 'Jump' or 'Move', and Action Maps group these actions logically.

Instead of reading raw button presses, you define actions like 'Jump' that can be triggered by any device button. Action Maps let you organize actions by game state, like 'Gameplay' or 'UI'. This abstraction makes input flexible and easier to manage.

Result

You can create input actions and maps that respond to player commands regardless of the device used.

Understanding input actions as device-independent commands is key to building adaptable input systems.

4

Intermediate

Setting Up Control Schemes

🤔Before reading on: do you think control schemes allow switching devices on the fly or require restarting the game? Commit to your answer.

Concept: Control Schemes define sets of devices and bindings for different play styles or platforms.

You can create control schemes like 'Keyboard & Mouse' or 'Gamepad' that specify which devices and buttons trigger actions. The system can switch between schemes automatically or manually, letting players use their preferred device seamlessly.

Result

Your game can support multiple input setups and switch between them smoothly.

Knowing how control schemes work helps you design games that feel natural on any device.

5

Intermediate

Reading Input in Code with Callbacks

🤔Before reading on: do you think input is checked every frame manually or can the system notify you automatically? Commit to your answer.

Concept: The New Input System uses callbacks to notify your code when actions happen, avoiding constant checking.

Instead of polling input every frame, you register functions to be called when an input action triggers. This event-driven model is efficient and clean, making your code easier to write and maintain.

Result

Your game reacts instantly to player input without wasting resources.

Understanding callbacks changes how you think about input handling from constant checking to event listening.

6

Advanced

Handling Multiple Players and Devices

🤔Before reading on: do you think one input system instance handles all players or do you need separate setups? Commit to your answer.

Concept: The system supports multiple players with separate devices and input contexts.

You can create multiple input user instances, each with their own devices and action maps. This allows local multiplayer games to handle inputs from different controllers independently and correctly.

Result

Your game can support multiple players on one machine with no input conflicts.

Knowing how to separate input contexts is essential for building multiplayer experiences.

7

Expert

Internals of Input Processing and Device Discovery

🤔Before reading on: do you think devices are fixed at game start or can be added/removed dynamically? Commit to your answer.

Concept: The system dynamically detects devices and processes input events through a layered architecture.

At runtime, the system listens for device connections and disconnections, updating input contexts automatically. Input events flow from hardware through device processors, then to input actions, and finally to your game code. This layered design allows filtering, remapping, and complex input handling.

Result

Your game adapts to device changes on the fly and processes inputs efficiently.

Understanding the dynamic and layered input flow explains why the system is robust and flexible.

Under the Hood

The New Input System uses a layered event-driven architecture. Hardware devices send raw input events to the system's device managers. These events are processed and translated into input actions based on configured bindings and control schemes. The system maintains a device list that updates dynamically as devices connect or disconnect. Input actions then trigger callbacks or can be polled by game code. This design separates device-specific details from game logic, enabling flexible input handling.

Why designed this way?

The old Input Manager was limited by fixed mappings and lack of device flexibility. The new system was designed to support modern gaming needs: multiple devices, hot-swapping, complex input schemes, and better performance. It uses an event-driven model to reduce CPU usage and improve responsiveness. The layered design allows easy extension and customization, making it future-proof for new devices and platforms.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  Hardware     │──────▶│ Device Manager│──────▶│ Input Actions │
│  Devices      │       │ (Device List) │       │ (Bindings)    │
└───────────────┘       └───────────────┘       └───────┬───────┘
                                                        │
                                                        ▼
                                               ┌────────────────┐
                                               │ Game Code / UI │
                                               └────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think the New Input System only works on new devices? Commit to yes or no.

Common Belief: The New Input System only supports new or fancy input devices.

Reality: It supports all common devices including keyboards, mice, and older gamepads, plus new devices.

Why it matters: Believing this limits developers from using the system for broad device support, missing its full benefits.

Quick: Do you think input actions must be manually checked every frame? Commit to yes or no.

Common Belief: You have to check input states every frame manually with the New Input System.

Reality: The system uses callbacks to notify your code automatically when inputs happen.

Why it matters: Thinking you must poll input wastes CPU and complicates code, missing the event-driven advantage.

Quick: Do you think control schemes require restarting the game to switch? Commit to yes or no.

Common Belief: Control schemes are fixed and cannot switch during gameplay.

Reality: Control schemes can switch dynamically, allowing seamless device changes.

Why it matters: Assuming fixed schemes prevents designing flexible input experiences for players.

Quick: Do you think multiple players share the same input context by default? Commit to yes or no.

Common Belief: All players' inputs are handled together without separation.

Reality: Each player can have separate input users and devices to avoid conflicts.

Why it matters: Ignoring this leads to input mix-ups in multiplayer games, ruining gameplay.

Expert Zone

1

Input actions can have processors that modify input values on the fly, like deadzones or sensitivity adjustments, which many overlook.

2

The system supports composite bindings that combine multiple inputs into one action, enabling complex controls like 'WASD' as a single 'Move' vector.

3

Device pairing and unpairing events allow dynamic reassignment of devices to players, crucial for hot-swapping controllers in multiplayer.

When NOT to use

For very simple projects or prototypes with minimal input needs, the old Input Manager might be quicker to set up. Also, if you need extremely low-level input access or custom hardware support not yet integrated, you might need native plugins or custom code instead.

Production Patterns

In production, developers use input action assets to define all controls centrally, enabling designers to tweak inputs without code changes. They implement control schemes for platform-specific setups and use callbacks for clean, event-driven input handling. Multiplayer games create separate input users per player, managing device assignment dynamically. Testing includes simulating input devices and remapping controls for accessibility.

Connections

Event-Driven Programming

The New Input System uses event-driven callbacks to notify code of input actions.

Understanding event-driven programming helps grasp how input callbacks improve efficiency and responsiveness.

Human-Computer Interaction (HCI)

Input systems are a core part of HCI, focusing on how humans communicate with computers.

Knowing HCI principles explains why flexible, device-independent input improves user experience.

Universal Remote Controls

Both unify control over many devices with one interface.

Seeing input systems as universal remotes clarifies the value of abstraction and device independence.

Common Pitfalls

#1 Trying to read raw device input directly instead of using input actions.

Wrong approach:

if (Keyboard.current.spaceKey.isPressed) { Jump(); }

Correct approach:

inputActions.Player.Jump.performed += ctx => Jump();

Root cause:

Misunderstanding that input actions provide a cleaner, device-independent way to handle input.

#2 Not enabling the Input System package or setting it as active in project settings.

Wrong approach:

// Using new input code without enabling system
inputActions.Player.Move.ReadValue(); // returns zero

Correct approach:

// Enable Input System in Project Settings > Player > Active Input Handling
inputActions.Player.Move.ReadValue(); // returns correct value

Root cause:

Forgetting to configure Unity to use the New Input System causes input to not register.

#3 Assuming input callbacks run on the main thread without considering timing.

Wrong approach:

Updating UI directly inside input callbacks without thread safety.

Correct approach:

Queue input events and update UI in Unity's Update method.

Root cause:

Not understanding Unity's threading model and callback timing leads to bugs.

Key Takeaways

The New Input System in Unity provides a flexible, device-independent way to handle player inputs using input actions and control schemes.

It uses an event-driven model with callbacks, improving efficiency and code clarity compared to polling inputs every frame.

Control schemes and action maps organize inputs logically and support multiple devices and players seamlessly.

Understanding the system's layered architecture and dynamic device management helps build robust, adaptable games.

Avoid common pitfalls by using input actions properly, enabling the system in settings, and respecting Unity's threading model.