Unity Input System

Overview

Unity’s Input System is the engine’s current package-based input workflow. It is intended as the flexible, extensible successor to the older UnityEngine.Input model. Unity’s manual now explicitly recommends it for most current projects and describes it as the engine’s best-supported input solution. Newer Unity teaching material also uses Action Maps and the PlayerInput component as the default way to structure player controls for prototypes and larger projects. (Unity Documentation, Input and Input System, see source-unity-input-system; Unity, The Unity Game Designer Playbook, see source-unity-game-designer-playbook)

Setup

Typical workflow:

1. Install the Input System package through the Package Manager.
2. Create an input actions asset.
3. Define action maps and actions.
4. Bind devices such as keyboard, gamepad, mouse, or touch.
5. Read those actions in scripts or through Unity’s event workflows.

Usage

What the package is best at:

• multi-device support
• configurable action maps
• cleaner rebinding workflows than the legacy Input Manager
• editor-side input configuration

In practice, a common route is:

• create an Input Actions asset
• separate controls into Action Maps such as Gameplay, UI, and Menu
• use PlayerInput when you want Unity to handle action callbacks and device pairing more declaratively

The main teaching contrast is with unity-input, which documents the older legacy Input Manager used in CRE132’s beginner material.

Gotchas

• It is a package, not the same workflow as the old built-in input API.
• Teams mixing legacy and new input approaches can confuse themselves quickly unless they choose a standard.
• For beginner teaching, the legacy system is simpler; for current production-facing work, the package is the better long-term default.

Related

unity-input · monobehaviour-lifecycle · overview-unity-csharp-cpp-programming · source-unity-input-system · source-unity-game-designer-playbook