🎛️ Lesson 3.1: Why the New Input System & Installing It

A Quick Look Back at the Legacy Input Class

In Fundamentals, moving a character looked something like this:

void Update()
{
    float h = Input.GetAxis("Horizontal");   // A/D or arrow keys
    float v = Input.GetAxis("Vertical");     // W/S or arrow keys

    if (Input.GetKeyDown(KeyCode.Space))
        Jump();

    transform.Translate(new Vector3(h, 0, v) * speed * Time.deltaTime);
}

This is polling: every single frame you ask "is Space down right now?" It's simple and it works for a keyboard demo. But look closer and the cracks show:

• KeyCode.Space is baked into the code. Want players to rebind jump to another key? You'd have to write all that plumbing yourself.
• A gamepad's "A button" is a completely different code path. Supporting keyboard and controller means branching input everywhere.
• The string axes ("Horizontal") live in an old Input Manager window that predates most of modern Unity.
• There's no clean way to know which player pressed a button when two controllers are plugged in.

None of this is a knock on what you learned — polling is the right first tool. But a real game outgrows it fast.

Why a New System?

The Input System package reframes input around actions ("Move", "Jump", "Fire") instead of specific keys. Your gameplay code says "the player wants to jump" and never cares whether that came from a spacebar, a gamepad button, or a touchscreen tap. Four concrete wins fall out of that idea:

• Device-agnostic. Bind Jump to the spacebar and the gamepad south button once. Plug in a controller mid-game and it just works — no extra code.
• Rebinding. Because actions and bindings are data, you can let players remap controls at runtime. We build exactly that in the Module 3 mini-project.
• Local multiplayer. The system pairs devices to players automatically, so "Player 2's gamepad" is a first-class concept rather than something you hack together.
• Event-driven, not polled. Instead of checking every frame, the system calls your method the moment an action fires — cleaner code and no missed presses on slow frames.

💡 The mental shift. Legacy input asks the hardware questions ("is this key down?"). The new system lets the hardware tell you when something happened ("Jump was performed"). It's the same shift from checking a mailbox every minute to just getting a notification.

Polling vs. Actions

Here is the two approaches side by side. Notice how the legacy path ties gameplay directly to specific keys and devices, while the action path routes every device through one shared action that your code listens to:

Figure 1: Every device funnels into one Action; your code reacts to the Action, not the hardware.

That single funnel is the whole point. Add a new device tomorrow and you add a binding, not a new branch in Update.

Installing the Package

The Input System ships as a package, so you pull it in through the Package Manager just like any other Unity package.

1. Open Window ▸ Package Manager.
2. At the top-left, set the source dropdown to Unity Registry (not "In Project").
3. Type Input System in the search box.
4. Select Input System in the list and click Install (bottom-right).

In Unity 6, the Input System is a verified package, so you'll get a stable version automatically — no need to hunt for a specific number.

Active Input Handling

The moment you install the package, Unity pops a dialog offering to enable the new backend and disable the old one. Whether you click yes or not, the underlying switch lives in Edit ▸ Project Settings ▸ Player ▸ Active Input Handling. This dropdown decides which input backend Unity compiles into your game:

Your three choices:

• Input Manager (Old) — only the legacy backend. The new APIs won't exist.
• Input System Package (New) — only the new backend. The clean, forward-looking choice for a fresh project. Any lingering Input.GetKey calls will throw at runtime.
• Both — both backends compiled in at once. Slightly heavier, but it lets old and new code coexist while you migrate.

The Restart & What Changed

Changing Active Input Handling swaps a compiled backend, so Unity must restart the Editor to apply it. Accept the prompt and let it relaunch — nothing is lost, and this is expected behaviour, not a crash.

Once the Editor is back, confirm the install worked by checking that a new menu path exists: right-click in the Project window and you should see Create ▸ Input Actions. That asset type is the star of the next lesson.

🔎 Sanity check in code. With the package installed you can now write using UnityEngine.InputSystem; at the top of a script with no red squiggle. If that namespace resolves, the backend is live.

Hands-on Challenge

Summary

🚀 What's Next?

The system is installed — now we need something to hold your actions. In Lesson 3.2: Input Actions & Action Maps you'll create your first .inputactions asset and build a Player map with a Move (Vector2) action and a Jump (Button) action, using the visual Input Actions editor.