Previziunea de pe partea clientului este o tehnică folosită în jocurile multiplayer pentru a reduce (la apariția) decalajul: mașina fiecărui jucător rulează propria simulare a ceea ce ar trebui să se întâmple în continuare, apoi se sincronizează rapid cu versiunea oficială a evenimentelor serverului. În acest articol, vom analiza de ce am vrea să facem acest lucru în primul rând.
Această tehnică a devenit popular atunci când jocuri de rețea cum ar fi Quake (al cărui cod sursă este disponibil pe GitHub) au început să apară. Vitezele de rețea disponibile la acel moment nu au fost atât de rapide - mai ales pentru internet - încercând astfel să păstreze toți jucătorii sincronizați perfect cu serverul au dat rezultate slabe.
Pentru a începe să explicăm problema, să înțelegem de unde provine.
La prima vedere, problema pe care o rezolvă predicția de pe partea clientului nu există!
Totul este simplu: jucătorul își mișcă personajul și jocul îi spune serverului noua poziție; serverul transmite această nouă poziție celorlalți jucători ai căror clienți actualizează poziția primului jucător în joc. Asta e.
Dar ceea ce se întâmplă dacă jucătorul modifică jocul pentru al face să treacă o poziție diferită de server?
Inselat! Serverul va avea încredere în noua poziție a jucătorului (39, 4)
, chiar dacă jucătorul este la o distanță considerabilă și va actualiza în consecință ceilalți clienți. Cheaterul poate teleporta în mod efectiv, făcând jocul neacoperit pentru ceilalți jucători.
Deoarece înșelăciunea este atât de ușoară, avem nevoie de o soluție nouă. Ce se întâmplă dacă serverul avea control total asupra stării jocului?
Cu server autoritar versiunea a jocului, fluxul va arata astfel:
Aici, clientul îi spune serverului: "Vreau să mut caracterul spre dreapta"; serverul procesează acest lucru și decide că aceasta înseamnă că caracterul ar trebui să se afle acum (1,0)
; serverul îi spune apoi tuturor clienților jucătorilor că personajul primului jucător ar trebui să fie la (1,0)
; și toți jucătorii văd că personajul se mută în noua poziție.
Problema rezolvată, nu? Nu in intregime…
Problema de teleportare a fost cea mai mare parte evitată, însă a fost introdusă problema latenței. Clientul trebuie să aștepte răspunsul serverului cu privire la intenția lor de a se muta înainte de a afișa mișcarea către player. Acest flux de lucru face ca jocul sa se simta lagos pe conexiunile medii si aproape nepractibil pe cei saraci.
Previziunea pe partea clientului îmbunătățește modelul de mai sus. În faza în care clientul a trimis intenția și așteaptă răspunsul serverului, va afișa mișcarea pe care o are prezice se va întâmpla:
Acest lucru evită senzația de întârziere prin eliminarea timpului de așteptare dintre intrarea player-ului și ieșirea afișată.
Simularea care are loc pe client ar trebui să aibă același rezultat ca simularea care apare pe server, dar există și excepții - de exemplu, dacă doi jucători încearcă să se mute simultan în același loc, unul va fi forțat. Când răspunsul serverului este trimis clientului, clientul trebuie doar să confirme că se potrivește propriei sale predicții; dacă nu, atunci clientul trebuie să utilizeze răspunsul serverului ca sursă adevărată de informații și să renunțe la predicție pentru a remedia situația clientului.
Sper că acest articol vă ajută să înțelegeți această tehnică folositoare pentru jocurile din rețea care trebuie să evite majoritatea problemelor de înșelăciune, evitând, de asemenea, întârzierea.