Part 7 – UE5 RTS Camera Edge Scrolling

What You Will Build

• A visible mouse cursor during gameplay
• Game and UI input mode for RTS-style mouse control
• Mouse lock inside the game window
• Screen-edge detection using normalized cursor position
• Camera movement triggered by screen edges
• Reusable movement functions for cleaner Blueprints

Why RTS Edge Scrolling Needs Proper Input Setup First

Before you even touch the edge-scrolling logic, the cursor has to behave correctly.

If the cursor disappears, escapes the viewport, or gets captured in the wrong way, the camera movement will feel broken no matter how good the Blueprint logic is.

In an RTS-style camera, the player often needs:

• a visible cursor
• mouse movement across the full screen
• the cursor locked inside the game window
• camera movement triggered by cursor position

That is why the first half of this setup is input mode, not movement logic.

Step 1: Open BP_RTSPlayer

Open the Blueprint that controls your RTS camera pawn or RTS camera player logic.

In this tutorial, that Blueprint is:

BP_RTSPlayer

This is where the camera movement and mouse behavior are managed.

Step 2: Configure Game and UI Input Mode on Begin Play

In the Event Graph, add:

Event BeginPlay

From Begin Play, add a:

Sequence

The Sequence is not strictly required for this one setup, but it keeps Begin Play cleaner and gives you room to add other startup logic later without turning the graph into garbage.

From there, get:

Get Player Controller

Then connect it into:

Set Input Mode Game and UI

Configure the node like this:

• In Mouse Lock Mode: Lock Always
• Hide Cursor During Capture: false or unchecked

This tells Unreal to allow game and UI style input together while keeping the mouse inside the viewport.

Step 3: Show the Mouse Cursor

From the same Player Controller reference, add:

Set Show Mouse Cursor

Set it to:

true

Now the cursor will stay visible during play.

This matters because edge scrolling depends on the player moving the cursor intentionally to the boundaries of the screen. If the cursor is hidden, the mechanic feels blind and bad.

What This Input Setup Gives You

At this point, pressing Play should give you:

• a visible mouse cursor
• the mouse locked to the game window
• a cleaner foundation for RTS-style mouse input

Test this before continuing. If the cursor still escapes the game window or disappears, fix that now. Do not build movement logic on top of broken input behavior.

Step 4: Understand the Edge Scrolling Logic

The idea behind edge scrolling is simple:

• Get the current mouse position
• Get the size of the viewport
• Convert the mouse position into a normalized 0 to 1 value
• Check whether the mouse is very close to an edge
• If it is, move the camera in the corresponding direction

For example:

• If normalized X is greater than 0.98, the cursor is near the right edge
• If normalized X is less than 0.02, the cursor is near the left edge
• If normalized Y is greater than 0.98, the cursor is near the bottom edge
• If normalized Y is less than 0.02, the cursor is near the top edge

Those threshold values define the edge zones.

Step 5: Get the Mouse Position

In an empty part of the graph, add:

Get Player Controller

From that, add:

Get Mouse Position

This gives you:

• Location X
• Location Y

These values are the current mouse position in screen space.

Step 6: Get the Viewport Size

Right-click and add:

Get Viewport Size

This gives you:

• Viewport X
• Viewport Y

You need these values because raw mouse coordinates depend on the resolution. A mouse X value of 1900 means almost nothing by itself unless you know whether the viewport width is 1920, 2560, or something else.

Step 7: Normalize the Mouse Position

Divide the mouse location by the viewport size:

NormalizedX = MouseX / ViewportSizeX
NormalizedY = MouseY / ViewportSizeY

This converts the mouse position into values between 0 and 1.

Example:

• 0.00 means the far left or top edge
• 0.50 means the center
• 1.00 means the far right or bottom edge

This is important because it makes the logic resolution independent. It works the same whether the game runs at 1080p, 1440p, or another size.

Why Normalization Matters

Without normalization, your edge checks would be tied to exact pixel values, which is a bad design.

For example, if you hardcode “move when mouse X is greater than 1900,” that might work at 1920 width but fail badly at another resolution.

Normalizing the values lets you think in percentages instead:

98% of screen width
2% of screen width

That is much better.

Step 8: Add Edge Comparison Checks

For both normalized X and normalized Y, create comparison checks:

• Greater Than 0.98
• Less Than 0.02

These thresholds define the active edge-scrolling zones.

In other words:

• greater than 0.98 means the cursor is at the far edge
• less than 0.02 means the cursor is at the opposite edge

You will do this for:

• X axis for left and right movement
• Y axis for forward and backward movement

Step 9: Reuse Existing Camera Movement Functions

If you already built RTS camera movement earlier in the series using Add Movement Input, do not duplicate that whole setup again.

Instead, collapse your existing movement nodes into reusable functions such as:

MoveForward
MoveRight

These functions should already handle movement using your actor forward vector and actor right vector.

This is the correct approach because:

• it avoids duplicated Blueprint logic
• it keeps movement behavior consistent
• it makes later changes easier
• it makes the graph cleaner and less stupid

Step 10: Connect Horizontal Edge Movement

Use the normalized X value to drive left and right camera movement.

Logic:

• If NormalizedX > 0.98, call MoveRight with Scale = 1
• If NormalizedX < 0.02, call MoveRight with Scale = -1

This means:

• cursor near right edge moves camera right
• cursor near left edge moves camera left

Step 11: Connect Vertical Edge Movement

Use the normalized Y value to drive forward and backward movement.

Logic:

• If NormalizedY > 0.98, call MoveForward with Scale = -1
• If NormalizedY < 0.02, call MoveForward with Scale = 1

Depending on your camera orientation and coordinate setup, forward and backward may feel reversed at first. If so, swap the signs.

The correct values depend on how your RTS player pawn is oriented in the map.

How the Full Edge Scrolling Flow Works

The full logic is:

1. Get mouse position
2. Get viewport size
3. Normalize X and Y
4. Check left and right edge thresholds
5. Check top and bottom edge thresholds
6. Call MoveRight or MoveForward with the correct scale

The camera movement itself stays inside reusable functions. That is what keeps the Blueprint modular instead of turning into duplicated spaghetti.

Step 12: Test the Camera

Compile and save the Blueprint.

Press Play, then move your cursor to:

• left edge
• right edge
• top edge
• bottom edge

The camera should move smoothly in each direction as the cursor touches the corresponding edge.

Tuning the Edge Zone

The values 0.98 and 0.02 are just starting points.

If the edge zone feels too thin, use something like:

0.97 and 0.03

If it feels too wide, tighten it further.

This controls how close the cursor needs to be before movement begins.

There is no perfect universal value. Test what feels good for your project.

Tuning the Movement Speed

If the camera feels too fast or too slow, do not blame the edge detection first. Check your movement speed values inside MoveForward and MoveRight.

Edge scrolling feels good when:

• the camera starts moving quickly enough to feel responsive
• the movement is not so fast that it becomes hard to control
• the edge zone is wide enough to trigger comfortably
• the cursor stays visible and locked

Common Issue: Cursor Escapes the Window

If the mouse leaves the game window, the edge checks stop being useful.

Recheck:

• Set Input Mode Game and UI
• Mouse Lock Mode = Lock Always
• cursor visibility settings

If these are wrong, the edge-scrolling logic may still be correct but the system will still feel broken.

Common Issue: Movement Feels Reversed

If moving to the top edge makes the camera go the wrong direction, your scale values are inverted relative to the pawn’s facing direction.

Fix it by swapping:

1 to -1
-1 to 1

Do not overcomplicate it. This is usually just a sign direction problem.

Common Issue: Camera Moves Too Often

If the camera starts moving too easily, your threshold zone is too wide.

Tighten the edge comparisons. For example, instead of 0.95 and 0.05, try 0.98 and 0.02.

Small threshold changes can make a large difference in feel.

Common Issue: Camera Does Not Move at All

If nothing happens:

• check that the movement functions are actually connected
• check the normalized division values
• check that the cursor is visible and moving inside the viewport
• check that MoveForward and MoveRight still work from other inputs
• check that the comparison branches are being hit during play

Use Blueprint debugging if needed. Do not just stare at the graph and hope.

How to Make This Even Better Later

This tutorial gives you a functional classic RTS edge scroll system. Later, you can improve it further by:

• scaling movement based on how close the cursor is to the edge
• disabling edge scrolling while UI menus are open
• adding camera acceleration and deceleration
• supporting multiple monitor setups more carefully
• combining edge scroll with drag panning and keyboard input
• blocking camera movement at custom map boundaries

Why Reusable Functions Matter Here

The smartest part of this setup is not the comparison nodes. It is reusing the movement functions.

If your WASD movement, edge scrolling, click drag panning, and future input systems all call the same movement functions, the camera stays consistent.

If you duplicate movement logic in four places, you will eventually break one path and forget the others.

Modular Blueprints are not just cleaner. They are easier to maintain.

Conclusion

In this tutorial, you set the RTS camera into Game and UI input mode, made the mouse cursor visible, locked it inside the game window, normalized the cursor position, checked screen-edge thresholds, and reused movement functions to build smooth mouse edge scrolling.

This is one of the core mechanics that makes an RTS camera feel real instead of half-finished.

Watch the full tutorial on YouTube: Part 7 – RTS Camera Edge Scrolling – Smooth Mouse Movement

Subscribe for more Unreal Engine tutorials: Subscribe to Rambod on YouTube

Resources

• RTS Camera GitHub Project
• Unreal Engine Input Documentation

Frequently Asked Questions

How do I add edge scrolling in Unreal Engine 5?

Get the mouse position, divide it by the viewport size to normalize it, compare the result against edge thresholds, then move the camera when the cursor reaches those edges.

Why do I need Game and UI input mode for RTS cameras?

Because RTS-style controls often need both gameplay input and a visible mouse cursor. Game and UI mode makes that setup easier and supports proper cursor handling.

What do 0.98 and 0.02 mean in edge scrolling?

They represent normalized screen percentages. 0.98 means 98 percent of the way across the screen, and 0.02 means 2 percent from the opposite edge.

Why normalize the mouse position?

Normalization makes the logic resolution independent, so it works across different screen sizes instead of relying on fixed pixel values.

Why is my edge scrolling reversed?

Your movement scale values are probably inverted relative to your pawn’s facing direction. Swap the positive and negative movement values.

Should I duplicate the movement nodes for edge scrolling?

No. Reuse your existing movement functions like MoveForward and MoveRight so the Blueprint stays cleaner and easier to maintain.