Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

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

(+1)

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.

Yea I agree, I also coded this with JS only

I saved and pulled the input data in my update loop, which made it synchronized even when the call interval slightly changes (I guess that that's what you meant)

Good luck on the jam ;)

(1 edit) (+1)

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!