0
\$\begingroup\$

As far as I know, most game loops are executed in the following order:

  1. Process user input
  2. Update (once per frame)
  3. Physics (also known as fixedUpdate, 0 to N times per frame)
  4. Rendering

You can find the execution order of the Unity game loop here: https://docs.unity3d.com/Manual/ExecutionOrder.html

Unity's game loop is different in that fixedUpdate is executed earlier than update, is there any benefit to this when designing a game loop?

Additional information: I'm not familiar with Unity, but I'm making a platformer game that mimics the execution order of Unity's game loop. I have found that if the update is later than physics, the rendering will lag significantly in responding to user input. If the physics fps is set lower (i.e. timestep is set higher), the lag is more significant. How does the Unity game solve this problem?

\$\endgroup\$
12
  • \$\begingroup\$ I'm sorry, but I don't think that we can answer this question. The only people who can answer this would be the people at Unity Technologies who made that architecture decision over a decade ago. And those are probably bound by NDAs. So we could only speculate. And speculative questions are not a good fit for the Stack Exchange model. \$\endgroup\$
    – Philipp
    Commented Sep 22, 2022 at 7:59
  • 1
    \$\begingroup\$ I've never seen a game loop that works in the order you describe. Can you cite a source or evidence for the claim that "most" work in that order? \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 11:26
  • \$\begingroup\$ I've edited the question to focus on the more abstract "is there an advantage to processing the physics first?" in general, rather than specifically trying to read the minds of Unity's developers, which I think addresses the concern that Philipp raised while keeping the question focused on what OP wants to learn about. \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 11:29
  • 1
    \$\begingroup\$ @Vaillancourt I'd argue Glenn Fiedler shows processing the fixed timestep at the start of the game loop — place 2, or even place 1 since he doesn't check input in those examples. Then the framerate-variable part, interpolation, occurs after that. This would be analogous to Unity's order of doing things, opposite the order OP proposes. I was planning to cite Fiedler's example in an answer, in fact. \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 11:40
  • 1
    \$\begingroup\$ It sounds like you're basing this on the false premise that Unity forbids acting on new input within FixedUpdate(). Although you can certainly find a lot of wrong/outdated advice from gamedevs saying something vaguely like this, it's not at all true. You can configure Unity to capture input before FixedUpdate and respond to input there for minimum motion latency. You have to be careful to do it correctly of course, which may be why so many folks say not to - it's easy for a beginner to get it wrong, so they over-generalize "be careful" as "never". \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 16:15

1 Answer 1

1
\$\begingroup\$

Executing the game logic after the physics and before rendering the frame allows the game logic to react to physics events before they are being rendered.

For example, when the physics engine moved an object into an area where it is supposed to be destroyed, then the game logic has the opportunity to destroy that object before it gets rendered in that invalid location.

Further, Unity is able to run the physics simulation with a much lower update rate than the FPS. In that case it offers the options to either interpolate or extrapolate rigidbody positions (which is a setting on the Rigidbody component) to smooth out the rendering of their motions. This smoothing happens before Update. So the Update method can access the interpolated/extrapolated object positions before the rendering happens. This is particularly important if you want to synchronize non-rigidbody objects with rigidbodies (e.g. transform.position = followedObject.transform.position). This needs to happen before rendering and with interpolated/extrapolated positions, or the objects won't be properly synchronized.

So by running the Unity Update-method just before the rendering guarantees that all the transform.positions and transform.rotations you check during it will actually be those which will appear on the screen...

...almost. There is still the animation system which runs before the rendering. The reason why the animation system gets processed after Update but before rendering is because you often want to set animation parameters in Update which you then want to be reflected in the current frame and not the next one.

But if you want to do something with the objects after the animation system was resolved, Unity still has you covered. You can use LateUpdate for that purpose.

\$\endgroup\$
12
  • 1
    \$\begingroup\$ "I am not entirely sure when exactly the new event-oriented input system processes events" - it's up to the user now. You can choose when you want input to be read. "physics being earlier than update means that the motion caused by user input is completely ignored in current frame" - only if you follow the rule that you do not act on new input in FixedUpdate. Nobody requires you to follow such a rule - in fact, I actively advise against it in previous answers. \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 16:03
  • 1
    \$\begingroup\$ Input events are generally things you can count on one hand in any given time tick - there's just not that many buttons or axes a player could be interacting with all at once, even in local multiplayer. So it's not something that would make any meaningful CPU drain compared to integrating hundreds of physics bodies or the like. \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 16:18
  • 1
    \$\begingroup\$ I think you'll get a lot further if you focus more on making good games, and less on passing judgement against other developers. \$\endgroup\$
    – DMGregory
    Commented Sep 22, 2022 at 16:21
  • 1
    \$\begingroup\$ @BlackGlory For someone who is "not familiar with Unity", you have pretty strong opinions about it and its users. \$\endgroup\$
    – Philipp
    Commented Sep 22, 2022 at 17:38
  • 1
    \$\begingroup\$ You're continuing to operate under the false assumption that Unity precludes handling input or running update logic before physics, which it does not in any way do. I'm sorry the engine is not to your taste, but that's not relevant to the question that you asked, and this site is not the venue to litigate which engines or game loops are implemented "right" or "wrong" in your opinion. \$\endgroup\$
    – DMGregory
    Commented Sep 23, 2022 at 22:09

You must log in to answer this question.

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