The Hierarchy as a database
If you spend time thinking about how best to structure code in Unity (I do) some of the design decisions behind the Unity3d editor can be confusing. One example of this is the Hierarchy. Functionally speaking, the hierarchy is a graph that visualises the spatial relationship of Transform components attached to GameObjects; Each transform‘s position, scale and rotation is relative to it’s parent.
In practice the Hierarchy is often used for other purposes:
- organising GameObjects into groups
- identifying GameObjects
- managing GameObjects (EG: parenting dictates what 2d UI components are ‘on-top’ of others…)
This confusion is partly a product of the relationship between GameObjects and Transform components but the API syntax surrounding the Hierarchy also contributes:
- Transform.Find() accepts a hierarchical string “/child/grandchild/…”
- Transform.Parent let’s us move up the hierarchy
- Transform.childCount() and Transform.getChild() allows us to iterate down through the hierarchy.
As a result we quite often see code that looks like query syntax: “Using the current transform select a child transform who’s name is foo and get me a component of type bar.” Which makes me think that we could also choose to view the Hierarchy as a database.
This leads to further ideas, like:
//using functional style syntax to process the Hierarchy:
transform.findAll(“foo”).MoveUp(10).SetColor(Color.red);
- using caching to speed up queries
- making a copy of the hierarchy as an array of value-types and iterating it to take advantage of cpu-caching and IL2CPP code generation characteristics (for the time being at least.) This needs qualifying see ‘The Hierarchy as State’ below…
It seems to me that choosing to view the Hierarchy as a database is at least one valid starting point for structuring your code base.
The Hierarchy as State.
Since publishing I had an additional interpretation of the Hierarchy suggested to me: That the Hierarchy visualises the state of the scene at edit and run-time.
Viewing the Hierarchy through this particular ‘lense’ makes copying and replacing the data in the Hierarchy seem like a risky business, since it could lead to inconsistencies in state that would be hard to debug.
To clarify, I am not suggesting wholesale duplication of the hierarchy itself, just copying selective properties of components into an array of value types, processing the array and modifying the values of the objects in the hierarchy.
The place where this gets gnarly is with caching, by ‘capturing’ state from the Hierarchy you are assuming that nothing will change during the frame where you process the data. This is a definite negative to the approach and would also need to be addressed in your codebase.
