In this lesson, you will learn how to transition from hardcoded input logic to centralized Input Action Assets to make your control schemes modular and easy to manage.
Moving Beyond Input.GetKey
In earlier lessons, you likely checked for movement by writing if (Input.GetKey(KeyCode.W)) directly inside your Update methods. While functional, this approach is rigid; if you want to change a keybind or support controllers, you have to rewrite your C# scripts. By using the Input Action Asset, you decouple the "what" (the action) from the "how" (the specific key or button).
Structuring Your Asset
An Input Action Asset acts as a data container that lives outside your scripts. You create one in your Project window (right-click > Create > Input Actions) and define "Action Maps," such as Player or Menu.
Inside these maps, you define Actions (e.g., "Jump," "Move"). Each action is assigned Bindings. For example, a "Jump" action might have a binding for the Space key on a keyboard and the South Button on a gamepad.
Why This Is Modular
By centralizing these definitions, your script no longer cares what key is pressed. Instead, the script simply asks the Input System if the "Jump" action is performed.
// Instead of checking for Space, we reference the Action
public void OnJump(InputAction.CallbackContext context)
{
if (context.performed)
{
// Apply physics force here
rb.AddForce(Vector3.up * jumpForce, ForceMode.Impulse);
}
}
By keeping input definitions in an asset, you can swap between different control layouts (like driving vs. walking) simply by switching the active Action Map. This modular architecture allows you to update your control schemes in the Inspector without ever touching your physics or movement code, ensuring your project remains organized as it grows.
Key Takeaway: Use Input Action Assets to abstract hardware-specific inputs into generalized Actions, allowing you to rebind keys and manage complex control states without modifying your underlying game logic.