Making a RTS game #10: Moving the camera (Unity/C#)

Making a RTS game #10: Moving the camera (Unity/C#)

In this article, I will guide you to Make RTS Game #10: Switch Camera (Unity/C#)

In this post, we’ll talk a bit about graphical projections and camera set up, and then we’ll do some user input handling and reuse the notion of coroutines we saw last time.

Graphical projections: perspective, orthographic, axonometric…

Video games are displayed on 2D screens. So, as they started to put more and more 3D objects in our games, engineers and programmers have had to find various views of representing this 3D in a 2D space. Luckily, graphical projections (techniques used to show 3D objects in a 2D view) are hardly new stuff — scientists have been drawing complex 3D machines on paper for centuries. Over the years, plenty of ideas have come up on how to best represent the 3rd dimension in 2D: some try and reproduce the way our human eye sees things by incorporating perspective with vanishing points, others decompose the 3D object to show all of its sides separately, others try and mix the two to show as much of the object as possible while not deforming it too much…

In a RTS game, we are confronted to this question since we have 3D objects (our units, the trees and rocks on the ground, etc.). In those games, the camera is very often orthographic — this way, you get a literal bird’s eye-view of the world which helps with micro- and macro-management of your armies and production. More precisely, we usually use the isometric projection — this type of projection is a subtype of parallel orthographic axonometric projections, as shown below:

“Classification of the orthographic projection and some 3D projections”, by Cmglee — Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=83384053

When computers were not as efficient as they are now, orthographic projections were an amazing way of simulating 3D for video games because they’d let artists create sprites that programmers could then paste next to each other in a neat grid — and you’d get a 3D feel. Also, you didn’t need to worry about scaling the visuals depending on the distance to the camera: your sprites had one set size and there was no need to dedicate compute power to recomputing it live. It also let the game take care of the camera for the players so they could focus on the game at hand, rather than moving both the characters and the camera.

Isometric projection in itself is interesting because it gives quite a comprehensive and well-proportioned 2D representation of our 3D objects: if you have a cube, so with edges of the same length, an isometric projection will scale them proportionally in the 2D representation, thus we still get the same equal lengths.

However, it is way harder to mentalize the directions with this rotation. If you’re going “up” in your view, then you should actually be moving along a diagonal in the world space. This will make camera movement more complex and it will become particularly cumbersome in later episodes, when we want to make a minimap (that will not be rotated 45°). So, instead, we’ll be using a pseudo-axonometric projection where we face the objects (on the left), compared to the “real” isometric projection (on the right)!

We can still simulate the isometric view (and in particular take advantage of it showing objects proportions better) by rotating the objects mesh in the scene at a 45° angle on the global Y-axis. More precisely, we’ll apply a rotation on the “Mesh” sub-object in our unit prefabs, for example for the “House” building:

This way, we get the best out of both world while reducing the mental overhead of computing the camera field of view ;)

Note: even in a true isometric projection, the vertical axis may not be scaled the same; plenty of old “isometric video games” actually used the dimetric projections, in particular [to avoid pixel aliasing_](https://en.wikipedia.org/wiki/Isometric_video_game_graphics). Nowadays, computer graphics have improved enough for anti-aliasing to kick in spontaneously and take care of this, so we can revert to “true” isometric projections if we want. But most of the RTS games you might think of (for example the ones I cited in the first article of this series like Age of Empires, Caesar, StarCraft…) have this orthographic view that gives a unique feel to the game._

games csharp tutorial unity game rts

What is Geek Coin

What is GeekCash, Geek Token

Best Visual Studio Code Themes of 2021

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Making an RTS game #14: Adding a minimap and fog of war 2/3 (Unity/C#)

In this new Unity RTS programming tutorial, we’ll continue working on our minimap and fog of war features!

Making a RTS game #8: Boosting our selection feature (Unity/C#)

Let’s continue our RTS game project: today, we’ll improve our selection mechanism!

Making a RTS game #11: Adding a day-and-night cycle (Unity/C#)

On with our RTS game: today, we add a day-and-night cycle!

RTS Interlude #2: Refactoring the event system (Unity/C#)

On with our RTS project — in this interlude, we’re going to improve our event system!

Making a RTS game #13: Adding a minimap and fog of war 1/3 (Unity/C#)

Today, let’s keep working on our RTS project — we’ll start implementing our minimap and fog of war features!