gameplay networking

Gameplay Networking

Jacob Steinfort

Importance of Multiplayer Games

• If gamers had to choose either a single-player game or a multiplayer game, most people will choose multiplayer

• Why?– Beating your friends is more fun than beating an

AI– Get a different experience every time you play the

game

USA 2011 Top Unit Sales

Multiplayer

Single-Player

Importance of Getting Multiplayer Right

• If developers provide a bad experience, people won’t buy the game

How do we get multiplayer right?

Computer Networking ReviewPart 1

• CS 3830 - Data Communications and Computer Networks– Latency = Delay, amount of time it

takes a packet to travel from source to destination• RTT (Round Trip Time)= source ->

destination ->source• Usually measured in milliseconds (ms)

– Bandwidth = amount of data that can be transferred per unit of time• Usually measured in Megabits /

second (Mbps)

Bandwidth

RTT

– Ideally:• Infinitely small latency (0 ms)• Unlimited bandwidth (999999999… Mbps)

– Realistically:

What is a perfect connection?

• Socket = bidirectional communication endpoint for sending and receiving data with another socket.

• Two main types of sockets:– TCP (Transmission Control Protocol)– UDP (User Datagram Protocol)

Computer Networking ReviewPart 2

TCP vs. UDPTCP UDP

Connection based (handshake) No concept of connection, have to code this yourself

Guaranteed reliable and ordered No guarantee of reliability or ordering of packets. They may arrive out of order, be duplicated, or not arrive at all!

Automatically breaks up your data into packets for you

You have to manually break up your data into packets and send them

Makes sure it doesn’t send data too fast for the internet connection to handle (flow control)

You have to make sure you don’t send data too fast for your internet connection to handle

Easy to use, you just read and write data like its a file

If a packet is lost, you need to devise some way to detect this, and resend that data if necessary

Slow Fast

Why UDP?

• Real-time requirement– For most parts of a game, it doesn’t matter what

happened a second ago, you only care about the most recent data

Gameplay Networking

• What is it?– Technology to help multiple players sustain the belief that

they are playing a game together– Is it possible to achieve this?

• Challenges:– Latency– Bandwidth– Dropped Packets– Cheaters– Joining/Quitting Games in progress

What type of games will I be talking about?

• Action Games– Emphasizes physical challenges, including hand–

eye coordination and reaction-time

Best Example:

SHOOTERS!

First technique of Gameplay Networking:

Peer-to-Peer Lockstep• Each computer exchanging information with every

other computer• Process: extract a game into series of turns and a set

of command messages– Example: turn = 50ms; set of commands = {move unit,

attack unit, construct building, …}• What happens during a turn on one machine?

1. Receive other player’s commands2. Evolve the game state3. Start recording commands4. Stop recording commands and send them to other peers

Peer-to-Peer Lockstep

• Was created for RTS (Real Time Strategy) games– Game state was too large to transmit• Had to settle for transmitting changes only

Peer-to-Peer Lockstep

• Deterministic– Will always produce same output when given

same input– Synchronized: each machine is at the exact same

state at any given time

Problems with Peer-to-Peer Lockstep

1. Game could become out of sync– One small change could destroy synchronization

2. Doesn’t support late join– Everybody needs to start from the same state

3. Everybody’s perceived latency is equal to the slowest latency– Necessary for consistency

Peer-to-Peer Lockstep

• Does it work for action games?– Maybe on LAN, definitely not over the Internet

• Problem: input latency

Doom (1993):First action game to attempt to implement peer-to-peer lockstep

• Client/Server model

Computer Networking ReviewPart 3

Solution:

Client/Server• Each client has only one connection: to the

server• Clients turned into “dumb” terminals– Input sent to server (real-time) to be evaluated– Server sends updated game state (their player and

all other players) to the client

2 Types of Client/Server:

• Dedicated Server– Clients are the only players

• Non-dedicated Server– Server is also a player– Server player is called “Host”

Client/Server Benefits

1. No more turns = Less latency– Other player’s latency will not slow you down

Process changes

2. No more consistency issues– Game is only being simulated on the server

(Peer-to-Peer Lockstep: game simulated on all machines)

Client/Server Benefits

Client/Server:Small Problem

• Frame rate on client is limited to how frequently the server sent the game state to the client

• Solution: Entity Interpolation!

Entity Interpolation

Game State 1

Game State 2

Interpolated Game State /

Rendered Frame

Entity Interpolationwith dropped packet safeguard

?

Client/Server with Entity Interpolation

Benefits:• Provides a very smooth experience (unlimited

framerate) that is much better than Peer-to-Peer Lockstep

• Clients still run minimal code (no physics/collisions)

Client/Server:Big Problem

• Client1 has an unfair advantage• If not dedicated server, huge host advantage

+ = LAG!(user-perceived latency)

New Solution:

Client-Side Prediction• As soon as user changes input, their machine

predicts where the server is going to put them– Push forward on keyboard, instantaneously move

forward on screen• Client needs to run more code– Client needs to be aware of physics and collisions

(don’t want to run through a wall)

Client-Side Prediction(This is where it gets complicated)

• After RTT has passed, the client gets the updated game state from the server and verifies that its game state WAS equal to what it predicted– If not, client performs correction

Server Correction

Client Prediction

Client’s Modified Prediction

User perceives lag

Client-Side PredictionHow to implement?

• Need a circular buffer on the client to store the user’s last few commands – When correction comes in from server, client performs

new predictions based on the saved commands

Client Prediction

Command Predicted Location

Actual Location

Forward - 3 seconds (0,3) -

Right - 4 seconds (3,4) -

Forward - 2 seconds (3,6) -

Command Predicted Location

Actual Location

Forward - 3 seconds (0,3) (0,2)

Right - 4 seconds (4,3) (4,2) -

Forward - 2 seconds (4,5) (4,4) -

Command Predicted Location

Actual Location

Forward - 3 seconds (0,3) (0,2)

Right - 4 seconds (4,3) (4,2) (4,2)

Forward - 2 seconds (4,5) (4,4) (4,4)

… … -

… … -

Gears of War 1 (2006) and 2 (2008):Host Advantage

0:57 Host

1:05 Non-host

Another problem with Client/Server

1. I shoot another player and know it is a hit2. Client sends shoot command to server– Contains point of origin, and direction

3. Server gets the command and evaluates the shot– Server: client did not get the hit

Why?The position of other players on the client’s machine is always out of date. You only see a “ghost” of other players.

Possible Solution:

Give Client authority over shots• Client performs collision check right after shot– If hit, send a “hit confirmed” message to server

• Problem?– CHEATERS!– Man-in-the-middle attack

Actual Solution:

Lag Compensation

1. Client sends shoot command to server– Contains point of origin, and direction

2. Server gets commanda) Estimates when the client executed the command using RTTb) Rolls back the game to the time of shotc) Simulates shot, checks for collisiond) Server updates current game state

Counter Stike:• View of Player1’s point of view from

the server• Player2 is running to the left

Player2’s actual position on server

Player2’s position seen from

Player1’s client

Review of Basic Techniques• Peer-To-Peer Lockstep– Simple, works well for RTS games

• Client/Server– Much better for action games, frame rate limited

• Client/Server + Interpolation– Unlimited frame rate, still has large input latency

• + Client-Side Prediction– No more input latency, interacting with other players is lagged

though• + Lag Compensation– No lag with other players– Amazing!

Battlefield 3Getting Gameplay Networking Right

Extra Tricks In Use Now

• Game: Halo: Reach• Developer:Bungie Studios

A closer look at

Client-Side Prediction• This technique works great for the character

that the client is controlling• What about the other objects in the game

(e.g. a grenade)

Entity Extrapolation

Entity Extrapolation

• This is how it looks on a Halo: Reach client

Entity Extrapolation

• Only makes sense for objects that have predictable paths– Grenades, rockets, anything not being controlled

by a user• Doesn’t make sense to use on other players– Unpredictable direction changes– Have to stick with Interpolation for other players

Entity Extrapolation

• It’s so complicated, why use it?• To reduce lag

Another Trick:

Prioritization• A Halo game can have hundreds of objects– Some objects are less important to update on one

client and more important to update on another

• Solution: Real-time prioritization– Each object for each client has an update priority

Prioritization

Prioritization example

0.50/1.00/0

Legend: Final priority / relevance / desired update period (ms)

0.22/0.97/127

Bungie’s Networking StackLayer Purpose

Game Runs the game

Game Interface Extract and apply replicated data

Prioritization Rate the priority of all possible replication options

Replication Protocols with various reliability guarantees

Channel Manager

Flow and congestion control

Transport Send & receive on sockets

Internet Protocol StackApplicationTransportNetworkLinkPhysical

Check out Bungie’s Presentation

• I Shot You First: Networking the Gameplay of HALO: REACH– Game Developers Conference, 2011

Sources• Aldridge, David. "I Shot You First: Networking the Gameplay of HALO:

REACH." GDC Vault. Game Developers Conference, 28 Mar. 2011. Web. <http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking>.

• Fiedler, Glenn. "Networking for Game Programmers." Gaffer On Games. N.p., 1 Oct. 2008. Web. 1 Sept. 2012. <http://gafferongames.com/networking-for-game-programmers/>.

• Kurose, James F., and Keith W. Ross. Computer Networking: A Top-down Approach. Boston: Pearson/Addison Wesley, 2008. Print.

• "Source Multiplayer Networking." Valve Developer Community. Valve, n.d. Web. 1 Oct. 2012. <https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking>.

• Steed, Anthony, and Manuel Fradinho. Oliveira. Networked Graphics: Building Networked Games and Virtual Environments. Burlington, MA: Morgan Kaufmann, 2010. Print.

Sources

Videos:• Gears of War 2 Host Comparison– http://www.youtube.com/watch?v=7eToxVxGO9k

• Battlefield 3 – Jet vs Sniper– http://www.youtube.com/watch?v=o1s0ED51Tic

Questions?