Netplay strategies

[hackfresh]

The buffering methodology Tepples describes (re: the emulator working on input 4 frames behind what's active) is commonly used, but the problem is that 4 frames is sometimes too little, or in other cases too much. It's going to vary based on several variables, absolutely none of which your emulator/game/whatever has control over.

Usually taking a measurement over X seconds before you load the game provided the connection you are on isn't experiencing heavy packet loss will give you an accurate measurement of the typical delay.

In peer to peer, its typically ping/2 rounded up to the nearest frame integer. Given the small amount of data that needs to be sent this is usually good enough 99% of the time and not a very difficult calculation to do.

[hackfresh]

Sorry last post...

For game that require near frame level responsiveness you don't want the extra delay that TCP by its very nature demands unless I'm understanding things wrong... you ALWAYS have to wait for the acknowledge. Versus using UDP you just have ask for a re-transmit on the rare times the packet does not arrive. On good connection packet loss should be very low. So yes you need to implement a good part of what TCP does but its worth it for twitch type games.

USing UDP with some minimal checking for re-transmit input delay is:

ping/2 +1

With TCP always requiring and acknowledge its

ping +1

Say I'm playing someone on the east coast from the west coast and I have an effective ping of 130

At 60 FPS With TCP I'm looking at 130ms/ (16.6ms per frame) +1 = 9 frames

At 60 FPS With TCP I'm looking at (130ms/2) / (16.6ms per frame) +1 = 5 frames

4 frames may not seem like much but in a sports, FPS, twitch type game its very noticeable.


If you just expect netplay to be used for LAN then TCP is fine as it would be a 1 frame difference.

[tepples]

If the emulator predicts that I didn't press a button to say pass the ball but I actually did press a button to pass the ball and it has to go back and re-do that if too many frames have gone by. Correct? That seems like a worse experience

In practice, changing the past feels closer to lagless than an occasional freeze.

For many parts of your game, for example player input and character positions, it really doesn’t matter what happened a second ago, you only care about the most recent data.

If your opponent launched a rocket at you a second ago, then you do care about what happened a second ago. But if you're not seeing the other player's keypresses for a whole second, then your pings are in the satellite range, and you'd have problems with SSH as well.

Kailerra which Nestopia and other emulators used to help implement netplay has worked well. It uses UDP to provide a less laggy experience. We've used it for our online NES leagues to great success. It figures out the needed frame delay by taking a ping average or a certain period of time.

So what happens if the player presses a button during a momentary freeze?

With TCP always requiring and acknowledge

TCP ultimately requires an acknowledge, but several packets can be in flight at once so long as they fit in a receive window. As I understand it, each packet is added to the receiver's stream once it arrives at the receiver, which is ideally half a ping after it is sent.

[hackfresh]

Another good article on the subject of TCP vs UDP


https://1024monkeys.wordpress.com/2014/ ... dp-vs-tcp/