Game state isn't usually frame rate dependent either

A lot of games have some internal "physics rate" or similarly termed tick rate at which the logical state is updated. The better you can decouple the graphics pipeline from it, the better.

Not anymore, in the past it was. Some games in the 8bit world ran slower in Europe vs the US because Europe TVs used PAL which was 50hz refreshes, while the US had NTSC with 60hz refreshes (some games counted on NTSC being interlaced and so updated at 30hz which made NTSC games slower). IIRC some PC games depended on frame rate as well, but I don't recall any specifics.

Skyrim infamously allows your frame rate to influence game physics, with hilarious results.

https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_...

This is one of the traps when you go for the naive approach to framerate independence: simply using the frame delta for stepping your calculations. Results for physics engines are very wacky! It's usually better to step your physics engine at a fixed rate (e.g. 60hz), and make the frequency of steps performed independent of the graphics framerate. Perform some slight interpolation on the position of rendered objects and nobody can tell the difference

The original DayZ mod had an issue with this. If your framerate was lower your character would run slower. It's a very subtle effect, but when you ran several km alongside someone with a weaker computer they'd end up further back and you'd have to wait for them to catch up.

Render state usually isn't, but internal simulation and physics often updates using a fixed time step because it avoids many many problems caused by variable frame rates.

https://gafferongames.com/post/fix_your_timestep/

When things aren't done properly, the whole experience can fall down.

I recently played Minnit [1], a very small and cute game with a very unique proposal: that you only have 1 minute of gameplay before being warped to a starting point.

But time is not checked asynchronously but as a function of the frame rate, so my playthrough was basically sped up and lasted for 45 seconds each time. Turned out I didn't realize until almost the end, when a _very_ difficult movement seemed almost impossible to make in time (I did end up achieving 100% doable things in the game, but it cost me a good amount of attempts!)

Gamedevs, please, do not count frames and assume they'll be whatever amount per second you believe they'll be. Because they won't.

[1]: https://store.steampowered.com/app/609490/Minit/

Didn't that mean you also moved faster?

Yes, that's how I was able to complete most parts of the game (which in general isn't difficult at all). But at least one of the extra optional things does get much more difficult if you don't have almost perfect execution, so faster movement speeds were actually a handicap as my control movements had to me much more precise.

To be clear: it was at that time that I discovered that some wrong settings in the Steam Deck had been affecting the in-game FPS, so after correcting them and getting to the designed runtime speeds, the challenge got from impossible to barely achievable :)

As a newbie in a graphics course I once animated something using xlib and openGL. I hadn't bothered install my graphics card driver, so everything was nice and slow.

I brought it into to the professor's office (it was our final) to demo it, and it was so fast on his machine that you couldn't see it. I freaked out, but he had seen that kind of problem before and just sprinkled some sleeps throughout so it was visible to a human and gave me a B.

In other words, don't write state, only consume it. (Time is also state.)

Removing frame rate dependence isn’t central to this concept, it’s almost a coincidental side effect. You can easily remove frame rate dependence in the first example

You do that by using delta-t instead of 1 when doing a stateful operation. The fact that a stateless function does it for you automatically is gravy.