TIL that some programmers have to be taught what others learned first hand by encapsulating IPX packets inside TCP/IP[1] packets inside PPP packets modulated over the POTS network.
(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!"
This article ends right when you expect him to start telling you everything you need to know about game networking.
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!:
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...
This is a great series of articles - I had searched for such information a month or so ago, as the subject was made interesting and relevant to me due to being a Beta-backer of Elite Dangerous, which is using a combination of client-server plus P2P networking whilst playing in the "All-Online" mode (multiplayer), and just uses client-server in the "Solo-Online" mode.
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.
What is the client sending to the client exactly? "I pushed down W" and "I released W" or send "I am holding down W" every X ms?
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.
The details vary, of course. Typically it's any gameplay-related commands the player gives.
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.
People who are interested in this may also be interested in Mauve's posts on rollback-based netcode for fighting games, and how he handled some issues related to that:
I found great joy in reading about Quake3's networking model [1]. It is build on top of the assumption that the network is unreliable: most of the packets will be dropped and those that make it are not in sequence.
(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!"