Question What is with all the default installed bloat in new Unity projects? (2022.3 LTS)

I've got to ask, because it's becoming this death by a thousand cuts thing.

Why is there a default 'Engineering' feature package installed (that can't be turned off by default when creating a project), now with every project I need uninstall that feature, and then installed just the VS editor package again (because it's either all or nothing)

Then there's the incessant need to install Bolt (Visual Graph) by default, whose Ludiq Background Worker doesn't seem to have an off button anywhere, which is added to the default scripting templates these days as well.
This wouldn't be so bad if it weren't for the fact the Ludic background worker kicks in for every little change in the code base,and with a decently sized code base said background worker add anywhere from 30 seconds to a minute for the most simple changes, yes, even when a script is in an asmdef that isn't referencing visual scripting at all), and when going to play mode adds half minute for going in to play mode and when getting back from play mode into editor mode again. Which is absolutely unacceptable.
Unity since 5.x has become more and more slow as it is without tacking on this slow as treacle during winter crap, despite all the promises made by Unity.
It's come to the point that, despite it being super handy, we simply don't use Bolt/Visual Scripting in projects anymore as it just slows down iteration times to a frustrating level

I'm just asking and wondering why and for whom these changes are being made?

 

Have you actually observed (measured) a difference with the other two IDE packages installed?

It's not Bolt. It's a complete rewrite and is called Visual Scripting. If you don't need that package, uninstall it. I do so frequently, it's not much of a bother since I clean up + add packages in a new project anyway. Now with the newer Unity version you can actually add/remove multiple packages at once, so that's no biggy.

Enable Enter PlayMode Options, disable Domain Reload. First thing I do when starting new projects. The near-instant enter playmode is worth the additional care when writing scripts, or (rarely) fixing some asset that does not play well with it.

That is a mantra repeated over and over by some frustrated devs with nothing to back it up. Turns out by my tests this is nothing but bullcrap! Perhaps at one point in time it was true, there were particularly slow 2020 early (beta) versions but this has since been fixed. Worth noting is the psychological aspect: 2020 was the first to show the "Hold On" progress bar which made things simply FEEL slower because the downtime was more present.

I'm in the middle of actually measuring 2017 to 2023 for all important workflow aspects and will blog about this soon. Things actually got worse until 2019 (slowest), then it turns around with 2023 being the fastest all around. The script change turnaround actually got cut in half in 2023.1 which is significant!



I should note this isn't a real project. It's a random collection of game templates and code libraries that I got to compile without errors in Unity 2017 and then I made sure it compiled all the way to 2023. It's got plenty of code in it but little assets. Here's the project view:



Assets contains ~850 MB, over 9,000 asset files, nearly 1,900 scripts. It's intentionally very script heavy.

For an experienced programmer, those visual scripting tools are nothing but a slow workflow experience anyway. It helps get beginners off the ground and it allows designers to do some simple logic, and it looks cooler than code, the angst to try it is far less because you don't ever have to search for that missing semicolon.

 

My biggest gripe out of all this is that everything that is being done is opt-out, rather than opt-in (just worded in an angry old man yells at clouds fashion.)

No of course not, but why bundle and lock the ability to remove what you don't need, or, gasp, give us the option to change the default in HUB or templates (I'm sure this is possible, but not in a very user friendly way?)

Is that why the manual and changelogs calls it Visual Scripting formerly Bolt, or the changelogs simply states:

Code (csharp):

1.  
2. - Updated Documentation
3. - Renamed assemblies to match Unity.VisualScripting naming scheme (Ex: Bolt.Core -> Unity.VisualScripting.Core)
4. - Merged Ludiq.Core and Ludiq.Graphs into Unity.VisualScripting.Core
5. - Moved Setup Wizard contents from pop-up on Editor startup to Player Settings. You can change the default settings from "Player Settings > Visual Scripting"
6. - Renamed "Assembly Options" to "Node Library"
7. - Renamed "Flow Graph" to "Script Graph"
8. - Renamed "Flow Machine" to "Script Machine"
9. - Renamed "Macro" graphs to "Graph" in machine source configuration and "GraphAsset" in Assets
10. - Renamed "Control Input/Output" to "Trigger Input/Output"
11. - Renamed "Value Input/Output" to "Data Input/Output"
12. - Updated built-in nodes. The Fuzzy Finder still accepts earlier version names of nodes.
13. - Renamed "Branch" node to "If"
14. - Renamed "Self" node to "This"
15. - Deprecated the previous Add unit. The Sum unit has been renamed to Add.
16. - Updated Window Naming  
17. - Changed "Variables" window to "Blackboard"
18. - Changed "Graph" window to "Script Graph" and "State Graph"
19. - Updated Bolt Preferences
20. - Renamed Bolt Preferences to "Visual Scripting"
21. - Removed BoltEx

(I know, it's kinda childish of me to go there)

That doesn't work when you're still changing the code base and notice a lot of juniors and designers don't really prep their scripts to work with it.
Don't get me wrong, when all you do is play test and tweak variables on an asset that works really well.

That's great (the 2023.1 thing), our tests using an actual production project and not some synthetic project shows a different story (it goes up and down, but it never has gotten back to the old startup times).
Also, any source on that test so that others can reproduce it?

That's great when you work solo as a programmer in a complete bubble without having to think of other people inside a production, unfortunately, that's not how we do our productions. We usually build our app in (albeit very small) teams.



Look, I'm sure I sound like a complete and utter a-hole, but I really don't like it when my issue gets thrown to the side simply because someone else "doesn't have the problem ,therefore my problem probably doesn't exist and is therefore null and void."

That said, I'm not really here to argue with you (I know, here I am, arguing), but just venting my frustration of all the little things that just start getting to me. When I pull 12 hour shifts and to get something finished on time and half my time is spend staring at Unity having a stroke because of background worker bloat and other stuff that takes time away from me actually doing my job, that start to get to me.

Hence the question to Unity, why? Why have so much added crap as opt-out, rather than opt-in and create a good boarding experience through the HUB, isn't that what it's there for?

 

I'll probably just put it on Github, if it's not too big for free & public. I did not check every source license though but since this is for testing only ...

I get that. Been there, done that. Probably do it again.
It can be cathartic though if something that still bugs you after venting has you hunt down every tail that may improve things.

I don't know about the background worker issue for Visual Scripting. But in my experience, Unity on the user-facing side all too often seems to be taking too long and generally slower than previous version. But when you look closer, analyze, try things out, rip the project apart for testing, all of a sudden it may turn out to be caused by a junior programmer's 20-lines editor script that happens to explode exponentially, and it's hooked into EditorApplication.update rather than reacting to the right callback.

Like that one time when an editor script was hooked into Selection change events, and it went all the way down the hierarchy for the selection in the scene, performing some code on every object it found. It only became an issue when we had deeply rigged bones in the hierarchy, I think that was for animating jellyfish. Like 50+ levels deep! Everyone thought the several second delay selecting these as well as FPS down to 5 when selected was because of that depth, and in a way that was true and made sense so the issue stayed there for months, everyone just accepted it. Some, of course, blamed Unity.

And my favorite pet peeve: any script using the AssetDatabase including one or several AssetDatabase.Refresh() - needlessly, no thought given, it can't hurt, right? And nobody takes any care to understand what this actually does.

 

Source: Unity


Things are getting slower year over year. I don't see how one synthetic test is enough to discredit what people with real projects experience and what even Unity's own metrics show.

 

You did notice the ‚b‘ in the third column? Have you tried 2022.3 or even 2023.1 and took some measurements?

I will definitely test more than one project.

 

Do you have a link to the that?

 

https://forum.unity.com/threads/imp...-c-script-changes.1184446/page-3#post-7815273

It's from here, I just edited the 3 tables together and kept the latest (at the time) versions for each year over year release to better compare the changes between major releases.

Here is when I originally posted the edited table: https://forum.unity.com/threads/imp...-c-script-changes.1184446/page-4#post-7918555

And here is a post by xoofx saying that more or less that editor iteration times will keep getting worse since they are moving more and more time to C# and therefore, even though they are spending more effort than ever, there is no chance of getting back to 2019 or pre-2019 levels, at least without them implementing CoreCLR or something.

https://forum.unity.com/threads/imp...-c-script-changes.1184446/page-6#post-8089391

 

If you're that determined to dispute Unity, go ahead.

 

Thanks! We were debating internally if the editor had gotten slower, or our code has been impacting the editor. (though in fairness, it may be both.