Netcode
Netcode es tracta d'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, packet loss, 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]
Causes potencials de problemes de netcode
La latència és inevitable en els jocs en línia, i és causada no únicament per la latència de la xarxa (la qual està en gran part fora del control dels jocs) sinó també per la latència inherent a la manera que les simulacions dels jocs s'executen. Hi ha diversos mètodes de compensació de lag utilitzats per a disfressar, reduir, o dissimular aquesta latència.
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.[5] El tickrate és limitat pel període de temps 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.[6] 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)[7] 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).[8][9] Un tickrate baix, naturalment, també redueix la precisió de la simulació, de manera que podria arribar a causar problemes si es porta a extrems, 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.[5][10]
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.[11]
El tipus de protocol de capa de transport escollit per un joc també pot causar problemes de la gestió de xarxa. Si un joc utilitza un protocol de control de transmissió (PCT, TCP en anglès), la gestió de xarxes tindrà un cost general elevat i una latència elevada. Si el joc en canvi utilitza un protocol de datagrames d'usuari (PDU, UDP en anglès), el seu motor pot necessitar la implementació de codi propi per encarregar-se de condicions d'error i d'altres coses que són solucionades pel PCT;[12] això augmenta la complexitat del motor, de manera que es podrien provocar problemes.
Tipus de netcode
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 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.).[13] 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, en el 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
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 ser variable: quan 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, el joc s'ha d'esperar (un netcode basat en retard no pot continuar amb la simulació fins que no rebi les entrades de tots els jugadors del fotograma en qüestió), causant que es "congelin" les pantalles.[14] 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.[15]
Retrospectiu
Un sistema alternatiu al netcode anterior és el netcode retrospectiu (rollback en anglès), el qual prediu l'entrada remota del jugador remot en lloc d'esperar-lo (suposant que farà la mateixa entrada que la del tick anterior). Quan aquesta 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. Alguns jocs utilitzen una solució híbrida per a tal de dissimular aquests "salts", mitjançant un retard d’entrada fix i després el sistema de networking retrospectiu. Aquest sistema requereix que el motor del joc pugui retrocedir el seu estat, cosa que requereix modificacions en els motors existents. 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).[16]
Vegeu també
Enllaços externs
Referències
- ↑ Huynh, Martin; Valarino, Fernando. An analysis of continuous consistency models in real time peer-to-peer fighting games, 2019.
- ↑ 2,0 2,1 «Addressing "Netcode" in Battlefield 4». EA Digital Illusions CE, 01-03-2014. [Consulta: 30 març 2014].
- ↑ «List of programming and computer science terms». Labautopedia.
- ↑ «Computer programming term». Computer Hope.
- ↑ 5,0 5,1 «Source Multiplayer Networking». Valve. [Consulta: 30 març 2014].
- ↑ «Titanfall, de l'importance d'un bon tickrate». gamekult.com, 29-03-2014. [Consulta: 30 març 2014].
- ↑ «Battlefield V Server Tick Rate Revealed & Why It Matters» (en anglès). [Consulta: 5 desembre 2020].
- ↑ 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.
- ↑ «How bad is Apex Legends netcode compared to Fortnite and PUBG?» (en anglès), 23-11-2019. [Consulta: 5 desembre 2020].
- ↑ «Unreal Networking Architecture». Epic Games. [Consulta: 7 setembre 2014].
- ↑ Glenn Fiedler. «What every programmer needs to know about game networking». [Consulta: 8 setembre 2014].
- ↑ Glenn Fiedler. «UDP vs. TCP». [Consulta: 8 setembre 2014].
- ↑ «Netcode [p1: Fightin' Words]». [Consulta: 7 desembre 2020].
- ↑ Staff, Ars. «Explaining how fighting games use delay-based and rollback netcode» (en anglès americà), 18-10-2019. [Consulta: 7 desembre 2020].
- ↑ Pinnacle. «The difference between LAN and Online esports» (en anglès). [Consulta: 1r desembre 2020].
- ↑ Pusch, Ricky. «Explaining how fighting games use delay-based and rollback netcode». Ars Technica. [Consulta: 11 juliol 2020].