How to Think About Games: Unity

This is the third installment of the “How to Think About Games” series. Here, we explore the philosophy behind a game engine, and how it structures a game. The goal is to get a sense for the abstraction of what will make up your game. I try to avoid comparison, and instead focus on the headspace you should be in as the one making a game in the software. From there, you can evaluate the pros and cons for yourself, and make an educated choice of which engine to choose.

Background on Unity

The focus of this article is the Unity Engine, another huge player in the game engine space. With a goal to ‘democratize game development’, they seem to have succeeded, as Unity was very popular among small developers, and still seems to be despite some semi-recent controversy. (It’s outside of the scope of this article, but you can read about the Runtime Fee controversy to learn more.)

• Unity supports both 2D and 3D Games, seemingly equally as well, although it’s worth noting that even 2D Unity games are actually 3D behind the scenes.
• Unity had annual releases up until recently with the version of Unity 6. As it's still somewhat recent and has less community support. Most of what's discussed in the article will be more relevant to the yearly releases.
• It’s very popular for mobile game development, but also can publish well to desktop and major consoles.
• It’s built using C++, but users typically write in C#.

Now that you know what it is, let’s get on to how it thinks about games.

How to Think About Unity

Scene(s)

Unity games can be a scene, or a bunch of scenes. As a game gets more complex, you’ll likely use multiple scenes to build out a game, a scene per level, for example, or maybe a title screen scene. Scenes are the space you work in to create a game. To make something of a scene, you can put GameObjects inside of them, each able to represent different parts of the game. GameObject scripts can load different scenes, letting the game navigate between them as is seen fit.

Screenshot of the Unity Editor when you open a new scene. Scenes start with a Camera and Light GameObjects by default. Sourced from the Unity Documentation.

GameObjects

GameObjects seem to be the primary meat of Unity game development. Games tend to consist of scenes that have game objects that communicate with each other. Game objects can be almost anything. They could be a player, a piece of set dressing, a camera, a light source, or even just a script that handles game logic. What form a GameObject actually takes depends on what components it has. GameObjects can even be children of other game objects, inheriting component properties from the parent selector, which can be used to make groups of objects that all move at once, for example.

An example of a basic cube GameObject, and some of its components. Sourced from the Unity Documentation.

As we can see here with an example of a Cube GameObject, it takes a lot of components to make it up, but you get a cube that can have a position in the scene, and collide with other collidable GameObjects. We can tell that its able to do this by its various components. It has a mesh-filter, deciding what shape it takes. It has a renderer, allowing the mesh to show up in the game world, and have a material applied to it. It has a Box Collider, allowing it to collide, and a Transform component, allowing it to be moved to a specific space in the game world, or to change in size.

This is but scratching the surface of what Components can do to build powerful GameObjects.

Components

GameObjects are all made up of components. Components have properties which the developer can use to change them, or have script components that change these properties over time, or based on input. Components define what that GameObject is. A player component might be a simple Cube GameObject as seen above, but with a script that allows for player controls.

Scripts in Unity by default have the functions Start, and Update (Sometimes FixedUpdate is preferable for physics calculations). Start runs the code involved when the scene starts, and Update runs the code involved every frame. To ensure certain game functions don’t just run faster on faster computers, Unity provides a Time.deltaTime value that can be used to make the game run on a more true clock.

There are also certain components that allow for events, which can be interacted with in scripts as well. Collision allows you to run code on collide, and a button UI GameObject can let you run code on click.

A screenshot of the component browser, showing the different categories of components you can add to a GameObject. Sourced from the Unity Documentation.

Components are the real power behind GameObjects.

Final Thoughts

If Unity is to be your engine of choice, you have to see if this structure makes sense to you. If it fits your style of development, and you like the flexibility, this engine may be right for you. Undoubtedly this structure is not a limitation. Unity is a tempting option, having been so big and popular, there’s a lot of community resources out there, and the variety of games it lets you make are immense. Hollow Knight, Cuphead, Subnautica, and Valheim were all made with this engine, showing you the power that it can give you.

On my opinionated note, I can see why the engine got so popular. The structure seems very free form and mostly built out by the user. Although I’m trying to avoid comparison, since I’ve been looking into these structures, it’s really interesting how similar Unity and Unreal's structure seems to be, but I believe the differences are reflected in the games made with each. A lot of the structure of a Unity game is more defined by the user. They can have as many or as few scenes as they see fit, they can write the scripts for game events in whatever way they prefer. I think this freedom may be intimidating, and could easily mess up a beginner, as it's open to a lot of holes and mistakes, but I think in the hands of a competent team, it can be used to make something great.

Sources

Unity in 100 Seconds - As usual with Fireship's content, it gives a great overview, which helped me know what I needed to start researching
How to make a Video Game in Unity - BASICS (E01) - If you're interested in using Unity, Brackeys is ones of the most well known for their huge number of tutorials for the community. I would definitely say their videos are 'further reading' if you're sure this is the engine for you.
The Unity Tutorial For Complete Beginners - However, I would start with this tutorial first. I think it really cleanly and concisely goes over the absolute core concepts in Unity very well.
Unity Wikipedia - Just for extra bits of information and background.
Creating Scenes Documentation - More about Scenes!
Using Components Documentation - More about Components!
GameObject class documentation. - More about GameObjects!
GameObjects documentation - (Yes, this is a different page. I got some information from both, so I wanted to ensure they were both represented.)