Handling Player Input (Keyboard & Gamepad)

From Direct Commands to Abstract Actions

In the last lesson's example, we used Input.GetKeyDown(KeyCode.Space). This is a direct way of handling input. Your code is specifically listening for the spacebar. But what happens if a player wants to use a different key? Or what if they're using a gamepad? You would have to write complex code to handle all these possibilities.

Modern game development solves this by separating the player's intent from the physical button they press. This is the core philosophy of Unity's new Input System. Instead of listening for a "W key", your script listens for a "Move" action. You then define, separately, that the "Move" action can be triggered by the W key, the arrow keys, or a gamepad's joystick.

This diagram illustrates the flow: a physical device triggers an abstract Action, which is then picked up by a component that calls a method in your script.

Let's explore this idea of a modular system.

Setting Up the Input System

Unity's new Input System is delivered as a package, so the first step is to install it into your project.

The Building Blocks of Input

With the package installed, let's dissect its main components. All your input configurations will live inside a special file called an Input Actions Asset. Inside this asset, you'll work with three key concepts:

1. Action Maps: These are sets of Actions that are used together in a specific context. For example, you might have a Gameplay Action Map for when the player is running and jumping, and a separate UI Action Map for navigating menus. This lets you use the same buttons for different things depending on what the player is doing.

2. Actions: An Action represents a specific player intent, like "Move", "Jump", or "Interact". It's an abstract concept, not tied to any specific button yet. You'll define the type of input it expects, for example:

   • Button: A simple press-and-release action, like firing a weapon or jumping.
   • Value: An action that has a continuous value. A Vector2 is perfect for 2D movement, representing both horizontal (X) and vertical (Y) input.

3. Bindings: A Binding is the connection between an Action and a physical control on a device. The "Move" Action, for instance, might have a "WASD" binding for keyboards and a "Left Stick" binding for gamepads.

This structure is incredibly powerful. It allows you to support multiple devices and makes it easy for players to remap controls, all without changing a single line of your gameplay code.

Implementation: Bringing Your Player to Life

Now for the practical part. We'll create a simple player object, add the necessary components, and write a script to make it move. The easiest way to get started is by using the Player Input component, which can automatically listen for actions and call corresponding methods in your script.

We'll follow a comprehensive video guide for this process. It covers everything from creating the object to writing the final code.

After following the video, your PlayerMovement.cs script should look similar to this. I've added extra comments to reinforce the concepts:

using UnityEngine;
using UnityEngine.InputSystem; // Required to use InputValue and other Input System types

public class PlayerMovement : MonoBehaviour
{
    // A variable to control the player's speed.
    // [SerializeField] makes it visible in the Unity Inspector without making it public.
    [SerializeField]
    private float speed = 5f;

    // A reference to the Rigidbody2D component, used for physics-based movement.
    private Rigidbody2D rb;

    // A Vector2 to store the player's movement input (e.g., from WASD or a joystick).
    private Vector2 movementInput;

    // Awake is called when the script instance is being loaded.
    // It's the ideal place to get component references.
    private void Awake()
    {
        // Get the Rigidbody2D component attached to this same GameObject.
        rb = GetComponent<Rigidbody2D>();
    }

    // FixedUpdate is called at a fixed interval and is used for physics calculations.
    // All Rigidbody manipulations should happen here.
    private void FixedUpdate()
    {
        // Set the velocity of the rigidbody.
        // The movement is the input direction multiplied by the speed.
        rb.velocity = movementInput * speed;
    }

    // This method is called by the PlayerInput component when the "Move" action is triggered.
    // The name "OnMove" MUST match the action name "Move".
    private void OnMove(InputValue value)
    {
        // Read the Vector2 value from the input (e.g., WASD produces (-1,0) to (1,1) vectors).
        movementInput = value.Get<Vector2>();
    }
}

Once this is all set up, enter Play mode. You should now be able to move your hexagon sprite around using both the WASD keys and the left stick of a connected gamepad. Congratulations! You've just implemented a modern, flexible input system.

Conclusion

In this lesson, you've bridged the gap between code and player interaction. You now have the fundamental skill needed to make any object in your game respond to player commands.

Here are the key takeaways:

• Unity's Input System decouples player intent (Actions) from physical controls (Bindings), creating a flexible and scalable control scheme.
• The system's main parts are Action Maps, Actions, and Bindings, all configured within an Input Actions Asset.
• The Player Input component is a quick and easy way to connect your Input Actions to your scripts.
• Using the "Send Messages" behavior, the Player Input component calls methods in your script named after your actions (e.g., OnMove, OnJump).
• You can read input values like a Vector2 from the InputValue parameter to drive physics-based movement via a Rigidbody2D.

Next Steps

You've now attached several components to a GameObject (SpriteRenderer, Rigidbody2D, PlayerInput, and your own PlayerMovement script) and even modified a property (speed) in the Inspector. In the next lesson, we will formalize this process. You'll learn more about how components work together and how to access and modify them not just in the editor, but also directly from your C# scripts. This will unlock the ability for different game systems to communicate and interact with each other.