Upgrading Player Controls from Legacy Input to the new Input System

New Input System Framework

Objective: Learn how to upgrade your player controls from Unity’s Legacy Input System to the New Input System. This article is part of a Software Engineering Framework provided by Game Dev HQ.

We’ll jump straight into upgrading existing player code. If you’re just getting started with the New Input System, check out the helpful resources below:

💡 Need help setting up Input Actions Scripts? [Click here]
💡 New to the Input System? [Start here].

Table of Contents

· Starting Point: Legacy Player Code
∘ Step 1: Set Up a Player Input Manager
∘ Step 2: Make the Movement Method Accessible
∘ Step 3: Replace Input.GetAxisRaw() with the New Input System
∘ Step 4: Refactor the Update Method
∘ Step 5: Finalize the Movement Method
· How do I Register Movement in the New Input System?
∘ Handling Input From Update
· The Result

Throughout the article, I will leave helpful links if you don’t have your Action Maps up and running by the time you read this one.

Starting Point: Legacy Player Code

We begin with a private method that handles player movement.

🔍Code Highlights

• Movement is currently handled using Input.GetAxisRaw("Horizontal") and Input.GetAxisRaw("Vertical").
• Our primary goal is to replace these legacy input calls with Unity’s New Input System equivalents.
• The rest of the code can remain untouched, as long as we update the input handling.

Step 1: Set Up a Player Input Manager

To avoid bloated, repetitive code, we’ll handle all input in a dedicated Input Manager script. This keeps your architecture clean and modular.

💡 Want a full guide on organizing input? Check out:
The Best Way to Organize Input Scripts

Step 2: Make the Movement Method Accessible

To call our movement logic from the Input Manager, we need to:

• Change the private method to public
• Modify it to accept a Vector2 parameter, which aligns with how movement is defined in Unity’s new input maps (e.g., WASD = Vector2 input)

💡If you need help setting up a WASD(Vector 2) Action Map click [here].

Step 3: Replace Input.GetAxisRaw() with the New Input System

The original input lines using Input.GetAxisRaw() are no longer needed. Instead:

• Use the move parameter passed in from the Input Manager to handle both vertical and horizontal movement.

🔍Code Breakdown

• The legacy input lines can be commented out for comparison or removed entirely.
• Your Vector2 move parameter now supplies all the direction data you need.

Step 4: Refactor the Update Method

Previously, the movement logic was called from Update() within the Player script. Now that we're focusing all the input in the Input Manager, we no longer need this.

🔍Code Breakdown

• Comment out or remove the Update() call to CalculateMovement().
• The _canMove condition, should be move into the new CalculateMovement() method. That validation is still necessary, but should now live inside the method itself.

Step 5: Finalize the Movement Method

Wrap up the method by incorporating the validation from before.

Our code is ready for the upgrade just like that! Everything else in this method is usable and non-dependent on the legacy or old input systems.

How do I Register Movement in the New Input System?

1. Reference the Player Object and Input Actions Class
   Use [SerializeField] to expose and assign the Player object in the Inspector.

2. Initialize Input in a Private Method
Instead of cluttering Start() or OnEnable(), create a dedicated method like InitializePlayerInput() to keep things clean and modular.

3. Call the Initialization at Runtime
Since the Player is our default controlled character, we call this as soon as the game starts.

Handling Input From Update

Now all we need is to register the input in our update.

🔍Code Breakdown

• Create a Vector2 move variable to match the parameter in the Player's CalculateMovement(Vector2 move) method.
• Use ReadValue<Vector2>() to read the current movement input.
• This gives us live input data, which we pass into the Player’s movement logic.

You’re good to go!

The Result

You’ve now set up:

✅You’ve successfully migrated your movement logic from Unity’s Legacy Input System to the New Input System.
✅ Input is now handled cleanly through a centralized Input Manager, while the Player script focuses solely on behavior.
✅ Your code is modular, scalable, and easier to maintain — ideal for long-term development.

Thanks for reading!

If you found this guide helpful, feel free to check out [my portfolio] or follow me — I’m currently open to opportunities in the video game industry! 😊