Cas d'estudi: Gauntlet - Part Vb: Red

En aquest post vaig a parlar dels punts fonamentals a tindre en compte al desenvolupar una arquitectura de comunicació per red en temps real per a videojocs.

Consistencia
Tots els jugadors deuen vore el mateix: Els enemics han de estar al mateix lloc i fer el mateix, el mapa he de trobar-se en el mateix estat, els objectes deuen estar al mateix lloc, etc... Però, a més, ha d'haver un consens respecte a les accions importants, com que una bala toque a un enemic, o a un jugador.

Respecte al nostre joc en particular, hi ha una serie de punts que deuen mantindre una certa consistencia, i cada un requereix d'un grau major o menor de consistencia:
- La posició dels jugadors mentres es mouen: consistencia baixa
- La posició dels enemics mentres es mouen: consistencia baixa
- Els canvis de direcció dels jugadors: consistencia normal
- Els canvis de direcció dels enemics: consistencia alta
- La posició dels jugadors al disparar: consistencia alta
- La colisió entre una bala i un enemic o jugador: consitencia alta

Hi haurà més punts a tindre en compte, pero aquestos ja ens valen per a fer un anàlisis.

Si vos fixeu, he dit que la posició dels jugadors o els enemics requereixen consistencia baixa. Açò es així perque el fet que un jugador estiga uns pixels desviat en un comp que en altre no afecta seriament a la consistencia del joc. Imagineu la consistencia com la similitud entre la versió del joc que te el servidor i la que té el jugador. Hi ha accions, com la posició d'un jugador mentres corre, que no requereixen que siguen exactament iguals en els dos comps. No obstant, la posició des d'on eix una bala o la colisió d'una bala amb un enemic ha de ser exacta entre tots els comps.

Les accions que no requereixen una consistencia alta poden ser executades pel client sense esperar confirmació del servidor. Està clar, de totes formes, que no podem permetre que aquestes accions es desvien massa de la versió del servidor, pero per a això usarem mètodes de sincronia. En realitat no es tracta de trobar quines accions deuen ser consistents, ja que totes deurien ser consistents, sino les que podem cedir un poc de consistencia a canvi de que la jugabilitat millore.

Les accions que requereixen una consistencia alta deuràn fer-se (o al menys prendres la decisió) en el servidor, que propagarà aquesta decisió als demes comps. De totes formes, reduïrem aquestes accions a la mínima expresió.

Per exemple, al nostre joc, els enemics tindràn un comportament determinista, o siga, que no tenen cap component aleatoria al seu comportament. Bàsicament, un enemic calcula quin jugador te mes prop i va a per ell. Com la posició d'un jugador no te perque ser del tot consistent en tots els comps, en un comp un enemic podria triar a un jugador i el altre comp a altre jugador, trencant totalment la consistencia, ja que l'enemic duria rutes diferents en cada comp. Per tant, el que farem es que eixa decisió, la de triar a per qui va, es faça en el servidor, mentre que el moviment cap a eixe jugador es farà en el comp del client.


Sincronia

Havem parlat de la consistencia. La consistencia el que farà es mantindre nugades les coses que controla. Pero les coses que no controla al ditet estaràn un poc soltes i, si no es busca un mètode alternatiu de control, acavaràn desviant-se sistèmicament. Per a evitar que les accions poc consistents es degraden usarem mètodes de sincronia.

Els métodes de sincronia el que faràn es revisar que les accions poc consistents no s'estàn tornant massa inconsistents. Per exemple, que la posició del jugador en el comp del servidor no es massa diferent de la del comp del jugador.

Per a tal cosa enviarem junt a la informació de canvi de moviment de cada jugador, la posició d'eixe jugador en el servidor, de forma que els clients puguen corregir-la donat el cas.


Seguretat

Si el client te massa decisions al seu carrec pot fer trampes. Per exemple, si es el client el que envia la senyal de que la meua bala a tocat a un altre jugador, eixe client pot fer trampes inventant-se ordres imposibles en el joc, amb una versió hackejada del joc, per exemple. Pitjor encara, pot fer un xicotet programeta que envie paquets UDP al servidor amb eixe tipus de ordre, de forma que imposibilitaria als demes jugadors jugar la partida.

Per tant, es important que el client no tinga més responsabilitats que les seues propies decisions, i que aquestes responsabilitats estiguen restringides al que es possible fer.

Per tant, el client nomes enviarà ordres de cap on està caminant i si ha pulsat dispar. Es més, ni tan sols enviarà la seua posició, que podria ser un exploit al poder inventar-se una nova posició i teletransportarse. El jugador començarà en una posició, coneguda per tots, i després nomes transmetrà ordres de "ara camine cap a la dreta", "ara pare", "ara camine cap a l'esquerra", que permetràn a tots els comps recomposar la sequencia. Ací es on faràn falta els mecanismes de sincronia per a que cada comp no estiga interpretant l'escena d'una forma diferent, ja que la latencia pot fer que en uns comps el temps entre tecla polsada i tecla soltada pot ser diferent.


Escalabilitat

No vaig a mirar molt el tema de l'escalabilitat. L'unic pas a favor que he fet es triar una arquitectura client-servidor, i llevar la responsabilitat de ser servidor als clients per a deixar un servidor dedicat.

En jocs de molts jugadors, com els MMORPG, lo normal es que no hi haja un servidor, sino un cluster de servidors, que deuen sincronitzar-se entre sí. Aixó s'escapa del nostre objectiu.


En el proxim post parle de la classe que controla al jugador i de la classe proxy que manté la comunicació.