Fix laggy appearance of breakout example by swapping to a delta-time approach

[BOB450]

Objective

• One of the first things people do when looking at a games engine is to look at the game examples. So it is important to make the examples feel smooth at the very least.
• The problem with breakout is that it used fixed update for moving the paddle and ball. Making the game appear to be laggy no matter the frame rate. On high refresh rate monitors this looks very bad.

Solution

• I simply put the systems in fixed update into update. then added delta time where time_step.period.as_secs_f32() was.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[hmans]

Noting that due to the nature of the "physics simulation" in this example, not using fixed steps will quickly introduce wonkiness and bugs (eg. with large time deltas, as unlikely as they are with a game this, er, complex, the ball may simply pass through a brick or the player and not register a collision.)

So yeah, it would feel smoother, but at the cost of applying (and teaching) a potentially game-breaking antipattern.

(There'd also be the option of increasing the fixed step frequency to something higher.)

[pnarimani]

If you want the movement to feel smooth, you should run the simulation in FixedUpdate and interpolate the position in Update.

[BOB450]

Thankyou for the response @hmans @pnarimani. I would prefer to not just increase the timestep because in order to get it feeling smooth on all refresh rates it would need to be very high and that would cause an unnecessary amount of load on the cpu. I like what @pnarimani said and that seems to be the solution

[alice-i-cecile]

A full fix would be to solve #1259, and then demonstrate its use here. For now, I think this is probably less bad than the current design. @inodentry, I know you've expressed opinions about this before.

[inodentry]

Yes. I've been complaining about overuse/abuse (yes, I'd use that word, I'm opinionated) of fixed timestep in Bevy examples before, incl. this exact one. Nobody wanted to listen, so I gave up. Here we are again.

FixedTimestep exists for physics and simulations, yes, true. Those things can misbehave with variable update rates, yes, true.

Though, a simple game like pong or breakout really doesn't need it, IMO.

Smooth visuals are more important than not glitching out in obscure edge cases here.

In any case, I am very much against doing anything visual from fixed update. Unless it is a game where that is part of the art style, by design (consider pixel-art games like Celeste that deliberately want the "low-framerate" feel).

Otherwise, for most games, a good design rule of thumb is: the top priority should be that what shows up on-screen should feel responsive and smooth to the player. The visual feedback and experience is paramount. Backend systems (like physics and movement) should be developed in service to that, not the other way around.

In an ideal world, we should have in-engine transform interpolation (as per #1259), and then we can have the best of both worlds. Smooth visuals updated every frame, and consistent physics/simulation/movement updated from FixedTimestep.

We don't have that yet, so I agree with the PR author here: we shouldn't use fixed timestep for Breakout (and most other bevy examples).

As for "teaching a lesson" and "showing good practices", I'd make the opposite case: are we not "teaching bad practice" by updating visuals from FixedTimestep? Do you really think that making a game look choppy, to avoid edge cases where the simulation might glitch, is "good practice" to be taught? I'd beg to differ.

At risk of going on an off-topic tangent: I can even bring up a recent example from a high-stakes AAA game, which is kinda tangentially related: Counter-Strike 2. Currently the one of the big controversies in the CS2 community is related to visuals/animations being triggered on the tick rate (effectively the game's fixed timestep), which makes them delayed, compared to the actual mouse input that triggered the event, making the game feel unresponsive and misleading.

Yes, it is important for a game's simulation/physics/netcode to use Fixed Timestep to be consistent. It is even more important to make things look and feel good to the user.