Search Unity

Play Mode(플레이 모드)를 이용하면 Unity를 더욱 다채롭게 활용할 수 있습니다. 프로젝트가 복잡해질수록 Play Mode를 시작하는 데 걸리는 시간이 길어지며, Play Mode를 빠르게 시작하고 종료할 수 있어야 변경 사항을 신속하게 적용하고 테스트할 수 있습니다. 이번 Unity 2019.3 베타에서는 이 기능을 구현한 Configurable Enter Play Mode(설정 가능한 플레이 모드 진입)를 실험적으로 도입했습니다.

에디터에서 Play Mode에 진입하면 Unity가 스크립팅 상태(도메인 리로드)를 재설정하고 씬을 리로드합니다. 이 과정에는 일정 시간이 소요되며, 프로젝트가 복잡할수록 Play Mode에서 새로운 변경 사항을 테스트하기 위해 대기하는 시간이 길어집니다. 하지만 Unity 2019.3 베타 버전부터는 ‘도메인 리로드’ 및 ‘씬 리로드’ 동작을 각각 또는 동시에 비활성화할 수 있는 옵션이 제공됩니다.

자체 테스트 결과에 따르면, 이 옵션으로 인해 프로젝트에 따라 대기 시간이 최소 50%에서 최대 90%까지 단축되었습니다.

유니티는 자체 FPS 샘플인 AA 제작물 ‘메가시티(Megacity)’와 빈 프로젝트에서 Configurable Enter Play Mode 테스트를 진행했습니다. 이 그래프는 에디터가 Play Mode에 진입하기까지 걸리는 시간을 초 단위로 보여주며, 숫자가 낮을수록 좋습니다.

Edit > Project Settings > Editor에서 Enter Play Mode 옵션을 클릭하면 Reload Domain 및 Reload Scene 옵션이 활성화됩니다. 기술 자료에서 Play Mode 설정 방법에 대해 더 자세한 내용을 확인하실 수 있습니다.

이 옵션을 사용하면 코드 변경 사항이 없는 경우에 Enter Play Mode 과정에서 도메인 또는 씬이 리로드되지 않도록 비활성화할 수 있습니다. Play Mode에 진입하기 전에 게임 상태를 재설정하려면 API와 콜백을 통해 이 기능을 사용할 수 있습니다.

아래 다이어그램은 Reload Domain Reload Scene을 비활성화하기 전과 후의 Enter Play Mode 프로세스를 보여줍니다.

Play Mode에 진입할 때 Unity에서 수행하는 단계는 기술 자료를 통해 자세히 살펴보실 수 있습니다.

이 기능은 현재 실험 단계이며, 일부 Unity 패키지에서는 Reload Domain Reload Scene을 비활성화할 수 없습니다. 오류가 발생한 경우 포럼을 통해 공유해주시기 바랍니다.

Reload Domain 비활성화 후 스크립트 수정 방법

Reload Domain을 비활성화한 후에는 Play Mode에 진입했을 때 스크립팅 상태가 올바르게 재설정되도록 반드시 스크립트의 정적 필드 및 정적 이벤트 핸들러를 조정해야 합니다.

다음 코드 예시에는 플레이어가 점프 버튼을 누르는 횟수를 집계하는 카운터가 있습니다. Reload Domain이 활성화된 경우, 이 카운터는 Play Mode에 진입할 때 자동으로 0으로 재설정됩니다. Reload Domain을 비활성화하면 카운터가 재설정되지 않으며 Play Mode 진입 및 종료 시의 값을 유지합니다. 즉, 이전 실행 시 카운터 값이 변경되었다면 에디터에서 프로젝트를 다시 실행했을 때 0으로 표시되지 않을 수 있습니다.

[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)] 속성을 사용하고, 값을 명시적으로 재설정하여 Reload Domain이 비활성화된 상태에서도 카운터가 올바르게 재설정되도록 하세요. 예:

Reload Domain을 비활성화한 경우 Play Mode를 종료해도 Unity가 정적 이벤트 핸들러로부터 메서드를 등록 해제하지 않습니다. 따라서 정적 이벤트 핸들러에 메서드를 등록하는 코드가 있는 경우 복잡한 문제로 이어질 수 있습니다. 예를 들어, 에디터에서 프로젝트를 처음으로 플레이하는 경우 메서드가 통상적으로 등록됩니다. 하지만 프로젝트를 다시 플레이하는 순간 해당 메서드는 첫 번째에 이어 두 번째로 등록되어 이벤트 발생 시 두 번 호출됩니다.

다음 코드는 정적 이벤트 핸들러 Application.quitting에 메서드를 등록합니다.

Reload Domain이 비활성화된 경우, 위 예시에서는 Play Mode에 진입할 때마다 Quit 메서드를 다시 추가하며, Play Mode를 종료할 때마다 추가적인 ‘Quitting’ 메시지가 표시됩니다.

[RuntimeInitializeOnLoadMethod] 속성을 사용하고 메서드를 확실히 등록 취소하여 두 번 추가되지 않도록 합니다.

Reload Domain이 비활성화되었을 때 스크립트가 올바르게 실행되도록 수정하는 방법은 유니티 기술 자료에서 보실 수 있습니다.

에셋 스토어

유니티는 인기 에셋 스토어 패키지에서 Reload Domain 및 Reload Scene 옵션을 비활성화할 수 있도록 지원하고자 합니다. 프로젝트에서 문제가 발생하면 에셋 패키지 퍼블리셔에게 알려주세요. 

Unity 2019.3 베타 참여

Play Mode에 진입하는 데 시간이 오래 걸리는 프로젝트의 경우, 이 기능을 통해 시간을 상당히 단축할 수 있습니다. Unity 2019.3 베타에 참여하여 새로운 기능을 직접 사용해보고 포럼에서 의견을 공유해 주세요! 현재 실험 단계에 있는 기능이므로 사용자의 필요에 따라 얼마든지 수정될 수 있습니다. 개발 중 발생한 문제들을 공유해주시기 바랍니다.

이 기능을 먼저 테스트해보고 소중한 피드백을 제공해주신 @Sini, @chrisk, @Peter77, @Baste님께 감사의 말씀을 전합니다.

26 replies on “더욱 빨라진 Unity 2019.3 버전 Enter Play Mode”

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

Options in File > Project Settings > Editor,

by

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.

Wow!
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.