3 ms·

See also: http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php http://www.gamasutra.com/view/news/177508/The_lagfightin

• sbarre 11y ago
  Just FYI that Gamasutra article is almost empty of any real details beyond the basics of client-side prediction and the actual linked magazine article from 2012 is a broken link. :-(
  • networked 11y ago
    Here's the correct link: http://twvideo01.ubm-us.net/o1/vault/GD_Mag_Archives/GDM_September_2012.pdf http://twvideo01.ubm-us.net/o1/vault/GD_Mag_Archives/GDM_Sep.... (If this link breaks try to go to http://www.gdcvault.com/gdmag http://www.gdcvault.com/gdmag and find a link the September 2012 issue there.)
  • hellbanner 11y ago
    I'm sorry -- I was loading from a bookmark where all the links had worked before! I responded above with more detail
• hellbanner 11y ago
  For most 2D fighting games, when a character jumps there's nothing else they can do but continue on their trajectory. When a character attacks, there's "startup frames", then "Active frames" and "recovery frames". So you throw a Punch with 5 Startup Frames. You send that packet with a timestamp. By the time it reaches me -- you're in Frame 2 of the Active Frame -- my client just updates straight to Frame 2, instead of starting at Frame 0 of the Startup Frames. This works because there's really no other state the action could have gone, and the frame counts are so low it's faster than humans can react to anyways. So it feels like you're playing locally. Same thing with jumping -- you might get my "Jump" action 20 frames later than I started it. So you just fast forward your client to that point. Our clients are effectively synchronized. Traditional clients would have you be continuously 20 frames lagging behind. It's a clever system!