Viquipèdia

Netcode

Netcode és un hiperònim emprat en la comunitat gamer per a denominar qualsevol cosa que es relacioni a la gestió de xarxes (networking en anglès) dels jocs en línia, sovint referint-se a problemes de sincronització entre clients i servidors. Els jugadors habitualment fan afirmacions sobre "netcodes dolents" quan es troben problemes de connexió en un joc, malgrat que les causes d'aquests problemes podrien estar completament fora del control del seu motor (algunes causes habituals: latència alta entre el servidor i el client, pèrdua de paquets, congestió de la xarxa, etc.). Fins i tot podrien ser causats per factors externs que no tenen res a veure amb la qualitat de la xarxa com el temps de renderització dels fotogrames o velocitats inconsistents de fotogrames.[1][2] Netcode com a terme tendeix a ser utilitzat només en el món dels videojocs, i no és reconegut per la comunitat científica de les ciències de la computació.[3][4]

Tipus de netcode modifica

A diferència d'una partida local on les entrades de tots jugadors s'executen a l'instant en una mateixa simulació o instància del joc, en una partida en línia hi ha diverses simulacions paral·leles (una per a cada jugador) on les entrades dels seus jugadors respectius es reben instantàniament, mentre que les entrades per al mateix fotograma dels altres jugadors arriben amb un cert retard (major o menor depenent de la distància física entre els jugadors, la qualitat i rapidesa de les connexions a la xarxa dels jugadors, etc.).[5] Durant una partida en línia, els jocs han de rebre i processar l'entrada (input en anglès) dels jugadors en un temps determinat per a cada fotograma (per exemple, 16 ms a 60 FPS), i si l'entrada d'un jugador remot d'un fotograma concret (per exemple, del fotograma número 10) arriba en el moment en el qual ja s'està executant un d'altre (per exemple, en el fotograma número 20, 160 ms més tard) es produeix una dessincronització entre les simulacions dels jugadors. Per a resoldre aquest conflicte i aconseguir que el joc funcioni amb fluïdesa hi ha dues solucions principals:

Basat en retard modifica

 
Diagrama sobre l'execució i sincronització de les entrades de dos jugadors (amb un ping de 90 ms entre ells) en un joc en línia que utilitza un netcode basat en retard en un model d'igual a igual.

La solució clàssica a aquesta problemàtica es tracta de la utilització d'un netcode basat en retard (delay-based netcode en anglès). Quan les entrades d'un jugador remot arriben tard el que fa el joc és retardar les entrades del jugador local el mateix temps per a sincronitzar les dues entrades i executar-les alhora. El fet que les entrades del jugador local no s'executin instantàniament pot ser molest per als jugadors (sobretot quan hi ha una latència alta entre ells), però en general el canvi no és gaire notable. El vertader problema d'aquest sistema es tracta de la seva inconsistència, ja que el retard de les entrades dels jugadors remots pot variar adequant-se a la latència del moment, la qual pot fluctuar inesperadament. Quan la latència entre jugadors és tan alta que no es pot enviar l'entrada del jugador remot dins d'una memòria intermèdia (buffer en anglès) de, per exemple, 3 fotogrames (48 ms), el joc s'ha d'esperar, causant que es "congelin" les pantalles (un netcode basat en retard no permet continuar amb la simulació fins que no rebi les entrades de tots els jugadors del fotograma en qüestió).[6] Com que aquest retard pot ser variable, l'experiència dels jugadors en partides en línia resulta ser menys agradable i responsiva que amb partides offline (o en una xarxa LAN), i pot arribar a afectar negativament el rendiment dels jugadors en jocs altament sensitius i d'acció ràpida com els jocs de lluita.[7]

Retrospectiu modifica

 
Diagrama sobre l'execució i sincronització de les entrades de dos jugadors (amb un ping de 90 ms entre ells) en un joc en línia que utilitza un netcode retrospectiu en un model d'igual a igual.

Un sistema alternatiu al netcode anterior és el netcode retrospectiu (rollback en anglès). Aquest sistema executa immediatament les entrades del jugador local (de manera que no s'endarrereixen com amb el netcode basat en retard), com si es tractés d'una partida offline, i prediu les entrades del jugador o jugadors remots en lloc d'esperar-los (suposant que faran la mateixa entrada que la del tick anterior). Un cop arriben aquestes entrades remotes (suposem, per exemple, 45 ms després), el joc pot actuar de dues maneres: si la predicció és correcta, el joc continua tal qual, de manera totalment fluida; si la predicció era incorrecta, l'estat del joc es reverteix i el joc continua des de l'estat corregit, de manera que l'altre o altres jugadors veuran el canvi d'estat en forma d'un petit salt temporal (equivalent a 45 ms, seguint l'exemple).[1] Alguns jocs utilitzen una solució híbrida per a tal de dissimular aquests "salts" (els quals poden arribar a ser problemàtics a mesura que la latència entre els jugadors creix, ja que cada cop hi ha menys temps per reaccionar a les accions dels altres jugadors) mitjançant un retard d'entrada fix i després aplicant el sistema de networking retrospectiu. El netcode retrospectiu resulta bastant efectiu al moment de dissimular pujades breus de la latència dels jugadors o altres problemes relacionats amb inconsistències de les connexions dels clients, ja que les prediccions són sovint correctes i els jugadors ni se n'adonen. Això si, quan aquest sistema es troba amb la situació que el joc d'un client s'alenteix (normalment per sobreescalfament), es poden causar problemes de rift que portin a un intercanvi d'entrades entre màquines a ritmes desiguals. Això genera errors visuals (glitches en anglès) que dificulten el joc als jugadors que reben les entrades a un ritme més lent, mentre el jugador el joc del qual està alentit tindrà un avantatge sobre la resta rebent a un ritme normal les entrades dels altres (això es coneix com a rollback unilateral).[8] Per a solucionar aquest desequilibri desigual d'entrades (i en conseqüència, de fotogrames), hi ha solucions lògiques com l'espera de totes les màquines per a sincronitzar les entrades que arriben tard (semblant al model de netcode basat en retard) o solucions més enginyoses com l'emprat actualment al joc Skullgirls, la qual consisteix en l'omissió sistemàtica d'un fotograma cada set perquè quan el joc es trobi amb el problema amb qüestió aquest pugui recuperar els fotogrames omesos per així a poc a poc sincronitzar les instàncies dels jocs en les diverses màquines.[9]

El netcode retrospectiu requereix que el motor del joc pugui retrocedir el seu estat, cosa que exigeix modificacions en molts motors existents i, per tant, la implementació d'aquest sistema pot ser problemàtica i cara en títols del tipus AAA (els quals solen tenir un motor sòlid i una xarxa amb molt tràfic), com ha comentat el productor de Dragon Ball FighterZ Tomoko Hiroki, entre altres.[10]

Encara que aquest sistema sigui sovint associat al model d'igual a igual (peer-to-peer en anglès) i als jocs de lluita, hi ha formes de networkings retrospectius que també s'utilitzen habitualment en arquitectures client-servidor (com els planificadors de tasques agressius que trobem als sistemes de gestió de bases de dades, els quals inclouen una funcionalitat retrospectiva) i en altres gèneres de videojocs.[1]

Hi ha una llibreria popular amb llicència MIT anomenada GGPO dissenyada per a facilitar la implementació del networking retrospectiu a un joc (principalment els de lluita).[11]

Causes potencials de problemes de netcode modifica

Latència modifica

La latència és inevitable en els jocs en línia, i la qualitat de l'experiència dels jugadors està estrictament lligada a aquesta (com més latència hi ha entre els jugadors, major és el sentiment que el joc no és responsiu a les seves entrades).[1] Cal tenir en compte el fet que la latència de la xarxa dels jugadors (la qual està en gran part fora del control dels jocs) no és l'únic factor en qüestió, sinó també la latència inherent a la manera que les simulacions dels jocs s'executen. Per a disfressar o dissimular la latència i per a corregir problemes causats per valors alts d'aquesta s'han desenvolupat diversos mètodes de compensació de lag.[12]

Tickrate modifica

La mesura temporal mínima d'una reiteració d'accions a un joc es coneix com a tick. La taxa a la qual la simulació és executada en un servidor és referit sovint com el tickrate (o taxa d'actualització) d'un servidor; això és essencialment l'equivalent dels fotogrames per segon del client.[13] El tickrate és limitat pel període que la simulació necessita per executar-se, i és sovint intencionadament limitat encara més per a reduir la inestabilitat introduïda per una taxa fluctuant (i també per a reduir els costos de la CPU i de transmissió de dades). Un tickrate baix incrementa la latència de la sincronització entre la simulació del servidor i les dels clients.[14] El tickrate en jocs d'acció ràpida com els shooters en primera persona sovint es troba entre els 120 ticks per segon (com és el cas de Valorant), els 60 ticks per segon (en jocs com Counter-Strike: Global Offensive o Overwatch), els 30 ticks per segon (com a Fortnite i a la versió de consola de Battlefield V)[15] i els 20 ticks per segon (com amb els polèmics casos de Call of Duty: Modern Warfare, Call of Duty: Warzone i Apex Legends).[16][17] Un tickrate baix, naturalment, també redueix la precisió de la simulació, de manera que podria arribar a causar problemes si es porta a valors significativament baixos, o si les simulacions del client i del servidor es troben executant-se a taxes significantment diferents.

A causa de limitacions en la quantitat de l'amplada de banda disponible i el temps de la CPU dedicat a la comunicació de la xarxa, alguns jocs prioritzen certes comunicacions vitals mentre es limita la freqüència i prioritat d'altres tipus d'informació menys importants. Igual que amb el tickrate, això augmenta la latència de la sincronització. Els motors de joc poden limitar les vegades per segon que les actualitzacions (d'una simulació) són enviades a un client determinat i/o a objectes determinats en el món del joc a més de reduir la precisió d'alguns valors enviats a través de la xarxa per ajudar amb l'ús de l'amplada de banda. Aquesta manca de precisió pot arribar a ser notable.[13][18]

Errors de programari modifica

Hi ha diversos errors de sincronització d'una simulació entre màquines que solen ser considerats com a "problemes de netcode". Per exemple, podem trobar diversos bugs que causin que la simulació avanci i es desenvolupi de manera diferent entre una màquina i una d'altre, o que alguns objectes o elements no es comuniquin entre ells encara que l'usuari percebi que haurien de fer-ho.[2] Tradicionalment, els jocs d'estratègia en temps real (per exemple, Age of Empires) van utilitzar models de gestió de xarxes peer-to-peer del tipus lock-step on s'assumeix que les simulacions s'executen de manera exactament igual per a tots els clients; tanmateix, si un client perdés el pas per qualsevol raó, la dessincronització pot ser greu i esdevenir irrecuperable.[19]

Protocols de capa de transport i codi de comunicació: PCT i PDU modifica

El tipus de protocol de capa de transport (i la seva gestió i programació) escollit per un joc també pot causar problemes de networking.

Si un joc utilitza un protocol de control de transmissió (PCT, TCP en anglès), hi haurà una latència afegida entre els jugadors. Aquest protocol es basa en la connexió entre dues màquines, en la qual aquestes poden intercanviar dades i llegir-les. Aquest tipus de connexions són molt fiables, estables, ordenades i fàcils d'implementar, i s'utilitzen en pràcticament qualsevol operació que fem per internet (tant a la navegació de la web com als correus electrònics o als IRC). Aquestes connexions, però, no s'adeqüen correctament a les velocitats de xarxa que els jocs d'acció ràpida necessiten, ja que aquest tipus de protocol (els protocols de flux de dades en temps real) agrupa les dades automàticament en paquets (els quals no s'enviaran fins a aconseguir un volum d'informació determinat) que s'enviaran a través de la connexió establerta entre les màquines, en comptes de manera directa (sacrificant la velocitat per seguretat). Aquest tipus de protocol també tendeix a respondre molt lentament quan es troba amb la situació que ha perdut un paquet, o que han arribat en un ordre incorrecte o duplicats, fet que pot ser molt perjudicial per a un joc en línia en temps real (cal recordar que aquest protocol no es va dissenyar per a aquest tipus de programari).

Si el joc en canvi utilitza un protocol de datagrames d'usuari (PDU, UDP en anglès), la connexió entre les màquines serà molt ràpida, ja que en comptes d'establir una connexió entre elles s'enviaran i rebran les dades directament. Aquest protocol és molt més senzill que l'anterior, però no gaudeix de la seva fiabilitat i estabilitat i requereix la implementació de codi propi per encarregar-se de les funcions indispensables per a la comunicació entre màquines que el PCT inclou (tals com la divisió de dades en paquets, la detecció automàtica de la pèrdua de paquets, la suma de verificació, etc.); això augmenta la complexitat del motor, de manera que es podrien provocar problemes.[20]

Vegeu també modifica

Enllaços externs modifica

Referències modifica

  1. ↑ 1,0 1,1 1,2 1,3 Huynh, Martin; Valarino, Fernando. An analysis of continuous consistency models in real time peer-to-peer fighting games, 2019. 
  2. ↑ 2,0 2,1 «Addressing "Netcode" in Battlefield 4». EA Digital Illusions CE, març 2014. [Consulta: 30 març 2014].
  3. ↑ «List of programming and computer science terms». Labautopedia.
  4. ↑ «Computer programming term». Computer Hope.
  5. ↑ «Netcode [p1: Fightin' Words]». [Consulta: 7 desembre 2020].
  6. ↑ Staff, Ars. «Explaining how fighting games use delay-based and rollback netcode» (en anglès americà), 18-10-2019. [Consulta: 7 desembre 2020].
  7. ↑ Pinnacle. «The difference between LAN and Online esports» (en anglès). [Consulta: 1r desembre 2020].
  8. ↑ Lee, Gerald (2020-08-04). Analysis: Why Rollback Netcode Is Better (Youtube)EN. 
  9. ↑ Hills, Dakota 'DarkHorse'. «Skullgirls receives an improved netcode update initially created by a fan of the game» (en anglès), 29-04-2020. [Consulta: 11 desembre 2020].
  10. ↑ Hills, Dakota 'DarkHorse'. «The era of delay-based netcode may finally be over for good in fighting games depending on what SNK does with The King of Fighters 15» (en anglès), 10-12-2020. [Consulta: 11 desembre 2020].
  11. ↑ Pusch, Ricky. «Explaining how fighting games use delay-based and rollback netcode». Ars Technica. [Consulta: 11 juliol 2020].
  12. ↑ «Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization - Valve Developer Community». [Consulta: 11 desembre 2020].
  13. ↑ 13,0 13,1 «Source Multiplayer Networking». Valve. [Consulta: 30 març 2014].
  14. ↑ «Titanfall, de l'importance d'un bon tickrate». gamekult.com, 29-03-2014. [Consulta: 30 març 2014].
  15. ↑ «Battlefield V Server Tick Rate Revealed & Why It Matters» (en anglès). [Consulta: 5 desembre 2020].[Enllaç no actiu]
  16. ↑ Davison, Ethan «Valorant’s super-fast servers are attracting streamers and pros in droves. Here’s why.» (en anglès). Washington Post. ISSN: 0190-8286.
  17. ↑ «How bad is Apex Legends netcode compared to Fortnite and PUBG?» (en anglès), 23-11-2019. [Consulta: 5 desembre 2020].
  18. ↑ «Unreal Networking Architecture». Epic Games. [Consulta: 7 setembre 2014].
  19. ↑ Glenn Fiedler. «What every programmer needs to know about game networking». [Consulta: 8 setembre 2014].
  20. ↑ G. Fiedler. «UDP vs. TCP». [Consulta: 8 setembre 2014].
Obtingut de «https://ca.wikipedia.org/w/index.php?title=Netcode&oldid=32647205»