I once built a talk with a collection of new hacks. This talk went through a couple of almost-delivered scenarios and with the new side projects I have since accumulated, scheduling gets difficult.

So I would rather share this stuff in post form now than stall for a possible eventuality. I have no idea how frequent I will be able to post, but here is one at least.

Challenge

Most Unity projects get spread across multiple scenes very quickly. This is advantageous not only for clearly segmented production, but also for tweaking of load times, streaming, and much more.

An unfortunate side effect of this is an increase of challenges in referencing objects in a live session, across those scenes. Desired targets include objects baked into specific scenes and specific instances created at runtime.

Common approaches to solving this include dependency injection and directory singletons – both of which work really great. Unfortunately they both introduce a level of indirection in the Unity serialisation system, making it impossible to track cross-scene dependencies with generic tools. This also usually adds a programming- or finicky book-keeping step to the process of introducing new conceptual instances.

If we could solve this challenge, we would end up with a clear dependency chain in the serialisation system, which would allow us to fully utilise the tracking and tooling benefits this yields, while greatly reducing the barrier to add new concepts and interact with existing ones.

Detour

With each scene a serialised island, there is one more (ignoring bundles) serialisation hub which all scenes can access: Assets.

Both the instance and its consumer can reference the same asset, which we can then use to facilitate a connection between the two. Further, with both referencing the same asset, we now have that dependency information in the serialisation system. Also, adding new conceptual instances is just a matter of creating a new asset, assigning it to either end.

Another bonus is easy listing of all conceptual instances by simply finding all assets of the type. You can demonstrate this via the object picker. Should you prefer a drop-down selector to the object picker, such would be a fairly straight forward piece of property drawer code. You could even utilise asset folder structure to define drop-down nesting.

Implementation

The base (5.3 tested) implementation of this needs three pieces:

• A ScriptableObject type representing the conceptual instance as an asset.
  • Example abstract, example concrete.
• One MonoBehaviour registering a source.
  • Example.
• A serialized reference to the ScriptableObject type or a MonoBehaviour acting as a gateway to the instance – similar to a MeshFilter component.
  • Example.

In the given example, the instances being passed around are just GameObjects. However in a real world scenario you may also want to create CoreObject<T> derivatives passing references to specific components. Not only does this facilitate quicker access to the components you need – it also naturally separates CoreObjects into categories.

A corresponding instance component could look a little something like this.

Variants

While this base functionality has plenty of utility, I have on occasion played around with variants on the concept. For one, the base idea passes a single-source instance producer to multiple consumers, but there is no reason why you could not use this setup to register/unregister to a list of instances in stead.

A personal favourite variant is more fundamentally different. In stead of facilitating references, the core objects wrap UnityEvents – turning them into global “game events”. This allows you to completely decouple event producers and consumers, while maintaining dependency tracking through the serialisation system.

The pattern I mostly use such events in start with the producers invoking the event via a serialised UnityEvent. Say you expose a “fire” UnityEvent to which you add a particle effect invocation, audio playback, and finally the invocation of the CoreGameEvent “gunshot”.

This “gunshot” event would then be referenced by CoreGameEventHandler components which also exposes a “handle” UnityEvent. The action list of this event could then include stuff like switching the soundscape, putting NPCs into an alert state, trigger an auto save, and whatever else might be useful.

Not only do you get decoupling of produces and consumers – you also get to centralise handling details around the individual consumers as opposed to leaving them all jumbled up at the producer.

So what do you think? Do you use something similar? What cool variants and tooling do you employ?

• Source and examples