Lag (videospill) - Lag (video games)
I online gaming er forsinkelse en merkbar forsinkelse ( latens ) mellom handlingene til spillere (input) og reaksjonen til serveren som støtter spillet , som må sendes tilbake til klienten .
Spillerens evne til å tolerere etterslep avhenger av hvilken type spill som spilles. For eksempel kan et strategispill eller et turbasert spill med sakte tempo ha en høy terskel eller til og med være upåvirket av høy etterslep. Et spill med rykende gameplay som en førstepersonsskytespill med et betydelig raskere tempo kan kreve et betydelig lavere forsinkelse for å gi tilfredsstillende gameplay .
Pingtid
Ping tid er det nettverket forsinkelse for en rundtur mellom en spillers klient og spillserver som målt med den ping-verktøyet eller tilsvarende. Pingtid er en gjennomsnittlig tid målt i millisekunder (ms). Jo lavere ping er, jo lavere er latensen og jo mindre etterslep spilleren vil oppleve. Høy ping og lav ping er ofte brukte termer i online spill, der høy ping refererer til en ping som forårsaker en alvorlig mengde forsinkelse; Mens et hvilket som helst nivå av ping kan forårsake et forsinkelse, er alvorlig forsinkelse vanligvis indikert med en ping på 100 ms. Denne bruken er en kulturkollokalisme i spill og er ikke vanlig eller brukes i profesjonelle datanettverkskretser. I spill der timing er nøkkelen, for eksempel førstepersonsskytespill og sanntids strategispill , er lav ping alltid ønskelig, ettersom lav ping betyr jevnere spill ved å tillate raskere oppdatering av spilldata mellom spillernes klienter og spillserver.
Høy forsinkelse kan forårsake forsinkelse. Spillservere kan koble fra en klient hvis ventetiden er for høy og kan være til skade for andre spillers spill. Tilsvarende klientprogramvare vil ofte mandat frakobling hvis ventetid er for høy. Høy ping kan også føre til at servere krasjer på grunn av ustabilitet.
I noen førstepersonsskytespill kan høy ping føre til at spilleren utilsiktet får urettferdige fordeler, for eksempel å forsvinne fra ett sted og øyeblikkelig dukke opp igjen på et annet, simulere effekten av teleportasjon, og dermed gjøre det vanskelig for andre spillere å bedømme karakterens posisjon og senere gjøre spilleren mye vanskeligere å målrette mot. For å motvirke dette sparker mange spillservere automatisk spillere med en ping høyere enn gjennomsnittet. Motsatt kan en høy ping gjøre det veldig vanskelig for spilleren å spille spillet på grunn av negative effekter som oppstår, noe som gjør det vanskelig for spilleren å spore andre spillere og til og med flytte karakteren deres.
I stedet for å bruke den tradisjonelle ICMP ekko -forespørselen og svare nettverkspakker for å bestemme pingtider, bygger videospillprogrammerere ofte sin egen latensdeteksjon i eksisterende spillpakker (vanligvis basert på UDP -protokollen) i stedet.
Noen faktorer som kan påvirke ping inkluderer: kommunikasjonsprotokoll som brukes, Internett -gjennomstrømning (tilkoblingshastighet), kvaliteten på en brukers Internett -leverandør og konfigurasjon av brannmurer . Ping påvirkes også av geografisk beliggenhet. For eksempel, hvis noen er i India og spiller på en server i USA, er avstanden mellom de to større enn det ville være for spillere i USA, og derfor tar det lengre tid før data blir overført. Imidlertid er mengden pakkebytte og nettverksmaskinvare mellom de to datamaskinene ofte mer signifikant. For eksempel må trådløse nettverksgrensesnittkort modulere digitale signaler til radiosignaler , noe som ofte er dyrere enn den tiden det tar et elektrisk signal å krysse et typisk kabelspenn. Som sådan kan lavere ping resultere i raskere nedlasting og opplasting av Internett.
Årsaker
Mens et enspillerspill opprettholder hovedspillstatusen på den lokale maskinen, krever et online spill at det vedlikeholdes på en sentral server for å unngå inkonsekvenser mellom individuelle klienter. Som sådan har klienten ingen direkte kontroll over den sentrale spillstatusen og kan bare sende endringsforespørsler til serveren, og kan bare oppdatere den lokale spillstatusen ved å motta oppdateringer fra serveren. Dette behovet for å kommunisere forårsaker en forsinkelse mellom klientene og serveren, og er den grunnleggende årsaken bak forsinkelse. Selv om det kan være mange underliggende årsaker til at en spiller opplever etterslep, kan de oppsummeres som utilstrekkelig maskinvare i enten klienten eller serveren, eller som en dårlig forbindelse mellom klienten og serveren.
Maskinvarerelaterte problemer forårsaker forsinkelse på grunn av den grunnleggende strukturen i spillarkitekturen. Vanligvis består spill av en loopet sekvens av tilstander, eller "rammer". I løpet av hver ramme godtar spillet brukerinngang og utfører nødvendige beregninger (AI, grafikk etc.). Når all behandling er ferdig, vil spillet oppdatere spilltilstanden og produsere en utgang, for eksempel et nytt bilde på skjermen og/eller en pakke som skal sendes til serveren. Frekvensen som rammer genereres med, blir ofte referert til som bildefrekvensen . Siden den sentrale spillstatusen er plassert på serveren, må den oppdaterte informasjonen sendes fra klienten til serveren for å kunne tre i kraft. I tillegg må klienten motta nødvendig informasjon fra serveren for å kunne oppdatere tilstanden fullt ut. Generering av pakker for å sende til serveren og behandle de mottatte pakkene kan bare gjøres så ofte som klienten kan oppdatere sin lokale tilstand. Selv om pakker teoretisk sett kunne genereres og sendes raskere enn dette, ville det bare resultere i å sende overflødige data hvis spilltilstanden ikke kan oppdateres mellom hver pakke. En lav bildefrekvens vil derfor gjøre spillet mindre lydhør for oppdateringer og kan tvinge det til å hoppe over utdaterte data.
Omvendt gjelder det samme for serveren. Bildefrekvensen (eller kryssfrekvensen) til serveren bestemmer hvor ofte den kan behandle data fra klienter og sende oppdateringer. Denne typen problemer er vanskelig å forutsi og kompensere for. Bortsett fra å håndheve minimumskrav til maskinvare og prøve å optimalisere spillet for bedre ytelse, er det ingen mulige måter å håndtere det på.
Kanskje er den vanligste typen forsinkelse forårsaket av problemer med nettverksytelsen . Tap , korrupsjon eller rystelser (en utdatert pakke er faktisk et tap) kan alle forårsake problemer, men disse problemene er relativt sjeldne i et nettverk med tilstrekkelig båndbredde og ingen eller liten overbelastning . I stedet spiller forsinkelsen som er involvert i overføring av data mellom klienter og server en betydelig rolle. Latens varierer avhengig av en rekke faktorer, for eksempel den fysiske avstanden mellom endesystemene, ettersom en lengre avstand betyr ekstra overføringslengde og ruting nødvendig og derfor høyere latens. Ruting over internett kan være ekstremt indirekte, noe som resulterer i langt mer overføring lengde (og påfølgende ventetid) enn en direkte rute, selv om skyen spilltjenesten OnLive har utviklet en løsning på dette problemet ved å etablere peering relasjoner med flere Tier 1 nettverks Internet Service Providers og velge en optimal rute mellom server og bruker. I tillegg kan utilstrekkelig båndbredde og overbelastning, selv om det ikke er alvorlig nok til å forårsake tap, forårsake ytterligere forsinkelser uavhengig av avstand. Som med maskinvareproblemer, vil pakker som kommer sakte eller slett ikke gjøre at både klienten og serveren ikke kan oppdatere spilltilstanden i tide.
Online spillsystemer som bruker et trådløst nettverk, kan være utsatt for betydelig forsinkelse, avhengig av arkitekturen til det trådløse nettverket og lokal elektromagnetisk interferens som påvirker nettverket. Elektromagnetisk interferens (f.eks. Fra en mikrobølgeovn ) kan føre til at overførte pakker går tapt, noe som krever en gjenoverføring som medfører forsinkelse. Selv om radiospredning gjennom luften er raskere enn lys gjennom en optisk fiber, deles trådløse systemer ofte mellom mange brukere og kan lide av forsinkelse som skyldes nettstopp , eller på grunn av nettverksprotokoller som introduserer latens.
Effekter
De merkbare effektene av etterslep varierer ikke bare avhengig av den eksakte årsaken, men også av alle teknikker for forsinkelseskompensasjon som spillet kan implementere (beskrevet nedenfor). Ettersom alle klienter opplever en viss forsinkelse, er implementering av disse metodene for å minimere effekten på spillere viktig for et jevnt spill. Lag forårsaker mange problemer for problemer som nøyaktig gjengivelse av spilltilstanden og treffdeteksjon. I mange spill blir forsinkelse ofte frynset fordi det forstyrrer normalt spill. Alvorligheten av etterslep avhenger av type spill og dens iboende toleranse for etterslep. Noen spill med et lavere tempo kan tåle betydelige forsinkelser uten å måtte kompensere i det hele tatt, mens andre med et raskere tempo er betydelig mer følsomme og krever omfattende bruk av kompensasjon for å kunne spilles (for eksempel førstepersons skytespillgenren). På grunn av de forskjellige problemene forsinkelse kan forårsake, er spillere som har en utilstrekkelig rask internettforbindelse noen ganger ikke tillatt, eller frarådes å spille med andre spillere eller servere som har en fjern serververt eller har høy latens til hverandre. Ekstreme tilfeller av forsinkelse kan resultere i omfattende desynkronisering av spilltilstanden.
Etterslep på grunn av utilstrekkelig oppdateringshastighet mellom klient og server kan forårsake noen problemer, men disse er vanligvis begrenset til klienten selv. Andre spillere kan legge merke til rykete bevegelser og lignende problemer med spilleren som er knyttet til den berørte klienten, men det virkelige problemet ligger hos klienten selv. Hvis klienten ikke kan oppdatere spilletilstanden i et raskt nok tempo, kan spilleren få vist utdaterte gjengivelser av spillet, noe som igjen forårsaker forskjellige problemer med treff- og kollisjonsdeteksjon. Hvis den lave oppdateringshastigheten skyldes en lav bildefrekvens (i motsetning til en innstilling på klienten, slik noen spill tillater det), blir disse problemene vanligvis overskygget av mange problemer knyttet til selve behandlingen på klientsiden. Både skjermen og kontrollene vil være trege og ikke svare. Selv om dette kan øke det oppfattede forsinkelsen, er det viktig å merke seg at det er av en annen type enn nettverksrelaterte forsinkelser. Til sammenligning kan det samme problemet på serveren forårsake betydelige problemer for alle involverte klienter. Hvis serveren ikke er i stand til eller ikke vil godta pakker fra klienter raskt nok og behandle disse i tide, kan det hende at klienthandlinger aldri blir registrert. Når serveren deretter sender ut oppdateringer til klientene, kan de oppleve frysing (ikke -reagerende spill) og/eller tilbakeslag , avhengig av hvilke typer forsinkelseskompensasjon, hvis noen, spillet bruker.
Forsinkelse på grunn av nettverksforsinkelse er derimot ofte et mindre problem. Selv om det er mer vanlig, er de faktiske effektene generelt mindre, og det er mulig å kompensere for slike forsinkelser. Uten noen form for forsinkelseskompensasjon vil kundene legge merke til at spillet reagerer bare kort tid etter at en handling er utført. Dette er spesielt problematisk i førstepersonsskyttere, der fiender sannsynligvis vil bevege seg når en spiller prøver å skyte dem og marginen for feil ofte er liten.
Løsninger og forsinkelseskompensasjon
Det er forskjellige metoder for å redusere eller skjule forsinkelser, selv om mange av disse har sine ulemper og ikke nødvendigvis er gjeldende i alle tilfeller. Hvis synkronisering ikke er mulig av selve spillet, kan det hende at klientene kan velge å spille på servere i geografisk nærhet til seg selv for å redusere forsinkelser, eller serverne kan ganske enkelt velge å slippe klienter med høy forsinkelse for å unngå å måtte håndtere de resulterende problemene. Dette er imidlertid neppe optimale løsninger. I stedet vil spill ofte bli designet med forsinkelseskompensasjon i tankene.
Mange problemer kan løses ved å la klientene holde styr på sin egen tilstand og sende absolutte tilstander til serveren eller direkte til andre klienter. For eksempel kan klienten oppgi nøyaktig i hvilken posisjon en spillers karakter er eller hvem karakteren skjøt. Denne løsningen fungerer og vil nesten eliminere de fleste problemer knyttet til etterslep. Dessverre er det også avhengig av at klienten er ærlig. Det er ingenting som hindrer en spiller i å endre dataene de sender, direkte til klienten eller indirekte via en proxy, for å sikre at de alltid vil nå målene sine. I online spill kan risikoen for juks gjøre denne løsningen umulig, og klienter vil være begrenset til å sende relative stater (dvs. hvilken vektor den gikk videre eller skjøt inn).
Klient side
Ettersom klienter normalt ikke har lov til å definere hovedspillet, men heller mottar det fra serveren, er hovedoppgaven til klientsiden-kompensasjonen å gjengi den virtuelle verden så nøyaktig som mulig. Siden oppdateringer kommer med en forsinkelse og til og med kan bli droppet, er det noen ganger nødvendig for klienten å forutsi spillets flyt. Siden staten oppdateres i diskrete trinn, må klienten kunne estimere en bevegelse basert på tilgjengelige prøver. To grunnleggende metoder kan brukes for å oppnå dette; ekstrapolasjon og interpolasjon .
Ekstrapolering er et forsøk på å estimere en fremtidig spilltilstand. Så snart en pakke fra serveren er mottatt, oppdateres posisjonen til et objekt til den nye posisjonen. I påvente av neste oppdatering, blir den neste posisjonen ekstrapolert basert på den nåværende posisjonen og bevegelsen på tidspunktet for oppdateringen. I hovedsak vil klienten anta at et objekt i bevegelse vil fortsette i samme retning. Når en ny pakke mottas, kan posisjonen korrigeres litt.
Interpolasjon fungerer ved i hovedsak å buffere en spilltilstand og gjengi spillstatusen til spilleren med en liten, konstant forsinkelse. Når en pakke fra serveren kommer, i stedet for å oppdatere posisjonen til et objekt umiddelbart, vil klienten begynne å interpolere posisjonen, fra den siste kjente posisjonen. Over et interpoleringsintervall vil objektet gjengis jevnt mellom de to posisjonene. Ideelt sett bør dette intervallet nøyaktig matche forsinkelsen mellom pakkene, men på grunn av tap og variabel forsinkelse er dette sjelden tilfelle.
Begge metodene har fordeler og ulemper.
- Interpolering sikrer at objekter bare beveger seg mellom gyldige posisjoner og gir gode resultater med konstant forsinkelse og uten tap. Skulle pakker som faller ut eller går ut av ordren overløpe interpoleringsbufferen, må klienten enten fryse objektet på plass til en ny pakke kommer, eller falle tilbake på ekstrapolering i stedet. Ulempen med interpolasjon er at det får verden til å gjengis med ytterligere forsinkelse, noe som øker behovet for en eller annen form for forsinkelseskompensasjon.
- Problemet med å ekstrapolere posisjoner er ganske åpenbart: det er umulig å forutsi fremtiden nøyaktig. Det vil gjengi bevegelse riktig bare hvis bevegelsen er konstant, men dette vil ikke alltid være tilfelle. Spillere kan endre både hastighet og retning tilfeldig. Dette kan resultere i en liten "vridning" etter hvert som nye oppdateringer kommer og de estimerte posisjonene blir korrigert, og kan også forårsake problemer for treffdeteksjon ettersom spillere kan gjengis i posisjoner de faktisk ikke er i.
Ofte, for å tillate jevnt spill, får klienten lov til å gjøre myke endringer i spilltilstanden. Selv om serveren til syvende og sist kan holde styr på ammunisjon, helse, posisjon, etc., kan det hende at klienten får lov til å forutsi den nye spillers tilstanden på serversiden basert på spillerens handlinger, for eksempel å la en spiller begynne å bevege seg før serveren har svart til kommandoen. Disse endringene vil generelt bli akseptert under normale forhold og gjøre forsinkelsen stort sett gjennomsiktig. Problemer vil bare oppstå ved høye forsinkelser eller tap, når klientens spådommer er veldig merkbart angret av serveren. Noen ganger, i tilfelle av mindre forskjeller, kan serveren til og med tillate "feil" endringer i staten basert på oppdateringer fra klienten.
Server-side
I motsetning til klienter, vet serveren den nøyaktige nåværende spilltilstanden, og som sådan er prediksjon unødvendig. Hovedformålet med forsinkelseskompensasjon på serversiden er i stedet å gi nøyaktige effekter av klienthandlinger. Dette er viktig fordi når en spillers kommando har kommet, vil tiden ha gått videre, og verden vil ikke lenger være i den tilstanden spilleren så da han utstedte kommandoen. Et veldig eksplisitt eksempel på dette er treffdeteksjon for våpen som skytes i førstepersonsskyttere, der marginene er små og potensielt kan forårsake betydelige problemer hvis de ikke håndteres riktig.
Spol tilbake tid
En annen måte å løse problemet på er å lagre tidligere spilltilstander i en viss tid, for så å spole tilbake spillersteder når du behandler en kommando. Serveren bruker spillerens latens (inkludert eventuell iboende forsinkelse på grunn av interpolasjon; se ovenfor) for å spole tiden tilbake med et passende beløp for å bestemme hva skyteklienten så på det tidspunktet skuddet ble avfyrt. Dette vil vanligvis resultere i at serveren ser klienten skyte mot målets gamle posisjon og dermed treffer. I verste fall vil en spiller være så langt bak at serveren går tom for historiske data, og de må begynne å lede målene sine.
Dette er en WYSIWYG -løsning som lar spillere sikte direkte på det de ser. Men prisen er en forverring av effekten av ventetid når en spiller er under skyte: ikke bare spiller deres egen latenstid en rolle, men angriperens også. I mange situasjoner er dette ikke merkbart, men spillere som nettopp har tatt dekning vil legge merke til at de fortsetter å motta skade-/dødsmeldinger fra serveren lenger enn deres egen ventetid kan rettferdiggjøre. Dette kan oftere føre til det (falske) inntrykket at de ble skutt gjennom dekselet og det (ikke helt unøyaktige) inntrykket av " laggy hitboxes ".
Et designproblem som oppstår ved tilbakespoling er om man skal slutte å spole tilbake en død spillers forsinkede kommandoer så snart de dør på serveren, eller om de skal fortsette å kjøre dem til de "tar igjen" til dødstidspunktet. Å kutte kompensasjon umiddelbart forhindrer ofre fra å postuum angripe sine mordere, noe som oppfyller forventningene, men bevarer den naturlige fordelen ved å flytte spillere som runder et hjørne, skaffer seg et mål og dreper dem på kortere tid enn en rundtur til det stasjonære offerets klient.
Tilbakespoling kan kritiseres for at den høye latenstiden til en spiller kan påvirke opplevelsen til spillere med lav latens negativt. Servere med lagkompensasjon vil noen ganger redusere lengden på lagret spillerhistorikk eller håndheve pinggrenser for å redusere dette problemet.
Stol på klienter
Det er mulig for klienter å fortelle serveren hva de gjør, og for serveren å stole på dataene den mottar. Denne metoden unngås hvis det er mulig på grunn av dets følsomhet for juks : det er en enkel sak å dirigere nettverksdata gjennom en annen datamaskin som setter inn fabrikerte treffmeldinger eller endrer eksisterende, en teknikk som ikke kan oppdages av anti-juks- verktøy.
Den store omfanget av noen spill gjør imidlertid beregningsmessig dyre løsninger som tilbakespoling umulig. I Battlefield 3 , for eksempel, brukes et "hybrid hit detection" -system der klienter forteller serveren at de treffer og serveren utfører bare en vag test av sannsynlighet før de godtar kravet.
Å stole på en klients resultater har ellers de samme fordelene og ulempene som tilbakespoling .
Gjør kundene ekstrapolerte
En mindre vanlig forsinkelsesløsning er å ikke gjøre noe på serveren og la hver klient ekstrapolere (se ovenfor) for å dekke latensen. Dette gir feil resultat med mindre eksterne spillere opprettholder en konstant hastighet, noe som gir en fordel for de som unnviker frem og tilbake eller bare begynner/slutter å bevege seg.
Utvidet ekstrapolasjon resulterer også i at eksterne spillere blir synlige (selv om de ikke er sårbare) når de ikke burde være det: for eksempel hvis en ekstern spiller spretter opp til et hjørne og stopper brått i kanten, vil andre klienter få dem til å spurte videre, ut i det åpne, i løpet av sin egen ventetid. På den andre siden av dette problemet må kundene gi eksterne spillere som nettopp begynte å bevege seg en ekstra hastighet for å presse dem til et teoretisk nøyaktig spådd sted.
Design
Det er mulig å redusere oppfatningen av etterslep gjennom spilldesign . Teknikker inkluderer å spille animasjoner på klientsiden som om handlingen fant sted umiddelbart, redusere/fjerne innebygde tidtakere på vertsmaskinen og bruke kameraoverganger for å skjule vridning.
Skyspill
Skyspill er en type online spill der hele spillet er plassert på en spillserver i et datasenter, og brukeren bare kjører en tynn klient lokalt som videresender spillkontrollhandlinger oppstrøms til spillserveren. Spillserveren gjengir deretter den neste rammen av spillvideoen som komprimeres ved hjelp av lav-lag videokomprimering og sendes nedstrøms og dekomprimeres av den tynne klienten. For at skyspillopplevelsen skal være akseptabel, er forsinkelsen for alle elementene i skyspillsystemet (den tynne klienten, Internett- og/eller LAN-tilkoblingen spillserveren, spillutførelsen på spillserveren, video og lyd) komprimering og dekomprimering, og visningen av videoen på en skjermenhet ) må være lav nok til at brukerens oppfatning er at spillet kjører lokalt. På grunn av slike tette forsinkelseskrav kommer avstandshensyn til lysets hastighet gjennom optisk fiber til spill, som for øyeblikket begrenser avstanden mellom en bruker og en skyspillspillserver til omtrent 1000 miles, ifølge OnLive . Det er også mye kontrovers om forsinkelsen knyttet til skyspill. I flerspillerspill som bruker en klient/server-nettverksarkitektur, gjengir spillerens datamaskin spillets grafikk lokalt, og bare informasjon om spillerens handlinger i spillet sendes til serveren. For eksempel, når spilleren trykker på en knapp, utfører tegnet på skjermen umiddelbart den tilsvarende handlingen. Imidlertid blir konsekvensene av handlingen, for eksempel at en fiende blir drept, først sett etter en kort forsinkelse på grunn av tiden det tar før handlingen når serveren. Dette er bare akseptabelt så lenge responsen på spillerens innspill er rask nok.
Når du bruker skyspill, kan innspill fra spilleren føre til korte forsinkelser til de kan se et svar. Inngangene må først overføres til den eksterne serveren, deretter må serveren begynne å gjengi grafikken for handlingen som utføres og streame videoen tilbake til spilleren over nettverket, og ta ekstra tid. Dermed opplever spilleren en merkbar forsinkelse mellom å trykke på en knapp og se noe som skjer på skjermen. Avhengig av spillerens ferdigheter og erfaring, kan dette forårsake desorientering og forvirring som ligner på forsinket auditiv tilbakemelding og hindrer navigering og sikte i spillverdenen. Når du raskt legger inn et langt kombinasjonsbevegelse, blir ikke karakteren på skjermen synkronisert med knappetrykkene. Dette forårsaker vanligvis alvorlig forvirring hos spilleren, noe som resulterer i mislykket kombinasjonsbevegelse.
Den ekstra inngangsforsinkelsen kan også gjøre det veldig vanskelig å spille visse enkeltspillerspill. For eksempel, hvis en fiende svinger mot spilleren og spilleren forventes å blokkere, så da spillerens skjerm viser at fienden har begynt å angripe, ville fienden allerede ha slått og drept spilleren på serveren.