You're absolutely right, but luckily that's exactly what I intended when I made the possibility to move walls, and block other players. I didn't want them to follow exactly the same path as they did in the last stage because in the context of my game that would turn everything boring (I rather want a similar behaviour and only an estimate of the path).
Hope you don't mind me asking how did you make your game? (Engine/language) your explanation is interesting
As some runs I tried very hard to keep all the walls intact in hope that a perfectly recorded replay will help me killing some of the enemies (unfortunately, it didn't work, though).
My tech is not very straightforward to explain, but in a nutshell it's just WebGL on Kotlin/JS without any engine, using a port of Box2D for physics ¦3
But I am pretty sure the general approach is engine-agnostic.
Yeah, that really depends on your implementation then ¦3
Usually, the update loop is based on requestAnimationFrame, which can return inconsistent durations. If you apply a force for 0.00161 seconds, it will be different from applying the same force for 0.00159 seconds. This delta time can be used for animations and visual stuff, but for consistent simulation, it's better to use a hardcoded step (usually referred to as a "fixed update" in different engines and articles), for example, exactly 0.0015, and sometimes you may have more or less than 1 physical step per rendered frame.
But I checked your code, and it seems that you already use the fixed update, so all of that explanation does not make much sense ¦3
Thanks, good luck to you too!
