Real-Time Networking in Games

• Why this subject? Don't we just use HTTP at Synacor?
  •  Still good to know about what's possible, have more tools in your toolbox
  • Maybe some business opportunity in the future has an engineering problem that one of these protocols better suits
• Overview of use cases for HTTP, TCP, UDP
  • HTTP: request/response, connect then disconnect
  • TCP: constant connection, guarantees ordering, essentially like writing to a file
  • UDP: no sense of connection, broadcast and listen for packets, no guarantee of order or delivery
• What's best for real-time games?
  • Could possibly make an argument for TCP under certain conditions and game design
  • TCP and WebSockets are good enough for streaming video, right?
  • But really, despite its lack of guarantees, UDP is actually the winner
  • Games have requirements about player input, and only need to convey the most recent "snapshot" of the game world
  • i.e. streaming video on TCP can create a buffer, rewind, etc. as long as the content gets to you, you're good
  • Real-time games have data that gets invalidated and discarded -- reliable, in-order packets actually get in the way of that - whenever a packet gets lost, everything else has to stop and wait, all for data that happened ages ago relative to a person's perception
  • Possible to have multiple kinds of streams in a game -- HTTP to talk to RESTful services like authentication, TCP for level loading, UDP for gameplay. Mixing TCP and UDP makes things more complex, using only UDP means you have to re-implement the parts of TCP that you want yourself, using only TCP is bad for real-time sensitive gameplay. Tradeoffs for each.
• a whole buncha this http://gafferongames.com/networked-physics/deterministic-lockstep/

Protocols

• HTTP:
  • Based around a client asking a request from a server, which sends a response
  • Forms connections only to send those requests and responses, disconnects when done.
• TCP:
  • ​Constant, maintained connection
  • Treats data stream essentially the same as a file
  • Has guarantees of in-order packets, reliable delivery
• UDP:
  • Broadcasts and listens for packets, no connection
  • The bare minimum - no guarantees, most flexibility in application code

Which protocol is best for an online game?

Real-time data, like a massively multiplayer online game, or a first-person shooter

By 'real-time', consider:

A game ideally updates visually at 60 FPS, or once every 16 milliseconds

Latency and ping in ideal conditions are roughly 50ms for most users

It's a bunch of smoke and mirrors to make it all look smooth

Which protocol?

• TCP might get you close, and it's good to start with if you're new to making networked games
  • Playout delay buffer
    • Treat game state data like a Youtube or Netflix video

but...

• If you know what you're doing, UDP is the clear winner.

Why UDP?

• TCP is just a poor choice for the problem
  • Perfectly fine for other situations! Just not here.
  • Reliable, in-order packets don't work when:
    • We only care about visually representing the most recent game state
    • If a TCP packet gets dropped, everything else halts -- but now the data's stale and out of date

Why UDP? (2)

• Don't just re-implement the parts of TCP you want
• Make something tailored to time critical data
  • Packets are going to get lost - some are critical and we can't just ignore them
  • Instead of resending lost packets, bundle lost/un-acked packet inputs into next packet
  • Better yet, inputs don't often change from frame-to-frame -- possible to send only frames where input changes

Title Text

Subtitle