Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A physics engine with incremental rollback for multiplayer games

easel.games

Post reply on HN
Print view View original

11–20 of 46 posts

Re: A physics engine with incremental rollback for multiplayer games

#11

Post by ornitorrincos »

BSTRhino wrote: post #2

Hi everyone, I'm making a game engine that uses rollback netcode for its multiplayer architecture. As far as I can tell, no physics engine supports incremental rollback thus far. This means the entire physics engine state has to be snapshotted every frame, which basically means it's infeasible to have large worlds with rollback netcode. I've made a physics engine which only snapshots the changes, and so now I think y…

How does it compare with deterministic physics engines, given that their appeal for multiplayer is that they can perform rollback?

Re: A physics engine with incremental rollback for multiplayer games

#12

Post by gafferongames »

BSTRhino wrote: post #9
gafferongames wrote: post #7

Earlier quoted context omitted.

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. m…

Yes thank you, you understand perfectly and thank you for explaining. Also, I LOVE your series of blog posts, thank you for making them! Just to add to the general discussion for everyone following along - rollback netcode only sends inputs around, not state, so it doesn't really have much to send. I think I'm doing about 1.5 KB per second. When you point your mouse it sends that data in 10 bytes. There's not a lot t…

One cool trick you could try (although you are probably doing it already) is to include all inputs for some long period (like 1-2 seconds!) in every input packet the client sends to the server.

This way if one input packet gets lost, the very next one getting through will have all the inputs for the last 1-2 seconds, and this greatly improves how well your game will play under packet loss.

When you do this, you can even do an encoding from left -> right for all inputs, and actually, sort of delta encode inputs within the packet! Inputs don't change that much, so you can even get smart with the encoding and optimize it down to basically nothing.

Re: A physics engine with incremental rollback for multiplayer games

#13

Post by mncharity »

Fwiw, one case where I've wanted rollback has been input fusion over interface devices with diverse latencies. You might have 10 ms for a keypress, 100 ms for optical tracking, and 1000 ms for speech. So given click+"the red one"(spoken), you might start running click+"the one in front"(default), and almost a second later rollback and rerun with "the red one". Or for real example, keypress event handling might branch on optical "pressed where on the keycap" and "by which finger", which won't become available for several frames.

Re: A physics engine with incremental rollback for multiplayer games

#14

Post by stephc_int13 »

gafferongames wrote: post #7
stephc_int13 wrote: post #5

Earlier quoted context omitted.

Have 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.

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. m…

No, in this context I meant delta-compression in the case of local roll-back.

The entire gamestate has to be rolled back when using this style of netcode, regardless of bandwidth, reducing the size of snapshots in memory can also reduce make it faster to rebuild.

Re: A physics engine with incremental rollback for multiplayer games

#15

Post by BSTRhino »

gafferongames wrote: post #12
BSTRhino wrote: post #9

Earlier quoted context omitted.

Yes thank you, you understand perfectly and thank you for explaining. Also, I LOVE your series of blog posts, thank you for making them! Just to add to the general discussion for everyone following along - rollback netcode only sends inputs around, not state, so it doesn't really have much to send. I think I'm doing about 1.5 KB per second. When you point your mouse it sends that data in 10 bytes. There's not a lot t…

One cool trick you could try (although you are probably doing it already) is to include all inputs for some long period (like 1-2 seconds!) in every input packet the client sends to the server. This way if one input packet gets lost, the very next one getting through will have all the inputs for the last 1-2 seconds, and this greatly improves how well your game will play under packet loss. When you do this, you can e…

Ah yes, I have heard of this method but the idea of sorting/delta encoding is new to me and now I’m reconsidering!

Maybe some people might find it interesting - I’m relaying packets from peer-to-peer using Cloudflare Realtime, which is like a one-to-many broadcast system for WebRTC. Each peer sends their input packet to Cloudflare, then Cloudflare forwards that on to the 10 other players (for example). It’s cool because (a) 10x less upload bandwidth from the peer (b) people IP addresses are not revealed to their peers and (c) Cloudflare is in 400 datacenters around the world so it adds minimal latency. Cloudflare Realtime is a really cool system that maybe more web game developers should look into!

Unfortunately, I’m paying for all the bandwidth that goes through Cloudflare Realtime and so I have perhaps over optimised on minimising bandwidth by sending only one input per packet. The other part of my equation is I’m getting my server to broadcast authoritative batches of inputs every 100ms or so via TCP, so if a packet gets lost, every peer will eventually receive the input but it might be a bit slow, and it will cause a big rollback that might be noticeable.

Reading your comment makes me think it might not be as expensive as I thought, and maybe I can play around with how long of an input period I resend for. Perhaps there is a better balance to strike between cost and reliability. So thanks for bringing this up!

Re: A physics engine with incremental rollback for multiplayer games

#16

Post by BSTRhino »

stephc_int13 wrote: post #14
gafferongames wrote: post #7

Earlier quoted context omitted.

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. m…

No, in this context I meant delta-compression in the case of local roll-back. The entire gamestate has to be rolled back when using this style of netcode, regardless of bandwidth, reducing the size of snapshots in memory can also reduce make it faster to rebuild.

Actually, it doesn’t roll back the entire game state. Everything is stored in slot maps, and if there are 1000 slots and only 10 changed, it really does only rollback those 10 only and it does not touch anything else. Slot maps are great!

Re: A physics engine with incremental rollback for multiplayer games

#17

Post by BSTRhino »

ornitorrincos wrote: post #11
BSTRhino wrote: post #2

Hi everyone, I'm making a game engine that uses rollback netcode for its multiplayer architecture. As far as I can tell, no physics engine supports incremental rollback thus far. This means the entire physics engine state has to be snapshotted every frame, which basically means it's infeasible to have large worlds with rollback netcode. I've made a physics engine which only snapshots the changes, and so now I think y…

How does it compare with deterministic physics engines, given that their appeal for multiplayer is that they can perform rollback?

This physics engine is a deterministic physics engine. It has to be to make sure that when it rolls back and resimulates forward, it gets the same answer on all machines.

The determinism is partly possible because WebAssembly is deterministic (except for a few known cases https://github.com/WebAssembly/design/blob/main/Nondetermini...), and partly because I’m making sure to use my own trigonometric functions, and the entire game simulation is executed single threaded with a known order of execution.

If you meant to ask how does it compare to non deterministic physics engines, I’m sure they might be faster on the physics but would be slower on the rollback, and I think on most reasonably-sized games the slow rollback would dominate and so they would be slower overall. But, you wouldn’t make a rollback netcode game with that size of world anyway, at least maybe not until now, so it’s a bit of a false comparison. They’re good at their different use cases.

Re: A physics engine with incremental rollback for multiplayer games

#18

Post by BSTRhino »

mncharity wrote: post #13

Fwiw, one case where I've wanted rollback has been input fusion over interface devices with diverse latencies. You might have 10 ms for a keypress, 100 ms for optical tracking, and 1000 ms for speech. So given click+"the red one"(spoken), you might start running click+"the one in front"(default), and almost a second later rollback and rerun with "the red one". Or for real example, keypress event handling might branch…

That is a cool idea! Could be a great application of rollback!

Re: A physics engine with incremental rollback for multiplayer games

#19

Post by gafferongames »

BSTRhino wrote: post #15
gafferongames wrote: post #12

Earlier quoted context omitted.

One cool trick you could try (although you are probably doing it already) is to include all inputs for some long period (like 1-2 seconds!) in every input packet the client sends to the server. This way if one input packet gets lost, the very next one getting through will have all the inputs for the last 1-2 seconds, and this greatly improves how well your game will play under packet loss. When you do this, you can e…

Ah yes, I have heard of this method but the idea of sorting/delta encoding is new to me and now I’m reconsidering! Maybe some people might find it interesting - I’m relaying packets from peer-to-peer using Cloudflare Realtime, which is like a one-to-many broadcast system for WebRTC. Each peer sends their input packet to Cloudflare, then Cloudflare forwards that on to the 10 other players (for example). It’s cool beca…

If you want to get fancy you can track the last received input frame on the server and send it down to the client, then the client only needs to send inputs since the last asked input frame the server has seen.

Re: A physics engine with incremental rollback for multiplayer games

#20

Post by Gregaros »

gafferongames wrote: post #7
stephc_int13 wrote: post #5

Earlier quoted context omitted.

Have 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.

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. m…

[dead]
Post reply on HN