Setting Time.timeScale to 0 will pause anything that is framerate independent. These are primarily all physics and time-dependent functions, rigidbody forces and velocities, and as an additional result the execution of FixedUpdate() will be halted. But also animations, and any transformations you put in Update() that are weighted by Time.deltaTime, which will also make them framerate independent: no matter how good or bad your framerate is, a rotation scaled by Time.deltaTime will always appear to take the same time.
The execution of Update() itself is unaffected by Time.timeScale, since they are unrelated. Update() is called as often as possible, as fast as your machine can render (unless you activated VSync, then the upper limit is 60fps). The game will seem to be frozen, since all time related things have been stopped. However, the game will still render, hence Update() will still be executed.
Also, when queried in Update(), Time.deltaTime will be 0 if Time.timeScale is 0. Maybe that wasn’t the case in earlier versions of Unity, but in 3.5 it is, and it is the correct behaviour. Note, Time.deltaTime does not reflect the time that has passed since the last frame has been rendered in reality, but instead it is that time scaled by Time.timeScale.
However, if you don’t scale your transformations in Update() with Time.deltaTime, they will be framerate-dependent, since such a rotation (for example) will be faster for faster framerates, and slower for slow framerates, since each time Update() is called (which is per definition once for every rendered frame) the same amount of rotation is applied.
- You can stop the execution of FixedUpdate() with Time.timescale=0
- You cannot stop the execution of Update()/LateUpdate(), unless you disable the script.
EDIT: all accepted answers in the link that @Berenger provided contain vital information that will help you understand what’s going on when messing with Time.timeScale, and also how you can still control your game if it is set to 0, how to “truly” pause your game (although it might still render as fast as it can, so the GPU still has to work), and so on.
EDIT2: fixed the confusion concerning what Time.deltaTime expresses, resulting from a badly written setnence.
EDIT3: note as @Eric5h5 mentioned in the comment below, you can use Application.targetFrameRate
to influence how often Update() is being called. However, you cannot set it to 0 (well, you can, but it has the same effect as disabling it with -1). You can set it to 1, which will call Update() exactly once per second (but the physics engine will continue at normal speed in the background) (You’ll need to set the "Maximum allowed timestep to 1 in this case, otherwise the value returned by Time.deltaTime will be too small). Note there is also Time.captureFramerate, which ensures a “simulated realtime” of a certain fps, independently from your actual framerate you can achieve. The time/physics engine will also use the desired fps as a basis, ignoring realtime, so for the default setting of “Fixed Timestep”=0.02, FixedUpdate() will be called exactly 50x (and Update() exactly Time.captureFramerate times) in one “simulated” second, no matter how long the rendering of these frames actually took.
EDIT4: Note that Time.deltaTime will not be correctly set to 0 if Time.timeScale is set to 0 too early (=in Awake, Start, or the very first call to FixedUpdate/Update/LateUpdate. OnGUI is fine). See comments.