Did Bennett purposefully make GOI physics indeterministic?

[Dicky Mcgeezaks]

As some of you may know, someone tried to make a TAS (tool assisted speedrun) for GOI and found that their recorded inputs yielded slightly different results each time. I was hoping Bennett Foddy could confirm whether this was an intentional game design choice, or simply a side effect of something like the unity physics engine?

[Hooch]

I can tell you that this is side effect of game physics engine. This engine was never meant to be deterministic.

[Dicky Mcgeezaks]

Thanks

[bennett]

Physics engines are all non-deterministic, yeah, for floating-point math reasons.

[Dicky Mcgeezaks]

Ah I see, thanks so much for responding!

[Hooch]

Originally posted by bennett:

Physics engines are all non-deterministic, yeah, for floating-point math reasons.

Not really. You can develop deterministic physics engines. It was one of the required projects on my university to create simple deterministic engine. It is just not needed for most applications, especially games.

[bennett]

yeah you can make a physics engine using fixed-point or integer math, I just mean the big popular ones are non-deterministic.

[Losername]

it doesn't have anything to do with fixed point vs. floating point. contrary to popular belief, floating point calculations are wholly deterministic. if you use any physics engine in an application with a fixed clock rate, you'll get absolutely consistent results every time you start the simulation fresh. you can see this for yourself if you download their sdks and run their included examples... they usually run at a fixed timestep which gives them deterministic results.

so the real issue may have more to do with the fact that unity does not use a fixed clock rate, but instead does what 99% of game engines do, which is calculate the time spent on the last frame and adjust the time step of the world process accordingly. meaning *any* slowdown, or speedup, in the game engine will affect how your physics engine works. and since the game engine is dependent on the OS to get many things done, any time the OS can't deliver a resource in exactly the same time it did before, the engine speed will be affected, and your physics will be affected too.

so whether you use an input recorder or not is moot... unless your engine runs physics in a fixed timestep you won't get consistent physics results.

[rango gaming]

how the heck we ever gonna have a TAS now?

[Dicky Mcgeezaks]

This is very interesting, and great to get input from other game developers as well @SheridanR. I guess only an Ai could do what TAS's would have in games like these.

[Phlarfl]

Originally posted by SheridanR:

it doesn't have anything to do with fixed point vs. floating point. contrary to popular belief, floating point calculations are wholly deterministic. if you use any physics engine in an application with a fixed clock rate, you'll get absolutely consistent results every time you start the simulation fresh. you can see this for yourself if you download their sdks and run their included examples... they usually run at a fixed timestep which gives them deterministic results.

so the real issue may have more to do with the fact that unity does not use a fixed clock rate, but instead does what 99% of game engines do, which is calculate the time spent on the last frame and adjust the time step of the world process accordingly. meaning *any* slowdown, or speedup, in the game engine will affect how your physics engine works. and since the game engine is dependent on the OS to get many things done, any time the OS can't deliver a resource in exactly the same time it did before, the engine speed will be affected, and your physics will be affected too.

so whether you use an input recorder or not is moot... unless your engine runs physics in a fixed timestep you won't get consistent physics results.

So if I cap the framerate of GOI to 20fps (using a means that would in reality render speedruns fake, and assuming it will never drop below 20fps on high end systems), a TAS is completely plausible?

[Losername]

Likely not, because fps caps are generally imperfect, and any minute difference in frame times will mess up your simulation.

If you really want this your best bet is to ask Unity to create a developer option for setting a fixed update cycle on the physics simulation, then ask bennett to expose this option to the user via the game's settings window.