Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[Official] Prefab Improvements

Discussion in 'General Discussion' started by bibbinator, Jun 23, 2014.

Thread Status:
Not open for further replies.
  1. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    May I suggest averting the danger by not storing the volatile parts of the data inside the scope of the prefab? For instance, break it out into a data object and store it elsewhere or something.
     
  2. davekalina

    davekalina

    Joined:
    Apr 2, 2013
    Posts:
    39
    Who are you?
    David Kalina, Tiger Style

    What kind of game are you trying to build or would like to build?
    Spider: Rite of the Shrouded Moon / www.shroudedmoon.com
    If you're not familiar with Spider, it's a 2D action-adventure-platformer type game.

    How do prefabs fit into that? What use-cases do you have?
    Generally we use prefabs for the following purposes:

    1. For facilitating common level markup (triggers, teleporters, patrol paths, etc)
    2. For facilitating initial level setup and enforcing hierarchy organization (e.g., place this 'insect container' and it contains a variety of required markup components necessary for the game to work)
    3. For designing/tuning reusable AI types. Place an instance of the "MonarchButterfly" prefab everywhere in the game, update it in one place to propagate changes to all instances.

    What about the current prefab system isn't working for you?

    Unlike most people, we haven't really run into the need for "nested prefabs."

    The biggest problem I tend to encounter is that prefabs are usually 99% data that I want to be common across all prefab instances... and then 1% data that I want to be specific for a given prefab instance. However, there is no way to specify "this property should always be specified by the instance, only."

    It seems that Transforms behave this way already. Transform changes on prefab instances don't propagate back out to all other prefab instances, because obviously you want this to be an instance property.

    Often I want to do other markup related things that are unique to prefab instances. e.g., this Insect specifies the WanderVolumes it will use during navigation, but another Insect uses a different set of WanderVolumes. However, if I put an array of WanderVolumes on the component in a prefab and then change it in one place, that change gets saved in the prefab and other instances' data gets clobbered.

    A simple property tag would suffice, e.g.:

    [SerializeInstanceOnly]
    public WanderVolume[] my_wander_volumes;

    That's the main change I'd like to see!

    Cheers,
    David
     
  3. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    @David: Sounds like you'd find ScriptableObject useful. Claire Blackshaw did a great, in-depth video on them here. I'm also giving a talk on them at some point this month in London if you're UK-based.
     
  4. davekalina

    davekalina

    Joined:
    Apr 2, 2013
    Posts:
    39
    @superpig Thanks for the video link -- ScriptableObject looks like a valuable concept, but I'm not sure how it addresses my specific problem.

    To try and clarify my use case: I'm looking to point prefab instances at instances of other GameObjects in the current scene. The way the prefab system currently works, I can't have an explicit reference to a GameObject in the scene without being at risk that the prefab might get updated elsewhere and my reference will be clobbered.

    We work around this by implicitly referencing data in the scene, for example by tag, or querying by location on game start... but that's awfully limiting and potentially error prone.

    I suppose I could imagine using ScriptableObjects to define "classes of AI characters" that are fixed chunks of behavioral and tuning data, outside of the prefab system, and then have AI instances point at these ScriptableObjects, but we are deep in production and rearchitecture isn't going to happen!
     
  5. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Yeah, that was the sort of thing I was proposing. But if you're deep in production and can't rearchitect stuff, I kinda suspect that whatever nested prefab solution eventually emerges might find you similarly stuck...
     
  6. Kragh

    Kragh

    Joined:
    Jan 22, 2008
    Posts:
    657
    Who are you?
    Henrik Kragh, Tech Artist at Red Zebra Games

    What kind of game are you trying to build or would like to build?
    Casual RPG Fantasy "Kill-creatures-level-up-gather-stuff" kind of game.

    How do prefabs fit into that? What use-cases do you have?
    To makel level setup easier, relying on some bulding blocks which can be updated independently from the layout of objects in the level.

    What about the current prefab system isn't working for you?
    Well... Nested prefabs.
    Some way to have a hierarchy of blue prints. In my world, if I had designed Unity, there wouldn't be this differentiation between scenes and prefabs. They would be the same in all aspects.
    So you could have a scene build from multiple other scenes. And if some guy worked on the "Pillar" scene, and then saved it, the guy working on the "Chuch" scene would see the new pillar in his/her scene. And then when saving the "Church" scene, the guy working on the "Graveyard zone" would see the update.
    So multiple people could work on individual scenes, which would be collected into higher order scenes, and then into the main game scene. Maybe even realtime reflectance of what other people are doing right now on subsets of your own scene.
    No need for this prefabs concept at all, in my opinion.
    With additive loading of scenes already being a concept at runtime, this would just be some recursive function in the editor, where a given scene would additively load it's children scenes, and then reflect what is what in the hierarchy. The only thing needed is the ability of me being able to change specific properties on individual instance of children scenes. Like you can in a prefab.
    If someone can explain to me in essence the conceptual difference between a scene and a prefab, I'm all ears. I know they differ now (you can make individual changes to prefabs at scene level and all that). But they really don't need to. I may not know who is working on the pillar right now, but I could just select it, the pillar, and chat directly with the guy who is working on it. See his changes realtime. Now...THAT would be cool.
     
  7. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    A little late to the party - but what was shown at Unite 2012 looked super-promising and if we could just get a bug-free version of that, I'd be all happy :)

    TBH, especially the new Unity UI is kind of a pain to use without nested prefabs. It could almost be considered a "bug" now that this is missing.

    Most important from my perspective:
    • Encapsulation: I need to be able to have a complex prefab in the scene, with just a few properties exposed, so the scene looks clean and simple while it's using complex / smart objects. This applies both to components and hierarchy (in other words: I might have a rather complex trees with lots of components on all the different levels - but in the editor, I only have a list of properties that are "exposed" and it looks like a single object). It would probably be nice to be able to show/hide parts of the hierarchy ... but I'd rather not have that and get nested prefabs earlier than have that promised and never get them ;-) ... you need to be able to channel properties through levels of nested prefabs (i.e. expose an exposed parameter that was exposed in a prefab that was used by a prefab that was used) but obviously cannot "grab" stuff from a lower level that wasn't exposed
    • Convenient Editing: I need to be able to do something like right-click "Edit Prefab" to get into edit mode and be able to change everything in the prefab as if it wasn't a prefab (this should automatically change all instances)
    • Backwards Compatibility: Actually, for quite a few purposes, the old prefabs are just fine ... so I'd really like to keep them as they are. IMHO, the best way to create an "advanced prefab" would be right-click on a prefab "Convert to Advanced Prefab" ... this should work both ways (also being able to convert Advanced Prefabs back to normal ones, with a warning that this might break stuff)
    • Be nice with editor scripting: I do like custom inspectors, and it would be quite nice if those could be handled appropriately even though PropertyDrawers are probably much more compatible with encapsulation ... when the old prefabs are still available, I'd be fine with just them properly supporting custom inspectors and encapsulation of "Advanced Prefabs" only working with PropertyDrawers ;-)
     
    JesOb likes this.
  8. MrBrainMelter

    MrBrainMelter

    Joined:
    Aug 26, 2014
    Posts:
    233
    I recently made a plugin called Prefab Mask, which more-or-less solves this problem, though maybe not quite as elegantly as what UT could make.

    Anyway, might be worth checking out.
     
  9. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,106
    Totally agree. UT need to merge prefab and scene into one entity.
     
  10. deram_scholzara

    deram_scholzara

    Joined:
    Aug 26, 2005
    Posts:
    1,043
    Just to be clear - I'd also like to see it set up so that when Pillar is saved, the Graveyard is also updated immediately, without having to save the Church with updated Pillars first.
     
  11. Kragh

    Kragh

    Joined:
    Jan 22, 2008
    Posts:
    657
    Sure. When the Graveyard is opened, it will additively load the Chruch, which would additively load the Pillars. Like a recursive loading of scenes, starting from the scene you are opening.
    So he would see the updated Pillars no matter if the Chuch has been updated or not :) All I meant was the Graveyard guy would see the updates on Church scene, when Church is saved (Or realtime even...). Just badly explained I guess ;)
     
    cygnusfear likes this.
  12. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Wow ... thinking outside the box ... awesome! I believe this would solve a lot of other problems as well. And with the tagging system, it would be easy enough to set it up so that you can differentiate between those "thingees" that you can actually open in the game, and those that you just use as building blocks (from my perspective, that's just a matter of "project organisation"). We already have a way to select which of these "thingees" are directly available in the build.

    The only issue I have with this approach is that neither "scene" nor "prefab" nor "thingee" are appropriate names. Of those three, my vote would go to "prefab". The issue with "scene" is that it's usually a "level" ... but then, quite often it isn't. So that name already has a real problem even without making it also the replacement for prefab. "Prefab" on the other hand already implies it's a "building block".

    What's currently "loadlevel" (and all of its variations) could then also be a way to "instantiate a prefab". The limitation would be that such a "prefab" would have to be listed in the build settings (like scenes currently are). With that approach, a lot of really nice possibilities would open up because using LoadPrefabAdditive(...) could in quite a few situations replace Instantiate (but obviously Instantiate has its good own place). Also asynchronous loading for instantiating (complex) prefabs would come quite handy.

    I'm really impressed! This is probably the coolest thing I've read on the Unity forums for a while (well, Joachim's statement regarding UT not being for sale kind of tops it but he's in a special position ;-) ).


    This would be a rather big change to how Unity works - but IMHO, it would be totally worth it (at least from what I can see right now). This may even solve some issues with Mecanim (when a "pseudo-scene" is opened when you go into configuration mode).
     
    JesOb likes this.
  13. Immanuel-Scholz

    Immanuel-Scholz

    Joined:
    Jun 8, 2013
    Posts:
    221
    Hello,

    I am a senior developer at Realmforge Studios. We are a team of about 15 to 25 people (depending who you count as "us" ;)) and released a couple of boxed PC titles (and one X-Box title), but non with Unity so far. The current project is a unity game "Dungeons 2". We are in a late stage of our game (first Beta tests soon). The game has a server-client architecture and currently uses 4.5.5 but we are in the process of updating to 4.6 (and maybe even 5.0beta, as we run into constant editor crashes due out of memory)

    We have in-house solutions for a coule of features about prefabs that we would like to have supported from Unity better.

    Nested prefabs
    As a plain "nested prefab", I understand a prefab inside another prefab that keeps getting updates from the original prefab. @hippocoder describe this perfectly: "if I create pilot and airplane prefabs, and the airplane contains the pilot prefab, if I change the pilot prefab's helmet to red, the airplane will contain a pilot with a red helmet."

    Although he is true about the "making the pilot's helm red and revert that change only in the outer prefab", we never really needed that feature, except for the transform. Instead, we would like to be able to restrict the changes to usually "change in transform only". (In other words: It would be OK if the editor guys can only change the local position of the "pilot" relative to the airplane. (But it would not hurt us if they could change all properties.... much. ;)).

    What should work here are, that links from outside properties into components/gameObjects inside the prefab are preserved. For example if the airplane has a component with a property "public Transform pilotHand;" and we link the pilot's hand bone to this property, then updating the pilot's helm color must not break this link. (or even renaming the hand gameObject.. In a project of 20+ people with multiple people working on animations, you HAVE to be able to rename bones to keep sane).

    We currently have a "solution" for that by adding a component (called "AssetLink") to the prefab that has a property of another prefab. Every now and then 1) the component calculates a hash value 2) and if the hash mismatches, it updates the prefab by instanciating->change->update->cleanup from code. We run into lots of trouble with this system (e.g. constantly loosing links from properties from outside the inner prefab into components of the inner prefab. Basically, we had to write our own "TransformLink" type, matching with very awkward rules). But it works somehow and is much preferable to having to copy the pilot's helm color over and over and over again.

    1) its complicated... we don't want to update too often to not run into constant merge conflicts with our source control. But not too seldom to actually see changes reflect in out game testing..
    2) usually just hashing the corresponding .prefab and .meta file, which was a bad idea, since we ran into a heap of trouble with unsaved assets


    Exposed prefab parameter
    Any prefab should be able to mark certain properties as "exposed". The editor restricts access to properties and only allow exposed properties to be changed. This is most helpfull in giving other people a clue what they are supposed to change.

    In our project, we actually found it sufficient if the "exposed" state is statically configured within the component, e.g. as an attribute. I can easily think of some good places where we would restrict access based on the prefab (e.g. the helm color property of the pilot is exposed, but the color of his shirt is not, although its the same property in the same component). But in practice, the much more usefull feature is to just "do not expose" some properties of some components (means: They can be configured in prefabs within the editor but are not allowed to be changed in the scene file).

    Also, in many places it would be desireable if the property could still be changed - at least temporarly (mostly to debug and try stuff out).

    We currently use an custom EditorWindow called "ModificationBrowser" that lists all "unexpected" changes in the scene and routinely reports these to the map designers. (There are two equally valid ways of fixing the problem: You either revert the property or you make the property exposed. So there is no automatism here, just error reporting).

    Inherited Prefabs
    For all our server code (game logic code), we have our own data classes not inheriting MonoBehaviour. (This had unrelated reasons, mostly to have multi-threading instead of inter-process-communications). We wrote an own editor for these what we called "Template".

    In previous projects, we supported multi-inheritance with this Templates. Basically, every template could specify 0 or more other templates in an ordered list. These base templates provide components and property settings. The current template will include these components and properties before it applies its own changes. Previously, we supported multi-components (multiple components of the same type) as well, but the component itself has to be attributed as MultiComponent. Overriding properties in multi-components required to specify the index of the parent template. Apparently, that was a pain.. Back then, we did not see the need for the ability to "remove" a component in an sub-Template.

    In our current project, we removed the support multi-components to simplify the solution and it worked so far for us.
    We also added the ability to remove components in child-Templates. This gave really funny problems with multi-inheritance (e.g. BaseA adds a Component, BaseB removes it from its parent. Is it added to the Child?). So we had to remove multi-inheritance to keep a sane and manageable system. We would like to add it again some day as it gives extremely flexibility writing some "mixin-like" templates to build your final types..

    Also, In some places we found it usefull to change the inheritance structure during gameplay or in other words: Take this instanced Template, now apply the following Template as if it were a new base template.

    We have support for "abstract templates" which is a simple flag in the template that prevents level designers to directly instantiate these templates. Very usefull as a communication flag "that thing is only here to construct another template". Most usefull with mutliple inheritance.

    RequireComponent improvements
    I just want to mention another point. Its only remotely related to "prefabs" but especially having Multi-Inherited Prefabs makes the following point important:

    IMHO, the current RequireComponent attribute is broken and not usable in larger projects. It is not a guarantee, since added attributes do not affect current scenes. It requires the level designer to clumsy juggle around with lots of unnecessary adds and removes when re-configuring prefabs (e.g. replacing one collider type with another). And finally, it forces the designer to know or care about the relationship (e.g. because of the error messages, he has to remove some other components he never added in the first place).

    We do not use RequireComponent at all. Instead, we have two other attributes: AutoAddComponent and OurRequireComponent.

    The former "AutoAddComponent" automatically adds the specified component whenever the class this attribute is attached to gets added. This happens during runtime as well. So it acts as a guarantee for the coder. If he puts AutoAddComponent, there is always the given component present. Needless to say, it works recursive (if A adds B and B adds C, only adding A will have B and C present as well). This feature is heavily used in our server code (and our "Template" classes) and we are very satisfied with it.

    In Prefabs, its important that an AutoAddComponent on Component A does not get "executed" when A is removed in a child prefab instance (thats one reason why we don't add the component in the editor but at runtime).


    The other attribut "OurRequireComponent" is a bit like RequireComponent, but does not add or enforce anything in the editor. What it does, is giving a warning in our custom ProblemsEditorWindow that there needs to be the specified component. This is mainly used if the required component has to be set up properly in the editor and hence cannot be added without prior configuration.
    My expectation was at first, that this is much more usefull than AutoAddComponent because I expected most components to "need some editor settings". It turned out to be "moderately usefull". But still much better than the stock implementation of RequireComponent.


    Hope it helps.
     
    Last edited: Nov 25, 2014
  14. Text

    Text

    Joined:
    Sep 22, 2014
    Posts:
    2
    Nested prefabs with ability to modify properties on prefab instances is great concept .
    Do we have any chance to get it in Unity 5.x ?
     
  15. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    Who are you?

    An extreme hobbyist bringing in $0, but keeping unity pro up to date!

    What kind of game are you trying to build or would like to build?

    Sandbox games, procedural games, horror games, clones of other games.

    How do prefabs fit into that? What use-cases do you have?

    What haven't I used prefabs for? I'm not used to the scene loading yet, so I build a level and parent everything to a transform called "level 1" or whatever level it is. When I transition into the next level, I blind the user with a fullscreen guitexture loading screen, destroy level 1 and load in a prefab of level 2. I also use prefabs when I'm making a bunch of copies of an item that has very specific components and settings on those components. I even use prefabs for making new UI stuff. When you have a prefab of something linked to a canvas, you can instantiate copies and you won't get that error from making a new 4.6 Text or Button at runtime.

    What about the current prefab system isn't working for you?

    I haven't had any issues at all with the prefab system. Performance wise, it's been great. If I am loading a big enough prefab, I'll load pieces of it round robin so the game doesn't slow down. Prefabs right now are as versatile as I need them to be for the foreseeable future. With that in mind, I guess if there are optimization options that can be made, go with that?
     
  16. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    290
    Who are you?
    Programmer, Artist, Designer, Game Engineer, maker of many things.

    What kind of game are you trying to build or would like to build?
    i make all kinds of games. currently making a hack n slash platformer. hope one day to make a 3d brawler(devil may cry-esk)

    How do prefabs fit into that? What use-cases do you have?
    Prefabs are the basis of every game as they are how you organize your objects into modular pieces.

    What about the current prefab system isn't working for you?
    currently its little more than a copy-paste system for objects. incredibly fragile objects connections. cluttered hierarchy's due to the inability to minimize prefabs. etc....

    while i know you won't just take my advice wholesale(nor would i say you should) i'm going to outline how i would make the system and hopefully you find something interesting or useful in my rambling.

    Prefabs should be treated more like single objects in scene hierarchy.
    -easier management (Player prefab would just show up as one object called Player)
    -harder to break prefab connections
    -makes more sense
    -easier nested prefabs
    -right click prefab and click the unroll option to turn it into its component objects
    -allows much better organization

    Prefab Editor for editing prefabs outside a level
    -artists can calibrate materials in a controllable environment(setting custom sky, etc...)
    -choose what parts of a prefab to expose to the level designer/other prefabs
    -could be customized specifically for prefab editing.
    -easier asset testing/setup
    -things like LOD which can really clutter up your scene view could be minimized.
    -would allow the creation of much more complicated object structures without the usual readability problems that discourage this behavior.
    -allows much better organization

    Nested Prefabs for better modularity.
    -make prefabs out of smaller pieces
    -makes prefabs components, based similar to gameobjects.
    -easier asset management
    -would really simplify using objects in complex ways. at the moment this is a real hindrance.
    -allows much better organization

    Prefab Inheritance for trees of prefabs
    -breaks your prefabs into smaller bits for easier editing.
    -makes it so prefabs can have a common ancestor. (player and monster might both be actors)
    -better for team editing (artists make a visual prefab, designers setup the logic, colliders, etc...)
    -allows much better organization

    Prefab Related Messages to allow for easier interaction with level designers
    -could hook into value changes at a prefab level for things like procedural generation
    -linking and cleanup would be much nicer as well. example: prefab that spawns a UI element in canvas could delete it when a value on the prefab is changed without having to be the root object.
    -many other benefits the community would cook up with more hookups like this.

    all this adds up to an awesome workflow improvement. this isn't just about making things easier. with that simplicity would come new levels of complexity. whether it be a procedural house prefab, automatic mesh merging or whatever other cool stuff people could make with a more solid prefab system. all this would add up to bigger, better and more complex games in unity. which would bring more users to unity and more users together working to make cool S***. =3
     
  17. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Any comments on this? I think this is a really really awesome idea totally worth consideration!

    Merge the concept of "scene" and "prefab", provide a really nice way of editing this new thing called "HierarchialUnityBuildingBlock" ... which would be ... um HUBB ;-) ... well, Prefabs (and there simply wouldn't be scenes anymore ... or maybe "IsScene" would just be a checkbox for Prefabs, kind of like Colliders can also be Triggers by activating the relevant checkbox).

    See also my comments in addition to what Kragh posted:

    Wow ... thinking outside the box ... awesome! I believe this would solve a lot of other problems as well. And with the tagging system, it would be easy enough to set it up so that you can differentiate between those "thingees" that you can actually open in the game, and those that you just use as building blocks (from my perspective, that's just a matter of "project organisation"). We already have a way to select which of these "thingees" are directly available in the build.

    The only issue I have with this approach is that neither "scene" nor "prefab" nor "thingee" are appropriate names. Of those three, my vote would go to "prefab". The issue with "scene" is that it's usually a "level" ... but then, quite often it isn't. So that name already has a real problem even without making it also the replacement for prefab. "Prefab" on the other hand already implies it's a "building block".

    What's currently "loadlevel" (and all of its variations) could then also be a way to "instantiate a prefab". The limitation would be that such a "prefab" would have to be listed in the build settings (like scenes currently are). With that approach, a lot of really nice possibilities would open up because using LoadPrefabAdditive(...) could in quite a few situations replace Instantiate (but obviously Instantiate has its good own place). Also asynchronous loading for instantiating (complex) prefabs would come quite handy.
     
    cygnusfear likes this.
  18. cygnusfear

    cygnusfear

    Joined:
    Oct 24, 2012
    Posts:
    14
    Yeah I'm totally interested in Kragh's solution here. Various other engines use a similar solution; in my opinion this pretty much solves a lot of Unity's design issues with prefabs. I'm not so sure complementing the currently broken by design system with more arcane features is actually going to solve those.
     
  19. SteenLund

    SteenLund

    Unity Technologies

    Joined:
    Jan 20, 2011
    Posts:
    639
    Hi all,

    Once again thank you all very much for the feedback.

    We have be gathering the feedback and processing it, but the focus is still on shipping 5.0.

    With regards to scenes and prefabs changing to become the same thing, that is an idea we have been tossing around internally as well, if it will ever happen i don't know.
     
    Cynicat and jashan like this.
  20. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Thanks for the update on this. Hoping for 5.1 ;-)
     
  21. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Oh, btw - not sure if this was already mentioned, but: When you do fancy "expose some fields but not others" stuff, which I think is quite important, don't kill custom inspectors. I believe PropertyDrawers kind of were introduced to solve exactly that problem - but there's still quite a few cases where full custom inspectors are very useful.

    Suggestion: Add an API to custom inspectors so that the developer can decide what should / should not be possible. In other words: If a component has a custom inspector, and the implementation says nothing, you can only either expose the full component, or nothing of that component. If the custom inspector says "I can handle exposing this and that parameter separately, but those other three only together", this should also be treated appropriately. It should be fairly easy to provide an additional flag to properties to tell the custom inspector "this is exposed, draw it" vs. "this isn't exposed, don't draw it".

    This is non-trivial but I believe it's quite important especially as Asset Store publishers are relying on custom inspectors and you don't want to break/invalidate their work by introducing a system that doesn't handle custom inspectors well.
     
  22. f4bo

    f4bo

    Joined:
    Oct 7, 2014
    Posts:
    21
    Who are you?
    just a gaming enthusiast
    What kind of game are you trying to build or would like to build?
    a modular game
    How do prefabs fit into that? What use-cases do you have?
    my workflow is to have 1 script that manages the whole gameplay, instantiating 1 prefab at a time containing other prefabs, mainly UI objects - each of these active parent prefabs send a message upwards to the main script when finished and this will destroy the prefab, instantiating the next one, depending on the gameplay status.
    What about the current prefab system isn't working for you?
    I can't replicate the use-case above, cause the UI of the child prefab inside the main active prefab doesn't respond to input events i.e. a simple button click
     
  23. Carpe-Denius

    Carpe-Denius

    Joined:
    May 17, 2013
    Posts:
    842
    I think thats a problem with your setup, not with prefabs. Maybe something is blocking the path to your button.
     
  24. f4bo

    f4bo

    Joined:
    Oct 7, 2014
    Posts:
    21
    The problem I mentioned above seems related to what I discovered a well known Unity prefabs issue, as is, I can't have a separate maintenance of one prefab and a child prefab of it. To be clear, let say I have a cellphone main prefab acting as a shell and suppose it have button clones, all coming from another prefab, child of the cellphone; if I modify and apply the cellphone prefab and then I modify the behavior of a button and apply it, that last change will not propagate to the other buttons because the reference to their prefab is somehow lost. That was the source of my issue above: I changed the click event of what I thought was a prefab but that didn't apply.
     
  25. cygnusfear

    cygnusfear

    Joined:
    Oct 24, 2012
    Posts:
    14
  26. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    I didn't think much of this idea at first glance, why would you want subsections of a scene within a scene?

    But I'm in the process of moving a subset of game features from an older game to a newer one with Unity and ideally I would just like to be able to import the entire scene and it's sub components from one project to another.

    Maybe if scenes exist in a world (this would separate the elements of a level from the world it's in).

    And if these scenes allowed streamed loading and navmesh connections then maybe Unity should look at entire scenes as 'prefabs'.

    Or could a sub scene be viewed as a map, on a 'display' texture within the main scene or a scene comprised mainly of a menu/ui system?

    Actually that would be cool if I could take games I've made in Unity and have them as sub scenes in another game e.g. on a display in a virtual arcade.
     
    frosted likes this.
  27. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    I've actually worked pretty extensively with prefabs and I've worked with a nested prefab tool from the asset store.

    I don't really need or want more from prefabs. At a certain point the complexity is just not reasonable to manage and it becomes a mess. Prefab evolution does a very reasonable job at giving you tools to manage nested prefabs but I still ended up removing it from my project. What I really need is something more like what @Arowx suggests.

    Basically, being able to isolate functionality in different scenes, then compose these scenes together to make a full composite. (Yes, there is an asset that does this also, but it lacked some key feature I needed).

    In a composite scene, changes made to other scenes would work similarly to prefabs (in that those changes would be local overrides).

    Being able to isolate out more complex gui screens would be huge.
     
  28. cygnusfear

    cygnusfear

    Joined:
    Oct 24, 2012
    Posts:
    14
    We're using prefabs extensively in a system for procedural generation; this means basic assets are first created as prefabs, those are nested within other prefabs. Unity cannot maintain any coherent relationship between the original prefab and the now nested prefabs.

    Prefab Evolution solves this problem (as far a possible) but it mind-bogglingly inconvenient and slow as it has to go through all the prefabs in the project and when necessary relink them. In a large-scale project the tedium is lethal.

    Proposed solution is to stop thinking about 'scenes' as 'levels', but instead see them as nothing but a hierarchy of objects. Any scenes contained within (previously prefabs) are hard references to separate files with another hierarchy, something that can be edited separately. This is very convenient for a level editor working on the same map as artists (who can now simply update the scene 'Large_House', to get the changes into the map).

    So basically you want to disregard the whole notion of prefabs, a prefab is simply a scene. Scenes can be put in other scenes. Maybe the hierarchy of nested scenes can be viewed but not changed. Additional objects can be placed in that hierarchy but exist only in the parent scene.

    The user should be responsible for the proper way of nesting them; the current system is broken because users don't have a system that is singular in function.

    Kragh already explained properly above, seems to me like the only solution to maintain sanity.
     
    angrypenguin and laurentlavigne like this.
  29. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    1,085
    Who are you?
    Lead designer, programming/level design support on a small 4-5 person team.

    What kind of game are you trying to build or would like to build?
    Every Unity project I've worked on has begged for this. Our current project is a musical spaceship shooter.

    How do prefabs fit into that? What use-cases do you have?
    Prefabs fit in everywhere: space backgrounds, particle systems, player and AI ships, UI, etc. Our use-cases are the standard "building blocks made up of building blocks". Here's an explanation involving of each the listed items:
    • Space Backgrounds - Our artist would really like to build up some interesting collections of constellations and space dust. At some point, the natural thing to do is say "Well, I already put together the particle for that." Our artist will create that particle and then try to fit it in multiple different prefabs. The problem is that he may then later want to modify all of them in the same way but the initial prefab link is gone (as it had been added to other prefabs).
    • Particle Systems - This is somewhat outlined above but generally Particle Systems are added to many, many elements to add flair to one thing or another. On top of this, a certain "class" of flair frequently takes on a particular meaning and naturally we want to reinforce that by using it in different areas. The problem is that Particles get subsumed into parent prefabs, making further edits/optimizations/upkeep a nightmare.
    • Player Ship - We have different build-outs for ships based on weapon enhancements chosen by the player. Our artist frequently wants to build the different versions/variations. We have a mixture of modularity and evolution (player selection vs in-level bonus grants). Some levels even have different variations period. These frequently start with the same basic setup (bullet/missile/laser spawn positions are set/specified with empty GameObjects and it is a pain to have to set these up/maintain them for every object that changes other elements).
    • AI Ships - Our levels are broken up into encounters. These encounters are groups of enemy fighters whose movement/attack is coordinated through a central script. We would naturally love to have a set of "Enemy" building block prefabs that we can layout in a parent Prefab and just spawn them all at once. Unfortunately, we have to resort to specifying a prefab and then several empty GameObject "Spawn Points" in the Editor. At runtime, the Spawn Points are disabled as the enemies take their place. This means that we have to test in the Editor mode to see how things look rather than in the level. Next to Particle Systems, this is our most common use case.
    • UI - See: Everyone else's UI comments. We have (or will have) pretty much all of them (our UI is fairly monolithic right now and very heavy to maintain).

    What about the current prefab system isn't working for you?
    Our current workaround involves creating "Particle System" links that artists (or, more frequently, programmers) setup and connect to game objects that then spawn them on launch. This allows multiple prefabs to use the same, in this case, Particle System without requiring the artist to go digging. The problem is that the artist doesn't get to see how things look and tweak either the Particle System (he understands that it's a shared object) or the parent object to look right. Most frequently this results in a positioning/sizing problem.

    There are times that we figure "Meh, we probably don't need to worry about the prefab issue." This bites us almost every single time. If we want one of something, we inevitably want a variation or three of it. Building these once is trivial - maintaining them is really painful.

    Suggestion: Look to Flash
    Others have already suggested that the Flash MovieClip editing system be used as a model for how to edit/build nested prefabs. I've worked with Flash across many projects over the years (including Scaleform) and I completely agree with this. Even if the system isn't taken wholesale, there are many excellent design cues that can be inform the design of nested prefabs (e.g. fading out elements not int he current MovieClip layer and adding a small bounding box to the elements at the current layer; the MovieClip "Library" [you could argue that this is the Project window but it may be worthwhile looking into having a "Prefab Library" view/quick-filter to reinforce the "building block" concept]).

    Flash isn't perfect by any stretch but they've certainly spent ~20 years working with the problem.
     
    angrypenguin likes this.
  30. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    Who are you?
    Edy, developer of Edy's Vehicle Physics and Vehicle Physics Pro.

    What kind of game are you trying to build or would like to build?
    Games with vehicles (cars, trucks, etc).

    How do prefabs fit into that? What use-cases do you have?
    Vehicles are a rather complex set of components in specific hierarchies that must be reusable.

    What about the current prefab system isn't working for you?
    Lack of clearness and editing flexibility. In the prefab (Project window) I cannot edit the components beyond the first level of the hierarchy.

    There's no way to realize where a nested prefab is located. It's not clear whether "apply" affects some nested prefab, or merges everything into a single monolithic prefab. This means that there's no practical way for reusing parts in the vehicles. I can only make a single prefab per vehicle, with all components.

    These are my ideas on how prefabs would work in my own "ideal world":
    • Prefabs are building blocks in the scene: a hierarchy of gameobjects with configured components that can be reused.
    • A prefab can nest other prefabs in any part of their hierarchy.
    • The gameobjects and their components in each prefab must be fully editable in the Project window, to any level of hierarchy.
      This includes nested prefabs and their hierarchies. Editions can be changing property values, adding or removing items to lists, adding or removing components, adding, removing, or relocating parts of the hierarchy.
    • Dragging a gameobject from the scene to a prefab in the Project window would add/merge that gameobject and its descendants into the existing prefab.
    • Parent prefabs store the modified values in their immediate nested prefabs. This is similar to the scenes storing the modified values in the prefabs.
    • Prefabs must be clearly represented in both Hierarchy and Project windows.
      There must be a clear representation of the root prefab and each nested prefab. Drawing all them in blue is not clear enough. A possible way would be putting a blue cube icon in front of each root of a prefab, also for nested prefabs.
    • There must be a clear representation of everything that has changed in each instance of a prefab.
      This includes property values, lists, components added, components removed, hierarchies added, hierarchies removed (removed elements from the original prefab might be shown grayed and non-editable). This is applicable in both the scene, and in nested prefabs in the Project window.
    • Prefab operations (apply to prefab, revert to prefab) should be available at property level, component level (adding or removing components), and hierarchy level (adding or removing parts of the hierarchy in the prefab).
    • Prefab operations must be very clear of which object(s) are affecting to exactly. "Apply to prefab" or "revert to prefab" in a nested prefab should affect that nested prefab only.
    • Possible new prefab operations (right-click menu?)
      - "Merge into parent prefab", where the hierarchy of a nested prefab would become part of its parent prefab, removing the nesting relationship.
      - "Split to new prefab", where a part of the hierarchy in a prefab would be split into a separate prefab, creating a nested prefab in the original one.
     
  31. stepan-stulov

    stepan-stulov

    Joined:
    Nov 26, 2013
    Posts:
    28
    Hi guys.

    Old and painful topic, and I've already written about it but I have some new highly abstract thoughts.

    I think Unity should merge two old concept of scenes and prefabs into one new blueprint/prototype. Itshould support nesting, individual loading (including it's subtree of instances) and unloading and instantiation. Every instance of such blueprint should be a scene on its own containing instances of other blueprints etc. Unity app should start up by creating one instance of a specially marked root blueprint. Perhaps one per build target to have custom unfolding on Mac, PC etc. The instance's tree is then unfolded by depth-instantiating of all other blueprints or non-blueprinted game objects. Such instances can be placed there by mouse or via code. Perhaps there could be a special Unfold() method added to the collection of Unity's conventional methods like Awake() and Start() specifically for injecting your start-up code-driven instantiation. Of course later instantiation should be possible too.

    I mean if you think about it difference between scenes and prefabs is purely artificial and historical.

    This will solve the good old problem of nesting prefabs plus will remove all the hack-y nonsense a'la DontDestroyOnLoad.

    Yet again, endless inspiration can be drawn from Adobe Flash's movie clips which are nearly perfect conceptually.

    Not sure if there is not too much input on this topic already but felt like sharing:)

    Best regards,
     
    Last edited: Aug 9, 2016
  32. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Sounds like it would cry out for a node based editor tool.

    What about adding a socket and plug design pattern to prefabs. This way you can formalise/structure where and how prefabs link and are combined.

    Potential benefits mesh combining of static* prefab sections, with movable plug/sockets.

    Or static plug/sockets that allow full mesh combining across procedurally generated prefabs e.g. Castles / Dungeons

    Also plug sockets could pass component information and provide an interface between prefabs, potentially improving the component architecture and streamlining calls like GetComponentInChildren<>()?

    And even allow for powerups to automatically boost their root user prefab e.g. Health / Armour on sub components totalled across all plugin interfaces.

    It would need some debate on API and usage but it could really empower the Unity Component system if developed well.

    *static in that sections will not move relative to each other, e.g. Ships / Spaceships
     
  33. derf

    derf

    Joined:
    Aug 14, 2011
    Posts:
    356
    Also if the nested prefabs contain scripts that have public properties or serialized properties, the ability to see them ALL
    and each of them showing what prefab they are linked too so we can change them in the editor or review the current values assigned. Here is an example of a complex prefab object I had setup some time ago.

    Parent Prefab A displays 1 string property
    Parent_Prefab_A_Child Prefab A has two int properties.
    Parent_Prefab_A_Child Prefab B has 1 string, 1 int and 2 boolean properties.
    Parent Prefab B has no properties
    Parent_B_Child Prefab A has 1 float, 1 int and a sound file.

    Parent A and Parent B were two independent prefabs that I made into one Prefab object with Parent B a child of Parent A

    It would be nice to be able to click on the Parent A prefab whether it was in the scene or in the editor and see the current property values and be able to change them.
     
  34. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,225
    This thread is 2 years old so I'll keep my expectations low: how about just simple nesting by 5.6 and then when you switch to autodesk numerology, expose variables in Unity 2019 sp2 anniversary edition r5.
     
  35. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    Unity 2019 sp2 anniversary edition r5 +new bugs
     
  36. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    The last two posts in this thread are some savant level predictive powers.
     
  37. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,132
Thread Status:
Not open for further replies.