Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was told to use Update() for graphics and FixedUpdate() for physics, but sometimes my inputs won't register when I use FixedUpdate(). It works fine if I use Update() for everything though.

Should I bother with FixedUpdate(), or am I doing something wrong?

share|improve this question
up vote 9 down vote accepted

FixedUpdate can run faster or slower than Update depending on your settings. That'll depend on load (how fast Update is running) and speed you have set for FixedUpdate (found in Edit->Project Settings->Time). Ideally, since Update is run once per frame, this is where you want to capture input. If you need to act on input in the FixedUpdate method (like controlling physics bodies), set flags in Update then handle them in FixedUpdate:

bool leftMouseDown = false;

void Update()
        leftMouseDown = true;

void FixedUpdate()
    if(leftMouseDown )
        //update physics bodies with input
        leftMouseDown = false;

It's still a good idea to control physics from the FixedUpdate method, since it's unlikely the physics needs to be updated as often, and physics on a fixed update is much easier to predict (determinism) than physics on a variable update.

share|improve this answer
what about if instead of a bool condition (es.GetMouseButtonDown) we need to read value from an axis (Input.GetAxis("Horizontal"))? If update is executed more times then FixedUpdate, what's your advice in that case? Should we eventually consider to calculate the mean value of the axis occured during the several Update before consuming it into Update? (+1 btw) – Heisenbug Apr 20 '14 at 20:42
How do I find out how fast my FixedUpdate is? – Tokamocha Apr 20 '14 at 21:01
@Tokamocha The rate for fixed update is set in Edit->Project Settings->Time. – Byte56 Apr 20 '14 at 21:09
@Heisenbug Personally I would just use the last value and see how well that works. If I get unexpected results, I might calculate a running average of the axis value until it's processed by FixedUpdate. That's one of those things that needs some play testing to really figure out what "feels" right. – Byte56 Apr 20 '14 at 21:11
@Byte56: yes I usually just use the last value. Since now I've never had problems with that, but It's a little bit I'm thinking that averaging would be the most accurate thing to do. Reading this thread, I was just curious if you ever did something similar.. thanks – Heisenbug Apr 20 '14 at 21:22

You need to understand what each one does. Update() gets called as often as possible (not sure, maybe it can be capped), either way - each frame. FixedUpdate() gets called every constant amount of time (hence "fixed").

Input goes into Update(), as simple as that (because as you noticed FixedUpdate() might not catch the input event). Game logic however might go into either one. Physics needs to be deterministic and that's why it should be in FixedUpdate(). Other things don't have to. Depending on the usage you have to decide which function is appropriate.

Althouth it's worth to say that some applications have all game logic update in FixedUpdate() (even outside of Unity) - it's called "fixed step game loop". Having all update code in a fixed step function gives you determinism and makes your app more likely to behave the same way each time (and on each device). Also allows for some fancy features, like replays.

share|improve this answer
So, if I put everything in FixedUpdate() my game will still register all the inputs, right? – Tokamocha Apr 20 '14 at 21:08
No, you can put there all game logic update but not input checking. – NPS Apr 20 '14 at 21:37
oh ok, I get it now, thanks. – Tokamocha Apr 20 '14 at 21:39
this answer is full of miss-information. First of all FixedUpdate gets called 1/fixedDeltaTime times per second, not every n:th fixedDeltaTime. Second, game logic should always go in FixedUpdate as it makes it easier o reason about. Update is for rendering purposes only (I know almost no one in the Unity community follows this, but that's really how its supposed to be done). Third, FixedUpdate and its relationship with the physics engine has nothing to do with determinism. – thr Apr 21 '14 at 5:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.