3 ms·

Right. AFAIK most games are essentially a loop which applies transformations to a huge number of items in a very short amount of time. Games have a lot of stat

by alxmng 4y ago

Right. AFAIK most games are essentially a loop which applies transformations to a huge number of items in a very short amount of time. Games have a lot of state and work with large amounts of data. Any kind of transaction (locking or copying) sounds like it would be bad for games.

4ad 4y ago
STM doesn't use locking and copying is cheap in a functional language (which this is) because of structural sharing.
epolanski 4y ago
> sounds like it would be bad for games I really wonder whether people making claims that "something would be slow for games" actually bother benchmarking if that's true and how much. The fact that something might be faster theoretically isn't really relevant if the calculations stay on a very small scale.
mfost 4y ago
ECS systems are gaining a lot of popularity for games and those are pretty similar to having some SQL database in your engine when you think about it. So it's actually not that surprising to see efficient snapshot/rollback/transaction features creeping in. I know for example that EnTT, a C++ ECS project has snapshots available to allow you to save the game state in the background without blocking gameplay as an example.
Tuna-Fish 4y ago
... they don't. Most games contain gigabytes of static data, a whole bunch of ephemeral data that is recreated and discarded every frame, and the actual mutable state that persists across frames is rarely more than a few hundred kB, unless you are making a huge open-world game (in which case it's still probably less than tens of megabytes.) This persistent data is what you use transactions on, and there are past experiments of doing things like fully double-buffering this state (Each frame, recreate the full state into a different buffer, with the code doing so only touching the previous frame, never reading from the current one. Great for multi-threading!)
- Rusky 4y ago
  It goes well beyond experiments- network multiplayer often keeps multiple copies of various pieces of state in order to support things like interpolation and rollback.

by alxmng 4y ago

4ad 4y ago

STM doesn't use locking and copying is cheap in a functional language (which this is) because of structural sharing.

epolanski 4y ago

> sounds like it would be bad for games I really wonder whether people making claims that "something would be slow for games" actually bother benchmarking if that's true and how much. The fact that something might be faster theoretically isn't really relevant if the calculations stay on a very small scale.

mfost 4y ago

ECS systems are gaining a lot of popularity for games and those are pretty similar to having some SQL database in your engine when you think about it. So it's actually not that surprising to see efficient snapshot/rollback/transaction features creeping in. I know for example that EnTT, a C++ ECS project has snapshots available to allow you to save the game state in the background without blocking gameplay as an example.

Tuna-Fish 4y ago

... they don't. Most games contain gigabytes of static data, a whole bunch of ephemeral data that is recreated and discarded every frame, and the actual mutable state that persists across frames is rarely more than a few hundred kB, unless you are making a huge open-world game (in which case it's still probably less than tens of megabytes.) This persistent data is what you use transactions on, and there are past experiments of doing things like fully double-buffering this state (Each frame, recreate the full state into a different buffer, with the code doing so only touching the previous frame, never reading from the current one. Great for multi-threading!)

Rusky 4y ago
It goes well beyond experiments- network multiplayer often keeps multiple copies of various pieces of state in order to support things like interpolation and rollback.