Request: Nested Monobehaviours + Hierarchy Folders + Monobehaviour Filters + Inspector Entities

Nested Monobehaviours + Entities + Stand Alone Monobehaviours stored as project prefabs.

Allow monobehaviours to be stored independently without being attached to a specific gameobject.

Gui: Monobehaviour without "Transform" component. Ie like scriptable objects gui.
Pros: Can now serialize Monobehaviours, not just gameobjects. ALONE.
Pros: This would unify ScriptingObjects, Monobehaviours and entities concepts as both would be "prefabs" +allow "ScriptableObjects" / entities to be stored on Scene (but wont have gameobject associated with them)

Reason/Need: efficiency of "make prefab" command of stand alone monobehaviours without incurring a gameobject creation cost. Currently, this results in "excess" redirection of "extra gameobject created" per prefab created.

Implementation: A monobehaviour fetches it's "Gameobject" by searching nearest parent above it. For efficiency, it is stored as "Gameobject reference class field on Monobehaviour". The pointer is updated automatically when monobehaviour is drag dropped elsewhere in hierarchy.

Pros: The scripting api view or it's performance wont be affected. Editor would guarantee that monobehaviours would find their gameobject automatically without user visibility or code changes.

MonoBehaviour Nesting. A monobehaviour can be "child of" another monobehaviour in the "Gui Hierarchy".

Gui: The scene hierarchy view now shows BOTH GameObjects + Monobehaviours. Before only gameobject. In additiion, entities and Scriptable Objects, can be added to scene hierarchy, and made prefab, their position on "scene hierarchy" is entirely ignored. For monobehaviour their position MATTERS, (nearest parent) "Acquires" the monobehaviour and holds it in his "child's list".

I propose "Fake Monobehaviour Nesting Navigation": The monobehaviour doesnt affect the the data layout/ iteratior order or "Gameobject" hierarchy (Code / Scripting / Performance wise ).

To the parent "gameobject" everything is stored as a list, without any "relations", it's just gui stuff. However for "Serialization" purposes. If you "prefab" a monobehaviour -> all it's children monobehaviours are prefabed as well.

As mentioned, with current request we would serialize monobehaviours directly, not needing to attach them to a gameobject.
Before: We had to create an arbitary gameobject, for "composition" purposes as a project prefab => Slower code.
After: Monobehaviours can be serialized alone and used as prefabs. They automatically acquire the parent "gameobject" depending on where they are dropped in scene hierarchy.

Rule: Monobehaviour's gameobject = nearest parent above it. "Autogroup". "Context Aware Parent Gameobject Find".

Lemma: "fake monobehaviour nesting" doesnt alter the "final" view / hierarchy / layout of gameobjects.

Example: User Code: "Folder Monobehaviour" - allows to group objects for gui reasons.
public class FolderMonobehaviour : MonoBehaviour {}

Usage: Folders are used to "prefabify" entire monobehaviour hierarchies.

Pros: PERFORMANCE.
Before: Inspector contained 1 gameobject with 1000 Monobehaviours. Which caused the unity editor to crash from rendering 1000 monobehaviours at the same time.
After: Inspector renders only 1 "SELECTED Monobehaviour" depending on which one is clicked on Hierarchy.

Example2: "Comment Monobehaviour" = string text. Again, it has no "code", just plain data.

Example3: Entities. We can now serialize entities without attaching them to "Gameobjects".
Idea: Special case so that "Entities" dont even have a gameobject or care to acquire one = true null.

Example4: ScriptableObjects in "scene" hierarchy.

Example: "Boss" prefab is a folder/monobehaviour that has bellow it monobehaviours
a)+100% max hp b)+ Immunity to debuffs.
Before: Impl1: Had to create 3 gameobjects if all those were "seperate prefabs" on project. Also the scripting api was "Corrupted" -> find all children done at runtime => Slow.
Impl2: 1 gameobject but had "ugly" side-effect of being HARDCODED prefab. I couldn't nest the "ImmunityDebuff" prefab. I had to inline it to the specific gameobject. This nerfs composability. Because i now cannot make a "regular goblin" prefab, a "boss". This corrupts the "prototyping" power of the program. "Boss prefab" was hardcoded to a SPECIFIC gameobject, therefore couldn't have "2 prefabs" cooperating together (Goblin + Boss).
After: Goblin = monobehaviour/folder + Boss = monobehaviour/folder. +"100% extra speed" stray monobehaviour can be "added to 1 gameobject" and automatically associate themselves. And become an inline "goblin boss fast" gameobject with 3 monobehaviours at runtime play mode.

Optional capacity: Monobehaviours with "null" gameobject. A special gameobject is created called "Null" with (0,0,0) transform to help groups monos and protect vs bugs. It Contains all ungroupped monobehaviours without parent. Null gameobject is created at "Runtime play mode" only. Implementation: At runtime, "Null" gameobject is the root of the scene. Thus all ungroupped monobehaviours without parent are by definition "child of null". Actually everything is "child of null". Since null is the root of the scene / world.
Implementation2: Actually not needed, if "editor" manages to forbid / guarantee that scene "root" is always a gameobject.

Proof that "Fake Monobehaviour Nesting navigation" has more power than "Real navigation". Altering the scripting view api wont give any more power. Why should unity pay staff for needless features that WONT BE USED. But for sake of discussion, i am mentioning the concept.

Scripters would get ability to iterate / navigate the tree formed by Monobehaviour Nesting. Easily easily emulated currently at runtime as ...
public class NestedMonobehaviour : Monobehaviour
{
public MonoBehaviour[] Monos;
}
//therefore pointless. Feature already present in current unity editor.
a. [Already Implemented] Stored as regular array. For those who want "Extra stuff". Eg order of fields to matter. Order in gui of arrays is important as it affects the "iteration order" of the array -> hence the behaviour of program.
b. Pros: Can already emulate "anywhere on graph relations" not just a tree (parent-child) => SUPERIOR.
Cons: for lazy people, it requires "manual drag drop" to fill the fields slots of the array. Not done automatically by "find all children". >Fix: Actually easy done as 'scripter' -> at awake() append all children to array => needless feature. Unity shouldn't enforce his "schema" at users. Better leave it "free". This is further proof, that unity shouldn't alter how scripters view "monobehaviours" of gameobjects. But as mentioned, should alter how monobehaviours are serialized to not require a "gameobject".

For Editor Addon Creators, capacity to "Navigate" nested monobehaviours as in editor view order, (not fake one) could be useful. However, this capacity won't exist in "build" / runtime.

So why would anyone need "True monobehaviour nesting navigation" ? Answer: We dont.


Extra Optional needless stuff: MonoBehaviour Filters: Specific type childs allowance only.
A monobehaviour descriptes a "Schema" of allowed children types, done via class attributes
Example: [AllowChildren(typeof(X))] , can have multiple such attributes.
Before: When you clicked to "add monobehaviour" the entire project was available => hard to search. Because anything was allowed.
After: Only a Specific subset of monos is allowed / visible => Restricts design errors + gives "a menu of allowed things".
Again... not important / needed, as we can do it "manually by hand". Assists only designers, not coders. It meanly helps in "productivity".


So would unity accept this feature? Standalone Monobehaviour Serialization + Unification of workflow (entity, So, Mono, Folders) + scene hierarchy gui changes

 

Can i have a unity official developer look into my post or answer about it? It seems my post is getting 0% visibility.

I realise unity is doing their best, and that their development schedule is tight, but having posts ignored without any feedback, especially when you consider them as pivotal change to improve prefab workflow is sad.

1. It would improve prefab "Composability".
Before: Only GameObjects can be prefabs.
After: Can prefabify a "collection of monobehaviours" without creating an intermediate gameobject.

This is not just for performance, as well for composability. By creating a GameObject, you are "LOCKING PREFABS" to a specific GAMEOBJECt => HARDCODED Prefab system.
Conclusion: Unity's prefab system is "too rigid" and "hardcoded" on a specific gameobject. This paradigm DISABLES MIXING PREFABS.

Yes, unity nested prefab system is powerful, especially for composition of meshes. (Mesh Composition Functionality not affected by Creation of gameobjects)
But REALLY WEAK for gameplay or scripting as it is "Disables mixing gameplay prefabs". (Monobehaviour Composition becomes LOCKED, you cannot mix scripting prefabs)

2. I am not saying that unity should drop what they are currently doing and implement this NOW.
But i want an answer or comment if unity is willing to put it on their roadmap after some years, don't care how many. Later is better than never.
I realize this is a big change, that would affect many users, and i want unity to get it RIGHT, on first attempt, and not "hurry" it = could lead to "broken projects".
Maybe reduce the scope to only monobehaviours at first, and then you can expirement to support other types "entities" / "Scriptable Objects" or not (discard needless extra features).
You could even introduce new concepts such as "Half GameObjects" if it speeds your development schedule.
A "half object" is a prefab that contains a list of monobehaviours without a gameobject specified but it is acquired from the nearest parent as "being part of".

3. Can a unity developer see this ? Should i repost it elsewhere / other forums ? Until i get an answer ?

Thank you, i am looking forward to your answer.