Cuando pienso en Star Citizen y su evolución tengo sentimientos contradictorios. Soy participe del proyecto desde 2014, como podéis leer en la entrada Mi historia con Star Citizen. En esta ocasión me gustaría dejar de lado mis sensaciones y emociones para centrarme más en lo técnico del proyecto.
En diciembre de 2015 llega la versión 2.0, la cual pretende unir los módulos que ya teníamos de forma aislada. Creando lo que se conoce como la primera versión del PU (Persistent Universe), integrando el módulo de Arena Comander, en el cual podíamos volar y combatir contra otras naves en un espacio muy limitado, mezclándolo con elementos de FPS. En resumen, nos permitía jugar online en una zona entorno a Crusader, con las lunas de Daymar, Celling y Yela representadas como imágenes en el horizonte, utilizando como punto de partida la estación de Port Olistar. En esta primera iteración podíamos hacer misiones narrativas, visitar Covalex y otras estaciones, pero todavía no podíamos aterrizar en superficies planetarias.
Dos años más tarde, en diciembre de 2017. Llegó la versión 3.0, añadiendo la tecnología planetaria al PU. Desde ese momento podíamos explorar y aterrizar en las lunas mencionadas de Crusader. Además, se añadió el planeta de Delamar y la zona de aterrizaje de Levski, más tarde con la salida de Orison se eliminó, pues Delamar pertenece a otro sistema llamado Nyx. En este punto se había ampliado enormemente la zona de juego, pero empezaron los problemas. Tanto cliente como servidor tenían que manejar una cantidad ingente de entidades, naves, jugadores, superficies planetarias, estaciones, etc.
OCS (Object Container Streaming)
Para solventar esto CIG plantea lo que denominaron: OCS (Object Container Streaming), tanto para el lado del cliente como por parte del servidor. Esta tecnología se basa en crear distintos contenedores de objetos para las distintas zonas; naves, planetas, outposts, etc. Básicamente cambia la manera en la que se cargan los distintos assets. Mientras que en otros juegos todos los assets se cargan al iniciar el juego o mediante pantallas de carga, en SC esto no era posible debido a la magnitud que estaba alcanzando el proyecto. Con esta tecnología lo que se consigue es que en vez de generarlos todos a la vez, se generen de forma dinámica en función de las necesidades, cribando así la información que se envía o recibe entre cliente y servidor.
El OCS por parte del cliente llegó en la 3.3 en noviembre de 2018 y por el lado del servidor salió en la 3.8 en diciembre de 2019.
Para representar esto, podemos decir que cada jugador tendría una especie de burbuja de transmisión a su alrededor, y sería lo que indicaría al servidor lo que tiene que mostrar al cliente de ese jugador aprovechando los contenedores, así como la colocación y estado de todas las entidades que se encuentren en ese contenedor. Tomando de referencia, para que tú puedas ver esos objetos físicamente en tu pantalla de ordenador en el momento en el que estos ocupen cinco pixeles.
Esto a su vez se complica en el momento en el que hay «varios» jugadores, generando una carga al servidor al tener que estar realizando continuamente estas tareas. Motivo por el cual vemos como la IA funciona mal a pesar de que nosotros como clientes mantengamos una buena tasa de frames por segundo.
A partir de este punto vamos a introducir un nuevo término llamado Shard, para poder entender todo lo que viene. Un Shard por medio de los servidores que tenga, vendría a simular un entorno de juego para los clientes que se conecten a esa Shard. Cada vez que nos conectamos al juego, estamos accediendo a una Shard, actualmente estas son de un solo servidor y están limitadas a cien jugadores, pero en un futuro habrá Shards de varios servidores. En el momento en que una shard está llena y entra otro jugador, se crea una segunda. Siendo por así decirlo una instancia aislada, guardando de forma independiente un registro de lo que pasa, desde donde están los jugadores hasta dónde has dejado tirada la botella de agua que te bebiste. Cuando un servidor crashea o se reinicia el progreso y el estado de todo se pierde. Aquí es donde entra la siguiente pieza del puzle.
PES (Persistent Entity Streaming)
Acaba de llegar ahora con la 3.18 en marzo de 2023, se trata de la persistencia de todo item o nave, así como el estado de estos y de todas las entidades del juego. Con esto ya habríamos solventado el problema de que se pierdan las entidades al reiniciar un servidor o después de un crasheo. Pero entonces. ¿Qué pasa si estrello una nave en un planeta y después entro a otro Shard?. Simple, que la nave no estaría, y este es el punto en donde nos encontramos ahora.
En respuesta a este problema, en el que cada Shard es una instancia independiente de otra sin que sepa que pasa en las demás, es donde entra el concepto de la capa de replicación. Esta recogería la información de cada objeto, jugador, nave… de cada Shard y la guardaría en memoria haciendo de nexo entre otras Shards, replicando la información a estas y otros clientes. De esta forma si el jugador Pedro se conecta a la Shard, llamémosla «A» y destruye su nave en el cinturón de asteroides de Yela. El jugador Marcos, que se conecta a la Shard «B», podría encontrarse los restos de la nave e inventario, (gracias al OCS) en el lugar del accidente de Pedro.
Server Meshing
Pero todavía nos quedaría afrontar el problema de la saturación de los servidores, limitando la cantidad de jugadores que podrían interactuar entre ellos. Es aquí, donde teniendo todos los ingredientes anteriores, entraría el Server Meshing. Básicamente aspira conectar varios servidores a un mismo Shard, como en una red. Manteniendo sincronizados y comunicados entre sí a los servidores de esa Shard y por medio de la capa de replicación extenderse a otras Shards. Físicamente no veríamos a los jugadores de otras Shards, pero si el efecto que causan estos en el universo..
La premisa del Server Meshing es que cualquier localización del juego solo exista una vez. Esto crearía efectivamente un único universo sin copias paralelas de ningún contenido, como se ve comúnmente en los MMO hasta la fecha. La primera versión del Server Meshing será estática y repartirá el trabajo de un sistema entre varios servidores, de forma que habrá uno por cada «área». La siguiente iteración será dinámica y permitirá que cada área tenga tantos servidores como sea necesario para alojar a los jugadores.
