SQYD.studio

Hello anyone! I’m back and blogging again. Work has been busy, so progress on my game dev projects has slowed down a bit. That said, I’m very happy with how the new Goblin is shaping up. I’m content with slow and steady progress as long as it’s heading in the right direction. Give it time to cook. When we are ready bring our work into WOFG! The Demo! I swear it will be worth the wait.

Now I’m wondering what to blog about… How about I share some Unity/C# tricks that I seem to be using a lot in my projects? Here’s the caveat: I have no formal training with Unity or C#. I have a few comp sci 101 courses from my University days and about four years (my gosh time flies) of working with Unity, first on some small learning project- before diving into the overambitious WOFG! (Which I have no regrets about- I learn to swim best in the deep end.) Do you understand? Before I get technical I want to let you know that I have no idea what I’m doing. My “expertise” comes from: watching what other people are doing and trying to copy them, skimming the official Unity documentation and wishing it was more useful, pretending I’m a hotshot coder, and just tinkering with stuff until it works. You got that? Nothing technical in this or any future blog on this channel is “the right way” to do anything- just what works for me*.

Bootstrap It

One of the things that’s important for both Joel and I while working is quick testability. I want to be able to launch my scene into playmode from the Unity editor at any time and have it work. When you start on new project this is very easy- everything runs out of one scene anyway. Then you start tying scenes together and realize you have a bunch of “Don’t Destroy on Load” game objects that the scene relies on. One solution is to put all your dependencies in every scene and check for and destroy duplicates on start. I did this for a while. It’s silly- leads to bloated a hierarchy and unnecessary computation cleaning up unnecessary objects. The solution I found was to take all your dependencies (i.e. the stuff you need for every scene) and load them in before the initial scene even loads. Check this out:

public static class RuntimeBootstrap
{
    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSplashScreen)]
    public static void OnBeforeSplashScreen()
    {
        GameObject inputReaderPrefab = Resources.Load<GameObject>("BackfireInputManager");
        if (inputReaderPrefab == null)
        {
            Debug.LogError("Could not find BackfireInputManager prefab in Resources folder. Make sure it is there.");
            return;
        }
        
        GameObject inputReader = GameObject.Instantiate(inputReaderPrefab);
    }
}

I’m using this bit of script to help load in a new Input Manager to get BACKFIRE to work using Unity’s Input Sytem. The magic bit here is this:[[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSplashScreen)]]
I’ve learned these square bracket chunks that go before classes, properties, methods, etc. in C# are called Attributes and they can do all kinds of wizardry. This one can be used to call a static method when entering runtime. Thus called, the OnBeforeSplashScreen() method runs, roots through the “Resources” folder for the BackfireInputManager prefab and instantiates it in the hierarchy before the first scene even loads. Now I can launch any scene anywhere and always rely on my InputManager singleton** to be there. Pretty slick.

I’ve seen similar setups that bootstrap in a whole scene rather than a single game object- thinking of the wonderful additive scene loader tutorial form git-amend (a top-tier Unity Youtube channel if ever there was one), but I’ve found I only really need the one prefab for my projects. Keep it simple.

Scriptable Objects for Settings

There’s a lot of fuss made over Untiy’s Scriptable Object type for very good reason. Scriptable Objects are very powerful. I think because of this power SOs confuse a lot of people new to Unity. You can find a lot of tutorials on Scriptable Objects as event channels or warning you that SO don’t save data at runtime (they just look like they do in the editor). It’s easy to get confused. Here I present a dummy simple use case for SOs. I use this everywhere I want to have settings that are used, but not modified, at runtime and that are easy to change in the Unity editor. Check it out:

    [CreateAssetMenu(fileName = "DashSettings", menuName = "Scriptable Objects/Goblin/DashSettings")]
    public class DashCommandSettings : ScriptableObject
    {
        [Tooltip("This is the required dot of the move to input vectors required to trigger a sprint.")]
        [SerializeField] private float _moveToInputAgreementToStartSprint = 0.5f;
        public float MoveToInputAgreementToStartSprint => _moveToInputAgreementToStartSprint;

        [Tooltip("If the goblin's liner velocity falls below this value and the dash button is not held then the sprint will end.")]
        [SerializeField] private float _minActorVelocityToMaintianSprint = 3f;
        public float MinActorVelocityToMaintianSprint => _minActorVelocityToMaintianSprint;

        [Tooltip("If the Move to Input agreement is less than this value while the goblin is sprinting then they will start a drift.")]
        [SerializeField] private float _moveToInputAgreementToStartDrift = 0.33f;
        public float MoveToInputAgreementToStartDrift => _moveToInputAgreementToStartDrift;
    }

This is one of the SO “settings” objects I’m using to in the new Goblin controller. This one manages some settings related to the new sprinting mechanics. We use serialized private fields to store the setting’s value, and a public property to access it. I always put a tooltip attribute above to make it easier for Joel to know what settings do what when he’s tinkering.

All the fields on these settings can be tweaked at runtime through the inspector- so you can get instant feedback on what settings give good game feel. Since multiple components reference the same scriptable objects, changing a value of the SO changes the behavior everywhere the SO is being used (if you had the settings in the same class as the component then you’d only be able to change the behavior of one instance at a time.) Finally, doing settings with SOs let’s you swap out settings to change behavior on the fly. Just point the component at a different SO and you can change the behavior.

I can’t stress enough how much doing settings as scriptable objects has helped speed our development. It’s such a simple and elegant tool. Whenever you catch yourself serializing a bunch of private fields at the top of a Monobehaviour ask yourself: “do these values need to change at runtime?” If the answer is no you should be wrapping them in a scriptable object. It’s such a nice workflow. Good job with the Scriptable Objects Unity!

That’s all for now. I was planning to put one more tip in here, just to follow the Rule of Three, but I’ve been writing for an hour now, so I think I’ll defer that to another blog. Thanks for reading. I hope you found something useful. I hope I’m not offensively wrong with any of my Unity tips (don’t make me tap the sign). And I hope you return next week for more whatever it is I blog about. Until then, Happy February!

Footnotes

* I have a hunch that everyone, in every industry, everywhere, is, in fact, faking it. I just can’t prove it because the inner life of others is ultimately unknowable. Thanks a lot human condition.

** Lots of people online seem to have strong opinions about not using singleton pattern. I tried to avoid it for a while- but it’s just too useful for Unity Dev. I get where the arguments against singletons come from, but more complex solutions aren’t worth the hassle for me.