5 ms·

Update is bound to the framerate. And if you have a faster PC or a higher refresh rate you can perform more logic. So why limit yourself by a fixed timestep? Bu

Update is bound to the framerate. And if you have a faster PC or a higher refresh rate you can perform more logic. So why limit yourself by a fixed timestep? But well, nothing prevents you from doing game logic in FixedUpdate and maybe it could even be beneficial. For example, you don't want your AI to run each frame. But in my opinion Update should still be the place most of your logic resides. Even in the case where you don't want logic to run each frame, simply keep track of the time passed and run your logic in self defined intervals from inside Update. Update is the place you handle your input and you can affect the next displayed frame immediately. The last part is really important, because you don't want the player to wait for the next physic step after he pressed a button (but unfortunately many games do). I think a large part of this problem comes from the fact, that the Update/FixedUpdate logic of most game engines is very static. In many cases you can't really influence its behavior. Unity allows you to invoke the FixedUpdate cycle manually from inside Update, but it can lead to other problems.

BoorishBears 6y ago
This is completely wrong. FixedUpdate can be called several times in one frame or not at all because it's designed to run a consistent amount of time regardless of framerate. Don't put game logic that involves collecting input in FixedUpdate or you will miss inputs and get all types of errant behavior, definitely don't put AI in there... - The rule of thumb: FixedUpdate is for per-unit-time, like X meters per second, Update is for per-frame. (really that boils down to, FixedUpdate is for physics. If you want FixedUpdate for something that isn't physics in Unity, use a Coroutine/InvokeRepeating) Things in Update will happen less often on a slow computer and more often on a fast one, you don't want your physics to behave differently on a slow computer
- cosarara 6y ago
  Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differently on a slow or a fast computer.
  - BoorishBears 6y ago
    "Aren't inputs usually on a queue" isn't really an easy question to answer because there's so many levels of it (and I'm not saying that to be difficult) But generally if we're talking about Unity and stuff like GetButton, no. You're polling for input at a specific point in time. Like I said, FixedUpdate can be called multiple times a frame, or not at all, so there'll be entire frames where Update is called (and you'd have gotten input), but FixedUpdate isn't (and you miss that input) - And AI moving and actually running AI are two different things. You want the AI's physics-based effects to be in FixedUpdate like any other physics, but you don't want your AI to be in FixedUpdate. A lot of people don't seem to get, FixedUpdate isn't magical, it's trying to run at a target rate, but if your game can't do it's work at that rate, there's no way to "cheat" time So it will try and run 2 times in a row for one frame if your frames are slow enough. And if your FixedUpdate is slow enough, it won't be able to run 2 times quickly enough, and then the next frame it needs 3 runs to "average out" to the correct number of calls per frame. That creates a cascading effect that leaves it trying to run as many FixedUpdates as it can. It also leads to a weird sort of "jitter" where FixedUpdate is called several times and your AI in turn updates several times before Update is called once. So it "sees" the same exact world view multiple times in a row and acts on it (unless all your game's logic is in FixedUpdate, which you definitely shouldn't do) then the next frame because the engine "caught up" on FixedUpdate calls, FixedUpdate isn't called at all, while Update is called, and your AI doesn't act on the new world view from Update's logic until the next frame. Instead, if you want a repeatable task updating independent of frame-rate like AI, in Unity use a coroutine or "InvokeRepeating"
    - cosarara 6y ago
      I'm thinking though that if the AI runs less often, it might take different decisions depending on how fast the PC is. So just like if you did physics without fixedupdate, you could have players jumping lower or higher depending on how fast their PC is, maybe you'll be making the AI dumber or smarter (due to thinking more often).
      - BoorishBears 6y ago

BoorishBears 6y ago

This is completely wrong. FixedUpdate can be called several times in one frame or not at all because it's designed to run a consistent amount of time regardless of framerate. Don't put game logic that involves collecting input in FixedUpdate or you will miss inputs and get all types of errant behavior, definitely don't put AI in there... - The rule of thumb: FixedUpdate is for per-unit-time, like X meters per second, Update is for per-frame. (really that boils down to, FixedUpdate is for physics. If you want FixedUpdate for something that isn't physics in Unity, use a Coroutine/InvokeRepeating) Things in Update will happen less often on a slow computer and more often on a fast one, you don't want your physics to behave differently on a slow computer

cosarara 6y ago
Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differently on a slow or a fast computer.
- BoorishBears 6y ago
  "Aren't inputs usually on a queue" isn't really an easy question to answer because there's so many levels of it (and I'm not saying that to be difficult) But generally if we're talking about Unity and stuff like GetButton, no. You're polling for input at a specific point in time. Like I said, FixedUpdate can be called multiple times a frame, or not at all, so there'll be entire frames where Update is called (and you'd have gotten input), but FixedUpdate isn't (and you miss that input) - And AI moving and actually running AI are two different things. You want the AI's physics-based effects to be in FixedUpdate like any other physics, but you don't want your AI to be in FixedUpdate. A lot of people don't seem to get, FixedUpdate isn't magical, it's trying to run at a target rate, but if your game can't do it's work at that rate, there's no way to "cheat" time So it will try and run 2 times in a row for one frame if your frames are slow enough. And if your FixedUpdate is slow enough, it won't be able to run 2 times quickly enough, and then the next frame it needs 3 runs to "average out" to the correct number of calls per frame. That creates a cascading effect that leaves it trying to run as many FixedUpdates as it can. It also leads to a weird sort of "jitter" where FixedUpdate is called several times and your AI in turn updates several times before Update is called once. So it "sees" the same exact world view multiple times in a row and acts on it (unless all your game's logic is in FixedUpdate, which you definitely shouldn't do) then the next frame because the engine "caught up" on FixedUpdate calls, FixedUpdate isn't called at all, while Update is called, and your AI doesn't act on the new world view from Update's logic until the next frame. Instead, if you want a repeatable task updating independent of frame-rate like AI, in Unity use a coroutine or "InvokeRepeating"
  - cosarara 6y ago
    I'm thinking though that if the AI runs less often, it might take different decisions depending on how fast the PC is. So just like if you did physics without fixedupdate, you could have players jumping lower or higher depending on how fast their PC is, maybe you'll be making the AI dumber or smarter (due to thinking more often).
    - BoorishBears 6y ago