Steam Next Fest - October 2023

Follow on Steam to get access to the demo in October as part of Next Fest.

Unity Single Scene Architecture Series

In this post, we'll finish the game UI by adding a Game Over screen, a UI Manager and wire everything up to the Game Manager... with tests.

Refactoring Prefabs with Prefab Variants

If we follow the same steps as the previous two posts for framing out the UI, we'd be duplicating some of the exact same game objects and components, such as the canvas and the background panel. Just like with code, when you see duplication, it can be an opportunity to refactor. In this case, instead of making a new prefab for the canvas we can make a base prefab, then use prefab variants to customize for each screen's content.

Let's do this now:

• Add a child empty game object underneath "UI" named "GameOverController"
• Add a child to "GameOverController" from the context menu UI > Canvas named "UICanvas"
• Change the Canvas Scaler component to Scale With Screen Size with ReferenceResolution set to 1920 x 1080
• Add a child to the canvas from the context menu UI > Panel, named "Background"
• Set the Image component Color to black with no transparency

That's enough for the base prefab. In the Project window create a new folder under "Bundles" named "UI". Drag the "UICanvas" from the scene into this folder to make a prefab, then delete it from the scene.

Now we have a base prefab for the three canvases needed for the UI, as well as any future ones.

Game Over Screen Variant

Now create the canvas for the Game Over screen. Select "UICanvas" in the Project then use the context menu Create > Prefab Variant to create a new variant named "GameOverCanvas" and open it in prefab editing mode:

• Add a child to "Background" with the context menu UI > Text - Text Mesh Pro
• Set the Rect Transform to middle stretch. set the Y position to 100 and Height to 200
• Set the text to "Game Over", center the horizontal and vertical alignments, set font size to 200
• Add another child to "Background" from the context menu UI > Button - Text Mesh Pro
• Set the width to 300, height to 100, Y position to -200
• Set the Text to "PLAY" with font size 64

Mark the prefab variant as Addressable with an address of "GameOverCanvas".

Looks a lot like the MenuCanvas right? We could use one prefab for both and maybe just change the text at runtime, but I am going to assume in the future the MenuCanvas will have more menu items for things like settings, credits, saved games, and more. We'll continue to keep these separated and distinct.

Loading Variant

Duplicate the "GameOverCanvas" variant we just created and rename it to "LoadingCanvas" then open it in prefab editing mode.

• Delete the Button
• Change the text to "LOADING"
• Set the text Y position to 0

Mark the prefab variant as Addressable with an address of "LoadingCanvas".

Menu Screen Variant

Duplicate the "GameOverCanvas" variant again and rename it to "MenuCanvas" then open it in prefab editing mode.

• Change the text to "Single Scenery"
• Don't worry about the Button for now, we'll come back to that

Mark the prefab variant as Addressable with an address of "MenuCanvas".

We still have the two old prefabs for the LoadingCanvas and MenuCanvas. Delete them both.

Refactor for Events

Before we add scripting to our "GameOverCanvas", I am unhappy with the way the UI events are being exposed for the "MenuCanvas". If you remember from the previous post, we're exposing the "OnClick" event of the button by making the entire button publicly accessible.

What if we later change that button to be something else, add more UI controls that have new events, or swap out UGUI for the new UI Toolkit (you know, when it's production ready in a few years)? Instead, let's have these loaded prefabs just emit plain events so that the parents of these objects do not need to know about their internals (encapsulation).

Scriptable Object Events

There are plenty of articles about using ScriptableObject, which is a sibling to MonoBehaviour meant to represent a custom asset in a Unity project. The script itself is not an asset, it is source code that gets compiled into a library at build time and distributed with the player, but the instances of that ScriptableObject, which can be created with the editor menu are assets (that can be addressable). Here's my version of a simple event class that allows listeners to add/remove callback methods, and publishers of the event to "invoke" it.

using System;
using UnityEngine;

namespace SingleScenery
{
    [CreateAssetMenu(fileName = "GameEvent", menuName = "Single Scenery/GameEvent")]
    public class GameEvent : ScriptableObject
    {
        private Action gameEvent;

        public void Invoke()
        {
            gameEvent?.Invoke();
        }

        public void AddListener(Action callback)
        {
            gameEvent += callback;
        }

        public void RemoveListener(Action callback)
        {
            gameEvent -= callback;
        }
    }
}

Now we can create instances of events and "inject" an event (via the editor) into an event invoker and one or more event listeners.

Event Button

Let's create a new component that can be added to a UI button and simply invoke a configured event on click. In the "Scripts\UI" folder add new script named "UIEventButton":

using UnityEngine;
using UnityEngine.UI;

namespace SingleScenery
{
    public class UIEventButton : MonoBehaviour
    {
        [SerializeField] private GameEvent onClickEvent;

        private Button _button;

        private void Awake()
        {
            _button = GetComponent<Button>();
        }

        private void OnEnable()
        {
            _button.onClick.AddListener(OnClick);
        }

        private void OnDisable()
        {
            _button.onClick.RemoveListener(OnClick);
        }

        private void OnClick()
        {
            onClickEvent.Invoke();
        }
    }
}

Configure a New Event

Now we can use our new GameEvent to create a new instance of an event in the project as a custom asset.

• Create a new folder in "Bundles" named "Events"
• Using the context menu Create > Single Scenery > GameEvent add a new event named "OnPlayEvent"

Refactor the Menu Screen

Let's integrate our new event system into the menu screen classes.

• Open the "MenuCanvas" prefab variant in the Project
• Select the "Button" and use Add Component to add the new "UI Event Button" component
• Assign "OnPlayEvent" to the On Click Event field

Open the "MenuController.cs" script and refactor it to listen to this new event, so that when the Play button is clicked, the controller will hide the menu.

using UnityEngine;

namespace SingleScenery
{
    public class MenuController : UIController
    {

        [SerializeField] private GameEvent onPlayEvent;

        private void OnEnable()
        {
            onPlayEvent.AddListener(Hide);
        }

        private void OnDisable()
        {
            onPlayEvent.RemoveListener(Hide);
        }

    }
}

Now the menu screen functionality is completely encapsulated.

But now we've broken our test code. Open "MenuController_Tests.cs" and replace the code with:

using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;
using UnityEngine.TestTools;
using UnityEngine.UI;

namespace SingleScenery
{
    public class MenuController_Tests
    {
        // Test Settings

        const string ADDRESS = "MenuController";
        const float DELAY = 3f;

        WaitForSeconds delay;
        MenuController controller;
        bool _setup;

        bool _playClicked;

        [OneTimeSetUp]
        public void OneTimeSetUp()
        {
            if (GameObject.FindObjectOfType<Camera>() == null)
            {
                new GameObject("Camera").AddComponent<Camera>();
            }

            delay = new WaitForSeconds(DELAY);
        }

        [UnitySetUp]
        public IEnumerator Setup()
        {
            if (_setup) yield break;

            var handle = Addressables.InstantiateAsync(ADDRESS);
            yield return handle;  // wait for async call completion

            Assert.That(handle.Status == AsyncOperationStatus.Succeeded);
            Assert.IsNotNull(handle.Result);

            controller = handle.Result.GetComponent<MenuController>();

            Assert.IsFalse(controller.Ready);

            _setup = true;

            Debug.Log("Setup: controller is instantiated in test scene");
        }

        [OneTimeTearDown]
        public void TearDown()
        {
            if (controller != null)
            {
                Addressables.ReleaseInstance(controller.gameObject);
            }

            Debug.Log("Teardown: controller reference is released");
        }

        [UnityTest, Order(1), Timeout(5000)]
        public IEnumerator Step_1_Load()
        {
            controller.Load();

            yield return new WaitUntil(() => controller.Ready);

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);

            Assert.That(controller.transform.childCount > 0);
            Assert.IsNotNull(canvas);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller load passed");
            yield return delay;
        }

        [UnityTest, Order(2)]
        public IEnumerator Step_2_Show()
        {
            controller.Show();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller show passed");
            yield return delay;
        }


        [UnityTest, Order(3)]
        public IEnumerator Step_3_Click_Play()
        {
            var button = controller.gameObject.GetComponentInChildren<Button>(true);
            button.onClick.Invoke(); // simulate button click

            yield return null;

            // canvas should be hidden after event is consumed
            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: play clicked passed");
            yield return delay;
        }

        [UnityTest, Order(4)]
        public IEnumerator Step_4_Hide()
        {
            controller.Show();
            yield return null;
            controller.Hide();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller hide passed");
            yield return delay;
        }

        [UnityTest, Order(5)]
        public IEnumerator Step_5_Unload()
        {
            controller.Unload();
            yield return delay;
            Assert.That(controller.transform.childCount == 0);
            Debug.Log("Test: controller unload passed");
        }

    }
}

Now you can delete the "Menu.cs" script from "Scripts\UI", we won't be using it anymore. Always delete unused code. If you comment it out instead, then put a date on the comment with a "TODO" or searchable tag so you can come delete it later.

Last step is to open the "MenuController" prefab in the Project and assign the "OnPlayEvent".

Finish the Game Over Screen

Now that we have successfully refactored, we can go back to the "GameOverCanvas" prefab variant, open it and add the "UIEventButton" script to the button. Assign the same "OnPlayEvent".

GameOverController

Create a new script in the "Scripts/UI" folder named "GameOverController".

using UnityEngine;

namespace SingleScenery
{
    public class GameOverController : UIController
    {
        [SerializeField] private GameEvent onPlayEvent;

        private void OnEnable()
        {
            onPlayEvent.AddListener(Hide);
        }

        private void OnDisable()
        {
            onPlayEvent.RemoveListener(Hide);
        }
    }
}

Drag this script onto "GameOverController" game object in the Scene and assign the fields. Drag the "GameOverController" into the "Bundles" folder to make it a variant.

Mark the prefab as Addressable with the address "GameOverController".

Add Tests

Create a new test script using the context menu Create > Testing > C# Test Script in the "Tests\UI" folder named "GameOverController_Tests".

using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;
using UnityEngine.TestTools;
using UnityEngine.UI;

namespace SingleScenery
{
    public class GameOverController_Tests
    {
        // Test Settings

        const string ADDRESS = "GameOverController";
        const float DELAY = 3f;

        WaitForSeconds delay;
        GameOverController controller;
        bool _setup;

        bool _playClicked;

        [OneTimeSetUp]
        public void OneTimeSetUp()
        {
            if (GameObject.FindObjectOfType<Camera>() == null)
            {
                new GameObject("Camera").AddComponent<Camera>();
            }

            delay = new WaitForSeconds(DELAY);
        }

        [UnitySetUp]
        public IEnumerator Setup()
        {
            if (_setup) yield break;

            var handle = Addressables.InstantiateAsync(ADDRESS);
            yield return handle;  // wait for async call completion

            Assert.That(handle.Status == AsyncOperationStatus.Succeeded);
            Assert.IsNotNull(handle.Result);

            controller = handle.Result.GetComponent<GameOverController>();

            Assert.IsFalse(controller.Ready);

            _setup = true;

            Debug.Log("Setup: controller is instantiated in test scene");
        }

        [OneTimeTearDown]
        public void TearDown()
        {
            if (controller != null)
            {
                Addressables.ReleaseInstance(controller.gameObject);
            }

            Debug.Log("Teardown: controller reference is released");
        }

        [UnityTest, Order(1), Timeout(5000)]
        public IEnumerator Step_1_Load()
        {
            controller.Load();

            yield return new WaitUntil(() => controller.Ready);

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);

            Assert.That(controller.transform.childCount > 0);
            Assert.IsNotNull(canvas);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller load passed");
            yield return delay;
        }

        [UnityTest, Order(2)]
        public IEnumerator Step_2_Show()
        {
            controller.Show();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller show passed");
            yield return delay;
        }

        [UnityTest, Order(3)]
        public IEnumerator Step_3_Click_Play()
        {
            var button = controller.gameObject.GetComponentInChildren<Button>(true);
            button.onClick.Invoke(); // simulate button click

            yield return null;

            // canvas should be hidden after event is consumed
            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: play clicked passed");
            yield return delay;
        }

        [UnityTest, Order(4)]
        public IEnumerator Step_4_Hide()
        {
            controller.Show();
            yield return null;
            controller.Hide();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller hide passed");
            yield return delay;
        }

        [UnityTest, Order(5)]
        public IEnumerator Step_5_Unload()
        {
            controller.Unload();
            yield return delay;
            Assert.That(controller.transform.childCount == 0);
            Debug.Log("Test: controller unload passed");
        }

    }

}

Reconfigure Prefabs

Select the "LoadingController" prefab in the Project and assign the "LoadingCanvas" prefab variant into the Canvas Prefab field in the Inspector.

Select the "MenuController" prefab in the Project and assign the "MenuCanvas" prefab variant into the Canvas Prefab and the On Play Event fields in the Inspector.

UI Manager

We've got the screens we need for this very simple UI, now we need way to orchestrate them. Let's create the UIManager script now in "Scripts\UI".

using System.Collections;
using UnityEngine;

namespace SingleScenery
{
    public class UIManager : MonoBehaviour
    {

        [SerializeField] private LoadingController loadingController;
        [SerializeField] private MenuController menuController;
        [SerializeField] private GameOverController gameOverController;

        public void ShowLoading()
        {
            if (loadingController.Ready)
            {
                HideAll();
                loadingController.Show();
            }
        }

        public void ShowMenu()
        {
            if (menuController.Ready)
            {
                HideAll();
                menuController.Show();
            }
        }

        public void ShowGameOver()
        {
            if (gameOverController.Ready)
            {
                HideAll();
                gameOverController.Show();
            }
        }

        public void HideAll()
        {
            loadingController.Hide();
            menuController.Hide();
            gameOverController.Hide();
        }

        public IEnumerator LoadAssets()
        {
            yield return StartCoroutine(loadingController.LoadAsync());

            yield return StartCoroutine(menuController.LoadAsync());

            yield return StartCoroutine(gameOverController.LoadAsync());

        }

        public void UnloadAssets()
        {
            loadingController.Unload();
            menuController.Unload();
            gameOverController.Unload();
        }

    }
}

Not too complicated, the public API will allow the GameManager to choose when to load and unload assets, as well as methods to show and hide screens.

Drag this script onto the "UI" gameobject in the Scene, then drag the object to the "Bundles" folder in the Project to make it a prefab asset. Rename the prefab to "UIManager".

Mark the prefab as Addressable with the address "UIManager".

UI Manager Testing

Just like the controllers, we can write tests to load the UIManager as an addressable asset and execute its public API to verify the prefab is working.

using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;
using UnityEngine.TestTools;

namespace SingleScenery
{
    public class UIManager_Tests
    {
        // Test Settings

        const string ADDRESS = "UIManager";
        const float DELAY = 3f;

        WaitForSeconds delay;
        UIManager manager;
        bool _setup;

        [OneTimeSetUp]
        public void OneTimeSetUp()
        {
            if (GameObject.FindObjectOfType<Camera>() == null)
            {
                new GameObject("Camera").AddComponent<Camera>();
            }

            delay = new WaitForSeconds(DELAY);
        }

        [UnitySetUp]
        public IEnumerator Setup()
        {

            if (_setup) yield break;

            var handle = Addressables.InstantiateAsync(ADDRESS);
            yield return handle;  // wait for async call completion

            Assert.That(handle.Status == AsyncOperationStatus.Succeeded);
            Assert.IsNotNull(handle.Result);

            manager = handle.Result.GetComponent<UIManager>();

            _setup = true;

            Debug.Log("Setup: manager is instantiated in test scene");
        }

        [OneTimeTearDown]
        public void TearDown()
        {
            if (manager != null)
            {
                Addressables.ReleaseInstance(manager.gameObject);
            }

            Debug.Log("Teardown: reference is released");
        }

        [UnityTest]
        public IEnumerator Show_And_Hide_Loading()
        {

            yield return manager.StartCoroutine(manager.LoadAssets());

            var canvases = manager.GetComponentsInChildren<Canvas>(true);

            Assert.That(canvases.Length == 3);

            manager.ShowLoading();

            var canvas = manager.GetComponentInChildren<Canvas>();

            Assert.IsNotNull(canvas);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);

            yield return delay;

            manager.HideAll();

            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            manager.UnloadAssets();

            yield return delay;

            canvases = manager.GetComponentsInChildren<Canvas>(true);

            Assert.IsEmpty(canvases);

            Debug.Log("Test: manager show and hide loading passed");

        }

        [UnityTest]
        public IEnumerator Show_And_Hide_Menu()
        {

            yield return manager.StartCoroutine(manager.LoadAssets());

            var canvases = manager.GetComponentsInChildren<Canvas>(true);

            Assert.That(canvases.Length == 3);

            manager.ShowMenu();

            var canvas = manager.GetComponentInChildren<Canvas>();
            var controller = manager.GetComponentInChildren<MenuController>();

            Assert.IsNotNull(canvas);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);
            Assert.IsNotNull(controller);

            yield return delay;

            manager.HideAll();

            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            manager.UnloadAssets();

            yield return delay;

            canvases = manager.GetComponentsInChildren<Canvas>(true);

            Assert.IsEmpty(canvases);

            Debug.Log("Test: manager show and hide menu passed");

        }

        [UnityTest]
        public IEnumerator Show_And_Hide_GameOver()
        {
            yield return manager.StartCoroutine(manager.LoadAssets());

            var canvases = manager.GetComponentsInChildren<Canvas>(true);

            Assert.That(canvases.Length == 3);

            manager.ShowGameOver();

            var canvas = manager.GetComponentInChildren<Canvas>();
            var controller = manager.GetComponentInChildren<GameOverController>();

            Assert.IsNotNull(canvas);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);
            Assert.IsNotNull(controller);

            yield return delay;

            manager.HideAll();

            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            manager.UnloadAssets();

            yield return delay;

            canvases = manager.GetComponentsInChildren<Canvas>(true);

            Assert.IsEmpty(canvases);

            Debug.Log("Test: manager show and hide game over passed");

        }

    }

}

Run the tests in the Test Runner to verify everything is working. If you follow along in the Addressables Event Viewer you'll see that we load all the assets just to show one screen. We can easily optimize this later if needed by adding discrete methods to the UI Manager, but we'll come back to that when optimizing later (if needed).

Game Manager

Now that the UI Manager is working, we just need to hook it up to the GameManager, and then implement our first game workflow, which is to display the loading screen and the menu.

Go back to the "Scripts\GameManager.cs" file and edit:

using System.Collections;
using UnityEngine;

namespace SingleScenery
{
    public class GameManager : MonoBehaviour
    {

        // Configuration

        [Header("Events")]
        [Space(10)]

        [SerializeField] private GameEvent onPlayEvent;

        [Space(10)]
        [Header("Managers")]
        [Space(10)]

        [SerializeField] private UIManager uiManager;

        // Unity Events

        private void OnEnable()
        {
            onPlayEvent.AddListener(OnPlay);
        }

        private void OnDisable()
        {
            onPlayEvent.RemoveListener(OnPlay);
        }

        private void Start()
        {
            StartCoroutine(LoadGameWorkflow());
        }

        // Game Event Handlers

        private void OnPlay()
        {
            Debug.Log("Play!!!!");
        }

        // Game Workflows

        private IEnumerator LoadGameWorkflow()
        {
            yield return StartCoroutine(uiManager.LoadAssets());
            uiManager.ShowLoading();

            // Pretend we're loading more stuff here...
            yield return new WaitForSeconds(3f);

            uiManager.ShowMenu();
        }

    }
}

Select the "Game" root game object in the Scene and assign the "UI" game object in the scene to the Ui Manager field. Assign the "OnPlayEvent" to the On Play Event field.

Tests

For now, open the "GameManager_Tests.cs" script and just delete the single test method completely.

Go to the TestRunner and Run All to verify everything should work.

Play

Finally we can play the game! Run play mode and you will see the loading screen display, then the menu. If you click the "PLAY" button, the menu should hide itself and a console log appear.

Summary

We've completed our UI for the game with controllers and a manager that can load and unload assets at runtime. We have a Game Manager that can orchestrate the UI and respond to events to implement high level game workflows. We have some decent test coverage to ensure our prefabs don't break after changes.

Source Code for this Post:

Github

Next

Follow along to the next post in the series.

Unity Single Scene Architecture Series

If you're finding value in these posts, please leave a comment below to let me know (it's a lot of work) and share on your social media for others. Thanks for reading!

Unity Single Scene Architecture Series

I will follow the same pattern of the previous post in which we built a loading screen as an Addressable asset along with tests. If you didn't read the previous post, I recommend doing so.

Framing Out the Menu Screen

Let's start by framing out the game objects for the menu screen.

• Add a child empty game object underneath "UI" named "MenuController"
• Add a child to "MenuController" from the context menu UI > Canvas named "MenuCanvas"
• Change the Canvas Scaler component to Scale With Screen Size with ReferenceResolution set to 1920 x 1080
• Add a child to "MenuCanvas" from the context menu UI > Panel
• Set the Image component Color to black with no transparency
• Add a child to "Panel" from the context menu UI > Text - Text Mesh Pro
• Set the Rect Transform to middle stretch. set the Y position to 100
• Set the text to "Single Scenery", center the horizontal and vertical alignments, set font size to 200
• Add another child to "Panel" from the context menu UI > Button - Text Mesh Pro
• Set the width to 300, height to 100, Y position to -200
• Set the Text to "PLAY" with font size 64

You should have a menu screen that looks like this:

Menu Events

Unlike the loading screen our menu will have one or more interaction components like buttons. A Unity UGUI Button component exposes an OnClick event, that is often wired up in the editor. The problem with this approach is that this event will be handled by a parent object somewhere in the scene and I don't want a child to directly reference a parent, which could easily be the beginning of a spider web of dependencies.

Instead let's create a Menu component that will serve as a design time way to collect these interactable components together and can be accessed by a parent at runtime to wire up these events programmatically.

Create a new script in the "UI" folder called "Menu":

using UnityEngine;
using UnityEngine.UI;

namespace SingleScenery
{
    public class Menu : MonoBehaviour
    {

        [SerializeField] private Button playButton;

        public Button PlayButton => playButton;

    }
}

Drag this script on the "MenuCanvas" game object and select the button in the PlayButton field in the Inspector. Now drag the MenuCanvas into the "Bundles" folder to make it a prefab and delete it from the scene. Mark MenuCanvas as Addressable using the address "MenuCanvas"

A Note About Conventions

Why not just public Button PlayButton? The reason I use these conventions is to add guard rails for other developers or myself in a week when I've forgotten about this code. I always use [SerializeField] private for fields intended to be set in the editor, which is a Unity mechanism for dependency injection at design time. By making runtime access to this same field a public, read-only property then no one can mistakenly think this should be set at runtime, and the property will not be serialized or show up in the editor.

MenuController

Other than the Menu component, this prefab asset is almost identical to the LoadingController, and if we write new code for the MenuController, it will look almost identical. When you see duplicate code it's a great indicator to refactor.

Inheritance or Composition?

To refactor we have different ways to reuse the identical code. We could create a base class for all of the common code, then inherit from that base class and customize per "controller". Or we could follow the principal of composition over inheritance, which means we'd put the identical code in a controller component, then add a new component for the button related code.

In this case, I feel like inheritance is the best way to go, but remember these approaches, especially if inheritance starts becoming complicated. Then it may be time to switch to composition and creating several smaller components instead.

UIController Base Class

Let's create a new script in the UI folder called "UIController" with the following code.

using System.Collections;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

namespace SingleScenery
{
    public class UIController : MonoBehaviour
    {
        [SerializeField] private AssetReference canvasPrefab;

        public bool Ready => _ready;
        private bool _ready;

        private GameObject _canvas;

        public void Load()
        {
            StartCoroutine(LoadAsync());
        }

        public IEnumerator LoadAsync()
        {
            var handle = Addressables.InstantiateAsync(canvasPrefab, transform);

            yield return handle;  // wait for async call completion

            if (handle.Status == AsyncOperationStatus.Succeeded)
            {
                _canvas = handle.Result;
                _canvas.SetActive(false);
                _ready = true;
            }
        }

        public void Unload()
        {
            _ready = false;
            Addressables.ReleaseInstance(_canvas); // will decrement refence count
        }

        public void Show()
        {
            if (_ready)
            {
                _canvas.SetActive(true);
            }
        }

        public void Hide()
        {
            if (_ready)
            {
                _canvas.SetActive(false);
            }
        }
    }
}

Now our new MenuController script can be as simple as:

using UnityEngine;

namespace SingleScenery
{
    public class MenuController : UIController
    {
        [SerializeField] private Menu menu;

        public Menu Menu => menu;

    }
}

MenuController now has the same API as the LoadingController, with the addition of exposing its interactable menu components for the future wiring up of events.

Refactor LoadingController

Don't forget, we need to go back and apply our refactoring to the loading controller, which is simple as this:

namespace SingleScenery
{
    public class LoadingController : UIController
    {
    }
}

Now let's go configure these changes in the editor:

• Drag the new MenuController script onto the game object in the scene
• Drag the MenuCanvas prefab into the Canvas Prefab field of MenuController
• Drag the MenuCanvas prefab into the Menu field of MenuController (Unity will find/assign the Menu component)
• Drag the MenuController game object from the scene into the "Bundles" folder to make it a prefab
• Mark the prefab as Addressable with address "MenuController"

Loading Controller

We refactored and made some significant changes, did we break anything? Does LoadingController still work? Run your tests from the previous post!

Oops. Yeah we broke it. Select the LoadingController prefab in the Project and you'll see in the inspector that the Canvas Prefab field is now empty. That's because we changed the name of this field when replacing the controller code with the inherited version. Assign the LoadingCanvas again then rerun the tests.

Everything should pass now, and while the test code is a pain, it probably just saved time investigating a bug or breaking the build for other team members. You're going to refactor a LOT. Investing in tests will help you keep momentum and not lose time with head scratching over bugs.

Tests

Speaking of tests, let's add more to cover our new code. Add a new test script "MenuController_Tests":

using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;
using UnityEngine.TestTools;
using UnityEngine.UI;

namespace SingleScenery
{
    public class MenuController_Tests
    {
        // Test Settings

        const string ADDRESS = "MenuController";
        const float DELAY = 3f;

        WaitForSeconds delay;
        MenuController controller;
        bool _setup;

        bool _playClicked;

        [OneTimeSetUp]
        public void OneTimeSetUp()
        {
            if (GameObject.FindObjectOfType<Camera>() == null)
            {
                new GameObject("Camera").AddComponent<Camera>();
            }

            delay = new WaitForSeconds(DELAY);
        }

        [UnitySetUp]
        public IEnumerator Setup()
        {
            if (_setup) yield break;

            var handle = Addressables.InstantiateAsync(ADDRESS);
            yield return handle;  // wait for async call completion

            Assert.That(handle.Status == AsyncOperationStatus.Succeeded);
            Assert.IsNotNull(handle.Result);

            controller = handle.Result.GetComponent<MenuController>();

            Assert.IsFalse(controller.Ready);

            _setup = true;

            Debug.Log("Setup: controller is instantiated in test scene");
        }

        [OneTimeTearDown]
        public void TearDown()
        {
            if (controller != null)
            {
                Addressables.ReleaseInstance(controller.gameObject);
            }

            Debug.Log("Teardown: controller reference is released");
        }

        [UnityTest, Order(1), Timeout(5000)]
        public IEnumerator Step_1_Load()
        {
            controller.Load();

            yield return new WaitUntil(() => controller.Ready);

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);

            Assert.That(controller.transform.childCount > 0);
            Assert.IsNotNull(canvas);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Assert.IsNotNull(controller.Menu);
            Assert.IsNotNull(controller.Menu.PlayButton);

            Debug.Log("Test: controller load passed");
            yield return delay;
        }

        [UnityTest, Order(2)]
        public IEnumerator Step_2_Show()
        {
            controller.Show();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller show passed");
            yield return delay;
        }

        [UnityTest, Order(3)]
        public IEnumerator Step_3_Wire_Up_Button()
        {
            controller.Menu.PlayButton.onClick.AddListener(OnPlayClicked);
            controller.Menu.PlayButton.onClick.Invoke();
            controller.Menu.PlayButton.onClick.RemoveListener(OnPlayClicked);

            Assert.IsTrue(_playClicked);

            Debug.Log("Test: controller button was clicked and handled");
            yield return delay;
        }

        private void OnPlayClicked()
        {
            _playClicked = true;
        }

        [UnityTest, Order(4)]
        public IEnumerator Step_4_Hide()
        {
            controller.Hide();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller hide passed");
            yield return delay;
        }

        [UnityTest, Order(5)]
        public IEnumerator Step_5_Unload()
        {
            controller.Unload();
            yield return delay;
            Assert.That(controller.transform.childCount == 0);
            Debug.Log("Test: controller unload passed");
        }

    }

}

Yes, a lot of this code is duplicated from the LoadingController_Tests, but that's for another day and another post. Go back to TestRunner and Run All, everything should pass.

You can also follow along in the Addressables Event Viewer to see the loading and unloading of assets.

Summary

We've added a menu to the game, reused the patterns from the loading screen and done some light refactoring to reduce duplicate code. In addition, our tests saved us from committing a broken prefab to source control.

Source Code for this Post:

Github

Next

Follow along to the next post in the series.

Unity Single Scene Architecture Series

If you're finding value in these posts, please leave a comment below to let me know (it's a lot of work) and share on your social media for others. Thanks for reading!

Unity Single Scene Architecture Series

In this post, we'll build a loading screen and talk all about loading assets in Unity. The loading screen will display as the game starts. We'll also use it when loading levels and anywhere else that the player may need to wait on a long-running loading activity.

Framing Out the Loading Screen

Let's start by framing out the game objects for the loading screen.

• Add a child empty game object underneath "UI" named "LoadingController"
• Add a child to "LoadingController" from the context menu UI > Canvas named "LoadingCanvas"
• Change the Canvas Scaler component to Scale With Screen Size with ReferenceResolution set to 1920 x 1080
• Add a child to "LoadingCanvas" from the context menu UI > Panel
• Set the Image component Color to black with no transparency
• Add a child to "Panel" from the context menu UI > Text - Text Mesh Pro (Import TMP Essentials if prompted)
• Set the Rect Transform to middle stretch
• Set the text to "Loading", center the horizontal and vertical alignments, set font size to 200

You should have a loading screen that looks like this:

Loading Screen - Prefab

Create a prefab for the "LoadingCanvas". In the Project window create a new folder "Bundles" (this will be relevant in a later part of the series dealing with building asset bundles). Select the "LoadingCanvas" game object in the scene and drag it into the newly created Bundles folder to make it a prefab. Now you can delete "LoadingCanvas" from the scene.

Loading Screen - Scripting

In the Project under "Scripts" create a new folder called "UI", then add a new script named "LoadingController".

We will add methods for loading and unloading assets at runtime, which will be available later when optimizing memory usage vs load times. We also need methods to show and hide the loading screen once loaded and instantiated.

Add the following code to LoadingController:

using System.Collections;
using UnityEngine;

namespace SingleScenery
{
    public class LoadingController : MonoBehaviour
    {
        [SerializeField] private GameObject loadingCanvasPrefab;

        public bool Ready => _ready;
        private bool _ready;

        private GameObject _loadingCanvas;

        public IEnumerator Load()
        {
            _loadingCanvas = Instantiate(loadingCanvasPrefab, transform);
            yield return null;
            _ready = true;
        }

        public void Unload()
        {
            _ready = false;
            Destroy(_loadingCanvas);
        }

        public void Show()
        {
            if (_ready)
            {
                _loadingCanvas.SetActive(true);
            }
        }

        public void Hide()
        {
            if (_ready)
            {
                _loadingCanvas.SetActive(false);
            }
        }

    }
}

Nothing exciting here, you've probably seen this prefab pattern in many other examples. We'll change this shortly, but it is relevant to understanding why.

A Brief Explanation of Assets and Instantiation

I think of an "asset" in Unity as anything that is not source code (a script). A sprite, an audio file, a mesh, a material, instances of scriptable objects, and prefabs are all common examples. Assets get packaged at build time with the player via different methods depending on how they are organized.

Assets are often directly referenced by game objects in a scene, which by default get loaded into memory with the scene at runtime (even if they are not instantiated).

Now our current LoadingController references a prefab, which will be loaded into memory even before being instantiated and remain there until the scene is unloaded. We don't want that because this pattern will break the single scene architecture.

If every prefab used in the game is referenced in the scene (UI, levels, models, audio, etc) they will all be loaded into memory and likely make the game unplayable on most platforms. This is why we typically break up games into multiple scenes...

Introducing Addressables

Instead of hard referencing the loading canvas prefab, let's use Addressables to instead load and unload the prefab on demand using a "weak reference". This means when the scene loads, the prefab being referenced will not be loaded into memory.

Let's learn a few core things about Addressables:

• Each asset marked as an Addressable has a string address that identifies it and can be used to load it without knowing where it exists in the project
• The Addressables API is mostly asynchronous, which can have rippling effects when added to an existing code base. I'll be using Coroutines to encapsulate these async API calls
• Addressables tracks reference counts to loaded assets, you must also use Addressables to unload assets to avoid resource leaks

Addressables

Refactoring for Weak References

Let's change the loading controller code to use the Addressables API.

using System.Collections;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

namespace SingleScenery
{
    public class LoadingController : MonoBehaviour
    {
        [SerializeField] private AssetReference loadingCanvasPrefab;

        public bool Ready => _ready;
        private bool _ready;

        private GameObject _loadingCanvas;

        public void Load()
        {
            StartCoroutine(LoadAsync());
        }

        public IEnumerator LoadAsync()
        {
            var handle = Addressables.InstantiateAsync(loadingCanvasPrefab, transform);

            yield return handle;  // wait for async call completion

            if (handle.Status == AsyncOperationStatus.Succeeded)
            {
                _loadingCanvas = handle.Result;
                _loadingCanvas.SetActive(false);
                _ready = true;
            }
        }

        public void Unload()
        {
            _ready = false;
            Addressables.ReleaseInstance(_loadingCanvas); // will decrement refence count
        }

        public void Show()
        {
            if (_ready)
            {
                _loadingCanvas.SetActive(true);
            }
        }

        public void Hide()
        {
            if (_ready)
            {
                _loadingCanvas.SetActive(false);
            }
        }

    }
}

You'll see some of the following changes:

• Changed the prefab reference to be an AssetReference, which requires an asset marked as Addressable
• Changed the loading and unloading code to use the Addressables API

If you read the docs, you'll quickly run into several different ways to accomplish the same thing. We're starting by using one of the easiest APIs in the package, which combines loading the asset and instantiating into one async call. When this is completed, which is trackable with the "handle", the prefab is not only loaded into memory but also instantiated into the game scene. There are other API calls we could use to do this in two steps (load and then instantiate), but we don't require that for now.

Configuration

Switch back to the editor to setup 'Addressables'. You should have an error because we're missing an Assembly Definition Reference in the SingleScenery assembly definition file. Select it and add "Unity.ResourceManager" to the references, then Apply.

Do the same for the SingleScenery.Tests assembly definition and Apply.

Welcome to the pains of assembly definitions... if you ever forget and find yourself unable to add a using statement for no reason, it's probably because of this.

Select the "LoadingCanvas" prefab in the Project and then check the Addressable field in the Inspector. The address will default to the project path but can be anything you put here. Let's just keep it simple and set the address to "LoadingCanvas".

Also note that the package has initialized its configuration in the "AddressableAssetsData" folder. We'll come back to that later.

Now select the "LoadingController" in the Scene and add the "LoadingCanvas" addressable asset to the field for "LoadingCanvasPrefab". Let's also prefab the controller and make it an Addressable. Drag it into the "Bundles" folder, check Addressable and name it "LoadingController".

Testing

How do we know our LoadingController works? It's not wired up in the scene yet and we don't want to always have to manually check if this prefab is working or not. Let's add a PlayMode test.

Create a "UI" folder underneath "Tests" and add a new test script called "LoadingController_Tests".

Another benefit of using Addressables is that we can load and unload assets easily from our tests, which avoids a lot of boilerplate code. To setup a temporary scene the test script will need to:

• Add a camera to the scene, so we can visually inspect the test run if needed
• Load and instantiate the "LoadingController" prefab asset using Addressables
• Clean up after the tests have run

Our actual tests should cover the public API that will be used at runtime (Load, Show, Hide, and Unload).

Before adding our test code, we'll be referencing new packages UnityEngine.UI and Unity.TextMeshPro. Add them to the "SingleScenery.Test" assembly definition file. Be sure to click Apply.

Open the new test script add the following test code:

using System.Collections;
using NUnit.Framework;
using TMPro;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;
using UnityEngine.TestTools;

namespace SingleScenery
{
    public class LoadingController_Tests
    {
        // Test Settings

        const string ADDRESS = "LoadingController";
        const string LOADING = "LOADING";
        const float DELAY = 3f;

        WaitForSeconds delay;
        LoadingController controller;
        bool _setup;

        [OneTimeSetUp]
        public void OneTimeSetUp()
        {
            new GameObject("Camera").AddComponent<Camera>();
            delay = new WaitForSeconds(DELAY);
        }

        [UnitySetUp]
        public IEnumerator Setup()
        {
            if (_setup) yield break;

            var handle = Addressables.InstantiateAsync(ADDRESS);
            yield return handle;  // wait for async call completion

            Assert.That(handle.Status == AsyncOperationStatus.Succeeded);
            Assert.IsNotNull(handle.Result);

            controller = handle.Result.GetComponent<LoadingController>();

            Assert.IsFalse(controller.Ready);

            _setup = true;

            Debug.Log("Setup: controller is instantiated in test scene");
        }

        [OneTimeTearDown]
        public void TearDown()
        {
            if (controller != null)
            {
                Addressables.ReleaseInstance(controller.gameObject);
            }

            Debug.Log("Teardown: controller reference is released");
        }

        [UnityTest, Order(1), Timeout(5000)]
        public IEnumerator Step_1_Load()
        {
            controller.Load();

            yield return new WaitUntil(() => controller.Ready);

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            var text = controller.gameObject.GetComponentInChildren<TMP_Text>(true);

            Assert.That(controller.transform.childCount > 0);
            Assert.IsNotNull(canvas);
            Assert.IsNotNull(text);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);
            Assert.That(text.text == LOADING);

            Debug.Log("Test: controller load passed");
            yield return delay;
        }

        [UnityTest, Order(2)]
        public IEnumerator Step_2_Show()
        {
            controller.Show();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsTrue(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller show passed");
            yield return delay;
        }

        [UnityTest, Order(3)]
        public IEnumerator Step_3_Hide()
        {
            controller.Hide();

            var canvas = controller.gameObject.GetComponentInChildren<Canvas>(true);
            Assert.IsFalse(canvas.gameObject.activeInHierarchy);

            Debug.Log("Test: controller hide passed");
            yield return delay;
        }

        [UnityTest, Order(4)]
        public IEnumerator Step_4_Unload()
        {
            controller.Unload();
            yield return delay;
            Assert.That(controller.transform.childCount == 0);
            Debug.Log("Test: controller unload passed");
        }

    }

}

Tricky stuff... the Unity Test Framework is basically NUnit with modifications to add in support for coroutines, which we need with the async portions of our code. Now go back to the editor, use the TestRunner to execute all of the tests with Run All.

You can follow along in the game view and watch the loading screen display, but how do we know that these assets are loading and unloading in memory?

Go to Window > Asset Management > Addressables > Settings which will select the global settings for Addressables in the project. In the Inspector, check Send Profiler Events. Now open the Addressables Event Viewer with Window > Asset Management > Addressables > Event Viewer. Keep this open and then run all of the tests again.

After "Load" is called, you will see the "LoadingCanvas" prefab is loaded into memory.

After "Unload" is called, you will see it is also removed from memory.

Summary

Wow! That's a lot for just a loading screen, right? While true, I hope this demonstrates the power behind Addressables and this architecture.

• You can load everything and keep it in memory for fast UX, but later optimize by inserting load/unload calls that are already part of the component's API
• You could add several versions of a loading screen with no memory impact
• You can later revise the loading screen and update it seamlessly after install
• A team member can modify the LoadingCanvas without ever having to touch the scene
• If someone breaks the LoadingCanvas prefab or the LoadingController, you'll know it with the tests
• Create different loading canvases for different resolutions / platforms and only load the appropriate ones at runtime (or download, which we'll cover later)

We'll be using this same pattern in the series and apply it to more UI, the Player, and Levels.

Source Code for this Post:

Github

Next

Follow along to the next post in the series.

Unity Single Scene Architecture Series

If you're finding value in these posts, please leave a comment below to let me know (it's a lot of work) and share on your social media for others. Thanks for reading!

Unity Single Scene Architecture Series

In this post, we will add a GameManager, Assembly Definitions, and play mode testing to the game.

Game Manager

Let's create a game manager script that will be responsible for orchestrating its child game systems. The script will be empty for now, but we'll be adding to it throughout the series.

In the Project window, create a new folder for Scripts underneath the "Assets" folder. Create a new C# script called "GameManager".

Open the script in your editor and replace with this placeholder code.

using UnityEngine;

namespace SingleScenery
{
    public class GameManager : MonoBehaviour
    {

    }
}

Then drag the script onto the "GameManager" object in the scene.

Assembly Definition

If you're not familiar with Assembly Definition files, then review the topic.

We're going to add one that will contain all of the source code for Single Scenery. Using an assembly definition will help with domain reloads as code scales as well as simplify testing with the Unity Test Framework.

Right-click the "Scripts" folder and add an Assembly Definition named "SingleScenery".

Once created modify its settings in the Inspector window.

• Set Root Namespace to "SingleScenery"
• Add a reference under Assembly Definition References to Unity.Addressables

Click Apply to save the settings.

Test Assembly

Now we can create a test assembly using the Unity Test Framework for play mode tests that we will later use to ensure our prefabs don't break.

Go to Window > General > TestRunner and then select PlayMode at the top. Click Create Playmode Test Assembly Folder. You should now have a folder called "Tests" with an assembly definition file of the same name.

Rename the file to "SingleScenery.Tests", select it and make the following changes in the Inspector window.

• Change Name to "SingleScenery"
• Set Root Namespace to "SingleScenery"
• Add a reference under ssembly Definition References to Unity.Addressables
• Add a reference under Assembly Definition References to SingleScenery

Test Script

Now we can add our first play mode test. If you're not familiar with tests, I'll cover more as the series progresses. A play mode test is executed by the TestRunner which creates a temporary scene and then executes tests in the scripts that are compiled into the test assembly.

Right-click the "Tests" folder and go to Create > Testing > C# Test Script and create a new script called "GameManager_Tests". Open in your editor and add the following placeholder code.

using NUnit.Framework;
using UnityEngine;

namespace SingleScenery
{
    public class GameManager_Tests
    {

        [Test]
        public void Can_Create_GameManager()
        {
            var go = new GameObject("Game");
            var gm = go.AddComponent<GameManager>();

            Assert.IsInstanceOf<GameManager>(gm);

        }

    }
}

When this test is run it will simply verify that all our references are correctly setup by creating a new game object in the temp scene and adding a GameManager component to it.

Go to the TestRunner window and RunAll to run the test.

Summary

We now have a GameManager, an assembly for our game's source code, a test assembly for our tests, and correct references setup to start building more logic.

Next

Follow along to the next post in the series.

Unity Single Scene Architecture Series

Unity Single Scene Architecture Series

Introduction

Instead of multiple scenes, this architecture will rely on dynamically loading and unloading assets (such as prefabs) at runtime using the Unity Addressables package.

Additionally, the scene hierarchy will be used to organize and control complexity, manage state, and encourage dependency inversion (loose coupling). I'll also cover laying a good game foundation by including tests and a CI/CD pipeline as the project progresses.

Why?

There are so many different ways to build and structure games. Most simple games will load the main menu scene, and when playing load the first scene by build index. When that level is complete, load the next scene index, etc.

Larger games may use additive scene loading to split up larger levels, reduce load times and optimize memory usage. Assets can be loaded and unloaded at runtime, often with the Resources folder (slow) or AssetBundles (complex).

Mix this all together and it becomes confusing when to group objects in a scene, when to use prefabs/variants, and when to load at runtime.

This architecture seeks to simplify these decisions, reduce the need for singletons/static scope, and create a better iterative experience.

Caveats

If your game will rely heavily on baked lighting, then this architecture may not work for you. Unity does not have built in support for baking light with prefabs! I'll cover some options for lighting in a post as part of this series.

For now, let's forge ahead and dive in!

Project Setup

Create a new Unity project. I am using version 2021.3 with 3D core features. Rename the SampleScene to "GameScene".

Use the Package Manager to install the Addressables package.

Game Design

In Single Scenery the game will be as simple as possible to demonstrate the architecture. The player will move through each level, which will simply be a landscape composed of Unity's built-in 3D objects.

The player will move through the landscape, enjoy the scenery, and find a "key" that allows them to move to the next level.

Game Setup

We'll use our single scene to frame out the main game systems needed for Single Scenery.

With "Game Scene" open in the editor, let's mirror the above architecture with empty game objects. Create an empty game object in the root of the scene named "Game". Add empty child game objects named:

• Cameras
• Lights
• Input
• UI
• Player
• Levels

Drag "Directional Light" under "Lights". Drag "Main Camera" under "Cameras".

You should now have a scene hierarchy that looks like this:

Summary

We now have the bones of a game, a scene that is framed out with empty objects and ready to start implementing.

Next

Follow along to the next post in the series.

Unity Single Scene Architecture Series

Source Code:

Github

In the example project, I am satisfying an actual use case for a game I am working on that populates random books in a store. I need each book to have a unique title and condition.

Requirements

• Unity 2021.3 LTS
• GitHub Project: https://github.com/PlayableDesign/unity-procedural-wording

Setup

Create a new Unity project. I am using the default 3D core template.

With the default "SampleScene" opened, choose the "Main Camera" game object and change the Clear Flags from Skybox to Solid Color.

In the Project window, under Assets, create a new folder for "Scripts" and another for "Data".

Procedural Books

In this example, I want to generate random books, including the following properties:

• Fiction or Nonfiction
• Title
• Condition

We're going to build a very basic grammar system using one MonoBehaviour and two ScriptableObject scripts.

Words Asset

First we need a container for random words that will be used in titles and condition descriptions. Create a new script in the Scripts folder for storing random words.

using System.Collections.Generic;
using UnityEngine;

[CreateAssetMenu(fileName = "WordsAsset", menuName = "Procedural Wording/WordsAsset")]
public class WordsAsset : ScriptableObject
{
    [SerializeField] private List<string> words;

    public string GetRandom()
    {
        var word = words[Random.Range(0, words.Count)];
        return word;
    }
}

Now you can create new assets in the editor to store a list of words at design time and use GetRandom to choose one from the list at runtime.

Let's extend this to also capitalize words based on a design time setting for each asset. I'll use the System.Globalization namespace for this.

using System.Collections.Generic;
using System.Globalization;
using UnityEngine;

[CreateAssetMenu(fileName = "WordsAsset", menuName = "Procedural Wording/WordsAsset")]
public class WordsAsset : ScriptableObject
{
    [SerializeField] private bool capitalize;
    [SerializeField] private List<string> words;

    public string GetRandom()
    {
        var word = words[Random.Range(0, words.Count)];

        if (capitalize)
            word = CultureInfo.CurrentCulture.TextInfo.ToTitleCase(word);

        return word;
    }
}

Rule Asset

Now we need to be able to use one or more word lists to replace tokens in a sentence. To keep things simple, I am going to use the string.Format method to accomplish this.

At design time, you would create a sentence or paragraph that is peppered with numbered tokens that will be replaced by the format method. Each numbered token will correspond to the index of a list of WordAsset instances.

using System.Collections.Generic;
using UnityEngine;

[CreateAssetMenu(fileName = "RuleAsset", menuName = "Procedural Wording/RuleAsset")]
public class RuleAsset : ScriptableObject
{

    [TextArea(10, 50)]
    [Tooltip("A valid format string using {n} to denote the position of each word list entry")]
    [SerializeField] private string format;

    [Tooltip("The position of each word list should match it's position in the format string")]
    [SerializeField] private List<WordsAsset> wordlists;

    public string Apply()
    {
        // store the results of each word list
        var words = new List<string>();

        // get a random word from each words asset
        foreach (var list in wordlists)
        {
            words.Add(list.GetRandom());
        }

        // pass the list of random words to the format method
        return string.Format(format, words.ToArray());
    }
}

Data

We have our two new custom assets that derive from ScriptableObject. Let's create the data to create unique books.

Use the new context menu entries to add instances to the project.

Create the following assets in the "Data" folder for random word lists.

• BookConditions
• BookTitlesFiction_1
• BookTitlesFiction_2
• BookTitlesNonfiction_1
• BookTitlesNonfiction_2

Create the following assets in the "Data" folder for rules.

• ConditionRule
• FictionTitleRule
• NonfictionTitleRule

Data - Random Words

Add some book conditions to the "BookConditions" asset.

Add book title words to the other four assets.

Data - Book Rules

Let's add some format strings and the random word data to the rules.

Book Controller

Now we have enough data to generate random books, we need a game object in the scene to orchestrate the procedure and display content using a UI text field.

Create a new script called "BookController" in the Scripts folder.

using TMPro;
using UnityEngine;

public class BookController : MonoBehaviour
{
    [Tooltip("The text field to update at runtime.")]
    [SerializeField] private TMP_Text text;

    [Header("Rules")]
    [Space(10)]

    [SerializeField] private RuleAsset fictionTitleRule;
    [SerializeField] private RuleAsset nonfictionTitleRule;
    [SerializeField] private RuleAsset conditionRule;

    private void OnEnable()
    {
        // Choose fiction or nonfiction book randomnly 
        bool fiction = Random.value > 0.5f;

        if (fiction)
        {
            SetText(fictionTitleRule.Apply(), conditionRule.Apply());
        }
        else
        {
            SetText(nonfictionTitleRule.Apply(), conditionRule.Apply());
        }
    }

    private void SetText(string title, string condition)
    {
        text.text = title + condition;
    }
}

This script will decide at random if the book is fiction or non-fiction and then reference the rule assets created earlier to generate random content.

Add a new, empty game object to the scene called "BookController" and add this script to it. Add the three rule assets to the appropriate fields.

With the "BookController" game object selected in the scene, add a TextMeshPro text element and then reference it in the "Text" field of the controller.

** If prompted to import TextMeshPro Essentials, do so

Change the "Text (TMP)" component width and height.

Play!

Now we have implemented our architecture, the BookController has a reference to the text component to display a book, and it references the rules for the title and condition, which then reference our random word lists.

Test it out in play mode.

With the BookController game object selected, check and uncheck the active flag to trigger the OnEnable method and generate new content.

Summary

In this article I demonstrated a simple way to generate random, unique content. There are many ways to extend this functionality with tokenizers, regex, etc. This solution also works well with the Addressables package, allowing you to update content after distribution - more on that another day. Feel free to contribute and comment.

You've been tuning a game object in a scene... one with many components, some child game objects, and those have components... it's time to apply prefab overrides. Your palms sweat. You click the button, like pulling the handle of a slot machine. What unintentional changes have you rippled throughout the game, prefabs, variants and instances???

Sound familiar? If so, then I have a technique for you to try out. You should be familiar with ScriptableObject, a sibling of MonoBehaviour, used to create custom assets for a project, to centralize and organize design time settings, and often to handle runtime state and events.

A Different Approach

In this article, I'll cover using ScriptableObjects to create "service" assets, which will provide reusable game logic alongside settings that reduce dependence on the prefab workflow and introduce several other benefits such as:

• Pluggable services that can be added to game objects at design time or runtime.
• Stateless, testable, independently versioned
• Source control friendly
• Follows Single Responsibility Principle (SRP)
• Can fit into state machine, behavior tree and other common patterns

Here are the rules I use for Service Assets.

• Inherit from ScriptableObject
• No "settings" related to this logic in the MonoBehaviour, instead they should live with the asset
• No "state" or external references, everything must be passed in and then returned, like a pure function
• MonoBehaviour acts as the "controller" or orchestrator of Service Assets, supplies state and references

Tackling Physics

With that, let's get hands on with an example to encapsulate some different physics scenarios with RigidBody. Physics is something I find myself often flipping settings around to get the "perfect" effects in game, which makes this a great candidate for packaging as an asset.

Project Setup

Create a new 3D project, I'm using Unity 2021.3 LTS.

Let's start with a simple scene, add a cube that represents the ground with a box collider and green material.

Add another cube that will be what we move around in this example, with a blue material and a RigidBody.

CubeController

Let's use a simple MonoBehaviour script to be able to move the Cube around with input. Create a CubeController script and attach it to the Cube in the scene.

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class CubeController : MonoBehaviour
{

    private Rigidbody body;
    private Vector3 direction;

    private void Awake()
    {
        body = GetComponent<Rigidbody>();
        direction = Vector3.zero;
    }

    private void Update()
    {
        direction.x = Input.GetAxis("Horizontal");
        direction.z = Input.GetAxis("Vertical");
        direction.Normalize(); //handle diagonal scale
    }

    private void FixedUpdate()
    {
        if (direction == Vector3.zero) return;

        // Add code to move the RigidBody
    }
}

Simple, we use Update to gather input per frame and we apply physics in FixedUpdate which will come from the new service asset. Input is captured in a Vector3 called "direction" which will be "state" that we pass to our service asset.

Prefab Approach

A typical approach would be to write the physics code directly in this MonoBehaviour and perhaps expose movement related settings, like "Speed" as a serialized field in the Inspector. We could then prefab it, make variants for different speed cubes, etc. But now we're back into the prefab workflow that I'd like to avoid and which will get more complex with additional components.

Service Asset

Create a new script called MovementServiceAsset, change it to inherit from ScriptableObject and then add a method that should be called from the CubeController to move using the RigidBody. Sticking to our rules, CubeController will pass in the RigidBody as a reference and direction as state.

using UnityEngine;

[CreateAssetMenu(fileName = "MovementServiceAsset", menuName = "ServiceAssets/MovementServiceAsset", order = 0)]
public class MovementServiceAsset : ScriptableObject
{
    public void Move(Rigidbody body, Vector3 direction)
    {
        Debug.Log($"Moving {body.name} in direction: {direction}");
    }
}

Assemble Parts

Now let's put this together. Add a field to the CubeController for a MovementServiceAsset that we can supply in the inspector. Then call the service asset Move method in FixedUpdate, passing the reference and state as paramaters.

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class CubeController : MonoBehaviour
{

    [SerializeField] private MovementServiceAsset movementService;

    private Rigidbody body;
    private Vector3 direction;

    private void Awake()
    {
        body = GetComponent<Rigidbody>();
        direction = Vector3.zero;
    }

    private void Update()
    {
        direction.x = Input.GetAxis("Horizontal");
        direction.z = Input.GetAxis("Vertical");
        direction.Normalize(); //handle diagonal scale
    }

    private void FixedUpdate()
    {
        if (direction == Vector3.zero) return;

        movementService.Move(body, direction);

    }
}

Create a new instance of our service.

Name it "BasicMovementService".

Then add the new service asset to the CubeController in the Scene.

Fire up play mode and use the WASD keys, which should trigger log messages in the Console window.

Add Settings

Now let's add some settings to the service asset, so we can change behavior of the movement logic from the editor. These settings will be saved independently in each asset instance created, such as BasicMovementService.

using UnityEngine;

[CreateAssetMenu(fileName = "MovementServiceAsset", menuName = "ServiceAssets/MovementServiceAsset")]
public class MovementServiceAsset : ScriptableObject
{
    [Header("Movement Settings")]
    [Space(10)]

    [SerializeField] private float speed;

    [Header("RigidBody Settings")]
    [Space(10)]

    [SerializeField] private ForceMode forceMode;

    public void Move(Rigidbody body, Vector3 direction)
    {
        Debug.Log($"Moving {body.name} in direction: {direction}");

        body.AddForce(direction * speed, forceMode);
    }
}

Select the BasicMovementService asset in the Project window and configure speed. We'll leave ForceMode at the default for now.

Fire up play mode again and use the WASD keys to move the cube (it should tumble around because we don't have any RigidBody constraints set).

More Settings

To stick to our rules and avoid prefab impact, I don't want to set RigidBody constraints on the component directly. Instead I want to set them via our new service asset. So let's add a method to be called from Awake.

using UnityEngine;

[CreateAssetMenu(fileName = "MovementServiceAsset", menuName = "ServiceAssets/MovementServiceAsset")]
public class MovementServiceAsset : ScriptableObject
{
    [Header("Movement Settings")]
    [Space(10)]

    [SerializeField] private float speed;

    [Header("RigidBody Settings")]
    [Space(10)]

    [SerializeField] private ForceMode forceMode;
    [SerializeField] private bool freezeRotation;

    [Header("Collider Settings")]
    [Space(10)]

    [Tooltip("Optional")]
    [SerializeField] private PhysicMaterial material;


    public void Initialize(Rigidbody body, Collider collider)
    {
        if (freezeRotation) body.constraints |= RigidbodyConstraints.FreezeRotation;
        if (material != null) collider.material = material;
    }

    public void Move(Rigidbody body, Vector3 direction)
    {
        Debug.Log($"Moving {body.name} in direction: {direction}");

        body.AddForce(direction * speed, forceMode);
    }
}

Another setting related to movement would be the PhysicMaterial which governs friction and bounciness of the Collider.

I'll avoid mass, because that might be something changed depending on the characteristics of a single model and not applied service-wide.

Add the call to Initialize in the CubeController Awake event.

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class CubeController : MonoBehaviour
{

    [SerializeField] private MovementServiceAsset movementService;

    private Rigidbody body;
    private Vector3 direction;

    private void Awake()
    {
        body = GetComponent<Rigidbody>();
        direction = Vector3.zero;
        movementService.Initialize(body, GetComponent<Collider>());
    }

    private void Update()
    {
        direction.x = Input.GetAxis("Horizontal");
        direction.z = Input.GetAxis("Vertical");
        direction.Normalize(); //handle diagonal scale
    }

    private void FixedUpdate()
    {
        if (direction == Vector3.zero) return;

        movementService.Move(body, direction);

    }
}

Create a new PhysicMaterial for the cube with default settings, add it to the BasicMovementService, and check to freeze rotation. Now that we've added friction, bump up speed to 20 (or play with this setting during play mode).

Hit play and move around, you'll see that the constraints have been set. You can now change these settings, which will be saved even in play mode and applied to all other objects using this service.

Another Service

Ok great, let's prefab our Cube, dragging into the Project. Create a variant called FastCube. Duplicate BasicMovementService asset, call it FastMovementService and set the speed to 25. Assign this to the FastCube variant, and add an instance to the scene.

Start play mode and move around, you should see both cubes move but at different speeds. But what has that solved? We still have a problem. Let's make each cube a different player with individual input settings. Again typical approach would be fields on the prefab to govern input schemes. Instead we'll use a service asset.

Create a new script called InputServiceAsset which will contain our key mappings.

using UnityEngine;

[CreateAssetMenu(fileName = "InputServiceAsset", menuName = "ServiceAssets/InputServiceAsset")]
public class InputServiceAsset : ScriptableObject
{
    [Header("Key Mappings")]
    [Space(10)]

    [SerializeField] private KeyCode up;
    [SerializeField] private KeyCode left;
    [SerializeField] private KeyCode down;
    [SerializeField] private KeyCode right;

    public Vector3 Poll()
    {
        var direction = Vector3.zero;

        if (Input.GetKey(up)) direction += Vector3.forward;
        if (Input.GetKey(left)) direction += Vector3.left;
        if (Input.GetKey(down)) direction += Vector3.back;
        if (Input.GetKey(right)) direction += Vector3.right;

        return direction.normalized;
    }
}

Add a field to the CubeController to hold an InputServiceAsset instance and change Update to use the Poll method to get direction each frame.

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class CubeController : MonoBehaviour
{
    [SerializeField] private InputServiceAsset inputService;
    [SerializeField] private MovementServiceAsset movementService;

    private Rigidbody body;
    private Vector3 direction;

    private void Awake()
    {
        body = GetComponent<Rigidbody>();
        direction = Vector3.zero;
        movementService.Initialize(body, GetComponent<Collider>());
    }

    private void Update()
    {
        direction = inputService.Poll();
    }

    private void FixedUpdate()
    {
        if (direction == Vector3.zero) return;

        movementService.Move(body, direction);
    }
}

Now we are better sticking to rules. The MonoBehaviour is coordinating 2 services, storing state and orchestrating different components.

Create an instance of InputServiceAsset called "PlayerOneInputService".

Assign keys for WASD movement.

Duplicate the asset, name it "PlayerTwoInputService" and change the keys to handle arrow movement.

Assign the "PlayerOneInputService" to one of the cubes in the scene, assign "PlayerTwoInputService" to the other.

Enter play mode and test out each cube with each set of keys.

Summary

Let's organize and look at our project now.

We have 3 scripts, two of which are ScriptableObjects. The CubeController, which is the single MonoBehaviour for our "Player" game objects. It gets injected with services that contain game logic. The CubeController doesn't need to supply any settings for these services, they are self-contained, it simply passes state around to and from services. You can test different player settings simply by switching out the assets on the game object or by changing the values in the referenced assets directly.

We have 4 service assets, a couple of variations of movement, and 2 different player input mappings. These can be tested from any script independently and don't require having their own state or references. They can be duplicated and customized easily and have clear responsibilities.

We have one prefab with 2 variants. The base prefab references a movement service asset, so that all players share the same movement characteristics. You could extend this to have a reference to both basic movement and fast movement, then switch to fast at runtime when a player has a "boost", for example.

Then each player variant references a custom input service asset to define controls.

Now the elements of the project play to their strengths and avoid some of their pain points as complexity scales. You could even distribute new configurations of services via Addressables after install.

Project on Github

• https://github.com/PlayableDesign/ServiceAssets

Please comment, contribute, and let me know what you think about service assets!

Addressables is a fantastic framework that can:

• Reduce memory pressure
• Abstract and simplify the loading of both local and remote resources
• Handle dependency loading and unloading
• Help create clean, scalable game architectures

The caveat is that using Addressables is complicated, it requires good foundational knowledge of Unity, and introduces the complexities of asynchronous programming.

In this article I am introducing a simple helper class that hides some of this complexity and fits seamlessly into the coroutine pattern.

Let's assume that you've installed Addressables are starting to switch from hard references of GameObject prefab to weak references of AssetReference prefab. If you're already using and familiar with coroutines then you can use this helper to initiate the instantiation of an Addressable asset and wait for completion.

using System;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public static class AddressablesHelper
{

    public static WaitUntil Instantiate(AssetReference asset, Action<GameObject> callback)
    {
        return Instantiate(asset, null, Vector3.zero, Quaternion.identity, callback);
    }

    public static WaitUntil Instantiate(AssetReference asset, Transform parent, Action<GameObject> callback)
    {
        return Instantiate(asset, parent, Vector3.zero, Quaternion.identity, callback);
    }

    public static WaitUntil Instantiate(AssetReference asset,
                                                Transform parent,
                                                Vector3 position,
                                                Quaternion rotation,
                                                Action<GameObject> callback)
    {
        var handle = Addressables.InstantiateAsync(asset, position, rotation, parent);

        handle.Completed += handle =>
        {
            if (handle.Status == AsyncOperationStatus.Succeeded)
            {
                callback?.Invoke(handle.Result);
            }
            else
            {
                callback?.Invoke(null);
                Addressables.Release(handle);
            }
        };

        return new WaitUntil(() => handle.IsDone);
    }

}

Now you can weave these calls into your coroutines like this:

private IEnumerable Loading()
{
    yield return AddressablesHelper.Instantiate(menuPrefab, transform, (go) =>
        {
            Log.Info(name, "Loaded menu controller...");
            _menu = go.GetComponent<MenuController>();
        });

    _menu.ShowLoading();
}

The helper methods return a WaitUntil that is tied to the AsyncOperationHandle of the Addressables invocation. You pass in an Action or define it inline as I do in the above example.

This hides some of the pain from having to manage handles, the only thing to track is releasing the reference for this instantiated GameObject, which should be done via Addressables.ReleaseInstance() to ensure the asset is unloaded when there are no more references.

private void OnDestroy()
{
    Addressables.ReleaseInstance(_menu.gameObject);
}

More to come on Addressables, please subscribe to my newsletter if interested and comment your thoughts on this pattern.

There are several approaches to implementing events, such as simply adding a UnityEvent to a MonoBehaviour or going all in on the popular trend of SciptableObject events.

I am a big fan of event systems and have implemented many different variations. As a mostly solo indie developer though, some of these implementations can become time consuming and difficult to manage over time. I like the ScriptableObject approach, but I don't have game designers who need to wire up events in the editor. So for me, with a developer-centric, small-team workflow I tend to favor something simple and effective.

A Simple Event System

After trying different approaches, these are the goals that this event system satisfies:

• Developer centric workflow, doesn't require wiring up in the editor
• Can quickly define new events of any type
• Requires a minimal number of classes, expandable for better team workflow with source control
• Follows a pub/sub model and is performant at scale

This approach involves creating 3 classes for your event system:

• GameEvent class
• Generic GameEvent<T> class
• Events static class that houses all of the defined events for the game

GameEvent Class

This is a simple C# class that defines a game event with no parameters and uses an Action with the event keyword to represent a multicast delegate.

While you could simply make the Action public and allow subscribers to directly register themselves, I prefer to encapsulate it with simple Add and Remove methods. This gives me room to later add in validation or logging behavior to these methods if needed.

public class GameEvent
{
    private event Action action = delegate { };

    public void Publish()
    {
        action?.Invoke();
    }

    public void Add(Action subscriber)
    {
        action += subscriber;
    }

    public void Remove(Action subscriber)
    {
        action -= subscriber;
    }
}

Generic GameEvent Class

Next, add a generic class for events that need to pass a type as a parameter.

public class GameEvent<T>
{
    private event Action<T> action;

    public void Publish(T param)
    {
        action?.Invoke(param);
    }

    public void Add(Action<T> subscriber)
    {
        action += subscriber;
    }

    public void Remove(Action<T> subscriber)
    {
        action -= subscriber;
    }
}

You could keep adding classes for multiple types, such as public class GameEvent<S,T> if needed, but I'd only do this when the requirement comes up.

Static Events Class

Lastly we now need somewhere to define and house events that can be used at runtime. When I need something global I typically ask, can it be static in scope? If I don't need it to be visible in the Scene hierarchy, then I go with static instead of troubling myself with Singleton MonoBehaviours or ScriptableObject instances.

    public static partial class Events
    {

        public static readonly GameEvent onJump = new();
        public static readonly GameEvent<float> onDamage = new();
        public static readonly GameEvent<GameObject> onPickup = new();

     }

I marked this class partial, because after you start defining events, it can become a long list and if you have other team members modifying it, then it can introduce the risk of a merge conflict. With a partial class, you can organize your events into a multilpe .cs files, for example:

• Events_Menu.cs
• Events_Player.cs
• Events_Enemy.cs

Subscribing to Events

Subscribers will need to add and remove themselves in their OnEnable and OnDisable methods. It can be tedious, but I have snippets setup to quickly frame this out and fill in.

using UnityEngine;

public class Player: MonoBehaviour
{

    private void OnEnable()
    {
        Events.onJump.Add(OnPickup);
        Events.onDamage.Add(OnDamage);
    }

    private void OnDisable()
    {
        Events.onJump.Remove(OnPickup);
        Events.onDamage.Remove(OnDamage);
    }

    private void OnPickup(GameObject item)
    {
        Debug.Log($"Picked up item: {item.name}");
    }

    private void OnDamage(float amount)
    {
        Debug.Log($"Damaged: {amount}");
    }
}

Publishing Events

Publishing is as easy as a single line of code.

using UnityEngine;

public class Pickup: MonoBehaviour
{
    private void OnCollisionEnter(Collision other)
    {
        if (other.CompareTag("player"))
        {
            Events.onPickup.Publish(gameObject);
        }
    }
}

Summary

This is a simple solution but it can be extended with logging, editor tooling to show subscribers during play mode, and because the Events class is marked partial you can add multiple files to better organize your events or split them out by team members to avoid merge conflicts. Feel free to use this pattern, suggest improvements, and you can view a real world implementation in one of my recent game jam submissions, Moodledy.

Game Accessibility Guidelines

This site groups guidelines into Basic, Intermediate and Advanced categories, so that one can choose a level of investment in accessibility features. The guidelines are a collaborative effort from a group of studios, specialists, and academics.

https://gameaccessibilityguidelines.com/

Can I Play That

This site is a treasure trove of reviews and news of real-world games and their adoption of accessibility features. They also offer workshops and already work with some high profile AAA studios.

https://caniplaythat.com/

Free Unity Courses

The training site, raywenderlich.com, offers 2 free training courses on how to practically implement accessibility features in Unity games.

• Improving Accessibility in Unity Games – Part 1
• Improving Accessibility in Unity Games – Part 2

By default, when you create a new MonoBehaviour component, it is added to the menu under Scripts/{namespace}/{component} and gets jumbled in with a lot of other random stuff from packages you have imported.

Default Example

namespace PlayableDesign.ThriftShop
{
    public class CameraController : MonoBehaviour
    {
    }
}

Menu

Yuck!

AddComponentMenu

Instead, you can create a custom folder at the top level of the context menu in the editor using the AddComponentMenu attribute.

Better Example

[AddComponentMenu("Custom/" + nameof(CameraController))]
public class CameraController : MonoBehaviour
{

}

Menu

Best Example

Even better, I like to use dashes as the folder name so that my components are always on top.

[AddComponentMenu("-----/" + nameof(CameraController))]
public class CameraController : MonoBehaviour
{

}

Menu

Enjoy!

I want a loading canvas that will display a loading progress bar that updates based on loading activities within the scene. I always forget the little details about how to make the slider look like a progress bar.

Solution:

Add a Slider to a UI Canvas:

Uncheck Interactable and set Transition to None:

Delete the "Handle Slide Area" GameObject from the hierarchy:

Select the "Fill" GameObject and set the Width of the Rect Transform to "20" (or use whatever value you like). Also change the Color of the Image to a value you prefer:

Select the "Fill Area" GameObject and set the Right value of the Rect Transform to "10" (or use half of the value you set for the Fill):

Select the "Background" GameObject and set the Alpha value of the Image to "1" (or whatever you prefer):

Adjust the size of the "Slider" Rect Transform to meet your preferences and play with the Value to get a feel for how it will look at runtime.

Scripting

Attach the script below to the slider and set the number of steps in the scene that have to be completed for loading to be completed.

For example, let's say I have a SaveManager object that is loading state from a file, an ItemSpawner that is placing prefabs and a MusicManager that is loading level music then that would be 3 steps to complete.

  using UnityEngine;
  using UnityEngine.UI;

    public class Loading : MonoBehaviour
    {

        [Tooltip("Set this value to the number of loading steps")]
        [SerializeField] private int steps;

        // Private state

        private Slider _slider;
        private int _completed;

        private void Awake()
        {
            _slider = GetComponent<Slider>();
            _slider.value = 0f;
        }

        public void Reset()
        {
            _completed = 0;
            _slider.value = 0f;
        }

        public void OnStepCompleted()
        {
            _completed++;
            _slider.value = (_completed / steps);
        }

    }

Now you can have other scripts in the scene call the OnStepCompleted method when each has completed its own loading activities.

You can expand on this solution with events and callbacks, but it's a simple start to displaying progress within a scene.

I want to add logging to a GameObject that can be called via code or wired up via the inspector. I also want to specify the color of the logs in the inspector so that I can easily distinguish the messages in the debug console.

Solution:

Use the code below to create a new component that you can add to GameObjects. You can then access the logging methods via GetComponent<LoggingBehavior>() or wire up logging calls in the inspector.

using UnityEngine;

public class LoggingBehavior : MonoBehaviour
{
    private const string FORMAT = "<color=#{0}><b>{1}</b>: {2}</color>";

    [Header("Settings")]
    [Space(10)]

    [Tooltip("Set the color for log messages")]
    [SerializeField] private Color logColor = Color.white;

    // Private State
    private string _htmlColor;

    // Unity Lifecycle

    private void Awake()
    {
        _htmlColor = ColorUtility.ToHtmlStringRGB(logColor);
    }

    // Public API

    public void LogInfo(string message)
    {
        Debug.LogFormat(gameObject, FORMAT, _htmlColor, gameObject.name, message);
    }

    public void LogWarning(string message)
    {
        Debug.LogWarningFormat(gameObject, FORMAT, _htmlColor, gameObject.name, message);
    }

    public void LogError(string message)
    {
        Debug.LogErrorFormat(gameObject, FORMAT, _htmlColor, gameObject.name, message);
    }

}

The results, in this example a timer component that invokes UnityEvents is connected to the LoggingBehavior component.

I want to emit a specific number of particles from a ParticleSystem at runtime. For example, in the game CatBoarder, for every spin the player completed during a jump, I wanted to emit a particle for each.

Solution

• Unity 2020+

Add a ParticleSystem to the GameObject that will be emitting particles. Uncheck Looping and Play on Awake.

Under Emissions, configure Bursts to only emit one particle.

Add the code below as a component, then call Emit with the number of particles to emit.

public class BurstEffect: MonoBehaviour
{
    private ParticleSystem _particles;
    private ParticleSystem.Burst _burst;

    private void Awake()
    {
        _particles = GetComponent<ParticleSystem>();
        _burst = _particles.emission.GetBurst(0);
    }

    public void Emit(int score)
    {
        _burst.count = score;
        _particles.emission.SetBurst(0, _burst);
        _particles.Play();
    }
}

The results... a happy cat after 2 spins!

Further Reading:

• https://docs.unity3d.com/Manual/PartSysEmissionModule.html