Transcript 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 Review
Part 1
• CS 3830 - Data Communications and
Computer Networks
– Latency = Delay, amount of time it
takes a packet to travel from source
to destination
RTT
• 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
What is a perfect connection?
– Ideally:
• Infinitely small latency (0 ms)
• Unlimited bandwidth (999999999… Mbps)
– Realistically:
Computer Networking Review
Part 2
• 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)
TCP vs. UDP
TCP
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.
2.
3.
4.
Receive other player’s commands
Evolve the game state
Start recording commands
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
Computer Networking Review
Part 3
• Client/Server model
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
Client/Server Benefits
2. No more consistency issues
– Game is only being simulated on the server
(Peer-to-Peer Lockstep: game simulated on all
machines)
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
Interpolated
Game State /
Rendered
Frame
Game State 2
Game State 1
Entity Interpolation
with dropped packet safeguard
?
Client/Server with Entity Interpolation
Benefits:
• Provides a very smooth experience (unlimited
framerate) that is much better than Peer-toPeer Lockstep
• Clients still run minimal code (no
physics/collisions)
Client/Server:
Big Problem
+
= LAG!
(user-perceived latency)
• Client1 has an unfair advantage
• If not dedicated server, huge host advantage
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
User
perceives lag
Client
Prediction
Server
Correction
Client’s
Modified
Prediction
Client-Side Prediction
How 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
Command
Command
Command
Client
Prediction
Predicted
Actual
Predicted
Actual
Location
Predicted Location
Actual
Location
Location
Location - Location
Forward - 3 seconds
(0,3)
Forward - 3 seconds
(0,3)
(0,2)
Forward
3
seconds
(0,3)
Right - 4 seconds
(3,4)
- (0,2)
Right - 4 seconds
(4,3) (4,2) Right
4
seconds
(4,3) (4,2) - (4,2)
Forward - 2 seconds
(3,6)
Forward - 2 seconds
(4,5) (4,4) 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 hit
2. 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 command
a)
b)
c)
d)
Estimates when the client executed the command using RTT
Rolls back the game to the time of shot
Simulates shot, checks for collision
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 3
Getting Gameplay Networking Right
Extra Tricks In Use Now
• Game:
• Developer:
Halo: Reach
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.22/0.97/127
0.50/1.00/0
Legend:
Final priority / relevance / desired update period (ms)
Bungie’s Networking Stack
Layer
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
Link
Channel
Manager
Flow and congestion control
Physical
Transport
Send & receive on sockets
Internet
Protocol Stack
Application
Transport
Network
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_Networki
ng>.
• 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?