XPBLOG: A robotics engineer’s introduction to Unity – 12/16/21

Despite being someone who has been interested in gaming as far back as I can remember, I had never had the opportunity to try and develop a video game until I was part of this internship. Pretty much all of my programming experience so far has been in relatively simplistic coding environments such as Eclipse and VSCode, and the only output was usually a text output or behavior in the physical realm. While there are similar themes in all coding environments, Unity would prove to be quite the new and interesting experience.

The first challenge that I had to face when using Unity for the first time was the complicated user interface. While I know my way around it now, practically at the end of the program, the sheer amount of buttons, scenes, and new terminology was more than multiple skims of the manual could prepare anyone for. In Fig. 1, instead of being presented with a central area for coding, like in Fig. 2, the user is presented with nothing more than the camera. Also, unlike in Fig. 2, where the user can get coding immediately, the user has to create a script somewhere under assets, which is an idea foreign to most programmers.

Figure 1: Unity’s new project screen, which is relatively complicated

Figure 2: Eclipse, a common IDE, which is simplistic

After getting a grasp on Unity’s UI, Unity began to feel natural. By this point, I had taught myself a bit of C# and had written a few basic functions. Despite this, I still found myself struggling with yet another roadblock: applying scripts. In Unity, there is a good number of ways to reference assets within code, such as through public variables (which allowed for dragging and dropping the assets into the script’s Inspector), which I discovered to be good for tasks like spawning a number of the same asset, or using a find command, which works best for quickly finding something static that already exists within the game scene. I would argue that at this point, any programmer would know the basics of how to use Unity, but in order to do something of any complexity, there are a few quirks that any user must deal with.
The largest of these so-called quirks is transforms. Someone new to Unity, like myself initially, assumed that all of the coordinates were relative to the world. However, this was not the case. This unfortunately led to a few issues in game, such as defining the maximum distance an enemy could move as a box around the enemy, but since it changed based on the enemy’s position, it always stayed in the middle of the box no matter where the enemy moved, effectively allowing it to go anywhere, as seen in Fig. 3. To fix this common issue, the best approach is to make it dependent on something which does not move, including putting it at the same level as the object which contains the script.

Figure 3: One of the pesky bugs who kept going offscreen

Another of these quirks are the Find methods, which I briefly mentioned earlier. In short, their role is to refer to specific game objects elsewhere in the script. Despite these functions having a role integral to just about any game, they can be difficult for new users to wrap their head around, like it was for me. The two different versions of the function are GameObject.Find(), which is used to look through ALL GameObjects that exist in the scene, and GameObject.transform.Find(), which returns the transform (not GameObject!) child of the searched object. This method can also use .parent to go to whatever it is nested in (it’s parent). The first method should be used to find something that exists many steps away and is unique, while the second method is best for items that exist nearby to the script, or within an object which has multiple instances. This is due to how the first method cannot handle repeats, and the second one handles them by going up and down the GameObject’s tree. Variables references in the inspector are a great way to completely mitigate this issue, but both of them have their own use cases.

Overall, I would say that I had a positive experience in Unity after climbing over a few hurdles that presented themselves to me in the beginning. Unity is luckily well documented, which allowed me to use new methods with ease. Also, since scripts are applied to assets very easily, making it possible to see the results of code very quickly, I was as fulfilled as, if not more than, what I get from Robotics projects; there are simply few things as joyful as seeing your code in action. In short, I have had a positive experience with this software which has further sparked my desire for game development, and has shown that it is, in fact, a possibility for my future. I hope that my next projects are as fun as this one.

By Philip Lund