Unity For Software Developers

• The Unity engine is built with native C and C++ but it’s scripting layer uses .NET

  • .NET is an open source development platform for building apps

  • Applications that run on the .NET platform are built using one or more of the .NET implementations

    • E.g., Mono is an open source implementation of .NET[source]

  • Unity uses it’s own custom .NET implementation that supports .NET Framework 4.x and .NET Standard 2.1, which are both .NET platform API levels

• C# is the primary programming language used to write scripts

  • Unity’s .NET implementation supports all of C# 8

• When you build your project, Unity uses one of two compilation styles to compile your code. This is based on the scripting backend of your project:

• Mono: uses just-in-time (JIT) compilation to compile your code into CIL that can be interpreted by each platform at runtime

  • CIL stands for “Common Intermediate Language”

  • The .NET runtime environment compiles CIL instructions into native code just in time for it to be executed

• IL2CPP: uses ahead-of-time (AOT) compilation to compile your code into C++

• In this course, we’ll be using the Mono scripting backend and the .NET 4.X version level of .NET

• The compiler converts your C# code into CIL code that it compiles as one or more DLLs

  • Common Intermediate Language (CIL) code gets compiled into machine code at runtime so it can run on many different platforms

  • In .NET, DLLs represent assemblies, which are basically components that the.NET runtime knows how to execute

Your First Script

• We’re going to start by creating a simple script to get our hands moving

• We’ll review what we did in the next section

• Give an overview of the project and the scene

  • We have a functional scene with some basic mechanics, but this is a survival game so the player needs to be able to carry items in an inventory

  • We’ll add this feature creating a new script and adding it to the scene

• What did we do in the previous section?

  • We created a C# class that extends the MonoBehaviour class

    • Classes that derive from MonoBehaviour are called Components

    • So we essentially created an Inventory component

  • Then we attached the Inventory Component to the Player GameObject

    
    

• GameObjects are the building blocks of your scenes in Unity

• They can represent characters, props, scenery, cameras, waypoints, and more

• Each GameObject’s functionality is defined by the Components that are attached to it

  • Refer to the Player GameObject that outputs the contents of it’s inventory to the Console because of the Inventory Component

  • Every Gameobject has at bare minimum a Transform component with position rotation and scale that can’t be removed.

• There are a couple of ways to execute code in Unity without attaching a component to a GameObject

  • E.g., RuntimeInitializeOnLoadMethodAttribute

  • But they’re recommended for very special use cases only, so we won’t be covering them in this course

  
  

• MonoBehaviour is the base class from which every Unity script derives

  • It’s what allows you to attach your code to GameObjects

  • It gives your code access to Unity events that you can hook into

    • Refer to the Start method in the Inventory class that we created in the previous section

    • Mention that we’ll cover those events in a future section

• When referring to MonoBehaviour-based classes I switch between two different terms:

  • Scripts when I’m referring to the code or talking about them in the code editor

  • Components when I’m working in the Unity editor

Open the example project in File Explorer and navigate to folders and open files that are relevant to the lesson

• Now that we have a better understanding of how Unity works, let’s give some more functionality to the player

  • We gave the player an inventory but they currently have no way to add items to it

  • Let’s write some logic to let the player interact with items in the environment

  • This will serve as a base for the mechanic of picking up items and adding them to the player’s inventory, which we’ll expand on in the next section

• Unity’s Component-based approach to giving GameObjects functionality gives us the opportunity to take advantage of a concept called Composition, instead of, or in complement to, the pattern of Inheritance

• Inheritance and Composition are techniques for establishing relationships between classes and objects

• Inheritance is the mechanism of basing one class on another class

  • If you’re an Object-oriented programmer (OOP), you should already be familiar with using inheritance to structure your code into hierarchies

  • Our component classes inherit from MonoBehaviour

• Composition is used to define a class as the sum of its parts

  • Behavior is created by composing a class from multiple objects

  • GameObjects are a sum of their components

• While inheritance is a common approach to development, classes that are created through inheritance are considered tightly coupled to their parent classes

  • This is one factor that can lead to spaghetti code

  • Spaghetti code is basically messy code lacking the structure required to scale effectively

  • It tends to be problem in Game Development due to how often objects tend to need to collaborate with each other

• That’s not to say that inheritance is bad

  • Inheritance and composition are compatible and complement each other

  • However, we are going to lean into using composition in an effort to combat spaghetti code in our project from the outset

• Let’s review the composition vs inheritance concept using a simple example

  • Building on the code we’ve been working on, let’s implement some logic so that our player can add items from the environment into their inventory

Anatomy of a MonoBehaviour

• Before we keep going, let’s pause to take a closer look at the anatomy of a MonoBehaviour

• MonoBehaviours are different from POCOs in that they cannot be instantiated using “new Object” and also do not support constructors

  • They must be attached to GameObjects and once they are are affected by Unity’s callbacks

• When you implement MonoBehaviour, you get access to methods that let you hook into Unity

  • You implement these methods and Unity calls them either once, during every frame, or when specific events occur (or when a criteria is met)

Visual Studio

Display the Inventory class

• We’ve already used the Start method in our Inventory component

  • Start is only called one time, during the script initialization phase

Webpage

• This flowchart represents the lifecycle of a MonoBehaviour

• It’s split into sections based on Unity’s lifecycle

• Initialization, Physics, Input Events, Game Logic, Scene Rendering, Gizmo Rendering, GUI Rendering, End of Frame, Pausing, Decommissioning

• Here are the most common callbacks we’ll use:

• Awake: Called once when the script instance is being loaded

• Typically used to initialize variables or game state before the game starts. Runs before Start, often use to prepare references that will be used by other callbacks.

• OnEnable: Called next, when a GameObject is enabled, which may happen multiple times in an objects lifecycle unlike Start and Awake.

• Start:

  • Called after Awake

• Update: Called every frame at a variable frame rate

• FixedUpdate: Called at a fixed frame rate in lockstep with the physics simulation.

• OnDisable: Called when a GameObject this component is attached to is disabled (can be called multiple times in objects life)

• OnDestroy: Called right before an object is destroyed or de-instantiated, called only once.

• Physics callbacks: We’ll discuss these later but are called by events in the physics system like collisions.

• Now we know how MonoBehaviours work—but how can we get them to work together?

  • Some scripts can function in isolation (e.g., high-level managers or small helpers)

  • Most mechanics require two or more scripts to collaborate with one another

• In this section, we’re gonna cover all the ways that MonoBehaviours can interact with one another

• In our game, interactable GameObjects are composed of the Interactable component and a set of InteractionHandlers components

  • We’ll use this as an example to cover each method

• Method 1: Editor Properties

  • Right now, the references to the handlers can be set from the editor

  • This is possible because Unity exposes public fields in the editor

  • You can also expose private fields in the editor by marking them with the [SerializeField] attribute.

    • Exposing a private field in the editor allows a reference to be set at edit-time by the user but no other class can modify the value.

    • This allows you to avoid making fields public just to be able to set them in the editor, keeping code cleaner

      • This is another technique you can use to avoid spaghetti code

  • In both cases, the type must be serializable. If it isn’t, Unity won’t expose them in the editor.

    • Serialization is the process of converting an object into a stream of bytes to store the object or transmit it to memory, a database, or a file. Its main purpose is to save the state of an object in order to be able to recreate it when needed. The reverse process is called deserialization.[Source]

    • You can enable serialization on classes and structs with the [Serializable] attribute

    • Only non-abstract, non-generic custom classes can be serialized

• Method 2: GetComponent

  • If you want to access scripts programmatically, you can use the GetComponent methods that are a part of the Component class’s API[Source]

• This can be a great way to set references we don’t want set from the editor

• It can also be used to grab dynamic references to other components at runtime based on interactions that can’t be predefined at edit time, like getting a reference to an instantiated bullet or enemy

• All methods return one or more components matching the declared type if attached (or null if not). Disabled components are returned, as well.

• GetComponent: returns the first component that is found (order is undefined)

• GetComponents: returns a list of components

• GetComponentInChildren: returns the first component that is found in the GameObject or it’s children using depth first search

• GetComponentsFromChildren: returns a list of components found on both the GameObject and any of its children (works recursively).

• GetComponentInParent: same as GetComponentInChild except resources upwards

• GetComponentsInParent: same as GetComponentsInChild except resources upwards

• Method 3: Runtime Callbacks

  • Another way to access scripts at runtime is using physics-based methods and runtime callbacks

• This is a good approach to use for mechanics that are based on interactions (e.g., a bullet hitting the player or an enemy)

• This approach depends on Unity’s built-in Physics system so all GameObjects must have colliders

• Physics-Based Methods

• *Cast (e.g., Raycast & BoxCast): returns hit information that includes the collider that the shape cast collides with in the scene

• Overlap* (e.g., OverlapBox & OverlapSphere): returns all colliders that overlap with the given shape

• Runtime Callbacks

  • OnCollision* (e.g., OnCollisionEnter): called on a script when a collision is detected. The collider of the other GameObject is included in the method’s signature.

  • OnTrigger* (e.g., OnTriggerEnter): same as OnCollision* except used for triggers. The colliders must be configured as triggers.

• Apart from the MonoBehaviour class, Unity provides another class to derive from called ScriptableObject

• Scriptable objects act as data containers that can be used to store data independently of class instances[Source]

• Scriptable objects are saved as assets that scripts can reference in their logic

  • Instances of scriptable objects are typically referred to as assets

    • To recap on terms, while in the Unity editor, we call MonoBehaviour-based classes “components” and ScriptableObject-based classes “assets”

  • They help avoid creating unnecessary copies of data that need to be accessed by multiple objects in the scene, which can reduce memory usage

  • They also help to decouple game logic from game data, which makes your code easier to scale and maintain

• Scriptable objects can hold information like configurations, settings, and other game data

• Let’s use scriptable objects to improve the maintainability and scalability of the inventory logic

  • The inventory references an array of strings that represent items

  • Magic strings are a code smell because they’re hard to keep track of and they’re prone to error

  • We’ll refactor the code to use scriptable objects instead of magic strings

• Coroutines

  • To briefly summarize what we’ve learned so far about scripting in Unity, Unity has complete control over the game loop which we can hook into using the Update methods of our MonoBehaviours

    • Most of the code we write will run once every frame

    • That means that any logic we write will need to execute within the span of a single frame

  • But what if you need to implement a behavior that can’t execute to completion in a single frame?

    • You need to track the time over which that behavior needs to execute

    • This can add unnecessary complexity to otherwise simple logic

  • As a simple example, let’s say we wanted to fade an object out when the player picks it up

  Tutorial 1

  
  

  • This approach works but it requires an additional field and logic to track the progress of the effect

    • This increases the complexity of the script

    • It’s now responsible for (1) fading the object and (2) keeping track of time

    • This script is relatively simple so it isn’t very noticeable, but more complicated scripts will be much harder to work with

  • That’s where Coroutines come in!

  • A coroutine is a function that has the ability to pause execution and return control to Unity but then to continue where it left off on the following frame[source]

  Tutorial 2

  
  

  • Unity provides a set of classes that all inherit from YieldInstruction which, when returned from a coroutine, tell Unity how long to wait before resuming execution

    • WaitForSeconds: suspends execution for the given about of seconds

    • WaitForFixedUpdate: waits until the next fixed frame rate update

    • WaitUntil: suspends execution until the supplied delegate evaluates to true

  WaitWhile: suspends execution until the supplied delegate evaluates to false

• Now that we’ve written some code, let’s talk about performance

• If your game is slow, no one will play it, so you need to optimize your code to run well on your target platform(s)

  • This applies to other aspects of your game, as well—like 3D models and VFX—but we’re going to focus on code performance

• Performance is important but don’t overdo it or optimize prematurely[Source]

• In this section, we’re going to cover some factors related to both .NET and Unity that you should consider when you write game code

• You need to know how to use the profiler before you can effectively optimize your code

• The profiler is a tool that provides performance information about your game

  • You can run it in the editor to get an overview of resource allocation during development

  • Or you can connect it to devices on your network to see how your game performs on your target platform/device(s)

• Let’s see the profiler in action

• Our profiler window set up to show us the performance of our scripts, so let’s take a look some things you should consider when writing code in Unity

• At a high level, the main things you want to keep in mind are expensive/long running logic, garbage collection, and Unity hot paths

• We can use the Interactor class as an example

  • Right now our logic is well written and performant, however we could have written it in a different way

• Let’s use the profiler data to get a better understanding of why our code is under performing

• Expensive/Long Running Logic

  • This one is self explanatory—we only have a few milliseconds of computation time per frame, so use it wisely

    • Avoid expensive loops

    • Don’t search the scene

  • If you need to perform an expensive computation, try to pre-compute the values ahead of time or perform computations while the scene is loading
    (i.e., In the Awake or Start methods)

• Garbage Collection

  • The hierarchy view in the profiler has a row called “GC.Alloc” that takes up frame time and affects the GC Alloc column

    • GC.Alloc stands for garbage allocations, which is related to garbage collection in .NET

  • Garbage Collection is a form of memory management[source]

    • Your game only has a finite amount of memory to work with

    • The objects that your logic creates take up space on the computer or device that your game is running on

    • .NET has a built-in garbage collector that allocates and releases memory so you don’t have to[source]

    • Memory is allocated when a new object is created

    • Memory is released when existing objects become orphaned

  • Before we refactored our code, Interactor’s Update method was allocating and releasing memory for each of the 500 Interactables it was assigning to _interactable during each frame

    • This is bad because garbage collection is an expensive process

    • We can see this in the profiler data

  • It isn’t always obvious when memory is being allocated[source]

    • For example, LINQ extension methods tend to generate garbage and can cause GC frame rate spikes[source]

  • Let’s minimize garbage collection by replacing this LINQ-based approach with a simple for loop

• Tutorial/Demonstration Steps

1. Replace _interactables.ToList().ForEach() with a for-loop

2. Switch back to Unity

3. Click Play and then pause the scene

   • Our logic is no longer allocating garbage!

• ...but it’s still running slow!

• Unity Hot Paths

  • One of the easiest ways to optimize your code is to keep it out of Unity’s hot path

  • A hot path is where a program spends most of its execution time[source]

    • Unity’s hot path is basically all variations of Update

  • Some code is going to have to live in Unity’s hot path (so make sure it’s efficient!)

  • There are a few ways to keep your code out of Unity’s hot path

    • Start, Awake, OnEnable, OnDisable

    • Physics method (we already used OnTrigger*)

    • Coroutines

  • Coroutines are essentially functions that you can execute for multiple frames[source]

    • When you call a function, it runs to completion before returning

    • Coroutines have the ability to pause their execution, return control to Unity, and then continue where they left off on the following frame

    • Coroutines a feature of Unity

  • Let’s complete our refactor by moving our logic into a Coroutine and out of Unity’s hot path

  
  

• Tutorial/Demonstration Steps

1. Implement a method called “FindNearestInteractable” that returns IEnumerator

   • Coroutines are iterator methods that Unity uses to step through—or enumerate over—your logic

   • IEnumerator is the base interface for all non-generic enumerators’

   • You can think of this method like a collection of objects

2. Add yield return new WaitForEndOfFrame() to FindNearestInteractable

   • When Unity iterates over this method, it will get an object that tells the engine to wait until the next frame before iterating again

3. Wrap the yield statement with a never ending while statement

   • We’re going to let this method run indefinitely

4. Wrap the yield statement with a for-loop of _interactables

   • Now we’re processing one interactable per frame

5. Copy the logic from Update to the for-loop

6. Introduce a local variable to hold a copy of WaitForEndOfFrame

   • Creating a new instance of WaitForEndOfFrame will generate needless garbage so let’s optimize this code by keeping a single local reference that’ll never be orphaned

7. Switch back to Unity

8. Click Play and then pause the scene

   • Now are logic is completely optimized

• Namespacing is a feature of the C# programming language and is primarily used to organize your classes into named collections[source]

  • In other words, a namespace declares a scope that contains a set of related objects[source]

  • You should already be familiar with the System, UnityEngine, and UnityEditor namespaces

  • System is a part of the .NET API and contains fundamental classes and base classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions[source]

  • Likewise, UnityEngine and UnityEditor contain fundamental classes that are used by Unity and the editor respectively

• Namespaces control the scope of your class names so they can help prevent clashes between names[source]

  • You can create multiple classes with the same name as long as they’re in different namespaces

  • This is useful when you use a third-party plugin that declares a class with the same name as one in your project (assuming the plugin doesn’t use namespaces)

• Besides helping to organize your code and avoid name clashes, namespaces also help you define System Boundaries within your code

• A System Boundary is a conceptual line that places a barrier between a system and the rest of your code

  • In our case, a system refers to the set of classes that implement a concept or mechanic

  • For example, take the concept of interactions which is made up of the following:

    • Interactor

    • Interactable

    • InteractionHandler

• To include a class in a namespace, use the namespace keyword

  • A namespace can be a single world (e.g., Game) but generally consist of multiple words that are delimited with periods (e.g., Game.Inventory or Game.Player)

To reference a class from another namespace, use the using keyword

• An Assembly is the compiled output of your code, and typically comes in the form of a DLL or EXE file—it’s the smallest unit of deployment for any .NET project[source]

• By default, when you build your Unity project, your scripts are compiled into an assembly file called Assembly-CSharp.dll

  • You can see this in both your Visual Studio solution and in your game’s build folder

  • Editor scripts live in the Assembly-CSharp-Editor assembly which does not get included in the build

• Like namespaces, assemblies can be used as an organizational tool and to set up system boundaries that are much more difficult to cross

  • If you want to include a namespace that isn’t a part of the current assembly, you have to add a reference to the assembly that the other namespace belongs to

• Assemblies can overcomplicate a simple project if you aren’t careful, but they’re an important tool in improving the scalability of your project

• Using assemblies can also speed up your development workflow

  • When you modify a script (i.e., change the code), Unity has to recompile every other class that lives in the same assembly as that script

  • A project with dozens of scripts in the same assembly will take a longer time to recompile

  • If you separate your scripts into multiple assemblies, Unity will only have to recompile a subset of your entire project each time you make a change

• In Unity, you define assemblies using Assembly Definitions

• To add a script to an assembly, create an Assembly Definition in the same folder as the script

  • Unity automatically associates scripts with assemblies based on the folder structure

• Each feature of the Unity engine comes in the form of package[source]

• A package is a container that stores various features or assets

  • Packages can contain the following:

    • C# Scripts

    • Assemblies

    • Native Plugins

    • Models, textures, animations and audio clips, and other assets

• Unity’s built-in packages include the particle system, physics, terrain, audio, and UI (to name just a few)

• Packages are also referred to as dependencies

  • Each Unity project depends on its own set of packages

  • For example, a mobile game depends on different packages than a VR game

• Packages can depend on other packages, which creates a dependency graph that Unity has to manage

• Packages are managed at the project level by the Unity Package Manager

• The Unity Package Manager, or just “package manager”, is the official package management system for Unity

• The package manager is responsible for loading existing packages, installing new packages, and resolving the entire dependency graph for your project

• When you open a project in Unity, the package manager reads the Project Manifest to figure out which packages to load in the project[source]

• The Project Manifest is a JSON file that both keeps track of your project’s dependencies and acts as a configuration file for the package manager

• The benefit of this package based approach is that it’s easier to manage the versions, dependencies, as well as the distribution of individual features

• As a developer, you can create your own custom packages to manage features that you’d like to share across multiple projects

The Importance of Automated Testing

• Testing is an important part of making games

• Every time you press Play and verify that your game is working the way you expect it to you’re performing a test

• But performing tests manually is time consuming and prone to human error

  • For example, to test our interaction code I need to start the scene, wait for it to load, and then find something to interact with

  • That only takes about a minute and may not seem that bad but it actually wastes a lot of time in the long run

  • Now imagine testing something that’s harder to set up, like an interaction that only happens during a boss fight

• That’s where automated testing comes in

• Automated testing, or test automation, is the use of software separate from the software being tested to automate a human-driven manual process of reviewing and validating that software [source]

• In other words, it’s offloading manual testing to a computer so you don’t have to do it

• This is super valuable because…

  • Your computer can perform tests much faster than you can

  • It can perform the same test a hundred times and always produce the same result

  • Once your tests are defined they’ll be a part of your code forever so you don’t have to remember which ones to run or how to perform them

• That last point is critical to help guarding against regressions

• A regression is a type of bug where a feature that was working before stops working [source]

• Regressions are particularly insidious because they tend to go undetected until the worst possible moment.

Automated Testing in Unity

• Unity has a built-in, automated testing solution called the Unity Test Framework, or UTF

  • It’s also referred to as the “Unity Test Runner”

• UTF lets you test your code in both Edit Mode and Play Mode, and also on target platforms (e.g., Standalone, Android, iOS, etc.) [source]

• Under the covers, UTF uses a Unity integration of NUnit version 3.5 [source]

• NUnit is an open-source unit testing framework for .Net languages

  • It has everything you need to create and run automated tests

• At their core, tests are just methods that you mark with one of two attributes

  • The [Test] attribute is a part of the standard NUnit library and is the primary way of creating a unit test

    • I use this as often as I can because it’s simple and runs fast

  • The [UnityTest] attribute is an addition to the standard NUnit library and creates a test that can skip frames as well as leverage some of Unity’s other features

    • I use this only when I need to use special yield instructions in Edit Mode or if I need to skip frames or wait a certain amount of time in Play Mode

What Do Automated Tests Look Like?

• Let’s take a look at some examples from our project: Example Code

What We’ll Be Covering

• There’s a lot to cover when it comes to automated testing

  • I.e., the difference between unit, integration, and functional tests

• But in this course, we’re just gonna focus on the different types of tests you can write for your games in Unity (Edit Mode and Play Mode)

Preparing Your Project For Testing

• Adding new tests to your project is simple but we need to do a little prep work

• In order for Unity to be able to recognize and run our tests, we need to create a test assembly

  • A test assembly is just a regular assembly that has a reference to the Unity test runner and the NUnit framework

  • The test assemblies for PlayMode and EditMode tests have slight differences

• We can create our test assembly by hand, but it’s much easier to just let Unity generate it

• Now that we have an idea of how to set up our tests, let’s take a closer look at the two types of automated tests in Unity: PlayMode and EditMode tests

• EditMode tests (also known as Editor tests) only run in the Unity editor and have access to both your game code and the editor code

• To create an EditMode test all we have to do is add a method to a class that’s associated with an EditMode test assembly and mark it with the [Test] or [UnityTest] attributes

  • Just like with PlayMode tests, EditMode test methods marked with the [UnityTest] attribute must return an IEnumerator and have access to special yield instructions

  • The difference is that EditMode test code runs in the EditorApplication.update callback loop as opposed to the game loop

• EditMode tests are just fine for testing most of your game code, but can also be used to test custom Editor extensions

  • I.e., custom inspectors, editor windows, and property drawers

• PlayMode tests are designed to exercise your game code

• To create a PlayMode test all we have to do is add a method to a class that’s associated with a PlayMode test assembly and mark it with the [Test] or [UnityTest] attributes

  • Test methods marked with the [UnityTest] attribute return an IEnumartor because Unity runs them as coroutines

  • This is useful when you need to wait for the next frame or a certain amount of time while the test is running

    • E.g., WaitForFixedUpdate and WaitForSeconds

  • These types of tests are slower and should be used less often to verify critical behaviour that can only be tested in your running game

• Play Mode tests can be run as a standalone in a Player or inside the Editor using the Test Runner Window

  • To run Play Mode tests in a Player, click the “Run all in player” button in the Test Runner Window

  • Unity will build and run your tests on the currently active target platform and display the test results in the Editor UI

• Congratulations on completing the course

• Let’s recap on everything you’ve accomplished

  • In chapter 1 you started out by familiarizing yourself with Unity

    • You got your environment set up for development

    • You downloaded and installed Unity Hub to manage your Unity installations

    • And you created a fresh project, which we set up using a standard project format

  • In chapter 2 you got acquainted with scripting in Unity

    • You learned all about Unity’s scripting backend, which is based on .Net and uses the C# programming language

    • You wrote your first script and learned about MonoBehaviours and GameObjects

    • You learned the difference between composition versus inheritance and how to use both approaches to developing in Unity

    • Then you took a closer look at MonoBehaviours and learned about the special Unity event function that they expose

    • After that you learned all the ways that scripts can interact with each other

    • What scriptable objects are and the role they play in Unity

    • How coroutines work and what they can be used for

    • And finally, how to use the profiler to optimize your code

  • In chapter 3 you discovered how to organize your project so that it’s easier to maintain and can scale with new requirements

    • You learned about namespaces and how they can be used to define system boundaries that keep your code organized and decoupled

    • Then you built on namespaces by defining assemblies which solidified your system boundaries and optimized compilation

    • Finally you took some generic code and moved it out of your project and into a custom Unity package so you could reuse it elsewhere

  • And in chapter 4 you took your well established project and made it even better by adding automated tests

    • You learned why automated testing is so important to game development

    • You discovered the differences between EditMode and PlayMode tests

    • And you wrote some tests that we ran in both the editor and in standalone mode

• This course was designed to give you the skills and tools to help you finish your next game with confidence. Good job for making it to the end!