Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feedback A thread for features that Unity should have.

Discussion in 'General Discussion' started by PaulMDev, Aug 23, 2022.

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

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,018
    When old ones don't have to be maintained, resources are freed and tech debt lessens. They are not the same people, but they are distributed between the many solutions Unity has for the same thing. Also, while the old systems remain the go to for so many years still, there's no pressure or incentive to finish the new systems in a reasonable timeframe. Packages get marginal improvements over time but there's no push to get these systems to actually replace the defaults. They forever continue to be another option for specific scenarios.

    I don't subscribe to the idea that more engineers == quicker development either, but I know for a fact that many packages are maintained by skeleton crews who could definitely use an engineer or two to fill in the ranks. I don't know where the issues lie, could be anything from internal process structure to inept management, to hires disproportionally going into sales and other secondary roles.

    Unity has become unfocused and slow. I want increased focus and quicker progress on the new systems that, given the time frame, should've been in a far better state.
     
    Deleted User likes this.
  2. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,498
    Maintenance of the old is significantly cheaper than development of the new.

    And that's a good thing.
    It is not right to push your vision of glorious future down customer's throat, because they might get fed up and leave.

    Making new systems the default is not the right idea, and effectively undermines unity's strengths.

    Old packages you want to nuke are tried and trusted systems t hat has been proven to work more or less predictably.
    New packages you propose to push in their place is untrusted unstable mess.
    Even if you drop the old and focus on the new, there will be years if not decades because your glorious vision of the new focused unity will have a chance to become reality. Because those things take time and have inertia.

    And during that time people will be left with broken engine. Meaning they'll be switching to competitor's products. That's because people need things done NOW. And not in the future.
     
  3. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,769
    Technical debt doesn't refer to an old system existing alongside a new one.

    https://en.wikipedia.org/wiki/Technical_debt

    When I referred to "same people" I meant "same qualified people". Someone qualified to maintain a system isn't necessarily qualified to actively develop a new one. The legacy animation system for example doesn't necessarily need someone knowledgeable in animation systems to fix the occasional bug.
     
    Last edited: Aug 26, 2022
  4. thelebaron

    thelebaron

    Joined:
    Jun 2, 2013
    Posts:
    843
    I do want the removal of obsolete fields for camera collider rigidbody etc. Are people still upgrading projects from unity 3 or 4 when these was a thing?

    Also a feature I would love: option to build a project with uncooked assets. Let my players mod in whatever replacements they deem fit.
    I don't pretend to have a full grasp on how Unity translates assets into the library and how much of a pipe dream this is, but I really want this feature.
     
  5. PaulMDev

    PaulMDev

    Joined:
    Feb 19, 2019
    Posts:
    69
    I'm not familiar with this, but I think that this is what you're looking for : https://docs.unity3d.com/Manual/StreamingAssets.html
     
  6. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,952
    Not really the same although can be used that way I guess

    Really the way to do moddable content is either through asset bundles (very limited) or to actually have the ability to import content at runtime (something like trilib)

    We have opted for trilib + onejs and combined you can build a very robust modding solution
     
    PaulMDev likes this.
  7. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    Have I said this in here already? I lose track.

    Natively maintained cross-scene references and global object IDs.

     
  8. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,952
    Its kinda funny that we (still) dont have an easy to use global object ID system, when under the hood they are use GUIDs anyway. Its like 50% of the work is already done :p

    Cross scene referencing is also something that feels so wrong to have to implement a custom solution for, seeing as I need it in every single project I have ever worked on....:rolleyes:
     
    Deleted User likes this.
  9. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,638
    Not sure I understand that request; what would that look like? I mean something still has to hold those references, so you would still need an object that is marked to not be destroyed on scene change and objects marked like that already do have a persistent global reference.
     
  10. kaiyum

    kaiyum

    Joined:
    Nov 25, 2012
    Posts:
    686
    I wonder the usage of these.
     
    DragonCoder likes this.
  11. Saniell

    Saniell

    Joined:
    Oct 24, 2015
    Posts:
    186
    Scene objects do not use GUIDs but local file IDs. I'm guessing there is no guarantee that those won't overlap between .unity files.

    Extremely useful when working on projects that have multiple additive scenes
     
  12. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    The thing that holds the references should be Unity.

    My current system has what is essentially a Dictionary<GUID, GameObject>. Any object with a global reference component adds itself to that list on creation, removes itself on destruction. Any object can have a "soft reference" to any other object which works via its ID, and will return "null" if the target object isn't currently loaded. That's the guts of it, though from there Unity can do optimisation and quality-of-life stuff far more easily than we can externally.

    As one example of that, as @MadeFromPolygons says, Unity already gives everything an ID, so when we roll our own we're doubling up on that, where ideally this would just extend upon it.

    I imagine that instead of adding a Component and then doing everything via that Component, instead we tick a box on the GameObject which opts it into the global ID list. After that, per the reference implementation someone at Unity already made, it's just another type of variable we can add to our components.

    In large / complicated games it's not uncommon to have functionality spit over multiple scenes. One for the player objects, another for the GUI, another for the world. Things in those scenes commonly need to communicate with each other, sometimes with a specific other object.

    If your game has a sufficiently large world then there's a good chance it's split into multiple scenes. Even without that, some studios have multi-scene workflows to keep art, mechanics, etc. separate from one another to reduce conflicts when multiple people are working on stuff. In those cases it's pretty common to have, for instance, a switch in one scene unlock a door in another, or a quest refer to an item in a room which may or may not currently be loaded.
     
    Last edited: Aug 30, 2022
    Deleted User, Ryiah, NotaNaN and 3 others like this.
  13. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,381
    Much as I love my scriptable objects, I would love a cross scene referencing system too. I mean, it's a PITA just making a seemingly simple as transitioning from one scene to another. I've only been able to do so with scriptable objects.

    We know why we can't: 'scenes' are just representations of what a scene should look like when its loaded; the loaded scene just being a copy of everything defined in the scene asset. For that reason you can load the same scene multiple times.

    One solution that comes mind is being able to mark a scene as 'standalone', or something that denotes there shall only ever be once instance of a scene (enforced by the SceneManager). That way its objects should be able to be referenced without the potential conflict of another scene being present.
     
    Deleted User likes this.
  14. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,952
    Yes completely correct, I used GUID a bit sparingly here when really what I meant is generated ID rather than globally unique id.

    But you totally get what I meant, the key thing is there is an ID system under the hood and it feels like its almost doing what we need but missing some key changes.

    Right now my solution is basically same as most peoples, GUID < > Something dictionary to help say "this is the thing I want and I dont care what scene you live in"

    Its simple to implement, but thats why its weird its not in unity by default when so many larger scale projects end up doing this.
     
  15. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,638
    If one doesn't like the "DontDestroyOnLoad" workflow, there's always the possibility to have a "setup" scene with all objects you want to maintain and then just load and unload the actual game scene with the "LoadSceneMode.Additive" mode...

    If such a scene-independent lifetime system would be implemented, it would also require some extra GUI window because you cannot see what exists otherwise.
     
  16. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    An object should probably have to opt in to cross scene referencing, so I think it's fine to leave scenes as they are, and raise an error if you do something invalid such as try to load the same "unique" object twice (by that method or any other, e.g. as a prefab). Our home grown solutions can't reasonably prevent it either.

    Another reason for opting in is that it allows keeping an index of the objects and, for the Editor, their names and references to their scenes. That's useful for a couple of reasons. First, I find it really useful to be able to both see what a ref points to and navigate to the referenced item. Second, I want to be able to see if a soft reference is valid, and for the Editor to tell me it needs to know if the object exists. I do this by maintaining a list of all cross scene reffable objects in the project - add to the list when the component is made, remove from it when destroyed. So my Property Drawer can check the list and tell me if the ref is busted, which is great.

    But, maintaining that list is a little tricky. What if I delete a component but don't save the Scene? What if I add one, save, then revert via version control? Last I checked there was no way I could find to detect some edge cases, so I have a "Rebuild Index" menu item, and we get by. But Unity could address the whole thing properly, once, for everyone.

    One other thing: the unique ID needs to be accessible so we can use it for other stuff if desired. Ours are also used by our saved game / world persistence system because, again, why double up? Also it'd be great if it's settable, so that if you replace one object with another you can move the ID from the old to the new.
     
  17. IllTemperedTunas

    IllTemperedTunas

    Joined:
    Aug 31, 2012
    Posts:
    780
    Couple things I would LOVE to see in Unity. So many times I just want to collapse everything in the heirarchy, and it's painful to have to scroll all the way to the top, hold alt, and click the collapse arrow so the scene can go back to being compact:


    Secondly, we have this new undo history list, it would be AWESOME, if we could right click something in that list, and instead of undoing to that point like it does with left click, if the engine SELECTED the object from that action slot instead without undoing. This would help with that sense of, "where did that thing go i was just working on a moment ago"
    upload_2022-8-30_7-2-10.png

    Edit: I just remembered one more thing. The ability to toggle on objects if we want them to show up in the inspector at all. In any given scene, there are 2 types of objects, things you want to select, fiddle with, adjust things, move them up and down in hierarchies, etc. And then you have THOUSANDS AND THOUSANDS of rocks, of trees, of pebbles, of various doodads scattered all over the scene that just take up massive amounts of space in the hierarchy tab. What if we could label these objects as "doodad" or some facsimile, then toggle if we want to see "doodads" in our scene hierarchy at all.

    It would be so incredibly liberating to be able to select objects, move them around, but not have their footprint clogging the hierarchy at every stage of development. The % of time I am interacting with rocks, needing to move their position in the hierarchy, etc is VERY small, yet their footprint in the hierarchy is massive.

    This would be different from tagging their parent object as unselectable. We would still be able to select them in the scene, move them and rotate these objects, we simply wouldn't see them selected and visible in the hierarchy when doodads are disabled.
     
    Last edited: Aug 30, 2022
  18. PaulMDev

    PaulMDev

    Joined:
    Feb 19, 2019
    Posts:
    69
    +1 for both !
     
  19. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,042
    Actually, here's another one.

    Using the editor when you have multiple monitors becomes absolutely ridiculously cumbersome if you want to have some editor windows on another monitor while also having a reference open in another program on another one. Let's say I have the main editor, hierarchy, inspector, and asset browser on one monitor. Simple enough. Now let's say I put Amplify Shader Editor or something on another monitor so I can easily view changes to the scene as I edit a shader. I would say this sort of setup is a reasonable use case.

    So I'm working on the shader and, on my main monitor, I have maybe a whitepaper describing how something should be implemented in the shader. I want to keep this open and visible while I start plugging in nodes so that I can ensure everything is in place while I work. Unfortunately, the absolute moment you click on any editor window, it brings every other Unity window to the front. The only solution for this is to use external software like DeskPins, but sometimes the way Unity handles things makes those things just sorta break.

    What would be nice is either a button to bring all Unity windows into focus on spawned editor windows or a button that would allow us to prevent certain windows from being yanked to the front when any other window is made active.
     
    angrypenguin and PaulMDev like this.
  20. PaulMDev

    PaulMDev

    Joined:
    Feb 19, 2019
    Posts:
    69
    DevDunk likes this.
  21. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,638
    There's this really useful asset that goes even a step further: https://assetstore.unity.com/packag...button-shortcuts-and-selection-history-228013
    Effectively allows you to jump around through your project just like you would in a code editor (using the back and forth must-have-as-a-programmer extra buttons of your mouse).
     
    IllTemperedTunas likes this.
  22. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,477
    A future-thinking LOD system.
    HLOD, Nanite tech, whatever; anything to make things actually scalable and remove the pains of manually creating LODs. Epic have hit the nail on the head with tackling this issue and realize current expected workflows are such a big content pipeline money and time sink.
     
  23. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,884
    There is a HLOD system on git from Unity. Not perfect but something.
    Also a nanite competitor in the works from a 3rd party developer.

    Not perfect and would love to see an official proper implementation as well. The reduced draw count is awesome for mobile especially if dome properly
     
  24. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,477
    Which HLOD system are you talking about specifically? :p Completely different Unity teams have made 4 different HLOD systems; most are abandoned (owner left the company, etc) and not owned by R&D to be a first-class citizen technology. I tried all of them on Gigaya and only 1 got slightly better LOD performance but required me to fix some bugs in the code and was a big restructuring of content to get it working. Compare this to Nanite where you literally tick a few boxes and it works.

    And i'd like to see Unity make their own nanite-competitor (or equivalent) and it not left to an entirely separate third-party person/team.
     
  25. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,884
  26. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,477
    Neither are an official HLOD system of Unity. Both were made outside of R&D as side-projects either for experimentation or as a custom extension tool. The developer of AutoLOD doesn't even work at Unity anymore.

    Source: Trust me. I lost count of the numbers of times whilst I was working at Unity that I flagged the needs for a serious strategy for LODing systems. I also spoke directly with both the owners of those tools you listed whilst we were evaluating tech for Gigaya. ;)
     
  27. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,884
    Fair enough.
    And didn't know that you worked at Unity. That explains the better insight :p
     
  28. Rotary-Heart

    Rotary-Heart

    Joined:
    Dec 18, 2012
    Posts:
    809
    Interesting, I hate this feature from Unity on Mac. Didn't thought that someone would like it
     
  29. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,952
    Anyone you see on here with "unity legend" are past staff that were likely let go by unity (for very badly thought out reasons, I might add)
     
    DevDunk likes this.
  30. PizzaPie

    PizzaPie

    Joined:
    Oct 11, 2015
    Posts:
    104
    -Global scripts would be nice with the ability to serialize value properties and asset refs.

    -Scene root game object with the abitility to add scripts to it or at least be there to enable/ disable whole scene. (force all scenes to have a root gameobject)

    -Ability to load additive scene with the new scene been disabled once loaded (root object disabled).

    -Dyncamic lighting on additive scenes is a pure pain. Would be cool if it is possible to use some global settings for directional light that affects all scenes or something like that i really don't know what i want here but it annoyes me that lights turn off between scenes or flicker for couple frames.

    -Package manager (specifically for packages from asset store) give option to import on any folder within assets directory and not only the root.
    FORCE CREATORS TO MAKE THE ASSET WORK FROM ANYWHERE.
     
    PaulMDev likes this.
  31. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    3,013
    For large 3D projects, UE5's Nanite and Lumen are must have features. Unity should try to add comparable features without delay. Look at the UE5 Matrix demo, and then imagine how many workarounds a game developer would need to use to try to build something like that in any version of Unity. With UE5, a game developer can build a large 3D world by kitbashing movie quality assets, and UE5 can handle it using Nanite and Lumens. With Unity, game developers have to generate lower quality game ready assets.

    Unity should also finish existing features like DirectX 12 support. Unity has been fiddling with experimental permanent preview DX12 for years. Unity's DX11 support is production ready, but Unity's DX12 support seems to never quite be ready. By contrast, UE5 literally requires DX12. DX12 support is something Unity needs to immediately catch up on.
     
    Deleted User likes this.
  32. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    You can access the Scene object, and get a list of all root GOs from that. It really shouldn't be a GameObject itself, as they come with significant overheads.

    I agree it's be nice to be able to attach scripts to the Scene itself.

    I strongly agree this should be an enforced standard.
     
  33. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,477
    You should install Godot. :)
     
    MadeFromPolygons likes this.
  34. kaiyum

    kaiyum

    Joined:
    Nov 25, 2012
    Posts:
    686
    Or UE. ;)
    LevelBlueprint is the closest I can think of this.
     
    MadeFromPolygons likes this.
  35. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    is it not trivial to make a class and define its lifespan to coincide with something like a level, or the game session?

    I had assumed UE's game framework classes had direct corollaries in other engines, or at least corollaries could be made easily.
     
  36. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,381
    Depends what you mean by 'level'. In any case it's pretty trivial in Unity.

    Game objects live and die in scenes; that's their lifespan. Static classes and scriptable objects are valid means of having data last longer periods of time.
     
  37. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    @spiney199

    level = map = scene

    @PizzaPie is talking about a static class that lives with the scene and knows about all game objects in the scene - but our very own unity hero suggest you need another engine for that.

    @kaiyum made some sort of UE gameplay framework plugin for unity. Is there a level blueprint corollary? What's involved with that? A level blueprint loads/dies with the level/scene, and it knows about what gameobjecst are in the scene (it must get updated at design time dynamically when we drag things in and out).

    Is that not something that any programmer can do, or does it require source access? Or is it involving deep engine mechanics only an expert would know about?


    a few related notes of interest:
    in UE I've never used the level blueprint. I am not sure what problem that it solves, and it is not as readily accessed as other classes like the game mode. It is also not super clear what the responsibility of the level blueprint is to me.
    Adding to my own ignorance, I've seen quite a few people mention that it's not generally recommended to use. However, it must have some viability if programmers went to the trouble to create it.

    I just mention this so that maybe, if somebody feels inclined, they might expand upon what utility they seen in a class like this, and maybe that could help answer questions about why or why not it doesn't exist in unity by default.

    edit: on further thought, i suppose a level/scene-related-class would be a great place to store events that will only happen in a specific scene. Like a cinematic or something unique like that.
     
    Last edited: Sep 1, 2022
  38. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,381
    You really don't. You can easily hook into the SceneManager's events and be informed when scenes are loaded. A 'static' class that lives with the scene doesn't make sense, mind you. That's what a singleton is for, but that runs into their own problems.

    Really it depends on what you're doing.

    As was sort of mentioned by the penguin, there is the SceneInstance struct that you can get via traditional scene loading, or addressables, should you need a reason to have access to that sort of data. I can't think of a reason off the top of my head.

    But it's certainly nothing advanced and definitely nothing that needs source access. Again, I don't see why you'd need some singleton entity to live and die with the scene when every game object inside it already does that.
     
    DragonCoder and BIGTIMEMASTER like this.
  39. Deleted User

    Deleted User

    Guest

    More importantly unity needs a complete system of tools which can
    1) merge multiple meshes and materials into one drawcall,
    2)texture atlas creator to merge many textures into one to reduce disk space and can automatically adjust UVs of the mesh accordingly,
    3)Out of the box mesh simplifier,
    4)material baking from shader to reduce the overhead of complex shaders like procedural textures (necessary for mobiles),
    5) A complete Impostor generating tool....extremely important tool for all types of games!! Don't know why unity is ignoring this!!
    Unreal engine has all of these tools out of the box!! These all are very basic and necessary optimization tools which unity lacks and are much more necessary than nanite because nanite still requires these tools to save memory and to scale down!! These tools, alone are enough to create ambitious games inside Unity!! If DOTS team isn't working on these than they are creating an incomplete pipeline for creation of AAA games and isn't solving majority of pain points which standard unity has!! Very interesting thing is that unity has all these tools, a very powerful system of all the tools i mentioned above which works out of the box and easily within few clicks and optimize memory, CPU, drawcalls etc of entire scene.... The tool is PIXYZ, but sadly unity wants to keep it behind a heavy paywall and only wants to integrate it inside their paid services :(!!!
     
  40. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,952

    Rolling your own "static class that holds info on all objects" or similar structure to get something similar to UE or Godot sounds like a good way to create accidental performance issues. This is not something that should be done at c# level but c++ level in unity if its to be done properly like Godot or UE handle it.

    So as always ,yes we can roll our own like with everything in unity, but it may not be anywhere near as good/performant/X as having it built into the engine.

    That said as has been said by others, hard to see why you really need this
     
    BIGTIMEMASTER likes this.
  41. kaiyum

    kaiyum

    Joined:
    Nov 25, 2012
    Posts:
    686
    This is what I see on Level Blueprint:
    It should contain logic related to a specific level. Suppose that Level A has a specific set of events that occurs in a quite unique fashion related to Level A. A very good chance would be cinematic stuff. Then I would utilize a level blueprint for that. This would be logically right and anybody can open up that level blueprint to know what is going on at "that specific level". So if the level blueprint has nothing in it, one can easily get the point that there is no specific stuff about that particular level. Level blueprint has some connection in level streaming but this role is yet to be cleared to me.

    I implemented this idea with the polymorphic class "GameLevel". There can be only one instance of this class per level, editor validation tools(not done yet) will make sure there is only one. It can have some common functionalities like:
    1. Pause/Resume the entire level
    2. Custom time dilation of all actors
    3. Time reverse of all actors
    4. Playing cutscene, auto play start and end cutscene if configured. Setting level behavior while playing cutscene.(would continue to tick or not, tick which and which actors, etc).
    5. Tick the normal and physics update of all actors(since in unity physics is separate unlike UE). A bonus implication is reordering the execution order of actors as I like.
    6. Handling of logging and uploading them to a web service if configured properly in setting
    7. Error handing. (i.e. if a Klog.Check(...your code....) throws then the level would stop ticking or continue?)
    8. Event of when gameplay started and ended, when the level started and ended. Configuring how to end levels, if the ball moves upward 50 meters and hits the bar, play end cut scene automatically and end this level for example.
    and so on.

    Since the game level is a polymorphic class, you can extend and make your own custom class. Even better, if you see a polymorphic game-level class rather than a built-in Game Level class, you would know that this level has some particular stuff!

    Since Unity favor component based design heavily and tries to cover as many use cases as it can including non-Game stuff, I understand that it must offer flexibility. This is also the reason I could implement certain UE ideas within unity.

    But at end of the day, my goal is to make games for certain platforms. From my experience, I have seen certain code architecture(like UE's gameplay framework) help build large and complex games that can be managed by large dynamic teams for a long period of time. Establishing certain conventions might help manage the game logic. Level Blueprint just helps in that. You can hide the entire level-specific complexity in a graph that can be read by the designer and this looks awesome!

    Having said that, I think the Level blueprint also exists for historical reasons.(UE3/UDK kismet)
     
    tatoforever and BIGTIMEMASTER like this.
  42. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    what is the alternative?

    if we are using a composition approach, we might have some gameobjects whose responsibility it is to trigger a cinematic event or some sort of event specific to the level. maybe a big door opening or something like that after you killed X bad guys.

    If you accomplish this through composition, is it just more difficult to "see" how that series of events is taking place?

    If that is true, is a simple workaround just to keep a project wiki/documentation which can hold onto human friendly notes and overviews?
     
  43. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,042
    I kinda disagree with all of these as suggestions because ultimately this all comes down to the architectural needs of a project that should be handled on the dev end, not engine side.
     
  44. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,381
    Yeah a few of the feature requests seem useful for folk's particular projects and personal styles, but not in general. Which, while nice... probably not the best use of time on Unity's behalf.

    But things like what @EagleG has suggested are absolutely things Unity should be able to do. As much as I see Unity as a framework, it really should make the underlying graphics stuff as painless as possible.
     
  45. kaiyum

    kaiyum

    Joined:
    Nov 25, 2012
    Posts:
    686
    Gameobject or component should not directly trigger cinematic events. They should call the method(i.e. CheckDoor(Gameplay tag)...) on the level blueprint or extended Game level class(if you consider my framework. Here it should be extended because this particular cinematic is applicable to this specific level and is absent in builtin GameLevel class, you can reuse the same class you made for multiple alike levels unlike UE where you have to copy-paste all the nodes to reuse).

    The level blueprint or Game Level inturns should handle the custom cinematic event. So from a high level perspective, entities or actors of your level just check and tells the Game level to decide what to do for the level. This also makes sense in a way that an entity or actor has a responsibility to check(or sense or request) for something, but what to actually do(that affects the entire level) should be handled by a thing responsible for the entire level. In UE it is the level blueprint. In my framework, it is Game Level.

    So here you would use inheritance(since you have to extend the built-in game level class or modify the level blueprint in case of UE) rather than composition. If you use mostly composition for gameplay, then also this approach has added benefit. Because in component-based design, ideally, your components contact level blueprint or game level. And in the inheritance with composition, your actor can just do that. I prefer the latter one. Because actors should know the components it owns and communicates with them. Components should only know the actor that owns them. Actors in turn can refer to other actors; or better, level blueprint or game level. In this way, I can have a good separation of concerns.

    As for wiki or documentation, I like this approach: Two architectural docs, one for the tech team; one for the design and art team. They look like one or max two paged diagrams or simple text in such a way that everybody in the team can get a basic understanding. But the technical doc should be fully understood by the tech team. These docs should not contain detailed information. Take for example UE's gameplay framework's architecture:
    upload_2022-9-2_10-5-44.png
    The doc does not say that the game mode class does not exist in the client. Nor does it say that you can not assign a level blueprint for a level. Nor does it say Orc boss dies in level 10 after a death blow with a green sword only. Putting those details into a doc is problematic since games can be pretty complex and people in the team might be dynamic. It can be overwhelming to frequent changes. But architectural diagram changes relatively less time.
     
    BIGTIMEMASTER likes this.
  46. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,477
    Yes, Unity needs all of these things to make asset and content creation scalable and smoother.

    But Unity would only build any of them (see also: any corporation building any product) if it sees the addition of it as a direct business advantage and/or revenue stream. Need to see a clear path to the $$$ before they invest the $$. This is why Epic invests so much in UE5 for Fortnite; there is a clear return in improving the game and keeping it alive.
     
    Last edited: Sep 2, 2022
  47. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,638
    Is that in principle possible?
    Unity already batches static meshes when they have the same material and thought that limitation is because GPUs can simply only handle one material per mesh.
    That limitation is largerly in place even if you use the low-end rendering Methods (DrawMeshInstancedIndirect).
     
  48. Saniell

    Saniell

    Joined:
    Oct 24, 2015
    Posts:
    186
    You can have 1 draw call per pipeline state if you use bindless resources. Merging meshes using compute shaders is not a new thing either (AC: Unity has it)
     
  49. Deleted User

    Deleted User

    Guest

    Its different!! The tool can merge multiple meshes with different materials into single mesh with single material and therefore making it one drawcall and reduces memory.... And on top of that if u use mesh simplifier with it u can use it as HLOD or use it with scene streaming to swap out your highpoly scene with this!! All this is very necessary for memory management and reduce CPU/GPU overhead
     
    DragonCoder likes this.
  50. vertexx

    vertexx

    Joined:
    Mar 18, 2014
    Posts:
    367
    A thread for features that Unity should have.
    Looking through the other lists and threads it appears that having a "stop" button is a popular request?
    Would this be considered a "feature?" Do any posters here think it's a good idea?
    It would be a good thing for Unity if there was just the one thread for this subject! But maybe it would extend to the end of the universe.
     
    angrypenguin likes this.
Thread Status:
Not open for further replies.