Cool puzzle!
I know how hard it is to make a perfectly reproducible replay, especially with physics simulation, when every tiniest difference entirely changes the outcome ¦3
I like the scattering transition when you return to the menu.
And the eurodance is my weakness, great track by Cecilia! (I hope you have the permission to use it, though ¦3)
Thanks! My goal wasn't to make the enemies repeat the player's position from the last stages (like in your game), but rather have them act as they are giving the exact same aim & keyboard input as the player did in his past (I'm basically saving the keys the player is pressing and the position of the mouse in every given moment, instead of his position), this leads to a way bigger chaos and change of plans ;)
Yeah, I do the same recording and replicating of player inputs ¦3
What I discovered was that to make it consistently reproducible, I had to somehow tie each input to a specific step of the physics simulation. And then having physics calculation at a fixed rate allowed me to use the count of such physical steps as a pretty solid measure of time for inputs (e.g. if I repeat the "jump" action exactly at step 119 every time, the end result will be exactly the same, if the surrounding world hasn't changed).
However, in your case, with all the moving platforms that would not work, as in the next run you can change the configuration of walls, making previous enemies hit them as they move, changing the result of their movement.
So that's a pretty hard task ¦3
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!
