I updated my Network Code Research mindmap. It includes now a presentation link from Gaffer On Networking. It is an excellent read especially to see how much the internet sucks for online gaming. The data Gaffer provides corresponds with my experience that I gained just by diving into the waters and trying my best at making multiplayer work good in my games. Here are the 4 bullet points:
- Most people in the world have max 64kbps up & down bandwidth and max 256 packets @ 30 packets a sec.
In the early versions of Soldat there was a big problem with this (and still is sometimes). I was sending lots of small packets thinking that is a good idea. When it got more than 30 packets a second bad things started to happen, pings would rise. I then combined all these packets in 1 megapacket sent each tick or couple ticks which worked much much better.
- Packet loss os not a problem. Typically ~0.5% loss
This is really nothing. I thought it was a problem and I’ve written the whole Link-Dead network code around the idea that packet loss is common. It is now extremely resistant to packet loss (as you can see on my youtube videos even 50% packet loss does little to the flow of the game). But half a percent is nothing to worry about! If I send 30 packets a second. This means typically there is 1 packet lost every 6-7 seconds. This data from Gaffer again corresponds with my empirical data. You can see packet loss as red dots or lines in Link-Dead by typing /n_graph 1 in the console (~).
- Latency is decent
Latency is not a problem. If you are playing on a server in your country it’s nearly as good as playing on LAN. This is the problem most developers and multiplayer development papers focus on. Ping isn’t really that much of an issue.
- Jitter and late packets are the key problem for real-time protocols
This is the real problem! And I see nobody focusing on this. In Valve’s paper on Counter-Strike network code they just say all incoming data is smoothened before displaying it to the player. This needs more explanation cause it is the key problem to all multiplayer game issues.
Jitter is caused by unpredictable networking delays (packets arrive either too fast or too late, rarely on time) or by delays of the game itself (when there is much going on the CPU will stall). If you do not take this into account your player will have jerky movement and warp around a lot. This needs to be smoothened. The client should never use the data he got from server directly, it always has to be somehow smoothened for better visuals. Gaffer shows an example of a packet arriving 1 second later with pings being 10 times smaller! This can cause chaos if you do not take this into account. Typically you just number the packets and discard any packets out of order. This is were packet loss really occurs, when you lose them yourself because they came out of order or late. So the time spent on making LD work with packet loss was not wasted. I spent an entire month before releasing the alpha trying every solution under the sun to make the multiplayer smooth in Link-Dead and the results are very good. If there is enough people interested I might share my experiences.
I were amazed how well the game plays at that awful, awful 200 ping Master server.
That server is awful because it is run on an emulator and is very slow.
But the game runs amazing for 200 ping, I agree.
I live in Australia, and was playing someone in Germany. No Lag D:
Yeah, the net code is really well done.
upload movie from lecture blzzzzzz.
MM, I’m pretty sure you looked at network engines before you made your own. What do you think about RakNet? Wouldn’t it solve your problems? You can set it to always receive the packets in the correct order and with 0 packet loss
Thanks
Clash: I used RakNet for a long time. Berserker ran on RakNet and the first implementations of Link-Dead. Short answer: for me it sucks. Long answer: do you need one? If you just hobby code RakNet is very good and easy to use.
“The client should never use the data he got from server directly, it always has to be somehow smoothened for better visuals.”
Yes, exactly.
I find the best way to think about networking is that each packet you receive (on the client side, for instance) is a tidbit of information. Hopefully some new information. It’s just a tiny piece of data that tells you a little more about the state of world at some certain time.
So each packet you get, you just toss it into your model of the world as you know about it.
Meanwhile, the client rendering code does something completely different, but it uses the background world state and tries to render something as close as possible to that.
tl;dr: Never ever use packets directly to render.
Good way of thinking about it.