Feedback A thread for features that Unity should have.

Ok so pretty much everyone here agree that Unity is missing some features (obviously a perfect software is impossible so that would always be the case), but not everyone seem to agree on what is the most important thing to add to the engine (mainly because everyone use Unity for different project with different workflows and don't struggle with the same things).
So I've made this thread to talk about that, both to better understand the needs of others developers and also to help Unity staff understand the features that we need, why we need them, and also to discuss about it.

So first I have to say this : Unity is a really good engine and you can make games with it. So no need to dramatize the situation by saying that Unity is unusable without this one feature that you want. These are just things that would be nice to have to make game development easier.

Also I prefer that we only talk about the features that we need. We are not talking about the Unity company (there are already enough threads for that).

Also also that I don't know at all what I'm doing by creating this thread (I was just bored) and I don't have a great experience with Unity I'm just a student. Also my English is meh, so sorry if i make mistakes.


And with that being said, here is my personal list of stuff I would like to see in Unity for 2023 LTS or 2024 LTS :

-Graph tool foundation : I'm putting this one first because I think that one of Unity's greatest strengths is its flexibility. Being able to make your own tools is a great way to speed up game development, and nodes are cool. I hope the team behind it is progressing well and I can't wait to start using it.

-UI Toolkit : Technically this one is already out but I put it here anyway because for me it is not yet fully usable in production. The old UI system is really not practical so I'm very happy to see that there's a new one (especially since UI Toolkit has a lot of potential) but so far it's missing too much stuff.

The biggest issues I noticed:
-No world space UI
-Can't have gameobjects in UI
-No way to keep the aspect ratio of an element without programming it yourself.
-Text don't change font size with %
I'm probably forgetting a lot, so feel free to add more below.
​

-Animation : The animation workflow is really frustrating and confusing. Even when doing the animations in another software, you must necessarily use the animator at one time or another. The graphs are a huge mess when it has more than a dozen animations, the connections to the code are meh, and the transition system is really clumsy. Really, make a new one soon please.

-Scene management : Communication between scenes is annoying. And scenes have to be referenced by name or id which is really not practical.

-Tags and layers : An object can only have one of each (which is not practical since we often want to be able to get a lot of information about an object (can we shoot it, can we interact with it, should it be attracted by magnets...)) and they have to be referenced by name which is not practical.

And it's already a long post for me so I'll stop there. That's enough English for today.

Feel free to criticize my list and remember to be nice and don't get upset for nothing, we're just talking about features and workflows.

 

UI Toolkit lacks a way to have tweens and other behaviours affected by timescale.

 

well none of that is going to change so maybe more productive is explain workarounds you used to overcome some problems?

that might help other people.

 

There isn't a way around things like UI Toolkit's lack of worldspace UI. The "workaround" in that case is "lol just use UGUI"

 

Addressables makes this easier, as you can just reference scenes by addressables references. Yes the package has many issues, but for just simple content loading it works fine.

At the end of the day if you wrap your scene references in objects... say, Scriptable Object, it becomes a lot easier to manage.

Sorry but Unity is a component based/OOP game engine. If you want more information on an object, put more components on it that hold this information. There's no limit to the amount of components you can put on a game object.

 

I make 3D world based UI's all the time. I use gameObjects, colliders and raycasts. Sounds like OP wants a CSS/html style sheet in 3D. OP needs to understand Unity is a component based, frame dependent architecture..not OOP and certainly not javacript or html/css.

 

I mean... Unity's component architecture is just a layer built atop of traditional OOP inheritance. Monobehaviour is the great-great-great grandchild of UnityEngine.Object. And obviously standard OOP practices can still be incredibly powerful even in the context of Unity.

Any time you use scriptable objects as socketable behaviour, that's OOP at it's finest!

Tags are basically as bad as enums. They hold no information and you can only react to them.

 

"Inheritance with composition"---I love this motto and this helps me building bigger projects. I also hate unity's way of handling animation, collision and multiplayer. You have also mentioned tags and layers, yes this should also be problematic and unity should do something about them too. Does not have enough experience on UI toolkit, but for UI, lets talk a bit more later.

Animation: I wanted a UE like workflow and to control the animation, mixing them with scripts. There is nothing like in unity AFAIK except Animancer and the library I built: https://github.com/kaiyumcg/Vortex

Tags and layer: I wish unity had hierarchical multi tags for gameobjects and components separately(like UE has). My solution for that: https://github.com/kaiyumcg/KTagSystem

And I wrapping my head around to get the solution for collision and multiplayer. I really love UE's multiplayer's architecture. For collision, it seems I have to r&d more to get spot the problem(s) deeper.

And lastly, I do not like Unity's gameobject-monobehaviour architecture. So I rolled out a thing of my own: https://github.com/kaiyumcg/KAction
It works on top of gameobject-monobehaviour and an attempt to correct the architecture to employ "inheritance with composition" style.

In short about KAction: The game consists of multiple "GameService" and GameServiceManager manages them. The game also consists of a number of GameLevel. Each "GameLevel" has a number of "LevelModule". There is at least one LevelModule called "ActorLevelModule". ActorLevelModule manages execution of a bunch of Actors. ActorLevelModule handles pooling of actors and registering them and the execution flow of actors. There are a bunch of builtin Actors; Actor-->ReactorActor(knows physics information)-->CharacterActor-->PlayerActor-->AIActor.

Inside Actor, there is a list of builtin components(Animation/Collision/AI related) and custom GameplayComponents. Actor handles execution of components. Only GameServiceManager and ActorLevelModule are sealed classes. Everything you can extend and customize yourself.

Anyway, I wish unity had something like this from day one.

 

@kaiyum

Did you just make... Unreal... in Unity?

 

well, I like many aspects of unity and I also love many stuffs about of UE. My certain projects have to be made in unity due to many reasons including C#, HR etc. So I tried and still trying to get the best out of UE to implement it inside unity. Obviously, many stuffs just can not be done due to each engine's core principles. Also I had to think about performance. So ya, kind of

 

Per scene or even per prefab occlusion culling.
Don't force me to load multiple scenes to bake occlusion culling for them, so later they can be loaded additively.

Per prefab lightmapping.

 

This forum needs "love" button in addition to like.

 

Unity had a janky semi broken version of per-prefab lightmapping floating around the forums, but surprise surprise, it never became an official solution.

That was like back in 2016/2017, its crazy to think they still dont support this despite knowing the use cases that require it.

Its pretty much impossible to do baked lighting in procedural/dynamicly generated content based games right now without some seriously hacky workarounds as a result.

 

I haven't tried addressables yet. I should probably give it a try.

You're right that's the workaround yet, but searching through every objects in the scene for this one component is really slow and I think that GameObject.FindGameObjectWithTag() is faster(?). If that's the case then having multiple tags would be great.

I haven't work with UE enough to exactly understand what you're talking about, but it's great that you made the tools for people who prefer this kind of workflows. Also, again : Flexibility ! I don't think that you could do this kind of tool to have the Unity workflow in Unreal, so that's a win for Unity !

YES PLEASE !!!
Occlusion culling and baking in general needs a lot more love.

 

You shouldn't use Find or it's sibling methods at all.

There's infinitely better ways to architect your systems.

 

yeah i am wondering about this as well.

i know intent of the thread is just general griping and not actual problem solving, but maybe something useful could actually come of it now that cat is out the bag.

I wonder what sort of situation demands polling the entire scene? Is there no way to pre-filter or make a more accurate query to begin with?

 

I still need to improve my workflows so you're probably right.

I don't know. I created this thread to talk about Unity features not workflow preferences. Maybe someone should create a thread about that, or maybe Unity should share some workflow tips.

 

Unity tried to make a game recently but wouldn't finish it. I'd look out for the developers who have found ways to finish work in unity. What is their strategy and workflows?

Seems like some people here could lend a few tips might be handy and using the tool in efficient ways versus non-efficient I think is beyond a word like "preference."

anyway, i'm just repeating myself but a thread like that would be what i'm talking about in the first place: I have a problem here's how I solved it; or I have a problem, who can help me solve it?

In case you don't know, unity is not reading individual threads on forums and making an action plan from it. Just ask @Murgilod. So if you are trying to solve some problems, peer to peer help is pretty much only way.

(and no, its not just Unity. No huge game engine corporations are watching random threads on forums, usually posted by beginners, to figure out what features they should add next to the billion dollar software.)

 

Thanks for sharing quality, valuable content.

 

Texture atlasing. I don't understand how Unity could develop a lightmap UV packing and sprite atlasing, but no built-in Texture atlasing? It seems like everything they'd need is already there.

Also, non-humanoid animation re-targeting. Right now the only way to re-target generic animation is if both rigs have the exact same bone structure and names. There should be a way to create your own mapping and specify for each rig, which bone is analogous to which.

I feel like both of these things are basic features that would be pretty easy to add.

 

I seem to remember them saying that they planned to add support for non-humanoid retargeting "in the future" some time back when mecanim was relatively new.

 

- Official ScriptableObject asset usage detector, for ScriptableObject event channel architecture
- Public method usage detector for Visual Studio IDE
- Nanite and Lumen

I'm looking forward to the hair/ cloth simulation and multiplayer networking tools

 

.SetLocalPositionAndRotation would be a nice addition for performance and should be relatively easy to implement

 

Like most event stuff, this is something that needs to be configured specifically per-project and can't be so easily generalized.

I'm pretty sure this is handled on the IDE's side? This is a feature Rider does on its own through the solution file.

Both of these are Unreal-specific technologies and workflows while Unity's own GPU lightmapper is barely functional. This is one of those situations where it makes more sense for Unity to fix the features it has rather than this being a feature it should have.

 

There is a free ScriptableObject usage asset detector plugin on the asset store, but it would be better if Unity provide a more performant and more API-change-resistant tool for it, since they recommend the architecture.

Yes, but I wish Unity can develop a Visual Studio extension to detect the usages of the public methods in animation events and inspector. Or at least an Editor tool to list down all public method usages in the Editor (maybe this Editor tool has already existed?)

Yes, Unity's GPU lightmapper doesn't seem to be on a par with the one on the asset store. I watched a YouTube video about a Nanite-like tool being developed for Unity and there was SEGI for real-time global illumination, so I bet Unity could have those features too.

 

Unity needs Lumen. To set up the lighting with only one sun light and reflection in Lumen is simply outstanding.
I believe Lumen is that unicorn GI we always wanted.

 

The very deliberate thing about the unicorn analogy is that unicorns aren't real.

 

In the end, just wishing for a tool that exists only for a different engine is not really expedient.

 

In this case unicorns are unreal.

 

Eyyyyyyyyyyy

 

Im a firm believer in "fix what you already have", before adding more features...

 

1: A keyboard shortcut to align the Scene View to the main camera or the player.
At the moment it means first selecting the Camera, and then after that, using the drop-down GameObject menu!

2: A much better way to see and select the Z axis when moving,scaling or rotating objects. It always gets hidden during transforms. Well for me it does!

 

https://docs.unity3d.com/ScriptReference/Transform.SetPositionAndRotation.html

Edit - ah, didn’t see it was local you wanted,

 

Yep, it's about twice as fast than calling both after eachother and don't see why local and global couldn't have equal support

 

I wouldn’t be surprised if it was already in, just not exposed. Believe that was the case with the one I referenced. Think someone brought it up in a talk a long time ago.

 

Awesome! Can it be backported to LTS?

And don't forget to add the intellisense message for combining the 2 calls into 1! Global pos and rot have this, which is very helpful

 

I have Roselynator installed, but the message about combining the position and rotation calls into one has the UNTxxx ID, so thought it was from unity itself

 

1. Remove the built-in legacy systems (especially the near useless ones like default Text) that bloat the engine and are used as crutches, so new replacement packages never reach feature parity and production ready state. After 4 years, there shouldn't be charts depicting what a package can and can't do. It should be the default choice and there shouldn't be 2-4 choices per system, each with their own caveats and gotchas. Just focus on one, two at most in case of render pipelines, since it's likely a bit too late to fix that fragmentation.

2. In fact, port the main packages, like Input System and UI Toolkit, to the core engine. One of the main reasons Unity's losing iteration time these days is because everything's a C# package now. It's unnecessary for universally used features all games need.

3. Reallocate resources to package development teams to optimize and finish them. I know for a fact many packages are run by skeleton crews. I don't know where all the new hires go, but it's not to the packages I care about.

4. Stop rating packages only for new engine versions when there's no change in dependencies. I can still run a lot of them simply by forcing the update in manifest.json but that, of course, is not officially supported. I thought the whole idea was that features could be updated or removed separately from the engine? You can remove them for sure, but meaningful updates are tied to new engine versions only, which is unfortunate.

Long story short, Unity should finish current features and stop dragging bloated corpses along indefinitely and use them as crutches. No new feature should take more than 4 years to reach feature parity and a production ready state for a multibillion company like Unity.

 

Actually, here's a feature Unity should have. It's even a feature it used to have!

Put the sprite editor back in the core engine.

This has been absolutely baffling to me since it was moved over to the package manager. The only time this becomes a default feature is when you select one of the 2D templates, but one of the most common reasons you'll be using the sprite editor is for 9-slices for UI, something I'd wager most projects need.

 

That's a royally bad idea. Someone's using those and it is "destroy the old without building the new" all over again.

----
Just because you are not using something, doesn't mean it is useless to everybody else.
Likewise, just because you're using something, doesn't mean it is useful or desirable to other people.
For example, for me UI Toolkit is bloat if I'm not using it.

 

Does anyone really still use default Text? TextMeshPro never got properly integrated and they're already working on a new text engine for Unity. So we have a system no one who knows better uses, a system that was never properly integrated but is usable and a new system in development that will replace both of them. Lovely bloat. Backwards compatibility is generally a good thing but there have to be limits. And people can keep using current versions of Unity for those legacy features. At least TMP is removable whenever the replacement comes in, but the default text really needs to go when that happens.

If people like using systems that haven't received any meaningful development for more than 4 years, they are free to do so. But it's also why a lot of the new systems still don't have feature parity and/or are not production ready. I like to imagine a world where Unity's resources are more focused, which would involve stopping support for legacy systems that are not developed anymore even if some people are stuck in their ways.

 

Literally everyone who still uses IMGUI, which a lot of people still rely on for internal testing tools that would be incredibly cumbersome to update to TMP and UGUI.

 

Good point. Editor tooling skipped my mind.

 

Unity should have:
- Less bugs
- Less fragmentation
- Less uncompleted/half baked features
- Less packages tied to future pre-alpha engine versions
- Less packages/features that gets abandoned or unsupported for long periods

I understand you guys (Unity devs) are humans but if your multi billion dollar company can't provide such basic needs for us end-users, it doesn't have a reason to exist. Find a way to get your sh*ts fixed, that's why we pay a license for.

 

I'm fairly sure I've used it bunch of times fairly recently, because TMPro is poorly integrated and generally unpleasant to work with. Sure, it might look nice, but the integration is ass.

Additionally, there's interesting functionality like this:
https://docs.unity3d.com/2020.3/Documentation/ScriptReference/TextCore.FaceInfo.html
This stuff allows you to access glyphs directly without interfacing with FreeType2 yourself. Now, remember that there's no proper ligature support for arabic? This is a gateway that gives you a chance of implementing it yourself.

Right, I even rolled out my own font renderer once by building on top of this.

Well, maybe before killing a functional system, the right idea would be to actually FINISH the integration and FINISH the "new text engine" which, for all I know, will probbaly take 80 years to complete and even that's optimistic.

You're getting a programmer's itch here. "Let's destroy something! We'll build better thing someday, maybe". Then you'll be left with broken old functionality and no replacement. Unity already did this bunch of times (Beast? Enlighten?) so maybe it isn't a good idea to turn it into a habit. As the only thing it achieves is increasing number of non-functional systems and not improving anything.

This stuff wrecks projects. Not to mention that amount of "bloat" for font support will be tiny.

There's no need for a limits, if the feature stays relevant for a century, it should remain in place. If it stays relevant for a millenium, it should remain in place.

One good thing about unity, by the way, is that updates do not destroy your codebase. In Unreal they can cause hard to fix compilation errors, if you dove too deep while implementing something that you needed and are now hit by an architectural change.

And you want that changed for the worse.

And that's a problem how?
It simply means those "legacy" features are needed and useful and newer alternatives do not qualify as a proper replacement. Didn't we already go through this with "Animation" component? It was declared legacy, then it was declared not legacy. Not sure if it is still legacy or not, but I'm fairly sure there are people who find this easier to work with instead of dealing with "Animator" with its "Animator Controllers".

That's non sequitur. Existence of old system does not affect new systems in any way. Code does not rot. If you never touch it, it will always work the same. And if people are using it, it should be kept available in functional, while somebody is bravely trying to build the better world (again) which a slight change of finishing the task in a century or two.

Also, rather than "meaningful development", I'd prefer if at some point features became complete and never needed further change. Take a look at libpng, zlib, libfreetype and so on. Sure they get a patch occasionally, but they do not meaningfully change over time, and despite that entire software industry is built on top of them. Or ImageMagick.

Spoiler

https://xkcd.com/2347/

 

The people who work on the new systems are not the same people who work on and verify that the old ones continue to function. Removing the old ones will not magically make the new ones be developed faster.