Feedback Recompile + Enter Play Mode Process

Hi Unity devs, (@alexeyzakharov @Justinasg)

Since I moved from 2019.1.5 my workflow has really taken a hit, due to something that might sound insignificant to you but that's had a non-negligible impact for me (projects like Ghost of a Tale tend to be rather large).

The issue in the 2019.3 beta10 is that as soon as I modify a script and then go back to the editor for a recompile, the editor becomes completely frozen (unresponsive) right away. In 2019.1 there was a two seconds window during which the recompile process started but you could still click on the play button. So in effect you were able to daisy-chain recompilation + enter play mode in one single click.

But now with the editor getting frozen right away I have to wait for 15s for the recompile process to finish in order to be able to then click on the play button and wait another 10s before entering play mode. That is super disruptive (as of course happens hundreds of times per day).

Is there a chance you guys could have a look into this please?

 

@lukaszunity How about Unity finally implements a responsive UI, so our entire editor is not frozen when it's doing some background tasks ? Proper approach to those use cases would be to display a tooltip "compiling..." while still allowing us to use the editor using the old compiled sources and refresh it when it's done.

Take a look at VS 2019, it launches much faster those days, while finalizing some background tasks as you start working with the solution.

This way Seith could still click Play button even while compilation is in progress and it will wait untill the process is done before triggering play mode.

 

Being able to tab back to the editor and press play before compilation was finished is one of the few things that makes programming for Unity at all bearable. Whenever there's a pause that's longer than 5+, it's very easy to get distracted and check email or forums or whatever, so the 5+ second pause becomes a 5 minute one. This change makes it so that we have two of those 5+ second delays instead of one. Every_single_time we make a code change.

If you break this, you've made a net negative impact on editor usability in the 2019 cycle. So please don't.


You're creating all of these features around entering play mode and whatnot that's supposed to improve the experience, but then you just keep making it worse by breaking stuff like this.

It feels like understanding the usability of the editor isn't a priority at all for you, and that's really frustrating.

 

for me it is an improvement. in the old version, I either:
- pressed play while compiling, not get feedback, press play again, then when domain reloaded it immediately exited play mode
- or if Unity managed to enter play mode and then reload the assembly, I needed to stop and then re-enter play mode because either our code or some 3rd party plugin I have breaks (because of singleton abuse and init non serializable state in Awake())

now at least Unity is already reloading when I focus.
an improvement could be to make the play button still responsive even when reloading (write that part of UI in c+?)
(ideally I'd like partial reload of only the recompiled assemblies and dependencies, but that is on Mono to support first)

or: add ability to only load some of the assemblies for a given editor session (like on-demand import of assets)

 

That wouldn't help much, as it's horrible for editing editor scripts. I don't want to enter play mode when I just made an edit to a ScriptableObject's Editor, or something like that. I don't usually work exclusively with editor scripts or exclusively with gameplay scripts. Instead, I work with both in tandem, so I generally want to enter playmode after switching to Unity about every other time.

There's essentially two things I want to be preserved:
- I should be able to alt+tab to the editor, and have it recompile, reload assemblies, and enter play mode as soon as possible. This is ideal when editing gameplay scripts.
I should be able to alt+tab to the editor, and have it recompile, reload assemblies, and not enter playmode. This is ideal when editing editor scripts.

The current (old) implementation manages to do both fine, because there's a window after I alt+tab where I can press ctrl+p to activate the play mode button, which is blocked from entering play mode until recompilation and assembly reload is finished. That that wasn't intended doesn't mean that it's not good.


The community has been asking you to get the main Unity Editor window and the play button off the main thread since forever, though that's usually asked for so there's a way to break out of infinite loops without killing the editor. This might be the time to actually do that.

 

I agree that this is a frustrating change. I don't want to auto-play every time I tab back in. Maybe have the blocking "compiling scripts" pop-up include a Steam-style "play when done" button that we can click, as a way to emulate the old behavior of being able to click Play during those couple of seconds before the whole editor hangs?

 

What about background importing on another tread?
So the editor does not get blocked during import.

 

One workaround might be to use Visual Studio's "Attach to unity and play" debug configuration:


It's not ideal to enter debug mode, but at least until there's a better solution you can enter play mode right after compiling

 

Where is Attach to unity and play located?

 

The only way I see to get rid of the long pause in the recompilation is to get rid of AppDomain Reload completely.
A single line of change in the source code in a tiny assembly will trigger AppDomain Reload and it will completely reload all the assemblies. Pretty crazy, right?
There is no way to get around in the current system.
The good news is that .Net Core can manage assemblies in finer granularity and it can just reload only the changed assemblies. Imagine less than a second compilation including reloading.

We should push Unity to move to .Net Core as soon as possible. That's when we can call it Unity updated for the 21st century.

 

There was a prototype to port Unity to .NET Core, but only a prototype: https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/

It should be possible, but the efforts aren't to be taken lightly.

I would love to see assembly load context in Unity. It really would end all this AppDomain reload insanity.
But again, porting something this old and large isn't cheap.
I'm not sure we'll ever see it land.

 

It's in this drop down menu:


I'm using Visual Studio 2019 with the Unity plugin.

 

Not to put too fine a point on it, but why does unity sit in the background doing nothing when you save changes to the code, and then grab the interface away from you the moment you alt-tab back? That's almost willfully rude.

 

With Visual Studio 2019, by default it actually compiles as soon as you hit save... and I absolutely can't stand it. It was constantly spinning up compilation and recompilation and re-recompilation while I was trying to get work done in VS, so I disabled it. Not to mention Unity occasionally crashing out from under me while I was making changes to script files in VS.

 

It sounds like a good short-term workaround for me. I had actually implemented this myself in older Unity versions

 

Alright. I'm warning you, this is going to be a rant. And an open letter to the developers of Unity.

That thing I brought up in the opening post is merely a symptom.

The problem is that almost none of you guys are working on very large AA or AAA games using your own engine (Unity). That is the crux of the issue.

And I'm not talking about making impressive demos, which are basically cinematic sequences destined to prove to the world that Unity can do amazing graphics. You know what? You've already proven this a couple of years ago.

What you have NOT yet proven, however, is that Unity is designed for top-notch development of rather large and demanding games (and yes I'm including Ghost of a Tale in this).

What you're missing is the deep seamless experience that a game is expected to be nowadays. It's not just about the visuals (I can't believe I'm saying that) on a 50m by 50m with baked static effects that can have no real application in an actual interactive production where the camera could be anywhere at any time.

If you guys had to live through the actual realities that teams like ours are living through on a daily basis you would go "wait that's crazy we should address that". We have to wait almost thirty seconds every time we need to make a small code change and test it in-game. Now multiply this by a hundred times or more during the day.

The Unreal Engine can enter game mode almost instantly. But you know what it doesn't have? The elegance and ease of use of Unity. The Unreal Engine is a work horse that's designed from the ground up to be a powerful game engine. Unity is much more user-friendly but it's also trying to be many things to many people.

When you guys make demos on stages around the world or show off the engine to students, the issues of inefficiency and time-wasting are never broached because on such a small level they almost don't register. But do you want Unity to keep being considered an entry-level engine in the game industry because of this? By all means if you're satisfied with that state of things then fine, I'm the fool for not understanding that sooner.

I want to keep using Unity. But you guys need to take the needs of producing larger games into account. All of your users will eventually benefit from it.

Now Lukasz, I thank you for your reply. But there should not have to be a "voting" on that issue. This is not a matter of opinion and even less a popularity contest. Please, do bring this up to your management and hopefully they'll realize a fundamental shift in priorities needs to happen at some point.

 

Very well said Seith, I can't agree more with you.

Unity should stop making eye-candies for every event. We've all seen it and I believe it's very capable. Seeing it more doesn't make me excited and perceived as an excuse to show something by pressure.

What about making an AAA game? Does Unity scale up? Hell no. It's an on-going battle fighting the sluggish Editor every day.

Yeah, Unity has employees who had experiences working on AAA titles but did they use Unity to make it? If not, it doesn't really matter.

So, stop mucking around eye-candies. Yeah, it's important but what's more important is the core. The core of Unity is to make a game, not eye-candies. And It must scaleup with as efficiently as possible.

Enough said, and you should make a slogan "Performance by Default for the Editor!" It benefits everyone immediately and I rather have a performant editor that I use everyday first than DOTS.

Kill some projects if you have to and move to .Net Core as soon as possible to get rid of the crazy AppDomain Reload. I don't see any better way.

 

Please can we get this in 2019.3 release?

 

What? .NET Core? Editor Performance by Default? Basically anything? Considering Unity's track record, it's going to take a few years at the very least.

 

Editor performance and immediate entrance to play mode

 

Yeah, considering Unity's track record, it will take a while. Right now, the closest you're getting to that is throwing static variables out the window (preferred option, can also use an ugly reset method) and using 2019.3's experimental enter play mode options.

Before someone asks for examples of Unity's track record: nested prefabs (2018.3), updated .NET (experimental in 2017.1, released in 2018.1), free dark theme ("news on that in 2020")...

 

Yeah, time in Unity goes about 2 or 3 times slower and it may take a while but we have to keep asking.
My goal right now is to put .Net Core port on the Roadmap.
If you fart long enough, S*** will finally come out.

 

May I ask why do you need .Net Core in Unity?

 

Right now to change a single dll, you will have to unload everything and then load everything using AppDomain system.
The compilation itself can take less a second for a simple assembly but reloading every assembly again can take up to 10s of seconds. Pretty dumb, right?

But .Net Core allows you to manage individual dlls. (AssemblyLoadContext). It will allow you to swap just the changed dll pretty much instantly. And it will also be possible to hot-swap dlls during runtime. This is a holy-grail of fast development.

I'm not the only one who is excited.
https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/

Also .Net Core runtime is really fast. I saw some reports that .Net Core is as fast as having Burst compiler. That's without us doing anything special.

So what's keeping us from using .Net Core? Only Unity can answer.

 

Where did you hear that?

 

https://twitter.com/unity3d/status/1184887255476953088
A few places in the forum too.

 

What Unity seems to be missing with DOTS is that it's a whole new paradigm and some people just want an updated and cleaner (avoid reflection, use override/interfaces instead...) MonoBehaviour (some ASAP). Write the whole engine in DOTS for all I care, but show MonoBehaviour some love too. No, this isn't a "MonoBehaviour removal?" panic post. What happened to "ScriptBehaviour"? Did it get moved to the rock bottom of their backlog like auto property serialization basically was?

 

Hi!

One of the things causing a bit of a disconnect here is that all of the things you're talking about is new stuff. It's a lot of "hey, we need to rebuild all of the core systems so things can go fast!". What we're saying is that editing in Unity the way it is now - ie. with no DOTS - was faster, back in the Unity 4 days. There's a real sentiment that you have regressed, especially in regards to how the editor itself performs.

Look at this test by the wonderful @Peter77. In the latest versions of Unity, the base overhead cost of entering play mode in an empty game is 2x what it was in Unity 4. That means that there's been a buildup of cruft that we as Unity users can do nothing about that's costing us a bunch of time.

And no amount of DOTS can help, since there's no way the conversion workflow or other optimizations on how we do things are going to be faster than not having anything in the scene at all. Which means that you might be barking up the wrong tree.


In other words, it feels like you're only pursuing big, interesting ways of making the engine faster, instead of doing the boring work of fixing all of the thousand tiny little inefficiencies that you've introduced over the last five years.

 

This might seems crazy but I think Unity should just start from scratch a new Engine like Epic did and keep supporting current ones with performance & bug fixes. Upgrading this old behemoth mammoth and making sure every projects is compatible with the latest features of Unity is a heck of a job and takes tremendous amount of time. Hence the reason why many features in Unity are buggy or takes ages to mature or even get fully implemented. Trying to be everything for everyone just slow downs everybody and is quite painful. At some point you have to fragment your userbase with different kind of software, tools and services like Autodesk and Adobe do.
They should create a large scale game with and adapt the editor & engine to it.

 

Again, thank you for this information, Will.

What worries me most about this is the time it's going to take to get all of what you mentioned into a production-ready state. I understand Unity is more or less undergoing a structural change at the moment and I do not foresee all of this to be stable and usable before at least a year. More likely two (more if there are serious hurdles on the way).

I know you guys are doing everything you can of course. And I suppose the real question for some of us users is going to be "Can we wrap our development calendar around Unity's"...

 

@lukaszunity, Yeah, moving to .Net Core will involve quite a bit of change, however despite of the excuses, I don't see a future Unity with Mono. You know you will have to move to .Net Core in order to escape from the AppDomain reload hell. There is no other way around. If you don't want to do that, on other options is to rewrite AppDomain reload yourself. You have the full source and it might be easier for the interim solution.

Instead of making the effort by a single person pet project, Unity should invest a lot more time and effort moving as soon as possible. I mean a lot more time. Until you make the commitment on the Roadmap, I don't see it it will happen.

Perhaps build Unity V2 might be a better idea to leave all the baggages behind.

I think adding new tech stacks on top of decades-old technologies will be increasingly difficult and we are all suffering ever getting slower editor. It was ok in early 2000 but not anymore.

 

About the problem raised by the OP, I honestly cannot comprehend how this is not taken as a major issue. We are not talking about minor inconvenience that developers can work with until it eventually gets fixed, we are talking about a truly hostile ux. Please don't ask us to file an issue and go vote for it on the issue tracker, I personally find that almost offensive for an issue like that.
I wish the unity engineers working on the feature (asset pipeline v2) had a better idea of the day to day experience of developers using unity with medium to big projects; surely the issue would have been caught sooner.

 

yes please!

 

You have badly misunderstood this thread.

People are asking for less technology churn and more attention paid to moment-to-moment use, and you replied with this fulsome promise that Unity will be techier and churnier than ever before once the bold futuristic vision is finalized eighteen months from now.

You read requests for less of a thing, and responded by swearing to double down on that thing.

Let's start reading.

 

Sorry, is there a "click here to upvote this issue" link? This is a huge usability regression.

 

how about HDRP package? a Blank HDRP project takes about 10s+ to reload, so, should i consider HDRP as "third party code " and remove it ? since DOTS only support HDRP, so, should i remove DOTS either ?

why not fire an Migrating to .NET issue and let's vote? i definely use up my votes on that.

 

Hey, just finding that having to wait for the compile to press play is actually having a big effect on my productivity. It may not sound like much but it's another step that you have to nurse along multiplied by the amount of times you do it in a day. It's draining watching the spinning compile icon all day.

Did anyone come up with a workable solution?
I'm using VSCode, I have the Unity plugin but I haven't found the "Attach to unity and play" option there. Does that exist in that editor?

Also if it's easy to make a script that plays after compilation, could you consider making an example script? I've been trying but I can't get anything working.

 

Unfortunately, so far the only workable solution I've found for this and other 2019.3 issues is to stay with 2019.2 for as long as possible.

 

Just to chime in about HDRP (2019.3) enter-playmode times:

Between saving a 1-line change to a c# file and being able to interact with my scene in play mode is timing out at 33s for me. If I don't modify any c# files, its 18-25s, usually about 22s. My project is only 3k LOC so I'm getting a little (edit: more than a little) apprehensive about what this will look like 6 months from now. It really, really adds up over the course of a day.

 

Has anyone that's experienced a severe regression from 2019.2 to 2019.3 actually sent a bug report with a repro project? Otherwise it will probably not get fixed.

 

Obviously when possible, but a lot of these usability and functionality regressions are teetering into "By Design" territory, such as the editor reskin or the "fix" to prevent being able to press the Play button immediately after tabbing back into the editor before script compilation kicks off.

 

How about having some code in a separate thread and listens for the CTRL P input, then triggers the Play button when compilation is done?
This would fit on top of whatever future compilation improvements you guys make (DOTS etc) so it wouldn't be wasted work. Even if you reduce the compilation time, a dev workflow is typically to save code changers, alt tab, smash ctrl p or play in very quick succession, so there is no guarantee you will ever get compilation fast enough for this. Having a separate thread queue the action up solves the issue no matter the result of the speed improvements.
It's been said many times but this simple thing really does degrade the Unity dev experience.