Can someone explain the use case for Prefab variants

I watched the intro video about the new prefab workflows. Now that i'm playing around with them in the editor, i wonder why would i need to use prefab variants?

Maybe i just didn't understand what they are, so if someone could give a short explanation that could be great.

 

you have Goblins. there are thousand of those in the scene, so it's a prefab.
your designer wants to add evil red goblins. he creates a prefab variant, changes the mesh/material (and possibly other values) and adds a couple hundred of them in the scene.

 

Interesting. I never considered the case of goblins.

 

In addition to goblins.

If you want to ADD something (like component or gameobject) to the goblin -- it's a new nested prefab (you take base goblin and add mount to him).

If you want to CHANGE something (like color, armor, speed) in EXISTING parts of prefab and reuse it -- it's a new prefab variant.

 

Use to have a bunch of similar prefabs with a little amount of differences. (like above: base goblin, a bit more healthier goblin, same health but more powerful goblin, same powerful but more wise, etc)
Now, in the new prefab system, you can have one root prefab and a bunch of variants and only override the data you want.
And when you need to change the common data, you have one place to make the change (for example if you need to make all the goblins 10cm taller, you don't have to hunt down all the goblin prefabs and change all of them, you can just change the base goblin and if the others don't override the height, it will automatically change everywhere).

 

This thread further convinced me that the old prefabs (flat, simple) are better for the following reasons:

• I'm seeing people with 10,000 "improved" prefabs
• If you need to change so much that you need variants, nesting etc you are in number scales that don't make sense to be using prefabs to begin with and should be using tooling / ScriptableObjects which solve performance, memory and simplicity

In the case of a variant, you're still burning the same amount of memory as having two old style prefabs. So there is no real world gain in cluttering up projects with hundreds of variants vs hundreds of actual prefabs. If we are having a large amount where variants make sense, then tooling makes sense a lot more!

A prefab in the scene will store all of the data uniquely, not just the differences. This is why we are looking at our own approaches. Essentially, if something will benefit from a improved nested prefabs and variants, it is likely that prefabs are the wrong design for the job to begin with.

If we look at the goblin scenario: we want a red version? cool, make a variant. You might as well just make another prefab though. Really. And the reason variants are a thing are because you want to keep "most of it the same except for some bits". There is no reason I can't just have a proper script on it that will adjust those bits a thousands times over without cluttering up the project with a thousand variants. It's way more efficient, imports instantly, shares resources etc... There is no actual proven case where nested + variant actually beats a designed solution.

So I think the whole nested/improved prefabs thing is actually really for industries that don't rely on programmers and for people who will not be making a factory or tool. And I won't even get started about ECS.

The whole prefabs system here, it's solving a problem one way where there are actually better solutions available. It's making a spanner support many more use cases instead of building a tool to solve something. I can't help but wonder just how many people are going to go right ahead and box themselves into huge development times and bugs waiting to happen. I imagine the scene view to be a blur of icons now for some people.

Would like to see more use cases that are real world because I am open minded and willing to be proved wrong.

I guess it's a great thing for some industries or people who won't make tools though. I am just leaving these thoughts here because, well, that's what feedback is for.

 

Well, you saw one guy with 10k of prefabs...
Don't generalize on one data entry, it may lead you to false conclusion.

I can't really tell too much neither pro nor contra in this dispute, because I haven't played with it enough just yet.
But the theory behind it very well thought. You have a prefab-hierarchy in your project and you can build on it when you need some common values and some different ones (if you only have common values, you should not duplicate prefabs) so there is no need for two prefabs which are exactly the same.

But if you change some values after you created some prefabs (like adjusting the attack or defense values or other such things) this hierarchy is very good, because usually you just need to update at one point, not in many like before, so it's lowering the chance that you forget/miss something.

Yes, you always can build your own tool for that, I agree, but then we need nothing from Unity (in terms of tooling), since we can always write our own again and again and again.
I disagree with this conclusion because the measurement should always be the savings on (wo)man hours on the entire Unity user-base, not only on one project which may or may not be yours.

But I'll get back on this topic when I played more with the new system so I have some hands on experience.

 

Since I am the 10000 prefab guy: I could have done 10000 prefabs before, but I didn't because I was afraid if I make a second one and change something on the first, I'd have to do it all over again. So I ended up with 1000 and never changed something.

You miss the start time. You'd need a script to handle your variations. if I want to change a building with interiors, my script would have to change:
- models
- textures
- some scripts maybe?
- some other prefabs

And what gameobject can do all these changes? A prefab. I'd have to reimplement the whole editor inspector to include all the possibilities I have with prefabs to change them to ScriptableObjects.

 

Time and money is a place prefab variants (and nested prefabs) will beat a well thought out coded solution just about every time. Since you don't have to code and maintain a complex factory and instantiation system for simple scenarios.

More complex scenarios will require less code in the same system.

Which also means less code to test overall for a similar (if not the exact same, depending on scenario) end result.

A good example is going to be UI. You may need to reuse the same UI element across multiple UI screens (very common). Lists of something that appear in multiple places for convenience, for example, or that have additional behaviors depending on where it is.

Prior, if you wanted to achieve that your only option was to do it in code. Now you can achieve it with nested and variant prefabs with 0 code to assemble the UI screen.

I'm actually going through and simplifying a lot of my factories to make use of the new prefab system.

Characters (enemies, friendly NPCs, player) used to be completely assembled via code. Instantiate the model, start attaching components, initialize the components (critical for DI) based on the options passed in.

I can now instantiate the prefab, reduce initialization (in code - there's still some, where DI is needed), and be done with it. In one factory I was able to strip out about 300 lines of code and eliminate ~30 unit tests just by using the new prefab system to handle it for me.

The other added benefit here is that when my game designer needs to make adjustments at run time to certain values....he can just do that. He doesn't need to have VS open at all. He doesn't necessarily need to restart the scene to see his changes. Those minor tweaks now take seconds instead of a minute or two.

 

My issue with all this is that it's designed for big jobs but big jobs do not want prefabs at these scales. It's designed boldly for where it can't go (ECS/Open world).

So strong prefabs, you'll use them for small games which don't really benefit from strong prefabs. I'm not trying to take away anything from anyone's desire to use them. But so far, no point for me.

If we did use prefabs like this, they would be parsed and deconstructed to match parts. I would probably generate data to allow them to be put back together from pools at runtime and for ECS compatibility. So I'm not able to avoid the code regardless if I care about performance.

Still welcome all and any use cases so that I can be informed. I would be a complete idiot if I rejected something without fully appreciating it (and on some level, Unity ought to appreciate the extended discussion).

I'm thinking a lot more now about how we can deconstruct these new prefabs, using them purely for blueprints for building the same things out of pools. I should be able to do this in a nonspecific way that doesn't require any maintaining.

 

Yes there is. Your artist will need to rely on a programmer and even if he capable of doing everything on it's own, a trainee who discovered Unity last week will be done with the gobelins before your script is done.

Like you said, this feature is meant for people who don't rely on programmers and it was one of the most requested because that's how you get work done.

 

You're being a little narrow minded if you can't see the rapid prototyping benefits with prefabs and prefab varients, as well as built in, clean cut functionality that doesn't bloat the project.

If you have a project where you know EXACTLY how everything will function, know EXACTLY the setups for all assets and how they will function over time 100% so you can create a very rigid code solution, that's great, but I'd wager your a very small isolated team and in a unique position to subvert the need for such systems, larger teams would benefit IMMENSELY from these tools.

I'd hate to be 10,000 assets deep into a code solution for assets and realize that there's a change that needs to be made that isn't easily solved by code or feel boxed in from making big changes because every new move we want to make requires more code, "everyone take a break, we need to solve something with our unit setups with code".

The fact of the matter is if you can have powerful global tuning tools rooted in the editor that are polished and easy to work with, you're going to have much happier designers who aren't having to figure out how to communicate to code what they need, and confidence moving forward that you don't need to dissect the engine to figure out future code features to maintain a large, diverse asset list.

 

I'm not being narrow minded. I'm clearly asking for people's use cases:

Thanks for sharing though - all good stuff.

In what application? it seems like an authoritative comment as if you've experienced it in other engines so I'm curious to check those out.

Regarding the code solution, we have worked that way for a while - it's very optimised and doesn't require new code per asset. I guess a lot of people built up similar workflows over the years.

 

Different projects/people have different requirements. It's difficult to say one system or approach is better than another. It probably depends on the project and team.

I imagine it's still possible to create "plain old prefabs" that are no variants and do not nest. If this is a better solution for a particular project, why no dismissing all the new functionality.

If prefab variants make a lot of sense for a particular project, why not using it? The same applies to nested prefabs.

I think, just because Unity provides the functionality, we don't have to use everything or use it in every possible combination. We should just pick the things that help us with our project the most, thus it seems to be a good idea that Unity Technologies provides different prefab workflows.

 

Hippocoder trust me I'm with unity day to day almost decade and nested prefabs solvindg so many design limitations even for simple app or game. The simplest usecase is UI design. You have button prefab that is on panel prefab that is on canvas prefab.The same is true for complex scene objects. Just allow your mind to drift a bit into infinity to see how nesting is the way how we can simulate how nature is built without having to recreate every nuances of our creations from scratch. Cheers.

 

I liked the button expample. May be UI is a great escenario for nesting. Sti for UI I use editor tool and I uniform things attaching scripts with editor tools. But I could see this workign with the new systrm

All we need is they fix the prefabs breaking on import so we can properly test on our ongoing projects without having to figure out how magical this new bulkier system will be.

 

UI for example. You'll have a lot of prefabs using the same text fields, icons... Have fun changing them all by hand instead of having them use prefabs in prefabs or prefabs variant.

Yes, I'm one of them and that's why I can tell you it doesn't compare to improved prefabs. Like I said, your solution require qualified personnel and maintenance. This is not free.

Now, if you are doing so well that you're ok with paying more for a slower solution, be my guest, but understand that some of us have a business to run and need tools that make working simple and easy.

 

TL;DR, I just write one good usecase

You are creating some model, exporting it to unity in FBX, work still in a process. You want one models with multiple textures variations. You create variant prefab from fbx-model (right click on the FBX model - create -> create varian prefab). You create varian-prefab for each texture-variation and attach corresponding materials. Work still in process, so you will probably add some modification to model, maybe create some subojects. With original-prefab (as early and still accessible in new workflow) all updates in FBX will be lost and prefab stay same as was created, with variant-prefab all modification was made in FBX will be applied to all variant-prefab (if it wasn't overrided in variant-prefab)

you can watch this workflow by the link (time 22:49)

 

sounds bit overkil for this particular example, l I use a simple script to manage skins and I've same prefab for Player and AI's. I can even handle multiple skins for same model and AI.

 

This is theorycrafting, but we shipped with bugs that would've probably not have been there with variants. It's cases where we had a bunch of very similar prefabs for an enemy type, each with different settings - primarily their mesh and renderer, but also settings for hp, attack rate, and AI tuning.

At one point during development, we had to change how the mesh and bone structure was set up for those. It took a while to change over all of the models, so so the changes happened over time. As a result, we ended up with different setups for the different models, and some of them got bad settings that we never caught, causing pretty bad bugs in corner-cases.

If there had been a single base prefab that contained all of the shared properties, it would have been way easier to work with those prefabs, and it would probably have been easier to handle the bugs.

We also shipped with the wrong fonts applied to a bunch of buttons in a seldom-used menu, as the button prefabs had been placed under a different prefab, and that different prefab had been applied. Nested prefabs would have prevented that (and also saved us a ton of time when redesigning look and feel).

This is one of the the number one thing the community has been asking for for years, and that's because we keep running into real, tangible problems due to the current prefab system in real games. Scripting our way around those problems is not a good solution, it's a workaround that costs time and money.
Unity's also gone ahead and analysed the real-world issues that people have, and tailored solutions to that. Prefab variants are really neat, because they solve my first example much better than just nesting would have done. So it's a solid piece of design.


Finally, sure we could script up solutions to solve the issues prefab variants and nesting solve, as you suggest. But, that has two major drawbacks. We have to:
- either just test things in play mode, or deal with the utter garbage that is [ExecuteInEditMode] in order to see the changes in the scene view. Neither of those are remotely viable.
- go through a programmer every time we need to have variations like this, and we . You know, I have pathfinding to fix, I'd really love this to be something our level designers can handle on their own.
- deal with increased onboarding costs as new people need to be taught your new interface.

You can say this about any feature ever. The new prefab stuff seems to have a very well rounded complexity-to-power ratio.

 

You're talking about performance and you're right that the improved Prefabs do not offer performance gains. (It's not a runtime feature at all; it's an Editor feature.) But there are huge productivity gains for some people (as some replies in this thread illustrates).

If we had waited shipping new Prefabs until they had been fully integrated with a mature ECS, it would have been several more years of waiting for everyone (how many exactly, nobody knows). That can still happen sometime in the future, but we wanted to provide a Prefabs solution now without having to wait an undefined amount of time for ECS to first be ready too.

I also suggest keeping an eye on Unite Austin for more on this topic at that time.

 

Awesome, thanks! Hope you don't mind that I'm digging into this stuff in-depth. The aim is not to pull it down, but see how strongly we can utilise it.

 

Oh.... this means it's possible to break Improved Prefabs out into a Package!!!

???

 

Nope. They had to do changes to Unity's core to support improved prefabs. That's why the beta was using a special version of Unity instead of a beta package.

 

It means that after you set up your prefabs, and they loaded up runtime, they won't be prefabs anymore, they will be ordinary gameobjects. Nothing to do with modularization.

 

@liortal

In answer to your original question:

if you know anything about OOP:
I think Prefab Variants are a partly failed attempt to surface Class-Like inheritance patterns and procedures to game object design and structure.

if your'e a designer, and/or unfamiliar with OOP:
Prefab Variants are going to be a LOT harder to explain. I could probably do it, but I'd have to use a lot of examples the first few times, until I found a way to make it simple to understand what's possible and why it is considered a good idea. The upshot of that is that for initial design processes and creativity, it's NOT needed, and should be overlooked.
ie its real benefit is only present in what you do once you've solidified design ideas and know what's going to derive traits from what...

 

I think prefab variants aren't a failed attempt to copy class patterns, but a byproduct of nested prefabs.
Since a prefab can include changes to a child prefab, it can include changes to a child prefab without an actual new parent as well.

 

same thing

 

I like to use variants in two ways at the moment:

1. Creating a variant directly from an imported model to use as a prop in a scene. This is great because usually simple props have a simple hierarchy and only use a couple of overrides like being static or having some lighting settings. Also any updates to the name of a mesh will not break the variant.
2. Having an Enemy (or any other class type: Boss, Player etc.) base prefab and inserting overrides to make variations of that class that can be saved as enemy variants.

Hope this helps, variants already is a godsend for me.

 

It is a pretty old thread, But I would like to ask about something I encounter in Unity 2019.2.17
In usecase 1 @Laurens-Paladin-Studios describes.

I have a character and several derived characters. They have a different mesh and a different material.
Now the name of the meshes in the model (that is part of the base-prefab) changed.

Suddenly the overrides that are set in the prefab variants don't apply anymore.

How can this issue be tackled? I can't find how the override finds the object/component of which it overrides the values.
I am guessing it finds it by some sort of GUID?