{"id":350,"date":"2021-05-01T15:35:19","date_gmt":"2021-05-01T15:35:19","guid":{"rendered":"https:\/\/bronsonzgeb.com\/?p=350"},"modified":"2021-05-01T15:35:20","modified_gmt":"2021-05-01T15:35:20","slug":"unity-architecture-pattern-structured-prefabs","status":"publish","type":"post","link":"https:\/\/bronsonzgeb.com\/index.php\/2021\/05\/01\/unity-architecture-pattern-structured-prefabs\/","title":{"rendered":"Unity Architecture Pattern: Structured Prefabs"},"content":{"rendered":"\n

This article shows a powerful Unity pattern that I’m calling Structured prefabs. Structured prefabs are a pattern I use to simplify prefab initialization and reduce bugs. They help to indicate the intention of the creator to other developers and lead to overall better maintainability.<\/p>\n\n\n\n

What is a structured prefab?<\/h2>\n\n\n\n

Like I mentioned, a structured prefab is a pattern I use to reduce bugs and increase maintainability for all my prefabs. The idea is to add a component at the root of every prefab to identify it, and give it structure. This component often has the same name as the prefab itself, but not always. Sometimes this component won’t contain any code, sometimes it’ll only contain serialized fields, and sometimes it’ll be a full-blown MonoBehaviour with behaviours.<\/p>\n\n\n\n

So let’s explore all the benefits of this pattern, starting with references.<\/p>\n\n\n\n

Prefab References<\/h2>\n\n\n\n

More often than not, I see developers reference prefabs with generic GameObject<\/code> fields like this:<\/p>\n\n\n\n

public class Game : MonoBehaviour {\n    public GameObject playerPrefab;\n}<\/code><\/pre>\n\n\n\n
There are two problems with this approach. First of all, as a developer working on the project, you’ve given me no indication of what you expect the player prefab to be. Does it require specific components to work? Most likely, yes. What developers should do instead is reference prefabs by a component, like this:<\/p>\n\n\n\n
public class Game : MonoBehaviour {\n    public Player playerPrefab;\n}<\/code><\/pre>\n\n\n\n
When you do it that way, you know that at the very least, the player prefab needs a MonoBehaviour<\/code> of type Player<\/code> at its root. What’s more, if you do this, the Inspector won’t even let you assign a prefab that\u00a0doesn’t<\/em>\u00a0have a Player<\/code> component on its root. You can’t accidentally assign the wrong prefab (well, you can, but the wrong prefab will have a Player<\/code> component on it as well, at least). By the way, when I talk about the root, I mean the GameObject<\/code> at the top of the prefab’s hierarchy, rather than buried inside the prefab.<\/p>\n\n\n\n
Now I’ll show how this subtle change massively improves your code’s reliability.<\/p>\n\n\n\n
Prefab Instantiation<\/h2>\n\n\n\n
This next bit is my favourite part. When you instantiate a Prefab using a generic GameObject<\/code> type, the function returns a GameObject<\/code>. Usually, the next step is to use GetComponent<\/code> to retrieve the components you care about like this:<\/p>\n\n\n\n
public class GameManager : MonoBehaviour\n{\n\tpublic GameObject playerPrefab;\n\n\tvoid Start()\n\t{\n\t\tGameObject playerGo = Instantiate(playerPrefab);\n\t\tPlayer player = playerGo.GetComponent<Player>();\n\t}\n}<\/code><\/pre>\n\n\n\n
Instantiating prefabs this way is pretty dangerous because there’s no guarantee the Player<\/code> component will be there, and then your whole game breaks. But, did you know that if you call Instantiate<\/code> using a reference to a Player<\/code> component, it’ll return the Player<\/code> component instead:<\/p>\n\n\n\n
public class GameManager : MonoBehaviour\n{\n\tpublic Player playerPrefab;\n\n\tvoid Start()\n\t{\n\t\tPlayer player = Instantiate(playerPrefab);\n\t}\n}<\/code><\/pre>\n\n\n\n
When you do it this way, you know with absolute certainty that you have a Player<\/code> component (unless playerPrefab is null). By the way, if you use the main loop pattern from my previous article, and you avoid unnecessary null checks, you’ll know for sure that a null reference on initialization is due to not assigning something in the Inspector. Think of all the hours of your life you wasted chasing null reference errors. Now you can take that time back for the rest of your life. Spend that newly found time with your family and loved ones.<\/p>\n\n\n\n
Now that we’ve solved prefab references and instantiation let’s cover the last piece of the puzzle: prefab initialization.<\/p>\n\n\n\n
Prefab Initialization<\/h2>\n\n\n\n
After instantiating a prefab, you often need to initialize it before using it. You could wait for the Awake and Start methods to be called, but then you have to rely on a collection of loose initialization functions to run in an undefined order before your prefab is fully initialized. In my experience, a much simpler approach is to give your root component an initialization function that you call explicitly. For example:<\/p>\n\n\n\n
public class GameManager : MonoBehaviour\n{\n\tpublic Player playerPrefab;\n\n\tvoid Start()\n\t{\n\t\tPlayer player = Instantiate(playerPrefab);\n\t\tplayer.OnCreated(this);\n\t}\n}<\/code><\/pre>\n\n\n\n
By the way, you might notice I passed this<\/code> into my OnCreated<\/code> function. That’s because I give my objects a reference to their parent object to simplify lifetime management. It’s the owner’s job to manage any GameObjects<\/code> that it creates, so having a reference to your parent makes it easier to ask to be cleaned up and destroyed. If you don’t know what I’m talking about, I recommend reading my previous article on the main loop pattern to understand how I structure my projects.<\/p>\n\n\n\n
Anyway, let’s get back to talking about initialization. We’ve already seen how we can remove GetComponent<\/code>, Start<\/code> and Awake<\/code>, and make our code less error-prone, right? Well, we can take those same approaches and use them on our root component as well. In other words, rather than use GetComponent<\/code> inside our Player<\/code> MonoBehaviour<\/code>, we can reference everything we need directly.<\/p>\n\n\n\n
public class Player : MonoBehaviour\n{\n\tGameManager _gameManager;\n\tpublic CharacterController characterController;\n\tpublic Animator animator;\n\tpublic Health health;\n\t\/\/etc...\n\t\n\tpublic void OnCreated(GameManager gameManager)\n\t{\n\t\t_gameManager = gameManager;\n\t\t\/\/call OnCreated on all the custom components...\n\t\thealth.OnCreated(this);\n\t}\n}<\/code><\/pre>\n\n\n\n
With that:<\/p>\n\n\n\n