Client-side voorspelling is een techniek die wordt gebruikt in multiplayer-games om (het uiterlijk van) lag te verminderen: de machine van elke speler voert zijn eigen simulatie uit van wat er daarna moet gebeuren en synchroniseert vervolgens snel met de "officiële" versie van de server van de server. In dit artikel zullen we bekijken waarom we dit in de eerste plaats willen doen.
Deze techniek werd populair toen genetwerkte games zoals Quake (waarvan de broncode beschikbaar is op GitHub) opduiken. De beschikbare netwerksnelheden waren op dat moment niet zo snel - vooral voor internet - dus pogingen om alle spelers perfect gesynchroniseerd te houden met de server gaven slechte resultaten.
Laten we om te beginnen het probleem uitleggen waar het vandaan komt.
Bij een eerste blik bestaat het probleem dat de voorspelling aan de client-side voorspelt niet, gewoon niet!
Alles is eenvoudig: de speler verplaatst zijn personage en het spel vertelt de server de nieuwe positie; de server geeft vervolgens deze nieuwe positie door aan de andere spelers, van wie de clients de positie van de eerste speler in de game bijwerken. Dat is het.
Maar wat als de speler het spel aanpast om het een andere positie aan de server te geven?
Vreemdgaan! De server zal de nieuwe positie van de speler vertrouwen (39, 4)
, ook al bevindt de speler zich op een behoorlijke afstand van de ruimte en werkt de andere clients dienovereenkomstig bij. De cheater kan dan effectief teleporteren, waardoor het spel onspeelbaar wordt voor de andere spelers.
Omdat valsspelen zo gemakkelijk is, hebben we een nieuwe oplossing nodig. Wat als de server totale controle had over de spelstatus?
Met de gezaghebbende server versie van het spel ziet de stroom er als volgt uit:
Hier vertelt de client de server: "Ik wil het personage naar rechts verplaatsen"; de server verwerkt dit en besluit dat dit betekent dat het personage nu moet zijn (1, 0)
; de server vertelt vervolgens alle klanten van de speler dat het personage van de eerste speler zou moeten zijn (1, 0)
; en alle spelers zien het personage naar de nieuwe positie gaan.
Probleem opgelost, toch? Niet helemaal…
Het teleportatieprobleem werd meestal voorkomen, maar het latentieprobleem werd geïntroduceerd. De client moet wachten op de reactie van de server over de intentie om te bewegen voordat de beweging naar de speler wordt weergegeven. Deze workflow zorgt ervoor dat de game laggy is op gemiddelde verbindingen en bijna onspeelbaar op arme.
Client-side voorspelling verfijnt het bovenstaande model. Tijdens de fase waarin de client de intentie heeft verzonden en wacht op de reactie van de server, wordt de beweging ervan weergegeven voorspelt zal gebeuren:
Dit vermijdt het gevoel van vertraging door de wachttijd tussen de ingang van de speler en de weergegeven uitvoer te verwijderen.
De simulatie die optreedt op de client zou hetzelfde resultaat moeten hebben als de simulatie die op de server voorkomt, maar er zijn uitzonderingen - bijvoorbeeld, als twee spelers proberen om naar dezelfde plek tegelijk te gaan, zal er een gedwongen worden uitgeschakeld. Wanneer het antwoord van de server naar de client wordt verzonden, moet de client alleen bevestigen dat deze overeenkomt met zijn eigen voorspelling; als dat niet het geval is, moet de client het antwoord van de server gebruiken als de echte informatiebron en de voorspelling weggooien om de staat van de client te corrigeren.
Ik hoop dat dit artikel je helpt deze nuttige techniek te begrijpen voor netwerkspellen die de meeste valsspeelproblemen moeten vermijden en tegelijkertijd achterlopen te voorkomen.