i am starting to learn Unity3d and one of the confusion i get is difference between Update() and FixedUpdate().

I am following Lynda Unity 2D game development tutorial there, the instructor uses Update method, the player has RigidBody2D component and Box collider, he uses the Update method to translate the player, but when i do same in Update the player doesn't move but when i do it in FixedUpdate, everything works. He is giving tutorial from Unity 4.3 and i am taking the course in Unity 4.6.

Where should i use Update and FixedUpdate?


4 Answers 4


I was going to write this as a comment, but it ended up being rather long winded so I've turned it into an answer.

The current answers are mostly correct, but a few things mentioned are misleading/wrong.

In general, most game-play related tasks will go in Update.

For example, you don't want to be polling for input in FixedUpdate (not because of performance, but because the calls simply won't work correctly). AI falls in the same boat.

Continuously updated physics are the only gameplay related task that FixedUpdate should be used for. Non-continuous/once-in-a-while calls to things like Physics.Raycast, or even Rigidbody.AddForce belong in Update. My mention of Rigidbody.AddForce is seemingly contrary to what might be implied by the documentation, but the key is Continuous vs Non-continuous.

One huge reason why only continuous physics belong in FixedUpdate is the actual nature of FixedUpdate. Other answers have mentioned how FixedUpdate is called at a fixed interval, but that's slightly misleading. In reality, a script is passed a time in Time.deltaTime/Time.fixedDeltaTime* which doesn't correspond directly to the actual time between calls, but rather the simulated time between calls.

(*Time.deltaTime and Time.fixedDeltaTime are the same value when called in FixedUpdate [Unity is able to tell if the current call to Time.deltaTime originated during FixedUpdate and returns Time.fixedDeltaTime])

Naturally the same way Update can't be called in a constant manner because of varying performance, neither can FixedUpdate. The key difference is, each frame, if FixedUpdate hasn't been getting called often enough to average out to the correct interval between calls, it gets called multiple times (or isn't called the average is too high). This is what the docs on Execution Order refer to in saying that FixedUpdate can be called multiple times a frame:

... FixedUpdate: FixedUpdate is often called more frequently than Update. It can be called multiple times per frame, if the frame rate is low and it may not be called between frames at all if the frame rate is high...

This doesn't affect Physics because of the nature of the rest of the execution order and the engine, but just about anything else you put in FixedUpdate will be affected, and it will cause issues.

For example, if you put AI processing inside FixedUpdate there's no reason to assume that the AI won't skip updates for multiple frames in a row. Additionally, each time `FixedUpdate falls behind, your AI will update multiple times in a single frame before things like physics and player input/movement are processed, which is a waste of processing at the very least, but is also extremely likely to cause hard to track down bugs and erratic behavior.

If you need to do something at a fixed interval use other methods Unity provides such as Coroutines and InvokeRepeating.

And a small note on Time.deltaTime and when to use it:

The easiest way to describe the effect of Time.deltaTime is it changes a number from unit per frame, to unit per second. For example, if you have a script with something like transform.Translate(Vector3.up * 5) in Update, you're essentially moving the transform at a rate of 5 meters per frame. That means if framerate is low the movement is slower, and if framerate is high, the movement is faster.

If you take that same code and change it to transform.Translate(Vector3.up * 5 * Time.deltaTime) , the object is being moved at a rate of 5 meters per second. That means no matter the framerate, the object will move 5 meters every second (but the slower the framerate, the jumpier the object's movement will appear since it still moves the same amount every X seconds)

In general, you want your movement to be per second. That way no matter what speed the computer is going at, your physics/movement will behave the same way, and you won't have strange bugs popping up on slower devices.

And there's no point in using it in FixedUpdate. Because of what I mentioned above, you'll get the same value each call (the Fixed Update Timestep value), and it won't do anything to your values. Movement/Physics defined in FixedUpdate is already going to be in units per second so you don't need it.


The Update function is called every frame. Its frequency depends on how fast the computer is able to render images. On a slower computer, Update is called less frequently than on a faster one. If you do time-based calculations, you can normalise them using Time.deltaTime which tells you how long it has been since the last time Update has been called (caveats apply).
You will generally use Update to perform display-related tasks (e.g. updating a UI element)

The FixedUpdate function is called at fixed intervals. No matter how often the image refreshes, FixedUpdate will be called 1/Time.fixedDeltaTime times per second
You will generally use FixedUpdate to perform gameplay related tasks (e.g. updating physics)

  • \$\begingroup\$ Is this an alternative to multiplying by Time.delta time? Is there a reason to use one or the other? \$\endgroup\$
    – Ben
    Commented Feb 11, 2015 at 8:25
  • \$\begingroup\$ @Ben they have two different goals and you should use the correct function for what you are doing. \$\endgroup\$
    – o0'.
    Commented Feb 11, 2015 at 9:39
  • \$\begingroup\$ @Lohoris Sorry, I meant is there a reason to use FixedUpdate over Update and multiplying things by Time.deltaTime to make them frame independent? \$\endgroup\$
    – Ben
    Commented Feb 11, 2015 at 9:44
  • \$\begingroup\$ @Ben yes, precision. In a system with slow rendering, Update gets called less and less often, and your simulation will suffer a lot from that. You might not notice while the simulation is simple, but it will easily break horribly when it isn't. \$\endgroup\$
    – o0'.
    Commented Feb 11, 2015 at 9:49
  • 1
    \$\begingroup\$ @Ben no: if you want your simulation to be precise, you have to take many small steps, not huge ones randomly bigger or smaller every time. And no, the whole point of FixedUpdate is that it gets called that many times, no questions asked. \$\endgroup\$
    – o0'.
    Commented Feb 11, 2015 at 11:18

From: http://unity3d.com/learn/tutorials/modules/beginner/scripting/update-and-fixedupdate

The time-step used in FixedUpdate is not variable.

If your game starts to lag, when it catches up, you don't want >10seconds of physics in one update, so it is typically done in FixedUpdate which is called on a fixed-interval.

For example:

Update(float elapsedSeconds)
  Position += Velocity * 34.23423; //Windows Update is self-important
FixedUpdate(float elapsedSeconds)
  Position += Velocity * 0.0166; //60fps




//4.23423 + 5.76577 game-seconds later...
  • \$\begingroup\$ I mentioned this in my answer, but FixedUpdate isn't actually called at a fixed interval. The actual nature of FixedUpdate is to squeeze multiple cycles of physics into one frame if your game starts to lag and skip cycles if it's going too fast so that the average works out to the Fixed Update Timestep. Unity isn't multi-threaded, so there'd be no way to guarantee FixedUpdate calls at a fixed interval (What happens when one FixedUpdate takes too long). Even if it was it'd probably still be near impossible. \$\endgroup\$ Commented Feb 14, 2015 at 14:32
  • \$\begingroup\$ Most [Unity?] people aren't aware that Render/Update/FixedUpdate are all invoked from within a single callback method, so I conceptualized. Thanks for your effort! \$\endgroup\$
    – Jon
    Commented Feb 14, 2015 at 19:02

Update is called as fast as possible. The variable 'Time.deltaTime' is set to the actual amount of time that passed since the last call. If lag or something similar slows down the game, Update will still be called only once once the lag is over, with a high value of deltaTime.

FixedUpdate is called at regular intervals. It will never be called more often than the ratio specified in 'Time.fixedDeltaTime'. If lag or something similar slows down the game, FixedUpdate will be called multiple times in quick succession to enable the game to catch up. Time.deltaTime is set equal to Time.fixedDeltaTime before FixedUpdate is run, but this is just a fudge to make it easy to migrate code between the two.

Generally, Update should be used for interpolable behaviours and FixedUpdate for behaviours that must be computed step-by-step, or that depend on those that do, such as physics based movement. If you are writing any kind of loop in Update along the lines for for(time=0;time<=deltaTime;time+=someStep)... then you should probably be doing it in FixedUpdate instead.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .