What every programmer needs to know about game networking (2010)
gafferongames.com
gafferongames.com
(Not Kali, the OTHER one. :) )
Oh, and there used to be different types of game engines. You used to be able to SEE whether or not your engine was interpolating missing data, whether it was maintaining state on your end, their end, or both, etc--by observing how your opponents' ships would react when your mom picked up the phone in the kitchen.
Descent had a pretty darned good method.
Alice and Bob play a game. From Alice's point of view, the visual of Alice's weapon fire striking Bob's ship is rendered on her machine based on her machine's understanding of the location of his ship. But the AUDIO of weapon impact is "rendered" on Bob's end. So if you see impact, it means nothing--but if you hear impact, you know that 1) your fire collided with Bob's ship on his end and 2) it happened approx. n/2 seconds ago.
This resulted in a kind of meta-game wherein the lagscape was just part of the terrain. There was a 'general relativity' component to it: since neither side was master or slave... No point of view was privileged[2]. Alice had to keep two gamestates in mind at all times, the local to protect her hitpoints, and the remote to reduce his hitpoints.
In my opinion, both the "sound/visual disconnect" and the "no privileged POV" were necessary ingredients in order for the lag to be "part of the landscape"--ie, fair and fun.
[1]: Wait, did we already use UDP at that point? I can't recall...
[2]: Some pieces of gamestate were given to the client that started the game or the client with the highest FPS. I think the reactor countdown was finalized in one client, for example, resulting in the famous "3... 2... 1... 0... ... ... ... ... BOOM!"
I was Hobbes in those days and there are non-zero chances that we have played together.
Characteristics of UDP Packet Loss: Effect of TCP Traffic, Hidenari Sawashima, Yoshiaki Hori, Hideki Sunahara, Yuji Oie, 1997: http://www.isoc.org/inet97/proceedings/F3/F3_1.HTM
I Shot You First: Networking the Gameplay of HALO: REACH David Aldridge, 2011: http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networ...
Web archive to the rescue:
http://web.archive.org/web/20141118054424/http://gafferongam...
It would be better titled 'a brief history of game networking', and funny enough on the site that actually has everything a programmer needs to know about game networking this article has that subtitle. And that site is made by the author as well!:
http://gafferongames.com/networking-for-game-programmers/
Cool hn discussion with game network programmers here:
Thus far I'm having a pretty easy time ensuring that my games are deterministic functions of sequences of user inputs. For people who don't want to do that, this talk about Halo multiplayer is pretty informative: http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networ...
I have my doubts that Frontier Developments will be able to get the P2P side of the netcode working smoothly and properly by the 16th December when they officially release the game. I'm also having doubts that model will ever work smoothly for them, but, time will tell, and good luck to them for all that.
If the latter, how would you prevent the client from spamming it more than every X allowed ms? I'm thinking it would build up a queue if commands came in too fast but not sure how that would be handled exactly. Also, even with a queue someone spamming would gain an advantage since it would bridge the latency.
Example: If the client sends "move 1px to the right" every 20 ms and someone manually started sending it in every 5 ms instead, it would still only move every 20 ms on the server. However, wouldn't this still be better than sending it every 20 ms from the client since latency and other things (slow processor?) could mean the real interval is more than 20 ms?
This is a topic of where to process commands (client vs server), what data to send, which restrictions to impose, what rules to enforce, etc. Give client too much say in the simulation and it can ruin the experience of others, leave it all on server and enjoy your lack of speed.
You avoid the timing problem by having the client timestamp the packets. Time on the server side is quantized into "ticks", which are basically frames of game state that are independent from the clients' framerate.
Or at least, this is how Source engine does it.
http://mauve.mizuumi.net/2012/02/22/investigating-rollcaster...
http://mauve.mizuumi.net/2012/03/08/how-i-didnt-clip-the-sou...
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-g...
[1] http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Ne...
Oh, and the system described sounds similar to what is powering Warframe right now.
Rather puzzling. Traffic strategy?
Front page post on reddit from 19 hours ago: http://www.reddit.com/r/explainlikeimfive/comments/2n9rbj/el...
Top comment: http://www.reddit.com/r/explainlikeimfive/comments/2n9rbj/el... with content:
> Here's a longer writeup I found: http://gafferongames.com/networking-for-game-programmers/wha...