Basic Concepts in Unity for Software Engineers
Tags: gamedev, unity3d
Published: 2020-10-22 03:50:54

---
title: Basic Concepts in Unity for Software Engineers
published: true
description: Skipping over an introduction to programming, we start our journey learning Unity from first principles. GameObjects, Assets, Scenes, Serialization, and more.
tags: gamedev, unity3d
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/i06z539nt9n2yai4yhgs.jpg
canonical_url: https://blog.eyas.sh/2020/10/unity-for-engineers-pt1-basic-concepts/
---

If you're trying to get into game development as a Software Engineer, finding learning materials with the right level of context can be challenging. You'll likely face a choice between following materials introducing you to basic C# and OOP concepts while also describing Unity concepts, or starting with advanced tutorials and be left to figure out the core concepts deductively.

To fill that gap, I'm writing a series called **[Unity for Software Engineers](https://blog.eyas.sh/tag/unity-for-software-engineers)**. This is the first piece, and I'll be releasing additional installments over the next few weeks, so [make sure to subscribe](http://eepurl.com/gVgusL) for updates. The series is intended for folks already comfortable with programming and software architecture, especially those who learn best as I do: starting with first principles and working your way upwards.

_[This article originally appeared on blog.eyas.sh](https://blog.eyas.sh/2020/10/unity-for-engineers-pt1-basic-concepts/)._

---

I started my programming journey around 17 years ago by picking up
[Game Maker](https://www.yoyogames.com/gamemaker). Countless hours spent coding little games and tools led me to a bigger passion for programming. Eventually, I was at a point where I focused mainly on Software Engineering. From my peers, I know this is quite a common path that many of us took to find programming.

Yet the game development scene has changed significantly from those days. When I went to pick up Unity after a long absence from game development, I was mostly interested in understanding the basic concepts: what are the fundamental building blocks of a game? What do I need to know about how these building blocks are represented in memory or on disk? How is idiomatic code organized? What patterns are preferred?

In the first article in the series, we'll focus on those first two questions.

## Scenes

A **Scene** is the largest unit of organizing your objects in-memory. Scenes contain the objects making up your game.

In basic use, one scene represents a **single level** in your game, where one scene is loaded at any given point. In more "advanced" use, you can have two or more active scenes at a time. Scenes can be loaded additively and unloaded [^1]. Having multiple scenes loaded during gameplay comes especially handy when building a massive world; keeping far-away areas on-disk rather than in-memory will help you stay within your performance budget.

<figure>

![A scene editor showing an empty scene in 3D Mode.](https://dev-to-uploads.s3.amazonaws.com/i/kub8jl7zkgvw79sx7ib5.png)

<figcaption>Unity Scene editor opening a default empty scene in 3D mode. Empty Scenes in Unity3D will by default include _Main Camera_ and _Directional light_ objects.</figcaption></figure>

<figure>
![A scene editor showing a heavily populated scene in 3DM mode.](https://dev-to-uploads.s3.amazonaws.com/i/t606jipj1at4nt5wghzp.png)
<figcaption>Unity Scene editor showing an example scene, with a few objects selected. You can use the scene view to edit levels in your game.</figcaption></figure>

[^1]: Still, there can only ever be one "main" active scene at a time.

Every _game object_ in Unity needs to be _in_ a scene.

## Game Objects

A **Game Object** (in code, `GameObject`) is one of the basic building blocks of a game.

Game Objects can represent both _physical_ things you see in the game (e.g., a player, the ground, a tree, a terrain, lights, a weapon, a bullet, an explosion) _as well as_ _metaphysical_ things (e.g., an inventory manager, a multiplayer controller, etc.) in your game.

Every Game Object has a position and rotation. For metaphysical objects, this doesn't matter.

Game Objects can nest under each other. Each object's position and rotation is relative to its parent object. An object directly in the scene is relative to "world space" coordinates.

<figure>
![Screenshot showing nested objects for organizational purposes](https://dev-to-uploads.s3.amazonaws.com/i/v3pzfj9150ivvrvmj0af.png)

<figcaption>A group of objects nested together in a scene under an empty "Interior_Props" object, for organizational purposes</figcaption></figure>

You might choose to nest your objects for many reasons. For example, you might decide it organizationally makes sense to put all your "environment" (e.g., individual pieces that make up a city or village) objects under an empty parent object. This way, it can be collapsed in the scene view and easily moved together when building your game.

<figure>

![Screenshot showing nested objects for functional purposes](https://dev-to-uploads.s3.amazonaws.com/i/3ln970djk0hy8hij539x.png)

<figcaption>A group of objects nested under the player. These include the player's weapon, avatar, and various UI elements rendered around the player.</figcaption></figure>


Game Object nesting can also have _functional significance_. For example, a "Car" can be an object, with code that controls the car's speed and rotation as a whole. But individual child objects might represent the four wheels (these would spin independently), the car body, windows, etc. Moving the parent car object would move all the child objects, keeping their relative orientation to the parent (and each other). We might want the player to interact with a door separately from the rest of the car, for instance.

## Components (& MonoBehaviors)

<figure>
![Screenshot showing the inspector window on an object.](https://dev-to-uploads.s3.amazonaws.com/i/6zt9yqen8mtw6l3ki84g.png)

<figcaption>
The Warrior object from the previous screenshot is shown above in Unity's "Inspector" window. Each illustrated section (e.g., Animator, Rigidbody, Collider) are _Components_ making up this object.</figcaption></figure>

Every Game Object is comprised of **Components**.

A Component implements a well-defined set of behaviors for a GameObject to execute. Everything that makes an object what it is would come from the components that make it up:

-   A single "visible" piece of a car will have a _Renderer_ component that paints it, and likely a _Collider_ component that sets up its collision bounds.
-   If a car represents the player, the car object itself might have a _Player Input Controller_ that takes key input events and translates these to code moving the car around.

While you can write large and complex Components that correspond 1:1 to an object (e.g., a player component codes the entire player, while an enemy component codes the enemy as a whole), it's typically common to factor out your logic into streamlined pieces corresponding to individual _traits_. For example:

-   All objects with _health_, whether a Player or an Enemy, might have a `LivingObject` component that sets an initial health value, takes damage, and triggers a death event once it dies.
-   A player might additionally have an input component controlling its movement, while the enemy might have an AI component that controls its movement instead.

Components receive various callbacks throughout their lifetime, known in Unity as _Messages_. Examples of Messages include `OnEnable`/`OnDisable`, `Start`, `OnDestroy`, `Update`, and others. If an object implements an `Update()` method, this method will automagically be called by Unity in every frame of the game loop while the object is active, and the given component is enabled. These methods can be marked `private`; the Unity engine will still call them.

Components can also expose public methods as you'd expect. Other components can take a reference to a component and call these public methods.

## Assets

**Assets** are the on-disk resources that make up your game project. These include meshes (models), textures, sprites, sounds, and other resources.

When serialized to the disk, your scenes are represented as assets made up of the Game Objects inside of them. We'll also discuss in the next section how you can make Game Objects that are reused often into an asset known as a Prefab. [^2]

[^2]: The term asset is a bit overloaded. Scenes are Prefabs are _serialized_ and _organized_ in your projects like other assets. You can browse these in the Asset view alongside code and other assets. If you're deep in Editor code manipulating an asset, Prefabs and Scenes cannot usually be treated as assets.

![Unity Asset view showing visual assets in a game project](https://dev-to-uploads.s3.amazonaws.com/i/795kp6euh61bcjeiu34k.png)

Assets can also represent less tangible things, such as Input Control Maps, Graphics Settings, i18n string databases, and more. You can also create your own custom asset types [using ScriptableObjects](https://unity.com/how-to/architect-game-code-scriptable-objects). I wrote about how these are saved
[here](https://blog.eyas.sh/2020/09/where-scriptableobjects-live/).

For your in-development project, assets form the key representation of your project's codebase, alongside your code.

Your built-and-bundled game will include _most_ [^3] of your assets. These assets will be saved on disk on the device where the game is installed.

[^3]: You can further optimize your game by loading some assets over the network or employing other [asset-management techniques](https://docs.unity3d.com/Packages/com.unity.addressables@latest/).

## Prefabs

Game Objects, their Components, and their input parameters exist as individual _instances_ in a scene. But what if a particular class of objects is commonly repeated? Such objects can be made into a **Prefab**, which is effectively the object in asset form.

Instances of a prefab in a scene can have local modifications that distinguish it (e.g., if a _tree_ object is a prefab, you can have tree instances of different heights). Instances of a prefab all inherit and override data from their prefab.

### Nested Prefabs

Starting with Unity 2018.3, Prefabs can be nested just as you expect:

1. A parent object with prefab child objects can be a prefab itself. In the parent prefab, the child prefab instance can have its own modifications. In the scene, the entire prefab hierarchy is instantiated, and scene-specific modifications can layer on top.
2. A prefab instance in a scene with its own local modifications can be saved as its own "Prefab Variant" asset. A variant is a prefab asset that inherits from another prefab, applying additional modifications on top.

These concepts compose; a prefab variant of a nested prefab, or a prefab variant of a prefab variant, for instance.

## Serialization & Deserialization

Your project's assets, scenes, and objects are all persisted on-disk. When editing your game, these objects are loaded in memory and saved back to disk using [Unity's serialization system](https://blogs.unity3d.com/2014/06/24/serialization-in-unity/). When playtesting your game, the objects and scenes in-memory are loaded through the same serialization system. This system also maps between assets in your compiled bundle and the loaded/unloaded scene objects in-memory.

The Unity Engine's Serialization/Deserialization flow loads on-disk assets into memory (in your project: for editing/playtesting; in-game, when loading a scene) and is responsible for saving the state of your edited objects & components back into their scenes and prefabs.

Therefore, the serialization system is also at the core of the Unity Editor experience itself. For a `MonoBehavior` to take an input on construction when instantiated in a scene, those fields must be _serialized_.

Most core Unity types such as `GameObject`s, `MonoBehaviour`s, and asset resources are [Serializable](https://docs.microsoft.com/en-us/dotnet/api/system.serializableattribute) and can receive initial values on creation from within the Unity Editor. Public fields on your `MonoBehavior` are serialized by default (if  they're of a serializable type), and private fields need to be marked with Unity's [`[SerializeField]`](https://docs.unity3d.com/ScriptReference/SerializeField.html) attribute to be serialized as well.

# Conclusion

These six concepts cover essential structural pieces for architecting games in Unity. Knowing more about these and how assets on-disk map to in-memory representation should give you the intuition needed to follow some of the more advanced tutorials.

There are still significant areas to wrap your head around in Unity. Understanding the Editor and [mapping your Software Engineering best practices to game development best practices](https://blog.eyas.sh/2020/10/unity-for-engineers-pt2-six-practices) will help hone in your skill. Even more, understanding broad areas such as lighting, animation controllers, navigation meshes, input handling will help you go a long way as well.

I will cover many of these topics in future iterations of this series, but I'm hopeful you're armed with the knowledge that makes the rest of your game development journey more intuitive.