How should I organize my Unity scene graph?

Question

In programming, we have coding conventions — self-enforced rules to help maintain order. Does such a convention or consensus exist on how to lay out scenes in Unity?

I've seen two styles of organisation:

• By proximity: Like, building X → floor Y → room Z → healing potion Q
• By type: A very flat scene graph with nodes like "Walls", "Doors", and "Healing potions".

What other options exist? Is there an overall best style? How do I choose the right one for my needs (e.g. indoor vs outdoor scenes)?

Answer 1

It's a little confusing as Unity conflates the organization of scene items with its transform hierarchy. There's no way to bucket or organization items without parenting them to another object.

The best bet you will have is to make empty "folder" objects that have no components and no state but simply serve to be a named collection of objects. These folder objects should have only the default transform (positioned at the origin with no rotation and a uniform scale factor of 1) as otherwise their contents will be moved or transformed unintentionally.

For instance, you might make an empty object called "Props" with a default transform and place all of your prop objects under that, and then another one called "Enemies", and so on.

The scene itself (building -> floor -> item on floor) should not be represented this way. If the building is a complex model then it might have its own internal hierarchy of physics bodies, sure. The static level geometry (buildings and their static surfaces) are entirely separate from the gameplay items (potions). If you use objects for organization, separate along these lines: "Static Level" (containing buildings and the ground and whatnot) and "Collectables" (containing potions and other items).

Again, in that scenario, both "Static Level" and "Collectables" would be empty objects with default transforms that do absolutely nothing other than organize your content.

This is one of those little things that lead to folks like me saying that Unity is a great tool that gets the job done for prototyping and small/medium games but has piles of little quirks and oddities and shortcomings that make it fall just a little short of being a great tool for large-scale game development. A good game editor really should separate organization of in-game content and the transform hierarchy.

Answer 2

Scene graph organization is guided by the various consumers of the scene - see answer to "Scene Graph as Object Container?" Fundamentally, the scene graph associates objects such that they share some logic, physics, position, and/or render state.

So concerning organization-by-type, except for very simple games it would be a mistake to treat the scene graph as a kind of folder structure. At no time would one want to hide all the walls or rotate all the doors around a common point, so the containing object would serve no purpose other than to group its children and isn't taking advantage of the scene graph. It would be better to use a tag or code level data structure for behaviors like "open all doors" or "remove all potions."

Proximity takes advantage of the scene graph logic. For example, you could break your scene up into chunks so that you can turn distant chunks' visibility or logic off when they're too far away to have an affect on game play. So most larger games, on the surface, will appear to be organized by proximity.

However, a further confounding factor is that the scene graph is mutable. Consider a game where the player can drive a car. In terms of the scene graph, the player's avatar becomes a child of the car entity - we'd like to just move the car and not have write code to adjust the avatar ourselves. We would then feed the player's controller input to its immediate child, which would filter down un-handled actions to its children, and so on.

Before

PlayerController
    Avatar
Car

PlayerController.Left -> Avatar.WalkLeft

After

PlayerController
    Car
        Avatar

PlayerController.Left -> Car.TurnLeft -> Avatar.LookLeft