Resolved Can I use Thread.Sleep(milliseconds) instead of a coroutine to pause a script?

Hey, so I was wondering if you can say

using System.Threading;

at the top then saying

Thread.Sleep(milliseconds)

to pause the script for however long you want instead of using a coroutine. Can I do that?

 

No. Unity is (more or less) a single-threaded application. Sleeping outside of a thread will freeze your entire application.

 

Oh. Well that kinda sucks

 

If you don't like writing coroutines, you can do most anything you would do in a coroutine in the Update method instead. Sometimes that makes it easier to understand as well.

 

But does the update method have an adjustable wait time?

 

You can wait via a timer pattern:

Code (CSharp):

1. float timer = 0f;
2.  
3. void Update () {
4.   timer += Time.deltaTime;
5.   if( timer > someAmount ) {
6.     // do something
7.   }
8. }

What is your aversion to coroutines?

 

Hmm, so if deltaTime (fps) is greater than how long I want to wait? Then it will do something?

 

You'd add Time.deltaTime to the running timer, then compare the running timer to how long you want to wait to decide to do something. If you just are checking Time.deltaTime itself to see if it is greater than how long you want to wait, then your check will likely never be true on good hardware and always be true on decade old hardware, since you're really just checking how long it took the hardware to complete the last frame (old and crappy hardware generally results in longer frame times).

You don't want to accidentally code your game to require a 10 year old CPU

 

Got it

 

I can't speak for OP, but personally I am averse to co-routines because at first glance, I would have to restructure mutliple codes i've written in order to add a single feature to a game which I'm not 100% sure is necessary. It's probably not hard to learn it, but rewriting a bunch of codes to accomodate coroutines so I can make my code wait ten seconds and check if my player's health is still <1 doesn't seem like a fun saturday night.

I also don't want to use too many things in the update method - not limiting your use of the update method causes modern machines to overheat, especially since stock machines off the shelf tend to use too much power while lacking heatsinks.

 

You can check your players health in the Update method without overheating your computer . A coroutine yielding on WaitForSeconds would be testing a counter each frame behind the scenes anyway.

 

It's highly unlikely that typical game logic will cause "modern machines to overheat" unless they call into something heavy (explicitly, like a physics query, spawning objects, or searching the scene for things; or implictly, like generating garbage that the GC needs to handle).

Think of it this way. Note that these are VERY rough calculations to illustrate a point.

• An if statement is between 2 to 20 cycles.
• Fetching memory that's not in CPU cache is ~200 cycles...
  • So you can do ~10-100 if statements (minus calculating the condition) per myObject.transform.
• A modern processor (we'll say 3 GHz) does ~3,000,000,000 cycles per core per second.

For let's say half of your performance to be dominated by the body of your update function, you would need to be using ~3 billion / 60 FPS * 50% = 25 million cycles... or ~millions of if statements (depending on branch prediction).

Other overheads (ex: Unity Engine needing to queue those Update() calls) will add up first... unless, of course, your Update() function calls into some very heavy things. You will see that stuff on the profiler.

It makes sense if you think about it -- your scripts will typically run ~dozens of items per frame. If the physics engine has hundreds or thousands of physics objects, and the rendering engine has hundreds or thousands of draws, and the animation system has hundreds or thousands of bones, then it's operating on much more data than you are.

And yes the data it's operating on is likely stored in a more efficient way, and it can be spread across cores, etc. etc. etc. but the point is that, unless you're doing something abnormal (ex: zombie game) then your scripts are not operating on much data relative to what the engine is.