How about "Performance by Default" for Editor?

My project keeps growing and it takes about 25 seconds to go into "Play" mode. It will soon reach half-a-minute soon. We barely began the project.

It's was very painful and now it's unbearable. I'm going to upgrade my PC once again if it can save few seconds. I think it worths it.

I'm really that desperate for better productivity. 3 seconds * 1000 times a day is about 50 mins and it can save about a couple days a month.

Unity! Please do something about it!
I know it's doable once you set your mind to it.

 

It looks like you have doubt that they don't have any intention to fix this issue, until you get a response in this thread? In that case is this suffice for you : https://forum.unity.com/threads/unity-incremental-c-compiler-deprecated.523993/page-9#post-3987316 also it indicates that they know full well about this. One other thread I can't find, Joachim talk about there're so much more he can do about "hot reload". I imagine a big rework is underway to truly not compile everything in more granular level than .asmdef.

Also I got one tips, if you are a debug-logger and not using editor attaching you can turn that off in the Preference. It can save some play mode entering time currently. I am at ~10 seconds but with that on it is usually 12-15 seconds.

One more tip, a big one that immensely help me I recently practiced doing. You should utilize local UPM. Compose your project from multiple local UPMs instead. Because the time to enter play mode depends on number of scripts in the project and not things in the scene, if you develop each UPM module in a separate project then combine together later you will get fast iteration time when working in each module in their own project. Why do you enter play mode and suffer 30 seconds wait? To test things. If you do local UPM, then there are less things to iterate test in the big project and save you big time on the weakness of Unity.

Make sure a test assembly is contained in each module. That way Play Mode Test will not be so gatekeeped by play mode entering time. It is the best way to fight with this problem right now, in a way that will also benefit your game and your other game in the future when you can reuse your own packages.

But it is much better if you could do everything in Edit Mode Test to avoid big play mode entering time altogether, with `yield return null` support you can even do network test in edit mode. I made a library which use Firebase Cloud Firestore from Unity with REST API, it works in Edit Mode Test and I could wait for results, all separated from my full game before I plug it in. (Then I need some integration test to bridge the two, but mostly those faster isolated project unit tests already took care of)

 

Yea, it takes a stupid amount of time. No idea why it recompiles every asset in the entire project for every small change, either.

 

Assembly reload time, mostly. As Unity projects scale you find Unity doesn't scale at all, so you will need to handle it manually in some manner or other, and usually this involves figuring out how to avoid Unity reloading the entire planet.

 

Have any tips? I used the "Maintainer" Unity asset to separate unused src will dramatically helped, but my Assets dir is still pretty large. I also suspect that my cache wasn't cleared for the files I separated from src, bloating my SSD. As for handling it manually beyond this... I wouldn't know where to start.

 

@

Please @hippocoder, tell us how to do just that!

 

Just to throw a few things in here:
- For me entering/leaving play mode in an empty project (trying both 2018.2 and 2019.1) takes approx 0.2sec. So its really fast
- My personal project is split into multiple components (multiple unity projects). I load the assemblies and unity content at runtime in the "main game project". That allows me to work on many things separately, every single project is very fast. Stuff like levels/environments are in the "main game". UI is its own project (which is pretty big!). Then there's another project for various "assets" that mostly has some scripts to create asset bundles that the other projects use.

But I definitely agree on the greater point of this thread (just not the issue with the reloading, that's just your own fault for using addons that take a long time to do their stuff. Should just be better optimized I guess. But then again I barely use any addons / external assets from the store).

If we ignore the huge load times for a moment, the biggest issue that shows that Unity is only for (very) small projects is that the asset browser/explorer simply has no folders.

Like, view an UGUI image component in the Inspector. Click the little dot that allows you to select a sprite/image for it, that browser window thing that opens is the one I'm talking about. How can it be that this thing can't filter by folder or tags or something???

However, in the end every engine has its downsides. There will always be people who can deal with it, make it work somehow, and others who'll get stuck. UE4 does *many* things better than Unity, yes, but it also has its disadvantages.

 

@dadude123, your setup works for you but that clearly doesn't work for everyone.

The point is that we want to find ways to improve our productivity without having to switch engine whenever we find something annoying that could be better.

 

There's nothing I can suggest other than throwing your scripts that will not change into a Plugins folder or dealing with the whole assembly dance, which is actually a proper pain in the arse, but it is what it is.

 

Yeah thats true. I didn't intend to say everyone should do it as I do.

Unity has a ton of stuff to improve in this aspect.
Usability with large projects. Reload times. ...

 

@hippocoder

here is my current headache:



Compile times are acceptable but `Assembly Reload Time` basically made all my half-day refactoring into Plugins/StandardAssets + asmdefs utterly useless.

I would love to be able to force unity not to reload assemblies which have not been touched (otherwise what's the point of asmdefs if it still takes ages?)

Any hint?

 

Yeah, at least there are *some* things we can do to mitigate the problem for the most part.

But people should not forget why it is that way. I'm not sure if everyone in this thread is really fully aware of the technical details here.

One can view the situation like this: these issues are actually (in a way) a price we are paying.
But what do we pay for? What are we getting?

We're getting .NET/C# and all its countless and massive advantages.
And with that comes the price of the runtime (in our case: Mono).

If I had to chose between having dotnet + these problems, or having a system like UE has (Blueprints + C++), I'd pick the Unity approach every single time, with absolutely zero hesitation.

I'm not trying to say the problems reported here are invalid or anything. Just trying to explain why we're having them.
Unity should definitely do better here.
But I think it's actually not even all that easy to do. The full switch to .net4.x / net standard 2.0 was not too long ago, and the changes and consequences are still propagating through the Unity ecosystem.

Again, not sure how informed everyone in here is, but the "performance by default" thing for the editor will come - in fact it's definitely being worked on. One of the recent videos has shown that some real nice improvements for this are on the roadmap already. Even some insane stuff like not even having to reload the appdomain to enter play mode! If that will end up actually working, It would be literally "instant play" as you guys want it!

 

@dadude123, you being apologetic helps absolutely 0. If this is not an issue for you move on and enjoy your Unity experience. If wasting tons of time for basically nothing is something you are not happy with then discuss it with others and try to find a solution or try to get the Unity peeps to look into it.

 

I know you're asking hippocoder.
But I feel like I can give an answer as well:
Unfortunately there is no way. Reloading the appdomain (which will always reload *every* assembly) is a very important thing to do. At this moment there's not really much you can do.

If your current scene is large (has many c# components) then that is an important factor as well.
You can try to see if the appdomain reload takes the same time with an empty scene open.
The domain reload itself should definitely not take 7sec.
So my guess is that there are many scripts in your scene that have to be serialized, thrown out, then deserialized after the new assemblies are loaded.

 

@dadude123, the only thing I am aware of is the heavy use of `[SerializeField]` and I have a couple of assets from the store.
I would looooove to be able to pin point what is causing the slowdown. Any tip? The profiler doesn't seem to tell much sadly.

 

Yeah although the idea of instant play will probably never happen in the monobehaviour world. Unity is probably going to only work with that for DOTS. So if your project is not DOTS-based and you're not using a 2020.1+ version then I do not expect compilation or reload time to change.

The reason for this is the whole assembly reload thing. I don't think it's actually a thing Unity will fix for mono editor projects.

This is just my own observation and I haven't received any information from Unity in this regard, I just think it's logical that Unity is looking at solving this the right way, which means "build a better solution".

 

For future readers, after lots of tests, here is what I did to manage to go from 9-10s to 6-7s in the compile/reload times:

1. Moved imported assets and general tools into the "Standard Assets" folder (name has to be that)
2. Removed as many files as possible (I went through and deleted all the Docs/Example/Demo folders from the assets I was using), their size is not necessarily important
3. Removed default packages which I didn't need: Ads, IAP, Analytics, Multiplayer, XR Legacy, Memory Profiler (you can always bring them back whenever you actually need them)

Notes: if, for some crazy reason, someone doesn't use the attach debugger feature in VS-Unity, disabling the "Editor Attaching" from the preferences, actually makes the reloading quicker (about 0.3-0.5s for me).

Other crazy stuff I found:

Unity seems to spam registry calls for certain player prefs, if they are not found, it will still try and try and try. Using process monitor, you can actually find the key and create an empty one in the registry. Little bit of a hack but worked and it stopped wasting time there.

As a side note: it turns out Unity loads the verdana(b) fonts every single compilation, it only takes 0.003s but yeah it adds up

And now, I can finally go back to develop in peace

EDIT: Posted a little tutorial/post about the adventure: https://gamejolt.com/games/talesofk...attempting-to-decrease-compile-times-she9y7qf

 

+1 on assembly reload times, and also generally handling game objects and components could be much faster.
I mean duplicating or moving hundreds of GOs takes it sweet time when there are lot of them.

 

So even moving art/sound files there will help reduce enter play mode time?

 

Couple of things you can already do to speed up the Editor:
- Remove any amount of code, packages, assemblies and assets as much as you can (without reducing planned features)
- Be careful with third party editor tools, those also play a big role with the overall editor performance, less is faster
- Make a separate asset project where you can test and strip all your third party assets, pack what you need and import it as packages on your project so you keep your main project as light and clean as possible
I understand this might not ideal (specially for heavy dependant third party asset projects) but we did this and reduced the Enter/Exit Play time to about 3 seconds. Not just that, we also improved editor performance by about 50% which is not bad with the current state of affairs.
I really hope Unity sort out something quick. They are smart people and if they really care about the future of Engine and his userbase, they will do what's best for all of us.

 

The thing that's unfortunate with Unity is that every year, they'll just sorta throw away support completely for what was standard a year ago. So you didn't use DOTs? Well, too bad, non dots will never get updated again unless you make, release and forget about your games on an annual basis.

Switched to dots? Well next year they'll probably deprecate that for something else. Remember how fast they ditched not 2.0 but even .net 3.5?

It's cool that Unity's looking at new tech, but whenever they swap, they'll deprecate the old one with 0 time wasted as if everyones maintenance cycle is less than 1 year aimed at hobbyists (as no one is going to rewrite their entire project for a new stack).

I wish they at least gave minor updates to their "old" (last year+) tech. My per-seat sub money doesn't even support my game. Old bugs and performance issues just thrown under the carpet.

 

DOTS is probably one of the longest feature developed continuously, since probably Unity 5.x. It just wasn't called DOTS before. But all Unity changes were and still are tailored toward DOTS architecture.

Btw, Unity made some significant improvements for editor in 2020.1.

 

It's called .NET Core (AssemblyLoadContext). @xoofx did a "little" experiment. I swear I saw Joachim saying somewhere in the forum that DOTS will have a .NET Core runtime, so hopefully this means that it will come to the rest of the engine soon enough.

 

A form of Quick play via disabling domain reload and/or scene reload is being introduced to 2019.3, without the requirement of dots. Of course, the former requires special cases towards static fields, so you have to make your project to support it + hope all third party assets support it. If so, that should boost our load times considerably!

 

Fast Enter-To-Play will solve half of the problem and we need a similar solution to C# Compilation.
The only way is to move Editor to .Net core as well using AssemblyLoadContext to manager individual Assemblies.

Here is a blog that describes what it can do.
https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/

Mono is the thing of the past and there is no future for Unity unless they move to .Net core as soon as possible.
Everyone can benefit instantly. To me, it's a constant fight with the Editor every day rather than producing games.

Generally speaking, when you schedule things, you will schedule Urgent and Important ones first.
DOTS is important but the performant Editor is far more Important and Urgent.

There is a Unity guy who already has tried with some success in a short amount of time.
https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/

If a single guy can do did this as a pet project, why can Unity as a team do this?
Soon, I mean not Unity Soon(tm)

 

Indeed, the no domain reload option solves the enter play mode speeds, but there's still the horrendous compilation freeze.

Hell, if only they embraced .NET as a whole: using a better project system (see Xenko) instead of regenerating the solution would already support NuGet and any .NET language.

People: Can you deal with essential things like editor performance, staying up-to-date with technology, and catching up to Unreal?
Unity: Let's do visual scripting.
Programmers: 3iahoifhweioafuh3o8uf
(And friends.)

And since they're doing visual scripting to make the engine more approachable, they might as well do it right, right? Nope, DOTS visual scripting, because DOTS is approachable in any way, shape or form.

Speaking of compilation, I'll just mention the annoyance of the language version mismatch between Visual Studio's code analysers and Unity's compiler.
For example, in 2019.3.0b10 the console says "The member '{X}' does not hide an accessible member. The new keyword is not required", but if you remove the new keyword, Visual Studio says "'{X}' hides inherited member '{Y}'. Use the new keyword if hiding was intended", where Y is one of the goddamn quick accessors that got deprecated all the way back in Unity 5 and should have been long gone by now.

 

Awesome to see potential solutions to this full assembly reload madness receiving some more developer time.
From what I'm reading, the community is really anxious for this situation to improve too.

Thanks a lot!

 

@xoofx, Hi, I really appreciate you are making some efforts trying to triage Unity. Mono is the thing of the past and I really cannot see the future with Mono if you want the high-performance Editor. Mandatory AppDomain Reload is one of the good reasons why you have to ditch Mono, period! And of course, there is much more.

Yeah, it will be difficult to move to .NetCore and make sure everything works, however, it must be done.
You are doing that to DOTS and it changes runtime quite a bit. Sure it will make the game faster but how about developing the game faster? The same amount efforts (probably more in my opinion) should be made to the Editor as well. I said several times that everyone can benefit from the fast Editor immediately and it's where I spend the development time the most and it's a constant struggle. It feels like I'm fighting with the Editor every day rather than making a game. It makes our life so miserable.

.NetCore cannot fix everything but it provides a solid foundation. .NetCore came a long way and it is now at V3.0 and V3.1 LTS will be released soon. We are in a much better situation from last time when you tried the port a couple of years ago.

So in short, please push it as hard as you can as if there is nothing more important. And it really is.
I won't stop asking until I see it on the official roadmap so please make it official soon.

Thanks.

 

When I schedule things, I do it based on two things, that is, 1. How Urgent it is. 2. How Important it is.

1. It's obvious that you should give the highest priority to Ugent and Important.
2. The next highest priority is the Urgent stuff. Yeah, it may not be important but it can be a show stopper if not done.
3. And then the next priority is Important ones. Among the three things, the Important one gets the lowest priority.

There are some unscheduled Ugent stuff surfaces once in a while but a good manager will never make Important stuff into an Urgent. That's basically what a Time Management teaches you. Do not make Important into Urgent. They are all common sense if you think about it.

Then, let's talk about what's Important and Ugent.

DOTS is Important for sure but is it Urgent? Sure, some may think it it's Urgent but most of the developers don't even know what it is and not every project will benefit. Please don't misunderstand me. I really like DOTS and it's the future but honestly, Unity's track records show me that it won't really matter the next a couple of years, thus not relevant for my projects even if I want to use it, unfortunately. I'll come back to DOTS when you make an announcement for DOTS v2.

And how about a performant Editor? I don't have to convince you how Important it is. But is it Urgent?
I think so. I wouldn't have started this thread if I'll be happy if you make the Editor by twice fast. Making the Editor twice as fast will not make much difference. I think you will have to make the Editor about 10 times to feel the Editor snappy. That's how bad the current experience is.

Here is one simple example. You click on something and often you have to wait a few seconds. When clicking on a checkbox I often have to click threes times. Why three times? First click, not responding.. thinking it ate my click so click again... it finally responds but it comes with undo click... and I have to click again one final time.

And when you have to reimport my project and it takes about half a day. When that happens, you are done for the day and I have to go home or work on something else.

You left the Editor in the limbo state for so long and now it has gotten to an Urgent. The current doggy slow Editor eating our lives right now. If you are working on a project other than Flappy bird style game and turn the Fast Enter To Play mode on, you will understand what I mean what we've been paying for such a long time. It literally makes a night and day difference and you will never want to work with the Slow mode.

I think the Fast Play Mode should be the default mode soon and force all Asset developers to adopt. If not, Unity should not approve of them. I'm talking about some quality controls that you've been ignoring. Yeah, some developers will complain but it's was your fault to begin with for the bad design and you should apologize to all of us and do a better job from now on.

To make the long story short, making the performant Editor is Urgent!!! And everyone will benefit immediately regardless of projects, and yet you are still pondering with some ideas. Do you still do not agree?
If you agree, please give it the highest priority right now and show your commitment.
If you still pondering with ideas, you are not taking your responsibility and Unity should find someone who can, seriously.

Please get your priority straight. It's better late than never and I'll be very happy for you.

Thanks for listening.

 

Opening the source code of the runtime (since it's floating around the internet anyway) under a contribution-friendly license might solve this.

 

i think a worse thing about "30s" reload time is that, while i am waiting, i distract myself to something else(like watching this thread with anger), 5mins later, i came back and spend another 1~2min to pick up what i was doing.

 

Can't agree more. It is a constant flow breaker. The best thing for Unity is, using C# and the fast turn around time compared to C++ but it's losing all its advantages by such a ridiculous whole assembly reload even when a single line changes.

I often wonder, is using Unity more productive than using Unreal?
Unreal takes longer to get started but what matters is when we can cross the finish line.
It's a constant struggle fighting with Unity editor rather than working on games. And Unreal now supports hot-reloading without even stopping the game. ( https://molecular-matters.com/products_livepp.html )
I'm pretty sure it puts productive far above Unity.

If I were to go back a year to choose the engine, I'll choose Unreal at a heartbeat and I can't wait until I finish the current "got them" project. I got too excited by last year's Copenhagen Unite where they showed many cool things.. and didn't know the Editor will crawl with large size projects. Right now, I chop the project into smaller pieces and merge it into the main project. And even the chopped project is slow to work with and I don't really want to keep working like this.

Mono has fundamentally had flaws that it has to reload the whole assembly when changing any AppDomain. There is no other way and Unity still pondering with supporting .NetCore. I don't think there isn't anyone at Unity who really takes ownership of the future. They don't really make money on our success but having as many as licensed users and assets for the basically useless Editor without help from 3rd party assets. It explains why they are behaving like that.

.NetCore 3.1 is just released and it's LTS. And Unity is still waiting for something, something seriously wrong with this company.

I really hope some responsible guy at Unity just thinks about what's really urgent here to help Unity users.
Stop making eye candies from Unity Events to Events. It seems like that's what dictates Urgency in Unity.

 

i don't think unity is "crawl with large size projects", you can create a blank project with HDRP(the only supported RP of DOTS project for now) installed, it will gives you ~10s total reload time, basicly, if you choose "performance by default" techlonogy , you have to endure ~10s reload time minimal

 

Yeah, that's because it has to reload all of its assemblies that are not even related to your project even if it's a blank project. Unity is trying to teach all of us "Patience is a Virtue" at the same time, trying to sell us "Performance by Default" Not sure to which to dance. One thing I know, Unity is either Lazy, Incompetent, or Stubborn. Or all of the above.

 

Here is my sincere advice for Unity.
Now you have been selling us "Performance by Default" past a couple of years. I get that. It's really nice but are you keep on saying the same thing going forward?

I think for the next year, I hope you turn the campaign into something like this.

"We've been concentrating Performance by Default for past a couple of years and it's making some good results. We have some proofs... blah blah... but that was all about making the games run fast. And now it's time to make game making experience the same. We present "Performance by Default for the Editor." Performant Editor will not only make the game faster but it allows us to give you many new features like the following... blah blah... that were not possible if the Editor weren't performant."

Please tell me if you have better ideas than the "Performance by Default for the Editor" campaign next year.
I'll forgive you if you skip making some eye candies if you can do that.

Thanks.

 

they are working on live link on code, i assume that's the solver, but "nothing to share" for now

 

It was said in the second bullet point list of this post (a wonderful thing to rub in people's faces) that Mono is relatively easy to port to other platforms. I'm wondering how easy it would be to do the same to .NET Core.

They might be waiting for DOTS, for some goddamn reason. I remember Joachim saying somewhere in the forum (if only it had a search function...) that DOTS will have a .NET Core runtime. That doesn't answer about the editor, though.

The only way I see they could feasibly rebuild Unity with no baggage from the past is "The Packaging" (moving to the unfinished package manager, see the second to last bullet point). They're doing that already, but rather slowly. What I personally want Unity to be is Xenko (a mostly pure .NET engine) but better (Unity offers a lot more).

 

Still butt-hurt, hope Unity devs take action before all switch to UE

 

Live code compile link is a good idea, but if you think about it, it will only work for certain types of situation. When you develop a game your will probably be have to restart play even with live link.

So what we need is fast compile time with much faster domain reload time than now. The most of the development time is spent waiting for the editor to reload domain...

Used unity for ... long time now and every iteration of unity, entering play start time increased... while I can understand a bit because Unity does try to do a lot more than before, but that is still not an excuse when the delay becomes irritating factor of everyday work.

 

And you must compare. Unreal 4 and 5 both have near 0 editor recompile time. This is not only time saved, but also both patience and sanity. Unity has 0 excuse if Unreal can do it. That's why it's a shame Unity is more of a marketing company than a game engine.

After my current project, I'm moving to Unreal - Why should I prioritize an engine that doesn't prioritize their clients? They're just vomiting out beta features to please investors and nothing more - always incomplete features that never get fixed or updated unless you upgrade. Even the LTS versions are unstable and rarely patch the fixes you want. If there's a big bug, they'll just toss it out completely as an excuse to not patch LTS: "It's a new feature, not a bug fix".

Man...

 

In my opinion, Unity should not try and compete against Unreal. They have... in my opinion, largely different clients. I can understand the way Unity operates due to their business model. Subscription means you need to spread out and attract as many clients as possible so going into vast different industry as a result. I am ok with that as long as the operation that runs it matches the model it is going for. Some successful changes to subscriptions are the one such as Adobe photoshop. It does what it does and it doesn't really need to innovate that much. Game engine business however feels different, you need to choose what you are good at and razer focus on it. In my opinion, Unity's best advantage was the asset store, where creative solutions (work arounds) were available even if the engine fall short most of the time. But after moving to SRP, DOT, ECS things started going weird...also after subscription model, all sort of Editor overheads began to increase over the time.

In my opinion, Unity should unify the rendering pipeline, focus on editor improvement (both performance and customization) rebuild the fundamentals and let the community thrives on the platform. Unity wants to influence the movie industry? If the platform is solid, community will build the apps (plugin) for Unity that can really shine that. When you try and outreach every possible industry out of box, the result is slow innovation, lack of features and bugs, plus you won't be at best on anything.

 

*BUMP*

I just noticed yesterday, that I always had not enough time for my hobbies, family and everyday deals(like just cook a meal) because I everytime waiting for unity to make just one simple task, like launch play mode, recompile scripts or make a build with JUST ONE change of the field in my scriptable object so I can test it - it takes 10 minutes with minimal load of my Ryzen 5 4650g CPU and evo 970 m2 ssd. I just going crazy when see endless processes that can be at least paralelized. One guy from my work with laptop spend more time on waiting while project just importing or entering play mode than actually working on project. WHAT THE HELL?
Why Unity Editor re-draw it self on CPU every frame? Why I should buy tons of assets to just fix Unity, but in the end I should wait while it will import all of those assets? WHY UNITY WHY?! I hate you!

 

Here's what's happening: Unity is a game engine made by non technical folks that tell technical folks how to make the engine.

The entire backstory behind Unity is that a couple guys tried to make a game, but it ended up being too hard for them, so they slapped Unity together where it's awesome on the outside (this is how they got funded), but the inside is held by Walmart tape (the source of all issues here).

When you recompile, it's just blindly going through every asset in your entire assembly. All of them. To see if it changed. They are just blindly going through every single meta file you have in that assembly (hard drive reads) for changes instead of being smart about it.

Sure, we can get a badass SSD and CPU, but the ultimate bottleneck is Unitys design.

Now, let's look at the CEO that quotes we are "f***ing idiots if we don't monetize" (real quote, Google it). You can see the priorities on his mind that reflect all the updates in the past 5 years. They simply need to hook you in and you're bound to Unity - once you discover the underwhelming editor performance LATER, it's too late. So fixing this would not make them more money. Similar to a dev having bad, undocumented code to infinitely keep their job.

Now, stack this with bloated features that only minimally work, again held with Walmart tape (UNET). They'll release it in alpha form to save money and never look at this feature again. if a breaking bug pops up, theyll just abandon the feature. Have you ever wondered why they never improve existing features? They just replace them? Look at Unity Text, UNET, and even the LWRP type features. They outsource the feature, it adds to the bloat, no one knows how the hell to fix it, so they just sweep it under the carpet and build on top of it. If they actually pull out the backend to optimize it, they'll have to admit to their financial board that their engine is slow, which implies incompetence and negligence from past decisions.

Thus, we'll never get a fix because fixing performance (that you only notice when you're already invested) won't make them money. This isn't a game engine, it's a lemon that looks like a BMW.

The only way we'll get a real fix is if Elon Musk buys Unity, fires the CEO, then hands Unity decision making seats to actual technical people.

Well, what are you still doing here? Go Tweet @ElonMusk !

 

Im agree with anything except part about Elot Musk like lifesaver. Elon Musk same capitalist like unity investors. He does not give a S*** about technologies and he invented subscription to physical systems on his Tesla cars which already included in car by default(like air conditioning, seat heating) to just give them work. Like when you buy PC and you should pay subscription for your GPU to work at all.

 

They are working on DOTS which almost nobody will use in the end. Because DOTS itself overhead for the development. No one indie-company will use it for their projects, because Unity already has "everything" needed for just making games, but most systems just implemented in weird manner or half-baked. We mostly suffer not from engine performance. We suffer from editor performance and from editor limited functionality from the box. And of course everyone who works with shaders or even just use them aknowledged about this mess with URP/HDRP/BiRP. Who will use those DOTS? For RTS game with million of minions or what? What are percent of such games made on Unity?

 

Lets talk about today LTS 2021.3.11f1 - they broke "undo" action. UNDO Carl! And now it causes a crash randomly!
And released a patch only in 25 days!
I remember when before this they broke "1 frame Back" button in Animation window in LTS 2019 or something. And weird bug with joints(it was rotated out of limiters freely) in LTS 2018, where they officialy said that fix will not come to LTS release because its "not a stability issue" so you should upgrade to next non-lts version. Cool.

 

Heheh true about Musk - it'd still be an improvement, though, to Unity's current CEO.

Oh yeah, when they had Unity 5.6 beta, I reported a breaking bug both in the editor and forum they decided to ignore, when they added some gimpy FB standalone build. If you had FB SDK, Unity thought you were using that standalone build and suddenly you couldn't build ANY standalone except FB. Eg: Let's say you have Windows build with "Login with FB" - it'd fail.

In 2019, they broke async scene loading.

Up to this very day, there's still all kinds of Unicode issues even with TextMeshPro. I have no idea how or why Unity is still #1 in eastern Asia other than marketing.

Unity is just a box full of unlimited potential, but it's a Pandora's box.

 

Unity implemented the "Fast Enter PlayMode" feature in 2019, it can significantly speed up entering and exiting play mode. It certainly does for me.

1. https://forum.unity.com/threads/configurable-enter-play-mode.768689/
2. https://forum.unity.com/threads/insanely-fast-enter-to-play-mode.701930/

However, it requires a certain approach how you reset static variables in your code. When you have an existing code-base and just turn on this feature, it probably introduces side effects/issues that you have to fix.

Unfortunately, it doesn't solve the long waiting times when recompiling scripts. I believe there is pretty much nothing we can do about it at the time of writing.

 

In a sense they improved, by implementing assembly definitions.
You can compile libraries into dlls files too.

Because you don't understand tech, doesn't mean no one uses it.
Here is nearly 100 unique projects using DOTS.
https://forum.unity.com/threads/share-our-dots-showcases.1010215/
Various use cases, from paintball, to RTS games. Some of these are released.
And many more which are not even showcased there.