Networking'in'Games' Peer=to=Peer' In=game'Networking'Topics' Computer Networks. Lecture'32:' Multiplayer'Gaming'

Transcription

1 NetworkinginGames Differentiatebetweenin=gamenetworking andbackendinfrastructure Computer Networks Lecture32: MultiplayerGaming Backendinfrastructure: lobbywheregamersmeet authenticationandkeychecking accountingandbilling rankingandladder reputationandblacklist buddylists,clans,andtournaments modsandpatchesmanagement virtualeconomy bewareofddos Issues:scalability,adaptingtofailure,security In=gameNetworkingTopics Topology: client=serverorpeer=to=peer Computationalmodel: distributedobjectvs.messagepassing Bandwidthrequirement Latencyrequirement Peer=to=Peer Peer=to=peerwithO(N 2 )unicastconnections: eachplayerisconnecteddirectlytoallotherplayers eachplayersimulatesthewholeworld advantages:reducedlatency,nosinglepointoffailure disadvantages:easiertocheat,notscalable:eachclient mustsendandreceiven-1messages Consistency Whichtransportprotocoltouse? TCP,UDP,reliableUDP

2 Client=Server Twoflavors: ad=hocservers:deathmatch dedicatedservers:mmog Twotypesofclients: clientssimulateworld,serverhasauthoritativestate: allowsforclient=sidedeadreckoning(quakeiii/half=life) clientsasdumbterminal,allsimulationsatserver:useful forthinclients,e.g.,cellphones,andpersistent=world MMOG Client=Server Advantages: eachclientsendsonlytoserver,servercanaggregates dedicatedserversmakescheat=proofingeasier servercanbebetterprovisioned persistentstates(formmog) Server Disadvantages: longerdelay serverbottleneck singlepointoffailure needsservermanagement MMOGServerArchitecture1 Theworldreplicatedateachserver(shard) eachshardcontainsanindependentworld playersgotospecificshard MostMMORPG Shard1 Shard2 MMOGServerArchitecture2 Theworldreplicatedateachserver(mirror) alltheworldsaresynchronized playersseeeveryoneacrossallmirrors Mirrorsmustbekeptconsistent Mirror1 High-speed Connection Mirror2

3 MMOGServerArchitecture3 Theworldissplitintoregions eachregionishostedbyadifferentserver example:secondlife Serversmustbekeptconsistent Server1 High-speed Connection Server2 DistributedComputingModel Gamecompanieshavetheirpreferred computingmodelandwouldprovidehigh= levellibrariestoimplementthemodel Twocommonmodels: distributedobjects messagepassing DistributedObjects Charactersandenvironmentmaintainedasobjects inputsareapplied toobjects(atserver) Changestoobjects propagatedtoall playersatendof gameloop Objectupdateusually implementedasone ormorelibrarycalls Initialization Overall Game Send & Receive Object Updates Game Session Render scene to buffer Copy buffer to display Local Input Main Logic: - update objects - game AI - physics - collision Time sync MessagePassing inputs(eitherbuttonpushesorhigher=level ments)aresenttootherplayers(orserver) Allplayersupdatetheir owngamestate Orserverupdatesthe globalgamestateand sendsitouttoallplayers Initialization Receive Remote (s) Input Overall Game Send Local Input Game Session Render scene to buffer Copy buffer to display Local Input Main Logic: - update states - game AI - physics - collision Time sync

4 MultiplayerGamingTraffic Whatinformationissentinamultiplayergame? dependsonyourcomputingmodel distributedobject:gamestate,e.g.,coordinates,status, action,facing,damage messagepassing:userkeystrokes,e.g.,commands/s ForRTS:1every1.5-2sec,upto3-4commands/secduring battles(butsomeoftheseareredundantandcanbe filteredout) In=gameNetworkingTopics Topology: client=serverorpeer=to=peer Computationalmodel: distributedobjectvs.messagepassing Bandwidthrequirement Latencyrequirement Consistency Whichtransportprotocoltouse? TCP,UDP,reliableUDP BandwidthRequirement BandwidthrequirementhasbeenHIGHLYoptimized evenwithaudiochat,takesupatmost8kbps so,bandwidthisnotabigissue butnotetheasymmetricnature: fornplayers,youreceiven-1timestheamountofbytesyousendout mustbecontinuallyvigilantagainstbloat However,withplayer=createdobjectsandworlds, bandwidthbecomesanissueagain:usestreaming, levelsofdetails,andpre=fetching LatencyRequirement Howislatencydifferentfrombandwidth? Tolerableround=triplatencythresholds: RTS: 250msnotnoticeable, msplayable,>500msnoticeable FPS: 150mspreferred carracing:<100mspreferred, mssluggish, 500ms,caroutofcontrol sexpectationcanadapttolatency itisbettertobeslowbutsmooththantobejittery

5 LatencyEffect:Consistency Problemstatement: Inbothcases: Case1: Case2: time player1 at1:2 sarrivesafter1 s at2:1 sarrivesafter2 s Should2beconsideredshotinbothcases? Oronlyinthesecondcase? player2 Synchronization Synchronization:: ordersbytheirtimesofoccurrence Assumegloballysynchronizedclocks Out=of=synchworldsareinconsistent Smallinconsistenciesnotcorrectedcanleadtolarge compoundederrorslateron(deernotspearedmeans onelessvillagermeansslowerbarrackbuild,etc.) WhentoRenderaMove? Howlongdoyouhavetowaitfortheother playerssbeforerenderingyourworld? time player1 X player2 Lock=StepProtocol Algorithm:eachplayerreceivesallother players sbeforerenderingnextframe Problems: time 1 2 longlatencyontheinternet variablelatencies jitterygamespeed gamespeeddeterminedbytheslowestplayer synchronize s and render scene

6 BucketSynchronization PessimisticConsistency Algorithm: bufferbothlocaland remotes playtheminthefuture eachbucketisaround, sayofabout200ms bucketsizecanbe adaptedtomeasuredrtt time Smootherplay,but: gamespeed(bucketsize)still determinedbyslowestplayer whatifaislostorlate? 1 X 2 synch s and render scene a player can have multiple s per turn Everyplayermustseetheexactsameworld eachplayersimulatesitsowncopyoftheworld alltheworldsmustbeinsynch usesbucketsynchronization eachplayersendsstoallotherplayers droppedpacketsareretransmitted adesignatedhostcollectsmeasuredrttsfromallplayersand setfuturebucketsizes Problems(thoseofbucketsynchronization): variablegamespeediflostpacketsmustberetransmitted speeddeterminedbytheslowestplayer DeadReckoningandRoll=back Deadreckoning,a.k.a.client=sideprediction extrapolatenextbasedonpriors e.g.,computethevelocityandaccelerationofobjectstodeadreckon v lost or late, dead reckoned playerscanhelpbysendingvelocityandaccelerationalong obviously,onlyworksifvelocityandaccelerationhaventchanged Incaseofinconsistency: serverassumedtoalwayshaveauthoritativeview whenclientscorrect(roll=back)inconsistentviews, playersmayexperience warping OptimisticConsistencywithRoll=back Observation:deadreckoningdoesnthavetobe limitedtolostpackets! Half=Life: eachclientplaysbackitsownsimmediatelyand sendsthestoserver eachclientalsodeadreckonstheotherplayers s servercomputesworldandsendsitsauthoritative versiontoallclients clientsreconciledeadreckonedworldwithserversversion onlyneedtosynchronizeimportantevents,butmustbe carefulthatdeadreckoningerrorsdontgetcompounded overtime canresultinsomejerkinessandperceptionof shootingaroundcorner

7 ShootingAroundCorner X Consistency:Correctness Forconsistencyalluserinputmustpassthroughthe Initialization Overall Game synchronizationmodule Becarefulwithrandom numbergenerators:isolate theoneusedforgame=state updatingfromotheruses Send Local Input (ambientnoiseetc.) Receive Remote (s) Input Designformultiplayerfromthestart single=playerbecomesaspecial caseofsingle=clientmultiplayergame Game Session Render scene to buffer Copy buffer to display Local Input Main Logic: - consistency - game AI - physics - collision Time sync Consistency:Smoothness Forsmootherplayback,decouplebucketsizefrom framerate Immediatelyrenderlocals Modifygamedesigntoallowforlatencyandloss,e.g., makeplayerwaitforelevator teleportationtakestime requiremultiplehitsperkill,evensniperscanmiss letbullet/missilehaveflyingtime buildininertia,dontallowsuddenchangesinfacing ReducingConsistencyCheck Doarea=of=interestmanagement (a.k.a.relevancefiltering): aura:howfaryoucanbesensed (ninjasandcloakedshipshaveauraof0) nimbus:howfaryoucansense (empathandquantum=sensorhavelargenimbus) PerformconsistencycheckonlywhenBiswithinAs nimbusandaiswithinbsaura Auraandnimbusaredefinedforagivensetof game technology (e.g.,cloakingdevice,quantumsensor,etc.)

8 WhichTransportProtocoltoUse? Gamingrequirements: latepacketsmaynotbeusefulanymore lostinformationcansometimesbeinterpolated (thoughlossstatisticsmaystillbeuseful) UseUDPingame: canprioritizedata canperformreliabilityifneeded canfilteroutredundantdata usesoft=state sendabsolutevalues,notdeltas orifdeltasareused,send``baselinedataperiodically mustdocongestioncontrolifsendinglargeamountofdata