- Home /
Wait times when developing
I have Unity running in the background and currently have MonoDevelop focused in fullscreen. I type "int temp = 0;" somewhere (doesn't matter where), I save, I tab back into Unity and want to test my game. The game is networked so I need to start a seperate window and connect to the game running inside the Unity editor.
[0 sec] = I tabbed into Unity from MonoDevelop and press CTRL+B (shortcut for "Build & Run").
[5 sec] = Unity stops being frozen and CTRL+B happens (build started).
[9 sec] = The progress bar disappears (build done).
[17.5 sec] = The game's configuration window appears (built exe file runs). Unity stops being frozen and registers that I have clicked the play button (build started).
[21.5 sec] = The game is running inside Unity (build done).
I clocked all of this with a stopwatch (rounding downwards to account for my reaction time).
You can imagine how tiring it becomes to develop in Unity when you have to wait 22 seconds every time you want to test your game. On top of this there's also the 5 sec wait for the "made with unity personal edition" logo to disappear from the stand-alone window I need to build every time to test the network gameplay.
My question is: What can I do (besides buying new hardware) to reduce all this wait time?
At this point I would gladly turn off the precompiler just to at least spare me the 5 seconds of Unity being completely frozen every time I tab into it from MonoDevelop. My computer's hardware isn't that bad (Intel Core i7 @ 2.40GHz) and the project's Assets folder isn't even 1 MiB yet (only have 15 scripts so far) - I have no idea why there's so much waiting going on.
Just to be the guy that says the obvious thing and gets it out of the way: Why not do the majority of your testing within the unity editor? Then once your scripts compile, you can play. Hit play while still compiling to play asap.
Sorry but I don't understand your suggestion. How would any of this stop Unity from freezing for five seconds when I tab into the program from $$anonymous$$onoDevelop? And when exactly am I supposed to hit the play button, while the program is building a stand-alone executable? That doesn't work.
I meant that the majority of your test work can be done within the unity editor. I only test on standalone builds for major changes to ensure nothing explodes. For day to day, moment to moment tests, just hit the play button. Why not? Unless you're testing something specific to the standalone player, obviously.
I've built my year-long project about a dozen times. I've hit the editor play button to test a change umpteen thousands. Use the "maximize on play" option when prudent to maximize real estate.
When you edit and save a script, unity compiles it as soon as the editor regains focus. This is the first "wait" time you report, I think. You'll see a little circle "work" indicator in the bottom right. When it's finished, you can play instantly. If you click the play button while it's still going, it'll enter play mode once it's finished.
I just read that you're testing network play. I guess my suggestion is somewhat meaningless for that case?
Unfortunately I don't know of anything within your power to reduce the time between a script change and testing in the standalone player; superior hardware probably wouldn't make much difference.
22 seconds? Quit complaining. That's a phenomenally quick build speed, compared to historical engines.
Only suggestion would be to avoid frequent builds. When I build network stuff I typically leave the stand alone build running, and make all my changes in the editor version. Only create a new stand alone when you make big changes.
Answer by Mackam · May 14, 2015 at 01:54 PM
I've successfully reduced the time it takes to test my network game from 21.5 sec to 4 sec!
Sit down for a moment and I'll explain how I did it.
+ Compression
The main fault turned out to be the compression of assets. Disabling compression shaved off so much time that I wonder why it's even enabled by default (disk space is not much of a problem today while someone's time is always invaluable).
1) Edit > Preferences... > General
2) Uncheck "Compress Assets on Import"
3) Edit > Preferences... > GI Cache
4) Uncheck "Cache compression"
5) Press the Clean Cache button
6) Assets > Reimport All
Don't know how much time is saved from disabling cache compression for the GI Cache but I bet there's some time to gain there as well.
+ Two Unity Editors
Another huge improvement was running the game in two instances of Unity instead of building a stand-alone exe-file to act as the client or server. This also spares you from the 5 sec long Unity logo (that I didn't even include in my measured 21.5 sec).
1) Edit > Preferences... > External Tools
2) Uncheck "Editor Attaching"
3) Create a new, blank dummy Unity project in a new folder
4) Close Unity and navigate to the dummy project's folder
5) Delete the "Assets" and "ProjectSettings" subfolders
6) Open cmd.exe as Administrator
7) cd "DummyProjectFolderPath"
8) mklink /D "DummyProjectFolderPath\Assets" "RealProjectFolderPath\Assets"
9) mklink /D "DummyProjectFolderPath\ProjectSettings" "RealProjectFolderPath\ProjectSettings"
10) Create a batch file ("MyProjectName.bat") with two lines:
start "" "C:\Program Files\Unity\Editor\Unity.exe" -projectPath "DummyProjectFolderPath"
start "" "C:\Program Files\Unity\Editor\Unity.exe" -projectPath "RealProjectFolderPath"
11) Start working on your game by running the batch file from now on
Two instances of Unity will be opened, they both share the exact same Assets on disk (scripts etc) and will have the exact same settings (layer names etc) as long as you save the scene before tabbing to the other instance of Unity. The "mklink" program comes with Windows and is used here to create symbolic links to the two key directories of your real Unity project. Unity might notice that you are using symbolic links in which case it'll warn you that you have to know what you are doing, which we do (it doesn't actually affect anything).
Since you edit the same script files in two instances of Unity I don't know how well "editor attaching" would work. I'm disabling that feature just to be sure everything works, it's fine for me since I don't use it. If you need it you could try keeping it checked, maybe it works?
+ Anti-Virus interference
Unity can do its job a little bit faster if it is left alone by other processes. Exclude your real project and dummy project folders from being scanned by your anti-virus software and tell it to leave Unity.exe and MonoDevelop.exe alone as well.
If you just use the built-in Microsoft Security Essentials like me here's what you do:
1) Settings > Excluded files and locations
2) Browse for the dummy project folder, press Add
3) Browse for the real project folder, press Add
4) Save changes
5) Settings > Excluded processes
6) Browse for "C:\Program Files\Unity\Editor\Unity.exe", press Add
7) Browse for "C:\Program Files\Unity\MonoDevelop\bin\MonoDevelop.exe", press Add
8) Save changes
+ Standard Assets
When you change a script Unity will recompile ALL your scripts. Except those that are put in Standard Assets (unless you change a script in there, then Unity will still recompile all scripts).
So, make a folder named "Standard Assets" if there isn't one already. Alternatively you can name it "Plugins" or "Pro Standard Assets" instead but "Standard Assets" is nice since it will be sorted next to your "Scripts" folder if you have one named as such. Just make sure it is placed in the root of your project's Assets folder.
Drag-and-drop all scripts that you are finished with into this special "Standard Assets" folder. Or those that you know you won't update often. The only downside to this is that scripts in Standard Assets can't use scripts outside of that folder (can use other scripts inside that folder though, and outside scripts can use everything inside the Standard Assets folder).
If you get errors when dragging a script into the Standard Assets folder just keep dragging more scripts into it until the errors go away. If you need to make a change to a script in the Standard Assets folder don't be afraid to do it like normal, all that will happen is that Unity has to recompile all scripts in your project.
If you know you need to work a lot on a script in the Standard Assets folder you can drag it outside of the folder again to reduce compile time. If you get errors just keep dragging more scripts out of Standard Assets (those mentioned in the error messages) until you don't have any errors left.
Example: You have 100 scripts, 80 are inside Standard Assets. You make a change to 1 of the 20 scripts outside Standard Assets - Unity will recompile 20 scripts. You make a change to 1 of the 80 scripts inside Standard Assets - Unity will recompile all 100 scripts.
+ Conclusion
Now Unity is fun to work with again! Launching a test of my game is over 5 times faster.
In my opinion the developers should do everything they can to make all of these steps I just listed needless for anyone to do. In this day and age you should have a optimized workflow out of the box with no extra work needed, nobody likes wasting their time waiting around.
Edit: I got some major error once about things being out of sync ("Timestamps (52) and assets (50) maps out of sync"). This was fixed by closing both instances of Unity and then deleting the "Library" folder in both project maps. These are rebuilt automatically by Unity upon start and the error should be gone.
Edit 2: Sometimes one of the still-playing Unity Editors crashes after stopping playing the game in the other Unity Editor. This forces me to close the other one as well and run the batch file to open both instances of Unity again. I don't know why it crashes and have posted a question about it over here: http://answers.unity3d.com/questions/968218/unity-srashing-efter-losing-connection-to-other-un.html
Answer by Bunny83 · May 13, 2015 at 11:30 AM
Some hints:
Try to not mix multiple languages (C#, UnityScript, Boo). Stick with one. C# usually compiles faster than UnityScript.
Don't use the Standard Assets / plugins Folder except for things that really aren't changed. This should leave you with only one compilation group (besides editorscripts).
As you already said it seems you have quite old hardware, so this is probably the biggest point. If the question is "How can i make my Vespa go 300 MPH?" the answer is: "you can't".
You usually can open Unity two times, however only with different projects. So you might want to duplicate your project and open one for server one for client. Of course code changes only makes sense to do in one build. If you have a version control system you can checkout the project twice into seperate folders and commit changes from both projects.
Unity (or .NET in general) has incredible fast compilation times (like Pascal back in the old days, single-pass-compiler ftw). If you look at compilation times of a average complex C++ program you might wait 10 min up to several hours.
Program in a more "smart" way. So be sure that the changes you've made make sense. You might be testing too often. If you're not really developing / writing new code but more balancing / adjusting values you should add hotkeys to do that ingame. Don't forget to add debug output (simplest with OnGUI) so you know what you're doing.
If the "Made with Unity Personal" bugs you, buy the pro version ^^. However it won't change much since while the logo is displaying Unity actually starts up the engine.
Finally check if you have a crappy AntiVirus software which slows down file access. Even with a good one, if you have slow hardware (CPU, HDD) it might have already an impact.
(1) Not mixing languages, using only C#.
(2) "Standard Assets / plugins Folder"? What do you mean? I keep all my stuff in the project's Assets folder. I don't use anything that I haven't written myself.
(3) "Quite old hardware". I never said that, I said it isn't that bad. The CPU is actually still quite good: http://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-2760Q$$anonymous$$+%40+2.40GHz
(4) Yes, PsychoHead adviced me on running two instances of Unity. It cut the waiting times in half.
(5) I don't think compilation is what takes time, it's something that Unity does. Or something... the problem is I don't know.
(6) No matter how I program it still doesn't reduce the freeze time when I tab back into Unity, which is the whole issue here (well, plus that it takes 4 seconds to build a game with less than 1 $$anonymous$$iB Assets).
(7) The logo is no longer an issue now that I test with two instances of the Unity editor.
(8) I only use the built-in $$anonymous$$icrosoft Security Essentials. I added the project folders to its exception list as well as Unity.exe and $$anonymous$$onoDevelop.exe and actually noticed a little boost in performance. The wait time was reduced 1 or maybe even 2 seconds (unless I was just bad at clocking before), thanks for that tip!
Regarding (2), I've now understood what you meant and have tried using the secret "Standard Assets" folder to speed up compilation time. But it changed nothing; Unity is frozen for just as long regardless if it is compiling all of the C# scripts or just a single C# script. Edit: Wait, there is a difference. It's very small since I don't have many scripts but it's definitely there.
Answer by PsychoHead · May 13, 2015 at 06:16 AM
I think your question is: "How can I test my networking without waiting for the lengthy build process every time"?
In that case, there are free mirroring utilities for that. That way you can simply test it in two editor instances, which is more handy anyway.
(I'm pretty sure there has been something similar on the Asset Store, too. I just cant find it.)
$$anonymous$$y question also involves a way of reducing the 5 sec freeze Unity seems to do whenever I tab into it but I do appreciate your mirroring idea (opening two instances of Unity with the same project - although the project can't be the same so it must be duplicated). I'm having trouble finding any "free mirroring utilities" though, if you can recall the URL for any of those I'd appreciate it. I'll keep looking in the meanwhile. (I really think Unity should make some built-in solution for testing multiplayer games.)
Alright! Down to about 10.5 sec of waiting now. I made an empty Unity project, closed it and replaced its "Assets" and "ProjectSettings" folders with symbolic links (a built-in feature in Windows 7) to the real project's Assets and ProjectSettings folders. Everything works exactly the same in the two instances of Unity that I now have open and they use the same files. This is a lot better than having to build a executable, question is why Unity's official tutorial videos don't show how to do it this way since it's so much better...? (Unity really needs a better built-in way to test network applications, even if this works it's silly having to make two projects for the same project and having two instances of Unity open.) Now if I could only remove that freeze that happens whenever I tab into Unity, that sure is annoying... I should probably do a health check of my SSD to make sure that's not the problem. Edit: Checked, SSD health is at 100%.
That's a nice solution, good to know it works.
Regarding compilation time: Your Scripts need to compile at some point, there's no way around that. Thinking about previous workflows from other engines, which required much more time to compile, closing and reopening of the editor and similarly lengthy processes, those 10s are incredible fast.
It may be the time for a built-in solution for such testcases, now that the new networking is about to be released, yeah. On the other hand, that might not be priority #1...
You know something about the upco$$anonymous$$g networking release? Please share, I can't find any information about it from 2015. Posted a question about it a couple of days ago but nobody knew anything then: http://answers.unity3d.com/questions/961515/unity-multiplayer-aka-unet-aka-unity-networking.html
Also, I wouldn't have such a problem with the compile time if it only happened in the background without completely freezing the editor. I've noticed I can uncheck "auto refresh" in Preferences > General but then it won't discover any new files and I have to remember to press CTRL+R before pressing CTRL+P. If there was a way to keep auto refresh on but not compile any scripts until I press CTRL+P (and with no need to press anything before pressing CTRL+P) I'd be a happier camper.