Search Unity

Play Mode is at the core of what makes Unity fun to work with. But as your projects get more complex, it can take a while to get started. The faster you can enter and exit Play Mode, the faster you can make and test changes. That’s why we’re introducing Configurable Enter Play Mode in Unity 2019.3 beta as an experimental feature.

Currently, when you enter Play Mode in the Editor, Unity does two things: it resets the scripting states (Domain Reload) and reloads the Scene. This takes time, and the more complex your project gets, the longer you need to wait to test out new changes in Play Mode. Starting with Unity 2019.3 beta, however, you’ll have an option to disable either, or both, of the “Domain Reload” and “Scene Reload” actions.

Based on our test results, this can save you up to 50-90% of waiting time, depending on your project.

We’ve tested Configurable Enter Play Mode with an AA production title, our FPS Sample, Megacity, and an empty project. The graph represents the seconds it took for the Editor to enter Play Mode, smaller numbers are better.

When you enable Enter Play Mode Options in File > Project Settings > Editor, you’ll see that the options to reload Domain and reload Scene become available. Check out How to configure Play Mode in the documentation for more details.

These options allow you to disable Domain and/or Scene reloading from the Enter Play Mode process when there are no code changes. You can also access this feature through an API and a Callback if you want to reset the game state before entering Play Mode.

The diagram below shows the Enter Play Mode process before and after you disable Reload Domain and Reload Scene:

See more details on the processes that Unity goes through when entering Play Mode in the documentation.

Note that this feature is currently experimental and not all Unity packages are validated to work with disabled Domain and Scene Reloading. Please let us know on the forum if you run into any issues!

How to modify your scripts correctly when you’ve disabled Domain Reload

As you can see, avoiding Domain reload is very simple, but it comes at a cost. You need to make adjustments to static fields and static event handlers in your scripts to ensure your scripting states reset correctly when Play Mode is entered.

The following code example has a counter which goes up when the player presses the Jump button. When Domain Reloading is enabled, the counter automatically resets to zero when entering Play Mode. After you disable Domain Reloading, the counter doesn’t reset; it keeps its value in and out of Play Mode. This means that on the second run of your Project in the Editor, the counter might not be at zero if it changed in the previous run.

Use the [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)] attribute, and reset the value explicitly to make sure the counter resets correctly when Domain Reloading is disabled. Example:

After you’ve disabled Domain Reloading, Unity won’t unregister methods from static event handlers when you exit Play Mode. This can lead to complications if you have code that registers methods with static event handlers. For example, on the first Play of your project in the Editor, methods would be registered as normal. However, on the second Play of your project, those methods would be registered a second time in addition to the first, and would, therefore, be called twice when the event occurs.

The following code registers a method with the static event handler Application.quitting:

When Domain Reloading is disabled, the above example adds the Quit method again each time you enter Play Mode. This results in an additional “Quitting” message each time you exit Play Mode.

Use the [RuntimeInitializeOnLoadMethod] attribute, and unregister the method explicitly so that it isn’t added twice:

See more details on modifying your scripts to perform correctly when Domain Reload is disabled in our documentation.

Asset Store

We would like to make sure that popular Asset Store packages work with disabled Domain and Scene Reloading. You can help us by reporting any problems you encounter in your projects to the publishers of your asset packages. 

Join Unity 2019.3 beta!

We believe that if your project is currently slow to enter Play Mode, this feature will speed things up significantly. Join Unity 2019.3 beta and try it out,  we’re looking forward to hearing what you think on the forum! Since this feature is experimental, you can still help us shape it so that it fits your needs. We’re especially looking forward to hearing about any issues that you come across.

Huge thanks to forum users @Sini, @chrisk, @Peter77, and @Baste who have already helped the whole community out by testing this feature and providing invaluable feedback.

26 replies on “Enter Play Mode faster in Unity 2019.3”

In my case, this function is wonderful. Thank you very much.
It would be good if you change

Options in File > Project Settings > Editor,


Options in Edit > Project Settings > Editor.

Have a nice day.

Why not just having an attribute to add to the fields/properties we want to be reset instead directly?
Like [InitializeOnLoadField]

I’ve tried InitializeOnLoadField approach and found that it introduces more issues than helps the feature.
There are mostly performance reasons:
1) Scanning for all fields of all classes in the domain is expensive – even with mono native api it takes 600ms on empty project (and seconds on big projects)
2) Static fields are initialized as a part of static class constructor. Simple 0 init case is trivial, but if there is anything else you basically have to split static constructor into 2 methods during compilation which involves a lot of changes in Mono, increases compile/jit times and is very risky.
TBH perhaps I exaggerated the issue with statics reset – in reality more likely you have a few singletons which might make sense to reset. If you don’t do any reset – the worst you can get is that you e.g. get asserts if you have any checks for singletons must be null, start playing from the same position you were last PlayMode cycle, etc. Which might be enough not not use the feature for existing projects. But if in the new project you rely on Awake/OnEnable for initialization (singletons, statics), then you will not have any issues.

I just turned that on and playback is now instant!
Great for physics tuning, setting up a scene, doing some lighting and testing it in playback.
The extra [init stuff] is verbose, make it more HumanReadable

Saving a few seconds of your time to enter play mode doesn’t make much sense if you have to first spend a few hours (or days, for large projects) to fix all your code and make it compatible. And even after all the code is adjusted, you’ll always have to keep writing additional lines of code in the future as your project grows + spend more of your time hunting for obscure bugs happening because you forgot to reset correctly some variables. Won’t all of that essentially eliminate any time and productivity advantage gained through faster entering of play mode? Maybe a feature like that would make more sense if it came with an editor extension script (or something like that) automatically resetting all static variables and stuff.

We have it on our roadmap for the future to be able to customize the toolbar UI and use that to hook up this feature to toolbar buttons.

It is not that much of the code you have to change and maintain (can’t say for all projects, but for ones I saw). Some projects have very real 10-20 seconds wait time when entering Play Mode. You can taken that down to 1-2 seconds with this feature and then have happy artists on the team. Yes, when coding you have to keep 1-2 extra things in mind, but it is a low cost in most cases.
If you don’t have any issues with existing workflow – you can keep it as is. But if you have and want to iterate faster on your game we are opening new possibilities and working on a better tooling to highlight performance issues. The goal is that you enjoy you time in Unity Editor

How about quick access drodown in Play window for these Domain/Scene reload options?. this seems like the kind of thing which need to frequently accessed when going through rapid scrip iteration cycles. Sometimes i would want to enter as fast as possible if all i have changed is inspector values etc. but if i am doing significant code changes , i might seek domain reload to be able to validate the edits properly. This is far more relevant for someone like me , whoa is the sole designer/programmer in a very small team.

Totally agree, Have it as a separate play button with a rebuild script will be nice, sometines you want a quick play to balance the game and sometimes you want your code to be rebuild. Anyway, this is a great feature!

Yes, I agree. Wouldn’t it be easier to add another button to the main UI in the editor?
Instead of hiding it away in the settings menu? Maybe Refresh / Play / Pause / Step ?

well those workarounds to reset the statics and other stuff looks really dodgy.. I’m sure there is a way to have this performance boost and yet hide all that manual resetting of variables away from devs.. it sounds like another potential source of bugs and funky behaviors (even though only in editor)

Add the drop down UI near to enter play mode triangle. In order to faster switching between play modes and not go into settins each time.

Seems like holding a modifier key (or two) or providing a dropdown (or right-click popup) beside the play button to fast-select the mode you want to be in would be much more useful than digging into project configuration options, since sometimes I just want to nuke it all to debug something by performing a full domain reload, but this wouldn’t be often.
It would be LOADS better for FLOW to give users a fast way to access these options only a moment before pressing play…. A menu is not the right way forward for this — even temporarily.

I think what TextusGames meant was that sometimes you would want to change it to domain reload, scene reload, both, or none.
Basically sometimes we may not always want the same setting.

The decision, whether or not to adjust your script lifecycle to this needs to be done globally for your team. All coders need to keep this in mind while writing code. It’s then either turned on, giving you the benefit, or turned off, not introducing odd bugs. Leaving it up to individual team members to use it ad-hoc would be doing them a disfavor. This is not a “just hot patch my quick code/scene change in” toggle after all.

Would there be any way for the Editor to run some diagnostics automatically for us and find all these things that will break with the domain/scene reload disabled? The feature itself sounds incredibly cool, but could also cause a mountain of both initial and ongoing work to make sure that something insidious isn’t breaking the game because somebody forgot to reset a static.

Not in the 2019.3 release. In the short term the goal is to collect the feedback and get better understanding of what are the pain points with the experimental workflow.
I’ve highlighted the potential issue that had been already found in the forum post. Once we have a better coverage and a confidence that this mode is beneficial, we can design the tooling (e.g. static analysis) which can help with making sure project is not broken after code modifications.
And then move the feature out of the “experimental”. Please let us know what works and especially what not :)

AA production? Surely you mean AAA? AA is not an industry accepted term as far as I can see and google seems to agree.

AA games refer to games that do not reach the same scope as AAA games. It’s pretty common to see it pop up in dev circles in discussions about game budget and scope.

AA is pretty commonly referred to as higher-end indie games that have a larger budget and scope than most indie games, but is still a much smaller team/budget than a AAA production.

Can also go the other direction: smaller scale non-indie contract work for a publisher with a budget higher than your regular indie but not reaching the hundreds of millions of AAA projects.

Comments are closed.