The natural reflex: split everything into prefabs
When structuring a Unity project, the instinct is often to turn every reusable element into a prefab. A menu? Prefab. A settings sub-menu? Prefab. A custom button inside it? Prefab. It sounds logical: it's modular, it's clean, it's "well-architected".
Splitting things up isn't a bad idea in itself: it allows team members to each work on a part of the scene without creating merge conflicts.
But in practice, this nesting has a hidden cost that only reveals itself when you try to change something.
The real problem: where is the config?
Let's take a concrete case. On one of my projects, a colleague asks me why the Settings menu isn't a separate prefab. As it stands, its configuration is attached directly to the parent prefab VRMenus. To modify Settings, you have to go through VRMenus.
At first glance, this looks like a flaw. But in reality, as soon as you nest prefabs, each level of nesting becomes a potential place where configuration can be saved or overridden. When you make a change, the question quickly becomes a headache:
- Is the change saved on the scene?
- Or was it applied on the parent prefab?
- Or on the nested prefab itself?
- Or is an intermediate level overriding the value?
All it takes is one intermediate level overriding a property for the final result to no longer match what's configured in the prefab. You then have to hunt down the source of the discrepancy across intermediate prefabs to find which one overrides the default value. Unity doesn't make this investigation easy: you have to navigate between the scene, each parent prefab, and the source prefab, comparing values at every level.
The rule I follow
To avoid this complexity, I keep prefab depth to a strict minimum:
Ideally, a single level of prefab. The prefab contains everything it needs directly, with no nested prefab. Configuration lives in one place, and changes are predictable.
Sometimes, a second level for ultra-generic components. A button, a text field, a progress bar -- this type of basic UI component deserves to be a prefab. Including a generic prefab inside a specialized one remains manageable: the generic component is rarely modified, and its overrides are easy to spot.
Never multiple specific prefabs nested inside each other. When you nest prefabs that each have their own business logic and their own configuration, the number of places to look for a problem multiplies. In the end it cost me more time than what the "modularity" had saved me.
A conceptual problem, not a tooling one
This stance might seem to go against the grain. Nested prefabs were introduced in Unity 2018.3 as a major feature, and they do solve real reusability problems. But the issue runs deeper than an interface to improve.
Better tooling would speed up debugging, sure. You could for instance imagine an editor that displays "this value comes from prefab X, overridden at level Y". But the cognitive load would remain: when I modify a value, at which level do I want this change to apply? Do I want to modify the source prefab (and impact all its instances) or only this specific instance? With two levels, the question is straightforward. With four or five, it becomes a mental exercise on every single edit.
It creates more situation where you have to ask yourself who the owner of the data is and where it belongs, and as such more opportunities to have a random data holder overriding the settings when it shouldn't.
That's why the solution in my opinion isn't to wait for a better tool, but to limit depth at the source.
Find me on social networks
If you found this article helpful, check my other articles and don't forget to follow me on your favorite network for more game development tips and discussions.