Here are the slides for my tutorial tomorrow
The goal of the tutorial is to show people the basic ideas of how to network a physics simulation
The key points are:
- Use UDP, not TCP
- Aim for 64kbit/sec – That’s 256 byte packets, 30 times per-second **
- Handle out of order packets with a sequence number
- Send input and physics state in your packet
- Snap the physics state and extrapolate
- Run the simulation on both sides, and use the input to improve extrapolation
- Use visual smoothing to hide errors
Of course, there is a lot more to it but I hope this serves as a good starting point if you want to get into networked physics
Cheers!
** actually, that’s a little bit over 64kbit/sec, especially when you include IPsec header for consoles and UDP packet header, it’s just such a nice number for folks to remember, I couldn’t resist a little white lie 
{ 9 comments… read them below or add one }
Just some quick thoughts.
Is this for a peer to peer model or client server model?
You do not seem to mention UDP frames overhead which adds to the upstream rate.
I am a little confused with your diagram of a packet, does this imply that input is sent even if the server is the sender?
Your maths seems wrong (or mine)64kBit is not 256 at a rate of 30 per second.
256*8*30 = 61440 bits per second
28*8*30 =6720 bits per second UDP overhead.
Users connections :
Reducing send rate for bad connections when packet loss above a threshold or the ping becomes high.
99 percentile is 8kbs – Bungie studios research.
Delta compression: is this used to snap an object or is this how position etc are send, as this may require knowledge of a packet which never arrived and was not reliable therefore not resent.
Compression: I assume you are going to talk about packing floats into uint16′s ie within a range?
When an object is close to the user sending high precession updates instead of compressed?
Client side reaction to events before server has authorised like your steering example?
I need some work doing in the bathroom do you have any more of the pipes
yeah i think i’ll add something on that – maybe a quick section on topology after the UDP/TCP/IP comparison
what i’m going to do is explain initially in the context of just two computers, so it’s kind of moot — but i will have to touch on authority issues, client/server vs. distributed peer-to-peer
my goal here is to show folks how to send their physics state over the network, do smoothing and extrapolation – then leave them with resources that explain further client side prediction, authority scheme, and my networking articles – so people can go read more and network their own sims
but yeah, i TOTALLY glossed over topology, so i’ll add that
thanks liam
Maybe you could talk about the problem to solve interactions (collisions) between rigid bodies in different timelines, or better said, under different authorities. I think that’s a very exciting thing for physics guys who love tech demos with brick stacks melting down, and bouncing balls runing down a valley
…Too much pipes.
yes i will briefly touch on authority scheme and how it works, then finish the talk with a Q&A session – i will show this in the demo, without slides
you didn’t like the pipes joke? waaaaaaah
Maybe not the biggest issue in a world but I wonder why do you use kbits/sec instead of kbytes/sec? I understand why ISPs are doing that (so they can show 8 times bigger numbers in advertisements, and that annoys me so much), but what’s your excuse?
Even if one uses for example a compression “thinking in bits” (Huffman), it’s still stored and send in bytes. Is there a reason in networking to talk about sending bits, other than that’s how ISPs show connection speed?
kbits/sec is (I think) standard for networking, xbox360 TCRs are specified in it – that’s where I learned it, so that’s what I use
cheers
That’s what I was afraid of (this confusing convention being actually used by network programmers
). Thanks anyway for the answer!
Yeah bytes are so scarce we think in bits instead
OK liam so sorry i missed your first comment somehow. you are right about all you say, I just simplified things to give people a very simple overview of the problem.
So this is why I told a white lie and said 64kbit/sec is 256 byte packets 30 times a second. It’s a nice round number. In truth this *is* slightly more than 64kbit/sec, so in reality you need packets that are a bit smaller. To cope with this what I do instead is drop to 10pps under bad network conditions. This way I’m hitting a half-decent bandwidth (nearish to 64kbit/sec) but then I drop to something around ~20kbit/sec when network conditions are poor.
Regarding the other points, the topic of the lecture was a very limited subset of the problem of networking physics. I only covered how to VIEW a physics simulation on a remote computer, no mention of topology, client side prediction, latency compensation, and all that – I wanted to keep it simple so people could get started with it.
There is definitely a whole other series of lectures where I cover the points you mentioned…
In fact, my friday lecture will touch on all of them – this is where I show the generalization of this technique to 4 players in peer-to-peer topology.
That’s all I have to say for now, I have to get back to work on the demo for friday
Thanks for your valuable feedback as always!