alt Hacker NewsHave you considered the opportunity of using delta compression on snapshots? Like the internal state of the physics simulation, most of the gamestate itself don't change between frames. Using delta compression on the whole structure is doable.
Replies
The thing the author is trying to solve for here is reducing the amount of CPU used on the client when it rolls back the simulation and re-simulates to keep server authority.
He does this by only rolling back and re-simulating only a subset of the world, greatly reducing the amount of CPU required. It's cool that he's approaching this from the point of view of adding support for it in the physics engine itself, vs. making it something that the game has to do themselves.
Delta compression is an unrelated technique which reduce the amount of bandwidth sent from server to client, by sending only the differences between the snapshot at baseline frame n and the current snapshot frame m on the server.
Just want to clear this up for anybody trying to follow along. Bringing in delta compression is an unrelated thing (but somewhat similar conceptually). It might confuse people to talk about these things at the same time, if they're really just trying to understand what the author is doing in the article.
cheers
- Glenn
I was also curious about this, and I don't think the other replies understood what was being suggested.
If I understood correctly, the aim of the engine is to lower the in-memory size of the history of game states, by only snapshotting the delta. I'm also curious what would happen if, instead, you'd just run any deterministic snapshottable physics engine, and delta compressed the history on the fly. I think this is how, for example, Braid works.
Might be that it doesn't work, that running the delta check on two big enough snapshots would be too slow, and that's what this engine fixes. But would love to hear if it was considered.