490 likes | 643 Views
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
E N D
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
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) RTT Bandwidth
What is a perfect connection? • Ideally: • Infinitely small latency (0 ms) • Unlimited bandwidth (999999999… Mbps) • Realistically:
Computer Networking ReviewPart 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)
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? • 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 • Game could become out of sync • One small change could destroy synchronization • Doesn’t support late join • Everybody needs to start from the same state • 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 ReviewPart 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 • No more turns = Less latency • Other player’s latency will not slow you down Process changes
Client/Server Benefits • 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
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 User perceives lag Server Correction Client Prediction Client’s Modified Prediction
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
Gears of War 1 (2006) and 2 (2008):Host Advantage 0:57 Host 1:05 Non-host
Another problem with Client/Server • I shoot another player and know it is a hit • Client sends shoot command to server • Contains point of origin, and direction • 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 • Client sends shoot command to server • Contains point of origin, and direction • Server gets command • 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 Player2’s position seen from Player1’s client • Counter Stike: • View of Player1’s point of view from the server • Player2 is running to the left Player2’s actual position on server
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!
Extra Tricks In Use Now • Game: Halo: Reach • Developer: Bungie Studios
A closer look atClient-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 • 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)
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