Warcraft III, by Blizzard

CSE 381 – Advanced Game ProgrammingNetworked Gaming Issues

Types of Online Games

• U.S. games market for 2004 was $ 7.3 billion– roughly 42% of gaming was done online in some

capacity

• Common online game types:– Deathmatch FPS

• direct control over avatar

– RTS, RPG• indirect, delayed control over avatar

– Casual Games– Mobile Games

• Used to rarely be plot driven, that’s changed

Concerns for Networked Game Programmers

• Throughput– amount of data that can be stuffed into the pipe– usually not a problem

• Latency– end-to-end delay– a problem for certain game types

• Jitter– variation of latency

• Packet loss– data lost along the way

Bandwidth

• Maximum transfer rate of a communication channel

• Size of a pipe

• The goal of the networked game programmer:– ensure there is little enough information going through

the pipe so as not to take up all available bandwidth– ensure enough data is passed to maintain data properly

Bad Bandwidth Assumptions

• It’s easy to blame bandwidth for poor network performance

• There are other culprits

• Ex:– Input buffers get filled faster than they get emptied

• To quote John Carmack talking about slowdowns:– “most of the problems are due to having far too many

buffers and abstractions between the data producers/consumers and the actual wire”

Latency & Gameplay Degradation Research

• RTS – Warcraft III

• with latency of several seconds, still minimal degradation of gameplay

• Sports Games– Madden NFL Football

• when latency over ½ second, rapid degradation

– Car racing simulation• latency over 50ms affects game results

• latency over 100ms affects realism of game

• FPS– Unreal Tournament 2003

• latency over 75 ms noticeable to players

• latency over 100 ms made gameplay less enjoyable

Generally Speaking

• Typical latency in a game played over a 56k modem would be 160 – 200 ms

• Human tolerance for game delays is 100 – 200ms– or lower for fast paced games as we’ve seen

• Too bad for mobile games– GPRS typically has round trip times of 1000 – 2700 ms– For newer 3G networks, 400 – 500 ms– Even longer if you want to use GPS

Network Information

• Much information is available to a network programmer (and API like DirectPlay)– statistics about network traffic– ex:

• peak throughput through pipe (bytes per second)• average throughput ( bytes per second)• round trip latency• number of timed-out messages

• Is the server sending too much data?• Can it send more?• Ex: long round trip latencies may mean you are

saturating either the client or server bandwidth

Some DirectPlay Rules

• Will not send messages to a remote computer faster than it can process them

• If it detects a remote computer isn’t responding fast enough:– will queue the message on the sender– won’t send it until a more appropriate time– ultimately, packets may be coalesced or timed out

• Doesn’t this ruin it for everyone?– only those players’ computers struggling to keep up will be

affected

• Programmers may also check the queue. Why?– to see if it’s filling up– if so, send less data to a client

Decisions to make

• Types of data to send

• Should prioritizing be used?– If so, what algorithm should be used?

• TCP vs UDP

• Should prediction and/or simulation be used?– If so, what algorithm should be used?

• Network Architecture

Minimize Data Sent

• Remember, the most important thing in tuning your network performance is to eliminate unnecessary data being passed across the network

• Rules of thumb:– don’t send strings unless it’s necessary– always send the smallest data types possible– never send a boolean variable

• especially if you have more than one• what if you have 4 booleans to send?

– send one byte that is bit-masked

• The more data you can get in the smallest packets, the more available network bandwidth you have

• Throughput requirement examples:– Counter Strike: approx. 34kbit/s– Warcraft III: approx. 5kbit/s

Prioritizing

• Deciding what data to send– don’t send all data, FPS in particular. Why not?– minimize the amount of data sent– Send only part of game state

• that which is currently relevant to a player

• Ex: positions of viewable players only

• Another approach: prioritize bandwidth– divide network bandwidth up among clients– provide more bandwidth to players who currently need

it more

TCP vs. UDP

• Both transport layer protocols on top of IP• What’s the difference?• TCP is lossless. What’s that?• What TCP (Transmission Control Protocol) gives you:

– reliable delivery

– retransmission and reordering

– congestion control

• What UDP (User Datagram Protocol) gives you:– unreliable delivery

– no retransmission, packets not ACKnowleged, no reordering

– no congestion control

– speed & low overhead (good for streaming audio/video)

TCP vs. UDP

• Which should you Use?• That depends• Some game data can be interpolated

– if packet is lost, the game can continue

• Some game data must be guaranteed to be received– some things can’t and shouldn’t be interpolated

• Understand TCP is slower, but safer• Both are used, both have virtues, both have drawbacks• Programmers are always looking for UDP opportunities• Alternative: write your own “Reliable UDP” and use for

certain types of info sent

Prediction & Simulation for Clients & Servers

• What does a client do in between receiving network communications?

• How can it render the game world for every frame?

• Prediction & Simulation– use some algorithm to predict what will happen and

simulate the results– obviously not everything should be

predicted/simulated

• For example, where are the other players located?

Mobility Models

• Prediction & Simulation Algorithms for actor movement

• Dead Reckoning– interpolate where an actor will be based on most recent

state– what’s the problem with this?

• Informed prediction– what are past patterns of movements– statistical predictions

Network Architectures

• The reality is that most architectures are hybrids– much processing is done on clients

• ex: collision detection

– would be too much of a strain on servers– much prediction must therefore be done on clients

• ex: players manage their own movements

– cost of this: cheating

References

• Unreal Network Architecture– http://unreal.epicgames.com/Network.htm

• Networking Multiplayer Games by Sugih Jamin– http://ai.eecs.umich.edu/soar/Classes/494/talks/lecture-15.pdf

• Analysis of Factors Affecting Players’ Performance and Perception in Multiplayer Games by Matthias Dick, Oliver Wellnitz, Lars Wolf

• John Carmack’s Blog– http://www.armadilloaerospace.com/n.x/johnc

• High Latency Multiplayer Gaming by Edward Hannay