Forhåndsvisning av klientsiden er en teknikk som brukes i multiplayer-spill for å redusere (utseendet til) lagring: Hver spillers maskin kjører sin egen simulering av hva som skal skje neste, og synkroniserer deretter raskt med serverens "offisielle" versjon av hendelsene. I denne artikkelen ser vi på hvorfor vi ønsker å gjøre dette i utgangspunktet.
Denne teknikken ble populær når nettverksspill som Quake (hvis kildekoden er tilgjengelig på GitHub) begynte å poppe opp. De tilgjengelige nettverkshastighetene på tiden var ikke så fort - spesielt for internett - så forsøkte å holde alle spillerne synkronisert perfekt med at serveren ga dårlige resultater.
For å begynne å forklare problemet, la oss forstå hvor det kommer fra.
Ved et første blikk eksisterer ikke problemet som klientsiden prediksjon bare eksisterer!
Alt er enkelt: spilleren beveger sin karakter og spillet forteller serveren den nye posisjonen; serveren sender deretter denne nye posisjonen til de andre spillerne, hvis klienter oppdaterer posisjonen til den første spilleren i spillet. Det er det.
Men hva om spilleren endrer spillet for å få det til å passere en annen posisjon til serveren?
Juks! Serveren vil stole på spillers nye posisjon på (39, 4)
, selv om spilleren er litt langt unna, og vil oppdatere de andre klientene tilsvarende. Cheater kan så effektivt teleportere, noe som gjør spillet uspillbart for de andre spillerne.
Siden fusk er så lett, trenger vi en ny løsning. Hva om serveren hadde full kontroll over spilltilstanden?
Med autoritativ server versjon av spillet, vil strømmen se slik ut:
Her forteller klienten serveren, "Jeg vil flytte tegnet til høyre"; serveren behandler dette, og bestemmer at dette betyr at tegnet skal nå være på (1, 0)
; serveren forteller deretter alle spillernes klienter at den første spilleren skal være på (1, 0)
; og alle spillerne ser tegnet flytte til den nye posisjonen.
Problemet løst, ikke sant? Ikke helt…
Teleportasjonsproblemet ble for det meste unngått, men latensproblemet ble introdusert. Klienten må vente på serverens svar om deres intensjon om å bevege seg før du viser bevegelsen til spilleren. Denne arbeidsflyten gjør at spillet føles laggy i gjennomsnittlige tilkoblinger og nesten ikke spillbare på de fattige.
Forhåndsvisning av klientsiden avgrenser modellen ovenfor. I løpet av fasen når klienten har sendt hensikten og venter på serverens svar, vil den vise bevegelsen den spår vil skje:
Dette unngår følelsen av forsinkelse ved å fjerne ventetiden mellom spillerens inngang og den viste utgangen.
Simuleringen som oppstår på klienten, bør ha samme resultat som simuleringen som oppstår på serveren, men det er unntak - for eksempel hvis to spillere forsøker å flytte til samme sted på en gang, vil man bli tvunget ut. Når serverens svar sendes til klienten, må klienten bare bekrefte at den samsvarer med sin egen prediksjon; hvis det ikke gjør det, må klienten bruke serverens svar som den ekte informasjonskilden og kaste bort prediksjonen for å fikse klientens tilstand.
Jeg håper denne artikkelen hjelper deg med å forstå denne nyttige teknikken for nettverksspill som trenger å unngå de fleste utroskapsproblemer samtidig som du unngår lagring.