The BuildR Asset Framework

BuildR 3 implements a new internal asset system to allow us to store data in Unity’s ScriptableObjects and link this data between each other. All BuildR data has a unique BUID value which is used to reference data within other data objects. This is all tied together with a main Project Asset ScriptableObject which hold references to all objects and allows BuildR to resolve the BUID into actual data. This should all happen behind the scenes and you should need to know this system unless you’re building some complex scripts.

History – what happened to make it happen

The genesis of this system was during expansion of BuildR version 2 into something able to handle generating lots of data at runtime. Version 2 stored it’s data in ScriptableObjects so we could edit and reference things easily from the Unity editor. This architecture however was very expensive at runtime when you wanted to create a multiple new data objects for use with BuildR buildings. It became clear quite quickly that BuildR would have to have separate it’s own data from the Unity ScriptableObjects to avoid this instantiation cost.

This is initially easy to do as you can just have ScriptableObjects run as editor assets that contain data content to consume. However, the Unity serialisation architecture soon made this task far more complicated. When Unity serialises something, it creates a copy of the data and on deserialisation, that copy is written back into a new object. This presents of problem as the data content we separated out, will now be copied and will exist as it’s own instance in the serialisation.

If we had a dynamic texture that was used across three objects, and then we decided to update that dynamic texture, there was no clear way to update the three objects that used it. Those objects would have a copy of the original settings and would not update along with the original.

We could check all the assets in the project to see if it referenced this dynamic texture and then update those objects when modification happens. This process would slow down as the project size grew and initial testing early in version 3 proved it would quickly make editing BuildR impossibly slow. It also meant that our data was redundantly being copied across the project and would potentially explode project sizes.

The solution we settled on was to implement our own asset identification system. BuildR data objects all got a unique identifier (buid) assigned when they were created. Along with this, we have a data manager and ScriptableObject to track the the data and allow us to resolve buid values to actual usable data. This solution allows us to create BuildR data at runtime with very little costs along with keeping the benefits of creating Unity editor asset based versions that are easily editable.