4 ms·

Checking in as a random indie developer who still prioritises determinism in my engine. I don't understand why so many games/engines sacrifice it when it has so

Checking in as a random indie developer who still prioritises determinism in my engine. I don't understand why so many games/engines sacrifice it when it has so much utility.

bob1029 7mo ago
Determinism isn't essential to achieve record/playback experiences. You could just record the transform of the player at some fixed interval and then replay it with interpolation. This is arguably more "deterministic" in a strategic sense of shipping a viable product.
- magicalhippo 7mo ago
  The player is just one entity, you'd need to do the same to any other non-trivial entity. And you couldn't use fixed intervals and naive interpolation, otherwise you'd have entities clipping the ground when bouncing etc.
JoshTriplett 7mo ago
I think if it were as simple as "remember the RNG seed", game developers would do it every time. But determinism also means, for instance, running the physics engine at a deterministic timestep regardless of the frame rate, to avoid differences in accumulated error or collision detection. And that's something that needs designing in from day one. Thank you for still prioritizing it.
- Krutonium 7mo ago
  Tying physics to framerate at all is a mistake. Like, should be filed as a bug mistake. There's no scenario in which that's desirable. And yet even Rockstar gets it wrong. (GTA V has several framerate dependent bugs)
  - JoshTriplett 7mo ago
    I completely agree, but it's an easy mistake to make.
  - Keyframe 7mo ago
    not framerate of rendering but physics running at (its own) fixed frame rate.
    - nottorp 7mo ago
      Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate. The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.
      - JoshTriplett 6mo ago
        > i.e. old generation consoles, before they started to make "pro" upgrades. And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.
    - bregma 7mo ago
      I think you mean timestep. The video frames get updated on one timestep (the so-called "frame rate" because it is the rate at which video frames get redrawn, the inverse of its timestep), physics gets updated on a separate timestep, and gameplay or input or network polling can be updated on its own timestep.
      - Keyframe 6mo ago
        pretty much, over the dozen or so game and rendering engines I made over the decades name mutated from tick to timestep to frame (rate) to refresh rate (hz) to tick again.. it doesn't matter as long as every system is decoupled and rendering is unbounded (if hardware/display combo supports it). This needs thinking from day one. Cool stuff you can do then is determinism, you can do independent timers which go forward, halt, backward in time, different speed multipliers over those (so some things run slower, faster, everything goes slower / faster), etc.
- magicalhippo 7mo ago
  > running the physics engine at a deterministic timestep As well as using special library versions of floating-point functions which don't behave the same across different processors I suppose, if you want to be safe. Eg cr-libm[1] or more modern alternatives like core-math[2]. [1]: https://github.com/SixTrack/crlibm https://github.com/SixTrack/crlibm [2]: https://core-math.gitlabpages.inria.fr/ https://core-math.gitlabpages.inria.fr/
- deleted 6mo ago
  [deleted]
Cthulhu_ 7mo ago
Probably (armchair HN reader, not a game developer here) due to dealing with multiplayer latency and / or performance / multithreading / scalability.
Jare 6mo ago
Mostly because determinism is an all or nothing proposition. Either EVERYTHING in game logic is perfectly deterministic and isolated from everything else, or it pretty much as if nothing was. So if you want to commit to determinism, you have to be constantly vigilant and debugging these maddening types of bugs. Whether this investment is worth it or not is up to each dev. Sometimes you can find small areas of the game that can be deterministic and worth it. In a basketball game I worked on in the 90s, I designed the ball physics to be deterministic (running at 100hz). The moment the ball left the player hands it ran deterministically; we knew if it was going to hit the shot and if not, where the rebound would go to.

Checking in as a random indie developer who still prioritises determinism in my engine. I don't understand why so many games/engines sacrifice it when it has so much utility.

bob1029 7mo ago

Determinism isn't essential to achieve record/playback experiences. You could just record the transform of the player at some fixed interval and then replay it with interpolation. This is arguably more "deterministic" in a strategic sense of shipping a viable product.

magicalhippo 7mo ago
The player is just one entity, you'd need to do the same to any other non-trivial entity. And you couldn't use fixed intervals and naive interpolation, otherwise you'd have entities clipping the ground when bouncing etc.

JoshTriplett 7mo ago

I think if it were as simple as "remember the RNG seed", game developers would do it every time. But determinism also means, for instance, running the physics engine at a deterministic timestep regardless of the frame rate, to avoid differences in accumulated error or collision detection. And that's something that needs designing in from day one. Thank you for still prioritizing it.

Krutonium 7mo ago
Tying physics to framerate at all is a mistake. Like, should be filed as a bug mistake. There's no scenario in which that's desirable. And yet even Rockstar gets it wrong. (GTA V has several framerate dependent bugs)
- JoshTriplett 7mo ago
  I completely agree, but it's an easy mistake to make.
- Keyframe 7mo ago
  not framerate of rendering but physics running at (its own) fixed frame rate.
  - nottorp 7mo ago
    Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate. The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.
    - JoshTriplett 6mo ago
      > i.e. old generation consoles, before they started to make "pro" upgrades. And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.
  - bregma 7mo ago
    I think you mean timestep. The video frames get updated on one timestep (the so-called "frame rate" because it is the rate at which video frames get redrawn, the inverse of its timestep), physics gets updated on a separate timestep, and gameplay or input or network polling can be updated on its own timestep.
    - Keyframe 6mo ago
      pretty much, over the dozen or so game and rendering engines I made over the decades name mutated from tick to timestep to frame (rate) to refresh rate (hz) to tick again.. it doesn't matter as long as every system is decoupled and rendering is unbounded (if hardware/display combo supports it). This needs thinking from day one. Cool stuff you can do then is determinism, you can do independent timers which go forward, halt, backward in time, different speed multipliers over those (so some things run slower, faster, everything goes slower / faster), etc.
magicalhippo 7mo ago
> running the physics engine at a deterministic timestep As well as using special library versions of floating-point functions which don't behave the same across different processors I suppose, if you want to be safe. Eg cr-libm[1] or more modern alternatives like core-math[2]. [1]: https://github.com/SixTrack/crlibm https://github.com/SixTrack/crlibm [2]: https://core-math.gitlabpages.inria.fr/ https://core-math.gitlabpages.inria.fr/
deleted 6mo ago
[deleted]

Cthulhu_ 7mo ago

Probably (armchair HN reader, not a game developer here) due to dealing with multiplayer latency and / or performance / multithreading / scalability.

Jare 6mo ago

Mostly because determinism is an all or nothing proposition. Either EVERYTHING in game logic is perfectly deterministic and isolated from everything else, or it pretty much as if nothing was. So if you want to commit to determinism, you have to be constantly vigilant and debugging these maddening types of bugs. Whether this investment is worth it or not is up to each dev. Sometimes you can find small areas of the game that can be deterministic and worth it. In a basketball game I worked on in the 90s, I designed the ball physics to be deterministic (running at 100hz). The moment the ball left the player hands it ran deterministically; we knew if it was going to hit the shot and if not, where the rebound would go to.