Definitely a rant, and shoutout. Been here for four years, and Unity somehow gotten worse.

Now, don't get this solely as hate, but.. come on.. Unity, over the years, have become bloated, slower, and eventually painful to work with.

I know.. I could do research to actually fix the bugs editor has on my own.
But thing is.. the editor is just.. "something" that likes to freeze. At random.
I can literally press Ctrl+S without changing anything, return to editor, and it just freezes, and keep on reloading assets till I kill the process. Sometimes it just crashes my whole system, or crashes at random occasions.

Batching? What is that, Editor asks. Quite literally, batching and occlusion has become non-existent.
No matter the settings, no matter whether instancing is on, off, whether it is occludee static & occluder setup, or full static, or even full dynamic, batching just does not work in any way. Not in built-in, not in HDRP.
And having 30k batches with less than 5k very low-poly objects is just mess.
I really don't get how Unity got here.

It constantly logs me off, even during sessions.
Hub license keeps deleting itself, and I need to log in every single day I start a computer.
But that's only scratching surface, and I am very upset, that this does not get fixed.
Yes, new rendering is very much important...
But tell me.. is it really okay if editor threw errors out of the box? I start an empty project, open package manager, and boom, console is spammed with errors from EditorWindow, EditorUI stuff.
It has become PAINFUL to work with it.

I'm asking myself... how long it will take, if ever, till Unity decides to fix all the bugs, so the editor is maybe usable?


And please, don't get me wrong. I love Unity for what it is and was. But it has become really bad over the years.
Just fix it. Please, fix it. This is not workable with.

 

yup 5.x was fastest, 2017-2018 were good, 2019 can be used.. newer editors are too slow.

can also follow this thread (if not already there)
https://forum.unity.com/threads/improving-iteration-time-on-c-script-changes.1184446/

 

One significant reason why newer Unity editor feels slower is how many components are C# now. While this can be a double edged sword, it definitely increases flexibility. My personal project for example would not be possible if the 2D animation system were "hardcoded" and not an editable package.

Editor speed really is not everything though. 2019 version looks and feels outdated to me already.

Errors are a whole different topic and I somehow doubt that was less an issue back then. We just forgot the time we had to spend on finding workarounds etc.

 

There's a few editor things that bug me:

• The Game window zoom percentage slider starts a few notches from the left when loading a project. Possibly fixed in 2022.

• Sometimes trying to unfold a component in the inspector triggers a 5-10 second load/freeze, as if it wasn't cached. Maybe they haven't tested with slower RAM/HD.

• Layouts are completely broken. Randomly the selected layout will go blank (the dropdown button), or you will get a console error about some window and have to reapply the layout.

• New toolbar UX is much worse. They moved snapping which broke it, then fixed it, then moved vsync toggle which broke it while playing, and don't the Global/Local and Pivot/Center use a dropdown menu now? Before they were one-click.

• Packages window is so slow, especially if it defaults to selecting My Assets when you only wanted to see Unity Assets. You have to wait for it to finish loading useless data before the button enables.

• It would be nice if Unity Hub wasn't just a slow web browser (Electron).

 

This doesn't seem to be the case in newer versions. In 2021.3 I can change my filters as it's loading packages.

 

Barring unusual cases older software is always faster than newer software.

Or maybe they expect their paying customers to not be running out of date hardware.

 

Kinda true and funny that this is the case. Wonder whether subconsciously we as devs often add as many features and are as sloppy in terms of optimization that we achieve what's just barely bearable/good on current hardware.
Then 1-2 CPU generations later, that software feels fast.

I do always wonder about the hardware when extreme complains come up. In the end there just is a reason why companies usually equip their devs with top notch hardware (albeit in laptop form).

 

While bloat and technical debt are a real thing they're only part of the picture. Newer technologies and techniques including ones aimed at increasing performance have higher minimum system requirements. AMD's FSR 2.0 can be run on hardware from the Unity 5.x days but you would lose more from it's overhead than you gained from using it.

 

Yeah it's true, Unity will solve any issue for Accelerate customers with deep pockets but you're completely on your own if you think it'll become "democratised".

Basically my advice is to test what the game needs up front, ahead of time. And don't rely on anything at all that is WIP or not completely finished. Alternatively, scope the title small enough so that you can cope with replacing the features that don't work in your use case.

Indies aren't Unity's target market vs military or advertising.

Or unavailable on the latest and newest hardware on 2/3 (the majority) of Unity's pipelines, in new Unity.

Their main customers don't need it, after all.

 

Yeah I switched my example to FSR 2.0 which is available on the consoles.

 

And old hardware running new software is doubly slow. Naturally, if you want to use the latest software, the latest hardware is preferable.

I kind of want to know what hardware the peeps experiencing really long domain reload times are using, because even on my old i7 5960X, a cpu that was 8 years old when I replaced it, I was still only get ~5 second reloads on 2021.

 

Worst I've seen is a few seconds in 2021.1 with a 130GB project (30GB assets plus 100GB library) with no assembly definitions. I'm on a 5950X w/ 64GB DDR4-3600 which is not dirt cheap but it's not crazy expensive either.

 

is what's in project total as important as what is in the scene though?

I had a project that was like 10gb total, but lots of instanced meshes in scene and it took ages to enter play mode. I don't remember what version, 2019 or later. I probably was closer to min specs than the other end.

 

It was a fighting game. Just about everything including the majority of the code was in a single scene. Stages were stored in their own scene files but they were just static objects and lightmap data. Most menus were separate too but most of the code that they used was reused in the main scene.

I just looked up the current cost of these components. It's $550 for the CPU and $200 for the RAM. I paid more than that but the majority of the difference was due to the pandemic.

 

@Ryiah
is most of that size coming from big textures, or something else?

 

A mixture of assets but primarily large textures.

 

For some reason, the whole "hold on, repainting this and that" doesn't exist on my m1 mac - which has made me quite fond of using it for smaller projects. Its singlecore performance is also significantly fast than my ryzen 3600, very noticeable.

That said, I remember there was an alpha or beta version which reduced/removed the "hold on" - with compile times that where quite similar between the m1 and pc. Didn't last.

 

Yes, especially in real game projects, with 5+ people contributing, unity 2020 and later got slower and slower and slower.

Unity 2022.1 takes the cake with a domain reload and no way to turn it off every time Rider autosaves a file. The play mode option to recompile after playing stopped is simply ignored, as well.

This is actually dangerous, I have domain reloads happening and code that I was just in the process of completing compiles AND EXECUTES, e.g. spawning some objects in an ExecuteAlways behaviour, and or in OnValidate code that's not quite right, literally clobbering hundreds of assets.

But what really breaks the camel's back opus the overall time I stare at "Hold on...,& Progress bars.
Every single day, I stare at them, waiting for gracious permission to make that one mouse click that would have completed the operation that ACTUALLY warranted the domain reload. (Which will trigger another one)

I have experimented with turning off auto refresh but I wish I could just let Rider trigger the refresh for me then. Manual is bad, often one ends up debugging the same code again and again breite realizing a refresh was needed for any changes to apply.

Conversely, Asset imports should be MUCH more forgiving, like with a 5 second grace period some can move files around or begin a Rename before the full blown asset importer kicks in.

Lastly, please please run some kind of linter that knows that only comments changed, and forego the recompile. Domain reloads from idempotent source code changes coming from writing the finishing documentation of a feature easily adds 10-20 minutes to the wrap up times.

 

I was extremely angry because Unity automatically compiled while I was typing code (Unity 2020 and later had this problem). So much so that I went to the Unity forum and created a thread cursing the psycho who made this feature -_-

 

Doesn't disabling autosave in Rider work?

 

Yes, but the real solution should be Unity only doing domain reloads when focused.

 

Would prefer if it's a choice honestly.
My PC is fast enough and maybe project small enough that it does not disturb my coding. Then since I often think for a moment staring at the code after the last save of the script, Unity compiles\reloads it already, and therefore on average every other time when I actually focus to Unity, it is already reloaded and ready. So it saves me time.
Fairly sure that workflow is what they intended.

That it may interfere with ExecuteAlways is potentially an issue\risk indeed. Maybe those things should not be executed when the editor is not focused.

 

But isnt that the whole idea? Recompile happens prior to tabbing to Unity, so you don't have to wait. Think theres a setting in Rider "automatically refresh assets in unity or something ..." if you wish to disable it.

 

I feel like Unity is coasting on inertia from years past when there were barely any other options than Unity for multi-platform deployment, and when the engine wasn't so fragmented and bloated and when Unity's management consisted of gamedev focused founders of the engine.

Now money suits are steering the ship and we get half baked MVP packages on the regular that look nice in marketing spiel, but don't really contribute to a healthy ecosystem Unity once sorta had. And there seems to be no effort made to push for production ready state, things just get marginally improved, github dumped or cancelled over the years. The fact that many packages, even after 4+ years of development, still aren't the default choice is... I just don't have words anymore.

Unity still sorta is the main option for scaling in both low end and high end directions if you need that, but that will change soon as gamedev focused contenders mature in the coming years. If Unity's internal processes and decision making won't change in the mid to long term, they're bound to break out of the positive feedback loop they're in right now. Unity might not care about gamedev much at all by then, though.

 

It was confusing because the toolbar scene stuff has moved to the scene view, which makes some sense, but it is a real change of UX after many years & 2 clicks worse than 1

I liked the words in the old one, the icons take some getting used to!

At least you can save the layout, because I don't need floating view mode icons (don't use them!)

 

I never use the game view zoom, except if I move my mouse wheel thinking I am in scene view, then it is damned annoying!

 

And the new UI system maybe?
This amusing reply to UI speed issues:

"The initialization time in UI Toolkit and Visual Elements is more costly than UGUI. For two reasons:
- The system does more work (For example, compute USS styles/selectors)
- It's not as optimized and is almost entirely C#"

Well maybe core components should be super optimised and not entirely C# then?

 

That was a design decision they made a while ago and it brings us the benefit of being able to make changes ourselves via packages. It's way closer to source code access (for everyone) than if it were precompiled parts of the editor.
It surely is a double edged sword to a degree.

 

Thought it was just me and my aging dinosaur, but yea... hurry up and wait is alot of time spent with unity.

 

In newer editors they have added many new UI widgets that block the UI thread causing the game to freeze momentarily, this definitely is undesired behavior especially when simply trying to change local mode to global mode and now the entire thread locks up while the drop downs are visible. This is really annoying and what is the point of adding dropdowns to a menu with two items? Just make it a button like it was. The newer editors compile faster but surely are becoming a headache and crashing or freezing or build behavior is different than editor.. I just wish the focus was less on adding things where they're not needed and instead work on solving existing issues and actual bugs.

 

Speaking of compiling code, I was curious to see how much we've lost over the years so I downloaded Unity 5.6.7, started a new project, installed Script Inspector 3, and created a simple script. Compiling the code took a few hundred milliseconds. It was so fast I almost didn't see the message SI3 gives when it's compiling code.

 

The cost of packages being C#.

 

Compilation times increasing has been an issue even before packages were a thing.

 

I hope at some point they will find a solution to slow Editor and code reload. When teh project passes certain threshold of complexity it becomes very annoying

So I keep my fingers crossed that they will find a way to make it at least somewhat faster.

 

Just turn off domain reload and use a hot reload asset like the free one below.

https://assetstore.unity.com/packages/tools/utilities/fast-script-reload-239351
https://github.com/handzlikchris/FastScriptReload

 

Workaround is not a solution ...but I know zip ties are the strongest

 

You may see it as a workaround but I see it as the future solution. Currently when you make changes to a script the editor tries to recompile every script in your project which is just not a viable approach when they're trying to move everything into the project.

Fast script reload (and other solutions similar to it like Hot Reload) works by only recompiling and relinking the code that has changed in the project. I fully expect Unity to head down this path themselves at some point in the future.

 

That's a solution, though. The point of full reload is that it provides you a guaranteed clean slate.

Most of the time you do not need that.

 

What I ment is i need to resort to 3rd party to solve the issue, its not built in .

Thats what I expect too, so hope that or some other solution will be in-engine soon, so devs don't have to rely on 3rd party tools.

 

It is built in feature in editor.
You need to learn using features which are provided on hand, which significantly improve your workflow. By now first thing is, you should try it. You will like it.

Also, learning to reload script changes manually, rather than rely on auto reloading, will improve yorwork flow further.

 

Funny.

 

I fortunately dont get on the forums much.... but WOW. Things havent changed in a decade. Unity still not listening to the users REAL WORLD actual needs and Hippo giving non relevant advice.

"Alternatively, scope the title small enough so that you can cope with replacing the features that don't work in your use case."

Oh and my favorite...

"Indies aren't Unity's target market vs military or advertising."

Wut?

 

Hippo hasn't really been around this year. He was deeply unsettled by Unity drama last August and was having a good time with the other engine, perhaps he's jumped the fence.

Indies can't sustain Unity financially, so he has a point. Unity does have a major military contract with the US government and more than half of Unity's revenue comes from their mobile ads offerings.

 

I want to believe you James. I really do. I want Unity to be THE PLACE for indie devs that it used to be. But there were many developers telling Unity the whole time that the choices they were making during the "risk taking time" were wrong and not good for the future. They never listened.

They intentionally forged on with shiny buzz words courting the mobile gaming industry and at the same time were pretending to be an "AutoCad Display Engine" for the Auto Industry. Both had NOTHING to do with the shoulders of small indie PC devs that they were standing on.

What has changed to ensure that Unity is heading in a dev centric direction? Cleary moderators are claiming they are only after the War Bucks Sims and Virtual shopping apps of 2015? So which is it?

 

This is literally the case. Indies aren't where the money comes from and, if they ever were, it was for a scarcely short period of time. Unity's ads and other services are major sources of income, as are big companies using the engine. But indies? Not even a little.

 

dont pick on employees over management issues, thats like these awful "karens" harassing min wage workers because their diapers price increased.

of course unity employees are going to say something nice. If you think you know better then you already have all the info you need to make your decisions.

 

No one's picking on employees, they are also victims of their management and if the vibe is indeed like there's a renewed interest towards indie devs, then that's also some bullshit to keep their employees happy and feeling like things are going to get better, the exact same thing Unity does to its users.

Or as I said, "funny".

 

@AcidArrow

i wasn't replying to you. But it seems you have a guilty conscious!

 

You mean there is someone with a more inflammatory attitude here? HERESY!