UE5 RTS Camera WASD Move

What You Will Build

• A new Axis2D input action for RTS movement
• WASD bindings through Enhanced Input
• Correct swizzle and negate modifier setup
• A fixed Spring Arm orientation for the RTS camera
• A Floating Pawn Movement component
• Blueprint movement logic using forward and right vectors
• A smooth RTS camera that glides around the map with WASD

Why RTS Camera Movement Needs Its Own Setup

RTS movement is not the same as character movement. You are not trying to make a player avatar walk around the world. You are moving a camera rig across a level in a way that feels responsive, readable, and stable.

That means the setup has to be clean:

• input must be reliable
• movement directions must make sense
• the camera angle must be correct
• the Pawn must actually support movement

If any one of those is wrong, the whole camera feels bad.

How This Movement System Works

The system is straightforward:

1. Create a 2D movement action.
2. Bind WASD to that action in the Input Mapping Context.
3. Use modifiers so the keys map into the correct Vector2D output.
4. Add Floating Pawn Movement to the RTS Pawn.
5. Break the movement vector into X and Y.
6. Use X for forward and backward movement.
7. Use Y for right and left movement.
8. Feed those values into Add Movement Input.

That gives you a clean, expandable RTS camera movement foundation.

Step 1: Create the Move Action

Go to your Input Actions folder and create a new Input Action named:

IA_MoveAction

Open it and set:

Value Type = Axis2D

Axis2D is the correct type here because RTS movement needs two independent movement channels:

• forward and backward
• left and right

One 2D action is cleaner than juggling multiple one-off button actions for movement.

Why Axis2D Is the Right Choice

A camera movement system like this works best when movement is represented as a single vector instead of disconnected single-key events.

Axis2D gives you exactly that:

• X can represent one axis of movement
• Y can represent the other axis of movement

That makes the Blueprint cleaner and easier to extend later.

Step 2: Open the Input Mapping Context

Open the Input Mapping Context you created in the project setup.

Remove the old test action binding from the previous setup if you no longer need it.

Add a new mapping for:

IA_MoveAction

This action will now receive the WASD key input.

Step 3: Bind W, A, S, and D

Add four key mappings:

• W
• S
• A
• D

At this point, just adding the keys is not enough. The modifiers are what make the movement vector behave correctly.

Step 4: Add the Correct Modifiers

Each key needs the proper mapping modifiers so it contributes to the correct 2D axis output.

Use:

• Swizzle Input Axis Values
• Negate where required

In the described setup:

• W uses Swizzle
• S uses Swizzle plus Negate
• A uses Swizzle plus Negate
• D uses Swizzle

For W and S specifically, make sure the swizzle order is adjusted correctly, such as:

XZY

so the forward and backward values land on the axis you expect.

Why Swizzle and Negate Matter

Without modifiers, the keys may feed values into the wrong axis or move in the wrong direction.

Swizzle tells Unreal which axis channel the input should populate. Negate flips the sign so opposite directions behave correctly.

This part is not optional. If you skip it or guess carelessly, the movement will feel broken.

Step 5: Fix the Spring Arm Rotation

Open:

BP_RTSPlayer

and select the Spring Arm.

Update the rotation so the camera has the intended RTS viewing angle.

Example values:

Pitch = -105
Yaw = 180
Roll = 180

This corrects the camera orientation so movement feels aligned with the actual view.

Why Camera Orientation Must Be Correct First

If the camera rig is oriented badly, even correct movement input can feel wrong. You might think the movement logic is broken when the real problem is that the camera is facing the wrong way.

Fix the view first, then judge the movement.

Step 6: Add Floating Pawn Movement

In BP_RTSPlayer, add the component:

Floating Pawn Movement

This is critical.

Without Floating Pawn Movement, your Add Movement Input nodes will not do anything useful because the Pawn has no movement component to process that input.

Why Floating Pawn Movement Is Needed

Add Movement Input is not magic by itself. It needs a movement component that knows how to turn input into actual movement.

For an RTS camera Pawn, Floating Pawn Movement is a solid fit because:

• it is lightweight
• it works well for free movement
• it avoids character-specific movement baggage

This is the correct component for this camera foundation.

Step 7: Remove the Old Test Action Event

In the Event Graph of BP_RTSPlayer, remove the old test action event from the setup phase.

That event served its purpose. Now you need real camera movement logic, not a debug print.

Step 8: Add the Move Action Event

In the Event Graph, add the Enhanced Input event for:

IA_MoveAction

This node will fire whenever the movement input changes.

Expand the node if needed so you can access the full input value.

Step 9: Break the Vector2D

From the action value, add:

Break Vector2D

This gives you:

• X for one movement axis
• Y for the other movement axis

In this setup:

• X is used for forward and backward movement
• Y is used for right and left movement

Step 10: Get the Movement Directions

Add:

• Get Actor Forward Vector
• Get Actor Right Vector

These vectors define the directions the RTS camera Pawn should move in based on its current orientation.

That means if the camera later rotates, movement can stay consistent with the Pawn’s facing direction.

Why Forward and Right Vectors Are Better Than Hardcoding

You could hardcode world axis movement, but that becomes limiting the moment the camera rotates.

Using the actor’s forward and right vectors is better because:

• movement stays relative to the Pawn orientation
• the system scales better when rotation is added later
• the logic stays more reusable

This is the right way to build it.

Step 11: Add Two Add Movement Input Nodes

Create two:

Add Movement Input

nodes.

For the first one:

• World Direction = Forward Vector
• Scale Value = X from Break Vector2D

For the second one:

• World Direction = Right Vector
• Scale Value = Y from Break Vector2D

This is the heart of the movement system.

How the Movement Logic Works

The full movement flow is:

1. IA_MoveAction fires.
2. Break Vector2D splits the 2D input.
3. X drives movement along the forward vector.
4. Y drives movement along the right vector.
5. Floating Pawn Movement processes the input and moves the Pawn.

Simple, clean, and correct.

Step 12: Test the Camera Movement

Open MainMap and press Play.

Then test:

• W for forward
• S for backward
• A for left
• D for right

If everything is wired correctly, the RTS camera Pawn should now move smoothly around the level.

What the Final Result Should Feel Like

When the setup is correct:

• movement starts immediately when you press a key
• the camera glides instead of snapping awkwardly
• the movement directions feel consistent with the camera rig
• the RTS camera starts feeling usable

This is the first real moment where the system stops being setup work and starts feeling like gameplay infrastructure.

Common Problem: The Pawn Does Not Move

If pressing WASD does nothing, check these first:

• Did you add Floating Pawn Movement?
• Is IA_MoveAction actually mapped in the Input Mapping Context?
• Is the correct Input Mapping Context active?
• Did you remove the old test event and add the movement event?
• Are the Add Movement Input nodes connected correctly?

The most common cause is forgetting the movement component.

Common Problem: One or More Keys Move the Wrong Way

If W, A, S, or D behave incorrectly, the issue is usually in the input modifiers:

• check swizzle order
• check negate setup
• check which vector component is wired to which movement node

This is almost always a mapping problem, not a movement-node problem.

Common Problem: Camera View Feels Wrong Even If Movement Works

If movement technically works but the view feels off, recheck the Spring Arm rotation values.

A bad camera angle can make good movement feel bad.

Why This Is a Strong RTS Camera Foundation

This movement system works well because it uses the right building blocks:

• Enhanced Input for flexible input mapping
• Axis2D for cleaner movement input
• Floating Pawn Movement for actual Pawn motion
• Forward and right vectors for direction handling

That is a much better base than hacking together one-off key events.

What Comes Next

Once WASD movement is working, the next logical upgrades are:

• zoom
• rotation
• terrain following
• camera boundaries
• edge scrolling

But movement comes first for a reason. If the camera cannot move properly, the rest is pointless.

Conclusion

In this tutorial, you created an Axis2D move action, mapped W, A, S, and D through Enhanced Input, applied the correct swizzle and negate modifiers, fixed the Spring Arm rotation, added Floating Pawn Movement, and built the Blueprint logic that converts the input vector into smooth RTS camera movement.

That gives your RTS camera its first real gameplay feature and a solid foundation for the rest of the system.

Download the project files: UE5 RTS Camera Tutorial GitHub Repository

Subscribe for the next RTS camera tutorial: Subscribe to Rambod on YouTube

Resources

• RTS Camera Project Files
• Enhanced Input Documentation
• Blueprint Documentation

Frequently Asked Questions

How do I add WASD movement to an RTS camera in Unreal Engine 5?

Create an Axis2D input action, bind WASD through Enhanced Input, add Floating Pawn Movement to the RTS Pawn, then use Break Vector2D with Add Movement Input and forward/right vectors.

Why do I need Floating Pawn Movement?

Because Add Movement Input needs a movement component to process the input. Without it, the Pawn will not actually move.

Why use Axis2D for movement?

Axis2D keeps both movement directions inside one clean input action, which makes the Blueprint setup easier to manage.

Why do swizzle and negate modifiers matter?

They make sure each key writes to the correct axis direction inside the 2D input vector.

Why use forward and right vectors instead of hardcoded world directions?

Because that keeps movement relative to the Pawn orientation, which is more flexible once camera rotation is added later.

What should I build after WASD movement?

The next logical steps are zoom and rotation, followed by terrain adaptation, boundaries, and edge scrolling.