What I Learned Making Games in Unity
By: Melody Soriano
Tags: Game Development, C Sharp Programming

What I Learned Making Games in Unity

Or, why you should learn C#

Photo by Kirill Sharkovski on Unsplash

Making games, and writing C# scripts in Unity is a lot like doing other types of coding, with a bunch of visual fun stuff plopped on top. It is definitely hard, but it’s hard fun. The Unity3D editor itself has lots of built-in tools for easy prototyping, like programmer-art style graphics with simple blocks with smooth matte textures and ready-made physics materials to get things attracted to the floor or bouncing around. But if you want those little blocks to move or to do anything interesting, you’ll need C# scripts.

C# is syntactically similar to C++ but with a garbage collector like Java. The creator of C# also created TypeScript, which is a strongly-typed extension of JavaScript that adds advanced object-orientation features like classes and objects. C# is also maintained by Microsoft and was built from the ground up to be open-source and fully cross-platform compatible. Also, since Unity is built on Microsoft’s .NET framework, by writing scripts for Unity, you’ll be learning tools that you can use in many other contexts.

But let’s get back to business. What good am I doing learning Unity? For starters, because it’s something that is fun for the most part, it’s a really good introduction to programming for people who are a little bit more on the scripting-nervous side. Everything placed in the world is an object and is visually represented in the Hierarchy. You can create objects with parent-child relationships for either functional or organizational purposes. This is done either by dragging and dropping or by changing the object's parent through code.

Editor Windows and Fully-Expanded Hierarchy of an Arcade-Style ball-rolling game

The only thing you have to keep in mind when changing the parent of a GameObject is that the object's position (or transform component) will be with respect to the parent object. So if you don’t want your programmer art rolling off the screen, you will need to set the parent's position to 0,0,0 in the world (also known as resetting the transform component of the GameObject). The only time this wouldn't be the case would be if you actually do want two objects to always be moving only in relation to each other, like if you were simulating the Earth going around the Sun, and the Moon going around the Earth, in which case the Moon would be a child object of the Earth, while the Earth rotates around the sun, as shown in the hierarchy below:

The moon is shown as the earth’s child, so it always moves in relation to it

You can get into a lot of trouble with this stuff if you’re too heavy-handed, however. Take the hierarchy in the rolling ball game in the first picture: we want the camera to follow the ball around the arena, so it makes sense to just have it as a child right? Wrong! If we set the camera as a child of a ball that is rolling around, guess what the camera is going to do: end up rolling around the ball, very rarely showing us what we want to see! Not good. What do we need to do then? Add a script! This script, called SmoothFollow, is a part of the Unity Standard Assets package, which is horrendously out of date and needed a code snipped in one spot updated and I can go through that in the future if anyone needs. However, this script works just fine for what we need.

Code Snippet in question

In the snip above, we have the LateUpdate method, which is called once per frame (React lifecycle methods, anyone?). We’re using LateUpdate here because the Update function of our ball controller, is what is making the ball move, and we want our camera to change after the ball moves. The eulerAngles.y is getting the y component of the object’s rotation component (in wantedRotationAngle it's looking at the target, whereas in currentRotationAngle it’s looking at the camera’s transform). We then use the wanted height and rotation to dampen/update the camera's current height and rotation, and then we move the camera to the desired x-z distance from the ball. This looks complicated to understand, but the Unity engine here is doing more or less all of the more complicated matrix transformations that would otherwise be necessary to do something like this from scratch.

And there you have it! I may have not convinced you to learn C# yourself, but I for one learned a lot by playing around and making little games in Unity.