Oct 31, Fall 2005Game Design1 Networks Network Protocols Peer-to-peer Client-Server Configurations...
-
Upload
kenneth-robertson -
Category
Documents
-
view
216 -
download
0
Transcript of Oct 31, Fall 2005Game Design1 Networks Network Protocols Peer-to-peer Client-Server Configurations...
Oct 31, Fall 2005 Game Design 1
Networks
Network ProtocolsPeer-to-peerClient-Server ConfigurationsTrust
Oct 31, Fall 2005 Game Design 2
Topics
AI– Flocking & coordinated movement– Planning– Pathfinding and search
Networking– Multiplayer/things not covered today
Audio
Oct 31, Fall 2005 Game Design 3
Other topics
Advanced graphics– Animation– Deformation, inverse kinematics– Motion capture– Particle effects– Special lighting
Ethics– Cheating, justice
Oct 31, Fall 2005 Game Design 4
Other topics
Fake terrain Industry Playtesting
AIwisdom.com
Oct 31, Fall 2005 Game Design 5
Networks
Required for multiplayer games 3 Standard technologies
– Modems– Ethernet– Internet
Oct 31, Fall 2005 Game Design 6
Internet
The greatest thing since sliced bread The savior of humanity Will increase freedom and
democracy– Around the world– In your neighborhood
Oct 31, Fall 2005 Game Design 7
Internet User Protocols
TCP– Connection– Reliable– Bytes arrive in order
they were sent– Collects small
packets and transmits them together
– Stream of bytes
UDP– Connectionless– Unreliable– Arbitrary arrival
order
Oct 31, Fall 2005 Game Design 8
TCP
Reliable stream of bytes– Implies the need for a “connection”
Connection sets up data structures – Hold incoming packets– Hold outgoing packets– Handle retransmits
Oct 31, Fall 2005 Game Design 9
TCP Reliability
Each packet does Send-Receive-Acknowledge
Sender holds sent packet until ACK is received
Sender retransmits if ACK takes too long
Sender
Receive
ReceiverSend
Acknowledge
Oct 31, Fall 2005 Game Design 10
TCP
One Send-Receive-Ack takes time Overlay Sends and Acks Maintain a queue in sender and receiver
0
1
2
3
0
1
2
3
Ack
0
1
2
3
SendSender
Sender
Receiver
Oct 31, Fall 2005 Game Design 11
TCP Circular Queue -- Sender
Sends data and Puts it in send queue Sets timer on this queue item If timer expires, and no ACK, re-send
data– Set another, longer timer– Exponentially increasing time
When ACK received – If this queue slot is the oldest,
• Free the slot for new data If no queue space avail, sender app
waits!
Oct 31, Fall 2005 Game Design 12
TCP Receive Queue
Receiver maintains a queue the same size as the sender’s
When a packet arrives, send ACK If the packet is next in sequence
– Give it to application Else Keep it in queue
– Another, earlier packet is on its way
Oct 31, Fall 2005 Game Design 13
TCP
If no ACKS arrive for a long enough time– Temporarily gives up– Sends test packets
When test packets get through– Starts slow, builds up
Oct 31, Fall 2005 Game Design 14
TCP Wrap-up
Connection sets up sequencing and queues– Reliable arrival: Retransmit– Reliable order: Sequence numbers
TCP bunches up data on 200ms intervals– Minimizes overhead for small chunks of data– This option can be turned off
TCP Has an “emergency” channel– OOB Out Of Band
Oct 31, Fall 2005 Game Design 15
UDP Connectionless!
– No underlying data to maintain Unreliable transmission
– If you lose a packet, it’s gone– Network software must handle this
Out-of-order arrival– Network software must handle that, too!
Fast– When the port gets the data, the app gets it
Oct 31, Fall 2005 Game Design 16
UDP
Packets will drop!– 1 in 5 over non-local connection
Have to do your own re-send Some packets are time sensitive
– Care little about the past ship location No header compression
– May end up with greater overhead than TCP with PPP
Oct 31, Fall 2005 Game Design 17
Game Architectures
Peer-to-peer Client/Server
– One server per game Floating server
– One client is also a server Distributed server
– Multiple servers for large world
Oct 31, Fall 2005 Game Design 18
Peer-to-Peer
Simple version: Lockstep– eg. Doom– Each client transmits to other– Wait for everyone to get data– Proceed to next step
Oct 31, Fall 2005 Game Design 19
Peer-to-Peer
Advantages– Simple– Nobody has to provide a
server• Including the Game’s
authors!
– Good for turn-based games with low bandwidth
– TCP
Disadvantages– Frame rate is that of
• Slowest machine• Worst connection
– Hackable– Not good for real-time
games
Oct 31, Fall 2005 Game Design 20
Client/Server
Server per game– MUDs, Fireteam, NetTrek– Someone must provide server ($$$)
• Possibly the game’s authors
– Less hackable– Single point of failure– Server must be big & well-connected
Oct 31, Fall 2005 Game Design 21
Floating Server
Peer-to-peer Server resolves the action One peer is the server
– Unreal • One player elects to be the server
– X-Wing vs Tie-Fighter:• First player to enter session
– Starcraft• Player with the CD
Oct 31, Fall 2005 Game Design 22
Multiple Server
Many machines coordinate service– Ultima Online, Everquest, AOL
Used for large virtual worlds Everquest
– One server per game-geographic region– Freeze on handoff affects game play
Oct 31, Fall 2005 Game Design 23
What Data to Send?
Sending entire world state is usually too much
Can send just user actions– Simulation engine does the same thing at
each client– Pseudo-random numbers from same seed
Oct 31, Fall 2005 Game Design 24
Sending User Actions--Problems Any error in engine
– Divergence in worlds– Small error can lead to big divergence
X-Wing vs Tie Fighter– Created a resynchronize protocol– Causes jumps
• Wrote smoothing algorithm for resynchs Sim City 2000 Network Edition
– Send checksums for world state each turn
Oct 31, Fall 2005 Game Design 25
Prediction
Eg. Unreal Waiting for user inputs is too slow Client does prediction
– Motion prediction Server corrects things if client is
wrong
Oct 31, Fall 2005 Game Design 26
Prediction: Dead Reckoning
Eg. SIMNET (US Army Tank Simulator) Each vehicle simulates own tank Sends data every 5 seconds, updating
– Position, Speed, Acceleration– Expected path– Prediction violation criteria
Receiver simulates own tank– AND simulates local copy of other tanks
Oct 31, Fall 2005 Game Design 27
Dead Recokoning
Receiver gets latest 5-second update Updates own copy of other tanks Predicts other tanks
– Using prediction data– Until new data arrives
Each simulator also sends update– When own prediction violates own criteria
Assumes latencies < 500ms
Oct 31, Fall 2005 Game Design 28
Dead Reckoning
Sim A
A’s Predicted Path
B’s Predicted Path
Sim B Sim A
A’s Predicted Path
B’s Predicted Path
Sim B
B Exceeds prediction: predict again and transmit
Transmit new prediction every 5 seconds
Predict B Predict BPredict A Predict A
Oct 31, Fall 2005 Game Design 29
Dead Reckoning: Requirements
Data structures for other entities Model of entity behavior
– Vehicle speed, acceleration range, turn radius
– Responsiveness to commands Situation parameters
– Following a road – Precomputed path (NPCs)
Oct 31, Fall 2005 Game Design 30
Multiple Copies
Maintain 2 Data sets Now
– Accurate self– Predicted others– “Zero” latency for self
Ground Truth– Accurate everybody– Large latency for almost everybody– 200-500ms ago
Oct 31, Fall 2005 Game Design 31
Latency Issues
When latencies get high– Prediction gets worse and worse
Correcting prediction errors may cause visual jumps– Easy to notice!
If jumps are large enough– Temporarily interpolate between wrong
prediction and the new correction
Oct 31, Fall 2005 Game Design 32
Prediction Interpolation
Real
InterpolatedResponse
Predicted
Oct 31, Fall 2005 Game Design 33
Some games may allow distributed ownership– Ballistic simulation– Shooter fires bullet– Intended target receives the simulation
Sports - eg. Tennis– Player A hits ball– Player B gets simulation token – B simulates ball path from A’s racket
Token Ownership
Oct 31, Fall 2005 Game Design 34
Trust
“Never trust the client” Data on the user’s hard drive is
insecure– Diablo utility to modify character data– Wrote patch to prevent hacking
• Throws out your stuff if there’s a time inconsistency
– Daylight savings nuked my stuff!
Oct 31, Fall 2005 Game Design 35
Trust
Network communications are insecure NetTrek communications are encrypted NetTrek also requires “blessed” client
– Servers have different policies on requiring a blessed client
– Prevents robot players or assistants
Oct 31, Fall 2005 Game Design 36
Trust -- Checksums
First line of defense:– Checksum of all packets– Include header in checksum!– Stops casual tampering
Hash function– Hard to compute source value from
result– MD5
Oct 31, Fall 2005 Game Design 37
Checksums
Not immune to:– Code disassembly– Packet replay
Packet replay attack:– Capture a legal packet, and re-send it more
frequently than allowed– Client can restrict send frequency– Server cannot reject high-frequency
packets• Internet bunch-ups are source of OK bunch-ups
Oct 31, Fall 2005 Game Design 38
Combating Replay
Each new packet client sends is different– Add a pseudo-random number to each packet– Not just sequence number!– Client & Server match pseudo-random
numbers Random numbers
– Seeds must match!– Dropped packets: include sequence number!
Oct 31, Fall 2005 Game Design 39
Combating Replay
XOR each packet with a pseudo-random bit pattern– Make sure the bit patterns are in sync!– Based on previous synchronized
pseudo-random numbers Add junk – Confuse length analysis
Oct 31, Fall 2005 Game Design 40
Reverse Engineering
Remove symbols Put encryption code in with rest of
network stuff Compute magic numbers:
– At runtime– In server
Encrypt from the start!
Oct 31, Fall 2005 Game Design 41
Lists Of Servers
Denial of service:– Send a packet to server-server saying
“I’m a server”– Fake the IP return address with a
random IP#– Server-server adds “new server” to list– Server may run out of memory storing
hundreds of thousands of fake servers
Oct 31, Fall 2005 Game Design 42
List of Servers
Require a dialog– Server-list server responds with
• Password• Keepalive interval
– Password must be given by attacker at the correct time
– Works OK if client is not better connected!
Oct 31, Fall 2005 Game Design 43
References
CS4455 course at GA Tech by Chris Shaw
http://www.cc.gatech.edu/classes/AY2005/cs4455_fall/