I’ve always been fascinated by camera systems in management and strategy games.
My love for cameras started when playing The Sims 2 back when I was in high school. Zooming in on your sims having a tasty lunch, orbiting around your house that you spent the last several hours meticulously decorating, panning to the street and seeing what the neighbors are up to.
It was like being an omniscient being, a god.
The camera was also an important aspect of the game in more action oriented strategy games, also called RTS for real-time strategy. I remember giggling as I watched my little soldiers climb up a hill in Ground Control 2, or being mesmerized by the Japanese buildings in the first Shogun: Total War, you could rotate the camera and watch them from all angles, forget the huge armies, the buildings were the real draw for me!
In the recent decades, RTS cameras came into the RPG genre as well, games like Kenshi or Baldur’s Gate 3 would be less without their amazing cameras.
If you think of a game on PC that has captivated you, I can bet that the camera system had a lot to do with it.
Let’s create a buttery smooth RTS camera system in Unity. And let’s make it one of the main reasons your players are going to be coming back to the game again and again.
I made two tutorials, one back in 2025 and an updated one in 2026. Below are the most important takeaways from both, with links to watch the videos.
Cameras in Unity
Creating such a camera system in Unity is easy thanks to Cinemachine.
Cinemachine can take care of:
- Following a target around.
- Smoothly orbiting around a target.
- Smoothly zooming in and out, it’s not technically a zoom, but a dolly, since we’re not changing the camera’s field-of-view (FOV), but rather making it physically move back and forth on its forward axis.
- Handling collisions
- And plenty of other features including camera shakes.
The 2025 Tutorial
This tutorial focuses a lot more on code, where we control the axes of orbit with our own script.
It’s a good tutorial because the camera speed depends on the zoom level, it talks about edge scrolling and uses the PlayerInput component from the input system, which you can see as a simpler way to use the input system.
Here are some lessons I learned from making this tutorial, and some points to keep in mind if you want to watch the video or make a camera system in general.
The Problem With PlayerInput
PlayerInput is confusing, at least to me.
Only one action map is active at a time, and apparently you can activate more action maps manually. It also complains when using project-wide actions. There are easier ways to manage input anyway.
I used an older version of the input package, and somehow the PlayerInput component was allowing input events from different action maps to trigger. Which is not the case in the newer version. A solution is to move the middle mouse action from the UI to the Player action map.
Use the direct input workflow:
Instead of going through PlayerInput, Middle mouse input can be checked by using Mouse.current.middleButton.wasPressedThisFrame in the Update method.
In fact, any keyboard key can be checked using the Keyboard.current object.
Framerate Independence
When making any kind of gameplay system, it’s important to make sure your code works the same no matter the framerate.
An easy way to notice framerate-dependent code is to set your monitor at a 60Hz refresh rate and activate V-Sync in the game view in Unity (it’s in the resolution drop-down list).
The camera should behave the same no matter the framerate.
Erratic Mouse Movement
When getting mouse delta as a Vector2 from the input system, it expresses how much the mouse has moved (in pixels) during the current frame.
Multiplying mouse delta by deltaTime to supposedly get a framerate independant value is a mistake.
It’s safe to use mouse delta as is, it already accounts for the framerate.
A funny anecdote is I only discovered this problem after implementing a first-person camera in another project, I was also multiplying mouse delta by deltaTime, and it resulted in the camera teleporting around when I moved the cursor.
What’s vicious about this issue is it only occurs when the framerate is low enough to make deltaTime larger, therefore making your computed mouse delta larger as well.
Watch the Video
The 2026 Updated Tutorial
What this tutorial did differently from the first one:
- We no longer control orbit and dolly from code, but from Cinemachine’s own input handling component called CinemachineInputAxisController.
- We make the camera remain above the terrain
- We make the camera avoid walls and obstacles
- Ability to track a moving object
- Quickly going to a position on terrain by double clicking there
- Cleaner code where we compute a value for the zoom level and use it to control the move speed of the camera.
Some tweaks you can use after watching the video to make the camera even smoother and more reactive:
- Keep the acceleration at 100 as opposed to 50 as in the video, higher values will make the camera respond faster to input.
- Keep the move speed at around 25-30 to account for the zoom level. A speed of 15 as in the video may result in a very slow camera.
- For OrbitScale in CinemachineInputAxisController, keep acceleration time to 0.5 while decelTime can be kept at 1, this again will make the dolly more responsive to input.