Lag

Er zijn verschillende methoden om vertragingen te verminderen of te maskeren, hoewel veel van deze methoden nadelen hebben en wellicht niet in alle gevallen toepasbaar zijn. Als synchronisatie door het spel zelf niet mogelijk is, kunnen de klanten ervoor kiezen om op servers te spelen die zich in de buurt bevinden om vertragingen te verminderen, of de servers kunnen er simpelweg voor kiezen om klanten met een hoge vertraging te laten vallen om te voorkomen dat ze met de resulterende problemen te maken krijgen. Dit zijn echter geen optimale oplossingen. In plaats daarvan zullen spellen vaak worden ontworpen met lag compensatie in het achterhoofd.

Vele problemen kunnen eenvoudig worden opgelost door de clients toe te staan hun eigen status bij te houden en absolute toestanden naar de server of direct naar andere clients te sturen. De client kan bijvoorbeeld precies aangeven op welke positie het karakter van een speler zich bevindt of wie het karakter heeft neergeschoten. Deze oplossing werkt en zal de meeste problemen met vertraging zo goed als elimineren. Helaas berust het ook op de aanname dat de client eerlijk is. Er is niets dat een speler ervan weerhoudt om de gegevens die hij verstuurt te wijzigen, direct bij de client of indirect via een proxy, om er zeker van te zijn dat hij altijd zijn doel zal raken. In online spellen kan het risico op valsspelen deze oplossing onhaalbaar maken, en zullen clients beperkt worden tot het versturen van relatieve toestanden (d.w.z. op welke vector hij bewoog of in welke vector hij schoot).

Client-sideEdit

Aangezien clients normaal gesproken niet de belangrijkste toestand van het spel mogen bepalen, maar deze eerder van de server ontvangen, is de belangrijkste taak van de client-side compensatie om de virtuele wereld zo nauwkeurig mogelijk te renderen. Aangezien updates met een vertraging komen en zelfs kunnen wegvallen, is het soms noodzakelijk voor de client om het verloop van het spel te voorspellen. Omdat de toestand in discrete stappen wordt bijgewerkt, moet de client een beweging kunnen schatten op basis van beschikbare voorbeelden. Twee basis methoden kunnen worden gebruikt om dit te bereiken; extrapolatie en interpolatie.

Extrapolatie is een poging om een toekomstige toestand van het spel te schatten. Zodra een pakket van de server wordt ontvangen, wordt de positie van een object bijgewerkt naar de nieuwe positie. In afwachting van de volgende update, wordt de volgende positie geëxtrapoleerd op basis van de huidige positie en de beweging op het moment van de update. In wezen zal de cliënt aannemen dat een bewegend voorwerp in dezelfde richting zal blijven bewegen. Wanneer een nieuw pakket wordt ontvangen, kan de positie iets worden gecorrigeerd.

Interpolatie werkt door in wezen een spelstatus te bufferen en de spelstatus te renderen naar de speler met een kleine, constante vertraging. Wanneer een pakket van de server arriveert, in plaats van de positie van een object onmiddellijk bij te werken, zal de client beginnen met het interpoleren van de positie, te beginnen met de laatst bekende positie. Over een interpolatie-interval zal het object worden weergegeven in een vloeiende beweging tussen de twee posities. Idealiter zou dit interval precies gelijk moeten zijn aan de vertraging tussen de pakketten, maar door verlies en variabele vertraging is dit zelden het geval.

Beide methoden hebben voor- en nadelen.

• Interpolatie zorgt ervoor dat objecten alleen tussen geldige posities bewegen en levert goede resultaten op bij constante vertraging en geen verlies. Indien dropped of out-of-order pakketten de interpolatiebuffer overlopen, zal de cliënt ofwel het object in positie moeten bevriezen totdat een nieuw pakket arriveert, of in plaats daarvan moeten terugvallen op extrapolatie. Het nadeel van interpolatie is dat het er voor zorgt dat de wereld met extra vertraging wordt weergegeven, waardoor de noodzaak toeneemt om een vorm van vertragingscompensatie te implementeren.
• Het probleem met het extrapoleren van posities is vrij duidelijk: het is onmogelijk om de toekomst nauwkeurig te voorspellen. Het zal beweging alleen correct weergeven als de beweging constant is, maar dit zal niet altijd het geval zijn. Spelers kunnen zowel snelheid als richting willekeurig veranderen. Dit kan resulteren in een kleine hoeveelheid “warping” als nieuwe updates binnenkomen en de geschatte posities worden gecorrigeerd, en het kan ook problemen veroorzaken voor hit-detectie als spelers kunnen worden weergegeven op posities waar ze eigenlijk niet zijn.

Vaak, om een soepele gameplay mogelijk te maken, is het de client toegestaan om zachte veranderingen in de game state aan te brengen. Terwijl de server uiteindelijk munitie, gezondheid, positie, enz. bijhoudt, kan de client worden toegestaan de nieuwe server-side game state te voorspellen op basis van de acties van de speler, zoals een speler toestaan te beginnen met bewegen voordat de server heeft gereageerd op het commando. Deze veranderingen zullen over het algemeen onder normale omstandigheden worden aanvaard en maken de vertraging grotendeels transparant. Problemen zullen alleen ontstaan in het geval van grote vertragingen of verliezen, wanneer de voorspellingen van de client zeer merkbaar ongedaan worden gemaakt door de server. Soms, in het geval van kleine verschillen, kan de server zelfs “onjuiste” veranderingen in de status toestaan, gebaseerd op updates van de client.

Server-sideEdit

In tegenstelling tot clients, kent de server de exacte huidige spelstatus, en als zodanig is voorspelling onnodig. Het belangrijkste doel van server-side lag compensatie is in plaats daarvan om nauwkeurige effecten van client acties te bieden. Dit is belangrijk omdat tegen de tijd dat een commando van een speler is aangekomen de tijd verder zal zijn gegaan, en de wereld zal niet langer in de staat zijn die de speler zag toen hij zijn commando gaf. Een zeer expliciet voorbeeld hiervan is hit detection voor afgevuurde wapens in first-person shooters, waar de marges klein zijn en potentieel grote problemen kunnen veroorzaken als het niet goed wordt afgehandeld.

Terugspoelen timeEdit

Een andere manier om het probleem aan te pakken is het opslaan van verleden game states voor een bepaalde lengte van tijd, en dan terugspoelen van speler locaties bij het verwerken van een commando. De server gebruikt de latentie van de speler (inclusief de inherente vertraging door interpolatie; zie boven) om de tijd terug te spoelen met een passende hoeveelheid om te bepalen wat de schietende cliënt zag op het moment dat het schot werd afgevuurd. Dit zal er meestal toe leiden dat de server ziet dat de cliënt op de oude positie van het doel schiet en dus raakt. In het ergste geval zal een speler zo ver achterlopen dat de server geen historische gegevens meer heeft en hij zijn doel moet gaan voorschieten.

Dit is een WYSIWYG oplossing die spelers in staat stelt direct te richten op wat ze zien. Maar de prijs is een verergering van de effecten van latentie wanneer een speler onder vuur ligt: niet alleen hun eigen latentie speelt een rol, maar ook die van hun aanvaller. In veel situaties is dit niet merkbaar, maar spelers die net dekking hebben gezocht zullen merken dat ze langer schade/dood berichten van de server blijven ontvangen dan hun eigen latency kan rechtvaardigen. Dit kan vaker leiden tot de (valse) indruk dat ze door dekking zijn geschoten en de (niet geheel onjuiste) indruk van “laggy hitboxes”.

Een ontwerp kwestie die zich voordoet bij het terugspoelen is of je moet stoppen met het terugspoelen van de vertraagde commando’s van een dode speler zodra ze sterven op de server, of dat je door moet gaan met het uitvoeren van deze commando’s totdat ze het tijdstip van overlijden hebben “ingehaald”. Het onmiddellijk stopzetten van de compensatie voorkomt dat slachtoffers postuum hun moordenaars aanvallen, wat aan de verwachtingen voldoet, maar behoudt het natuurlijke voordeel van bewegende spelers die een hoek omkomen, een doelwit pakken en hen doden in minder tijd dan een rondreis naar de client van het stilstaande slachtoffer.

Het terugspoelen kan worden bekritiseerd omdat het de hoge latency van één speler toestaat om de ervaring van spelers met een lage latency negatief te beïnvloeden. Servers met lagcompensatie zullen soms de lengte van de opgeslagen spelersgeschiedenis verminderen, of ping-limieten opleggen, om dit probleem te verminderen.

Clients vertrouwen

Het is mogelijk voor clients om de server te vertellen wat ze aan het doen zijn en voor de server om de gegevens die hij ontvangt te vertrouwen. Deze methode wordt indien mogelijk vermeden omdat het gevoelig is voor valsspelen: het is eenvoudig om netwerkgegevens door een tweede computer te leiden die valse treffers invoegt of bestaande treffers wijzigt, een techniek die niet kan worden gedetecteerd door anti-cheat tools.

De schaal van sommige spellen maakt computationeel dure oplossingen zoals terugspoelen echter onmogelijk. In Battlefield 3 wordt bijvoorbeeld een “hybride hit-detectiesysteem” gebruikt, waarbij clients de server vertellen dat ze hebben geslagen en de server alleen een vage aannemelijkheidstest uitvoert voordat hij de claim accepteert.

Het vertrouwen op de resultaten van een client heeft anders dezelfde voor- en nadelen als het terugspoelen.

Clients laten extrapoleren

Een minder gebruikelijke lag-oplossing is om niets op de server te doen en elke client te laten extrapoleren (zie hierboven) om zijn latency te dekken. Dit geeft onjuiste resultaten, tenzij spelers op afstand een constante snelheid houden, wat een voordeel geeft aan degenen die heen en weer bewegen of simpelweg starten/stoppen met bewegen.

Extra extrapolatie resulteert ook in spelers op afstand die zichtbaar worden (hoewel niet kwetsbaar) wanneer ze dat niet zouden moeten zijn: bijvoorbeeld als een speler op afstand naar een hoek sprint en dan abrupt stopt aan de rand, zullen andere clients hem verder laten sprinten, in het open, voor de duur van hun eigen latentie. Aan de andere kant van dit probleem moeten clients spelers op afstand die net zijn begonnen met bewegen een extra snelheidsstoot geven om ze in een theoretisch-nauwkeurige voorspelde locatie te duwen.

DesignEdit

Het is mogelijk om de perceptie van vertraging te verminderen door het spel te ontwerpen. Technieken zijn onder meer het afspelen van client-side animaties alsof de actie onmiddellijk plaatsvindt, het verminderen/verwijderen van ingebouwde timers op de host-machine, en het gebruik van camera-overgangen om warping te verbergen.