Star Citizen #HG

Sí, por supuesto que lo hará. La clave del server meshing es que cada servidor simulará menos elementos. Ya sabemos que cuando se simulan menos elementos, el rendimiento del servidor es mucho mejor. Claro, esto acelerará el desarrollo, pero también reducirá el tiempo que nos lleva entregar el parche, sí. Cuando nos preparamos para las versiones 3.24 o 3.24.2 o 3.24.1, llevar el parche a la versión en vivo requiere mucho esfuerzo. ¡Es en ese momento cuando descubres cosas nuevas...!
Cuando los jugadores llegan al servidor, siempre hacen algo adicional, jaja. Los desarrolladores tienen una forma de probar que es más "diagonal", ¿verdad? Los jugadores van más a fondo. Entonces, esto nos va a ayudar con eso, nos dará más margen en cuanto al rendimiento, lo que nos permitirá ir un poco más rápido. Y con más subdivisión, también nos da un grado de control que antes no teníamos.

Por supuesto, el server meshing estático incluyó TODO el desarrollo tecnológico. Así que el código de bajo nivel que gestiona la red: la transmisión de paquetes fiables frente a los no fiables, toda esta tecnología se reescribió para el server meshing. Luego está el concepto de "autoridad", en el que estamos afinando todos los errores relacionados con la transferencia de autoridad, es decir, cuando cambias de servidor, todos los componentes del juego deben responder a este cambio de autoridad.

Hay muchos elementos que en su momento se hicieron mal o de manera innecesaria, y ahora hay que abordarlos. Y estamos lidiando con eso en este momento.

Para continuar con el tema del server meshing, estamos hablando de transferencias masivas de autoridad. Tomemos un gran mesh de Microtech en su totalidad, y decidimos traer un servidor que se encargue solo de New Babbage. Así que aquí estamos haciendo transferencias masivas de autoridad que llevarán todas las transferencias al nuevo servidor, parte del desarrollo del meshing dinámico, además del ciclo de reconciliación que evaluará dónde están los jugadores, dónde se necesitan servidores y distribuirá las necesidades de servidores para servir mejor a los jugadores.

Eso significa no solo agruparlos, porque también hay una dimensión de costo involucrada. ¡Por supuesto, si pudiéramos darle a cada jugador su propio servidor, lo haríamos, jaja!

En resumen, hay menos desarrollo que hacer con el dinámico que con el estático. Espero que podamos hacer esto rápidamente, pero ya en la versión 4.0 hay ciertos elementos del meshing dinámico implementados en el código. Esto significa la capacidad de activar y desactivar servidores dependiendo de si hay jugadores o no.

Estamos tratando de asegurarnos de tener esta misma flexibilidad en la 4.0 (internamente lo llamamos "casi-dinámico" por falta de un mejor término, jaja). Pero aquí estamos, tratando de ofrecerles tanto del modo dinámico como sea posible en la versión PU. Pero no creemos que nos enfrentemos a un desarrollo de varios meses para el dinámico, estamos en buen camino por el momento.

Oh. La construcción de bases, sin duda. Todo lo que está ocurriendo en segundo plano con la construcción de bases, todo lo relacionado con la fabricación. Hay muchas bases de datos nuevas, muchos servicios nuevos, transferencias de esquemas, y así sucesivamente. Porque queremos asegurarnos de que si reclamas un territorio y construyes una base en él, esté disponible en todos los shards.

Es un desafío bastante importante, pero realmente interesante. Va a cambiar mucho el juego, junto con la fabricación. Va a traer un universo donde los jugadores serán los que hagan la economía, y realmente creo que esa es la dirección que el juego debe tomar. Estamos bien encaminados, y es lo que más me emociona.

De hecho, cada sistema es una parte del mapa. Todavía tenemos el concepto de mega mapa, pero tenemos un principio de ramas, y cada sistema solar tiene su propia rama. Lo que llamamos la raíz del universo, en realidad no puede haber jugadores allí, siempre están en los sistemas estelares. En realidad, no son mapas como tal, pero es el mismo concepto, solo que es un gran conjunto de datos.

Así que a medida que se agregan más sistemas, sigue siendo el sistema de streaming el que entra en juego.

En realidad, eso es lo realmente genial. La forma en que se hacen los saltos, cuando entras en el salto hay una zona; imagina que es como una nave grande o un tren grande.

Cuando se abre el paso, todos los jugadores que entran en el agujero de gusano se convierten en parte de este tren, y a medida que los jugadores se mueven a través del paso, la zona se mueve contigo. Y en el momento en que caes en la autoridad de Pyro, en su rama, es cuando la zona y los jugadores han llegado a Pyro, luego el tren/zona se destruye. Piensa en ello como un autobús grande, jaja. Así que es realmente un cambio de coordenadas: un universo.

De hecho, ya tenemos los sistemas en su lugar, pero están desactivados por el momento, porque hemos descubierto muchos efectos a través de ellos. Es algo que vamos a intentar traer de vuelta, pero no es la prioridad en este momento; nuestro enfoque está en agregar jugabilidad al juego.

Pero sí tiene un efecto, es decir, si implementamos este principio, tendrá un impacto en los sistemas para cambiar zonas, etc.

Primero y ante todo, necesitamos tener algo estable y sólido antes de considerar avanzar hacia una nueva regla del sistema como esta.

Sí. Por supuesto, no estamos muy contentos con los tiempos, lo que significa que 3.24 fue una actualización realmente difícil. Trajo muchas características (hangares personales persistentes, sistemas de elevadores de carga...) que afectaron muchos sistemas ya existentes que eran problemáticos.

Hablé un poco de esto en SC-Live la última vez: hay realmente 3 sistemas en el juego que son problemáticos. El sistema de control de tráfico, el sistema de terminales ASOP, y el sistema de tránsito (todos sabemos qué problemas tiene). Como son un poco antiguos, intentamos actualizarlos, pero nunca tenemos prioridad sobre ellos.

Y luego el server meshing añade complejidad, así que 3.24 realmente nos frenó. Después, en marzo, durante las pruebas de rendimiento, identificamos que teníamos que hacer un desvío para instalar el sistema RMQ, que nos da un mejor rendimiento de red.

Así que no estamos completamente contentos con el calendario, pero estamos contentos con el resultado en el sentido de que podemos ver que la tecnología es funcional, y realmente es solo el primer paso. Como dije en mis informes de acción, no estamos persiguiendo números, estamos buscando una verdadera calidad de experiencia de juego. Vamos con lo que sea más estable y funcional.

Bueno, juego todos los días o casi jaja, sí, sí, sí, ¡soy un gran jugador! Me encanta, hice el Simpit en CIG, así que en casa tengo joysticks, pedales, el gran equipo, soy un fan de los juegos de simulación en general.

Sí, el Hornet. Siempre quiero jugar con el Hornet. El Hornet MKII es mi caballo de batalla. Eso para el caza monoplaza, y en cazas medianos: el Hurricane, me encanta esa nave. Con un buen artillero, el Hurricane: simplemente imparable. Y en las grandes... Para la exploración es el Carrack al 100%. Cuando escuché sobre el Carrack, realmente me volví loco, ¡un verdadero fanboy jaja! Y en cuanto a carga, tengo una pequeña inclinación por Drake, así que definitivamente el Caterpillar.

Nyx. Para mí, tiene que ser ilegal, porque me gusta la acción. Así que para mí, tiene que ser ilegal y... va a estar caliente.

Sí. De hecho, a nivel técnico, tenemos game servers. Estos son los que forman parte del Server Mesh. También tenemos Replicants, que se encargan de la red. Entonces, en este momento en 4.0, tenemos un Replicant y luego varios game servers que distribuyen las zonas entre ellos. Así que el sistema es capaz de asignar un servidor a una zona.

Así que podemos asegurarnos de que donde haya jugadores, haya buen rendimiento, ¿verdad? Cuanto más avancemos en la implementación del dynamic mesh, más receptivo será. Así que, amigos, si todos se van en un 890 Jump, bueno, vamos a darle un servidor al 890 Jump. Vale, es un poco tonto, pero así es. Eso es lo interesante, ¿sabes?

Ahora, hay otros niveles en esto. Hay lo que llamamos Star Services, que son servidores de juego que no están asignados a un shard, sino que se encargan del universo en general. Ejecutan el servidor del juego, es el mismo núcleo de software fundamental, pero solo están ahí para responder a llamadas de procedimientos remotos para coordinar varios shards juntos. Así que cosas como el Dynamic Weather, por ejemplo, son algo que puede colocarse en un servicio y ser usado por cada shard.

(Otro chico murmura en francés para asegurarse de haber entendido lo que explicó Benoît)

Exactamente. Todo lo que es VOIP son los Voice Servers, todo lo que es social es el group manager y así sucesivamente. Así que hay servicios como esos. El entity graph, que maneja toda la persistencia del juego, también son servicios que están en parte en el game server, pero están desplegados como servicios que sirven para todo.

Uno de los grandes elementos en los que estamos trabajando para 4.0, que es una característica clave, es el sistema de misiones. Por ejemplo, el sistema de misiones en 3.23 o incluso 3.24, cuando aceptas una misión o un contrato, crea una entidad de misión en el servidor. De hecho, ¡está ubicada en 0,0 del universo! Es una entidad invisible, obviamente, que persiste y te sigue, pero está ahí. ¡HOY ya no puedes tener eso! Porque ahora 0,0 es otro servidor.

Así que ahora estamos en el proceso de mover todos los sistemas de misiones a servicios que podrán servir a todos los shards. Estamos hablando del Contract Broker, por ejemplo, que se encarga de todos tus contratos que están disponibles en tu MobiGlass. También está la Mission Factory, que se encarga de crear misiones en el juego y coordinar los game servers. Por ejemplo: si tengo una misión de entrega, creamos una entidad en la primera ubicación, y otra entidad en el lugar de entrega, y eso hará posible el seguimiento.

El sistema de marcadores también se ha lanzado. Por ejemplo, algo tan simple como un marcador de grupo en otro sistema... Es realmente difícil de hacer en el modelo anterior. En el modelo anterior, solo ponías un marcador, pero ahora con la nueva arquitectura, tienes que tener un servicio dedicado a eso.

Así que ahí lo tienes, todo se trata de extraer lo que está en el game server actual (PU) hacia servicios que nos permitirán gestionarlo de una manera más amplia.

Entrevistador: Así que podemos entender claramente por qué 4.0 lleva tanto tiempo... jaja. ¡Gracias por tu tiempo, Benoît!