1621083660

# Making a RTS game #10: Moving the 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. 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

1621083660

## Making a RTS game #10: Moving the 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. 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

1602565700

## Game Development with .NET

We’ve launched a new Game Development with .NET section on our site. It’s designed for current .NET developers to explore all the choices available to them when developing games. It’s also designed for new developers trying to learn how to use .NET by making games. We’ve also launched a new game development Learn portal for .NET filled with tutorials, videos, and documentation provided by Microsoft and others in the .NET game development community. Finally, we launched a step-by-step Unity get-started tutorial that will get you started with Unity and writing C## scripts for it in no time. We are excited to show you what .NET has to offer to you when making games. .NET is also part of Microsoft Game Stack, a comprehensive suite of tools and services just for game development.

#### .NET for game developers

.NET is cross-platform. With .NET you can target over 25+ different platforms with a single code base. You can make games for, but not limited to, Windows, macOS, Linux, Android, iOS, Xbox, PlayStation, Nintendo, and mixed reality devices.

C## is the most popular programming language in game development. The wider .NET community is also big. There is no lack of expertise and support you can find from individuals and user groups, locally or online.

.NET does not just cover building your game. You can also use it to build your game’s website with ASP.NET, your mobile app using Xamarin, and even do remote rendering with Microsoft Azure. Your skills will transfer across the entire game development pipeline.

#### Available game engines

The first step to developing games in .NET is to choose a game engine. You can think of engines as the frameworks and tools you use for developing your game. There are many game engines that use .NET and they differ widely. Some of the engines are commercial and some are completely royalty free and open source. I am excited to see some of them planning to adopt .NET 5 soon. Just choose the engine that better works for you and your game. Would you like to read a blog post to help you learn about .NET game engines, and which one would be best for you?

#.net #.net core #azure #c# #game development #azure #cryengine #game developers #game development #game development with .net #game engines #games #monogame #playfab #stride #unity #visual studio #waveengine

1664775764

## How to Create a Successful Gaming App?

How to create a game app is a comprehensive guide, explaining the entire process of creating and publishing games for iOS and Android. Covering all the essential information a budding game developer needs to know.

1567579080

## Developing 2D & 3D Games using C# and Unity for Windows

Learn how to develop Unity Games for Windows using C# and Unity, and see why Unity is the tool of choice for millions of game developers around the world. Explore the interface, 2D and 3D game development, publishing for Windows, and monetizing your games. Find out how Unity helps you animate events, use environmental controls, add finishing touches for a more polished game, and more. Don't miss it!

Thanks for watching

If you liked this post, share it with all of your programming buddies!