[HO] Star Citizen || Alpha 3.15.1

¿Cuándo veremos la transmisión persistente y la malla del servidor en la PU?

Nuestro objetivo actual es lanzar Persistent Streaming y la primera versión de la capa de Replicación, idealmente, entre el primer y segundo trimestre del próximo año. Luego continuaremos con la primera versión de una malla de servidor estático, salvo que surjan complicaciones técnicas imprevistas, entre el tercer y cuarto trimestre del próximo año.

¿Cuál es el estado actual de la tecnología de mallado del servidor y cuáles son los mayores problemas que la detienen?

La mayoría de la gente, cuando habla de Server Meshing, suele pensar en el último paso de esta tecnología en el que "conectamos los servidores". La verdad es que, antes de este paso final, es necesario realizar una cadena muy larga de requisitos previos y cambios tecnológicos fundamentales en nuestro motor de juego. Con eso en mente, intentaré responder a esta pregunta en el contexto del panorama completo.

La respuesta corta es que el estado está realmente muy avanzado.

Ahora la versión larga. El camino hacia Server Meshing comenzó en 2017/2018:

Transmisión de contenedores de objetos

Para que Server Meshing funcionara, primero necesitábamos tecnología que nos permitiera vincular / desvincular dinámicamente entidades a través del sistema de transmisión, ya que esto no es algo que el motor admitiera cuando comenzamos. Entonces, cuando lanzamos 'Client Side Object Container Streaming' (OCS) en 2018, ¡también lanzamos el primer paso hacia el mallado del servidor!

Una vez que este trampolín inicial salió por la puerta, la tecnología que nos permite vincular / desvincular dinámicamente entidades en el cliente también tuvo que habilitarse en el servidor (ya que, en última instancia, los nodos del servidor en la malla necesitarán transmitir entidades de entrada / salida dinámicamente ). Esta tecnología se llama 'Transmisión de contenedores de objetos del lado del servidor' (S-OCS), y la primera versión de S-OCS se lanzó a fines de 2019. Este fue el siguiente gran paso hacia Server Meshing.

Autoridad de entidad y transferencia de autoridad

Si bien teníamos la tecnología que nos permitió transmitir entidades dinámicamente en el servidor, todavía hay un solo servidor que 'posee' todas las entidades simuladas. En una malla donde varios nodos de servidor comparten la simulación, necesitábamos el concepto de "autoridad de entidad". Esto significa que una entidad dada ya no es propiedad de un solo servidor de juegos dedicado, sino que hay varios nodos de servidor en la malla. Entonces, un nodo de servidor que controla la entidad y varios otros nodos de servidor que tienen una vista de cliente de esta entidad. Esta autoridad también necesita la capacidad de transferir entre nodos de servidor. Se dedicó una buena cantidad de tiempo de desarrollo al concepto de 'autoridad de entidad' y 'transferencia de autoridad' en la primera mitad de 2020. Esta fue la primera vez que toda la empresa tuvo que trabajar en Server Meshing, ya que se tuvo que cambiar una gran cantidad de código del juego para que funcionara con el nuevo concepto de autoridad de entidad. A fines de 2020, la mayoría del código (del juego) se modificó para respaldar el concepto, por lo que se dio otro gran paso, pero no hay una malla real a la vista.

Capa de replicación y transmisión persistente

El siguiente paso fue mover la replicación de entidades a un lugar central donde podamos controlar la lógica de transmisión y enlace de red. Esto luego nos permite replicar el estado de la red en múltiples nodos de servidor. Para lograr esto, tuvimos que mover la lógica de transmisión y replicación del servidor dedicado a la capa de “Replicación”, que ahora aloja el código de replicación de red y transmisión de entidades.

Al mismo tiempo, también implementamos Persistent Streaming, que permite que la capa de replicación conserve el estado de la entidad en una base de datos gráfica que almacena el estado de cada una de las entidades replicadas de la red. 2021 se dedicó a trabajar en la capa de Replicación y EntityGraph, que nos permite controlar la transmisión y la replicación de entidades desde un proceso separado (separado del servidor de juegos dedicado tradicional). Este trabajo está casi terminado y se encuentra en su etapa final.

Mallas de servidor estáticas y dinámicas

Sin embargo, esto todavía no es una "malla". El trabajo en la malla real ha comenzado y nos llevará hasta el próximo año completarlo, y todos los requisitos previos que describí anteriormente eran necesarios para llegar a este punto. La primera versión de esta tecnología será una malla de servidor estático y será el próximo gran paso adelante. Sin embargo, ¡tampoco será el último! Con la malla estática, tendremos la primera versión de una malla verdadera pero, como indica el nombre 'estática', la capacidad de escalar esta malla es muy limitada.

Antes de que podamos realmente llamar a esta función completa, tendremos que dar otro gran paso, que llamamos "malla dinámica". Este paso nos permitirá combinar dinámicamente los nodos del servidor y luego escalar la malla dinámicamente según la demanda. Gran parte del trabajo en esta parte se realiza en paralelo. Por ejemplo, el Fleet Manager que controla la demanda dinámica de la malla ya está en desarrollo, así como los requisitos de emparejamiento que vienen con la nueva inclusión de "fragmentos".

Mientras tanto, muchos equipos de código de juego también tienen que trabajar para adaptar el código de juego existente para que funcione completamente con una malla de servidor (y lo que es más importante, encontrar todos los casos extremos que solo aparecerán una vez que tengamos una malla verdadera). Si bien el trabajo de autoridad de la entidad se completó en 2020, la autoridad de la entidad actualmente solo se transfiere entre el cliente y un solo servidor, por lo que algunos códigos pueden necesitar ajustes adicionales.

¿Cómo planeas administrar un barco grande, digamos un Javelin? ¿Sería ese su propio recurso dedicado con barcos a su alrededor?

Con Dynamic Server Meshing, es posible que los barcos grandes como un Javelin puedan tener su propio servidor dedicado asignado para ejecutar la simulación autorizada para ese barco y todo lo que contiene. Sin embargo, estamos tratando de evitar tener reglas inflexibles sobre cómo se asignan las entidades a los recursos de procesamiento, por lo que podría no ser siempre el caso. Todo se reduce a la eficiencia en términos de velocidad de procesamiento y costos del servidor. Si tuviéramos una regla estricta de que cada Javelin y todo lo que contiene tiene su propio servidor, entonces no sería muy rentable cuando un Javelin solo tiene un puñado de jugadores. La misma regla tampoco sería eficiente en términos de velocidad de procesamiento del servidor si hubiera cientos de jugadores apiñados en el mismo Javelin, ya que la regla evitaría que distribuyéramos la carga de procesamiento en varios servidores.

Dynamic Server Meshing será un poco diferente en el sentido de que reevaluará constantemente la mejor forma de distribuir la simulación, con el objetivo de encontrar el punto óptimo para que ningún servidor esté sobrecargado o infrautilizado. A medida que los jugadores se muevan por el verso, la distribución ideal de los recursos de procesamiento cambiará. Para reaccionar a esos cambios, necesitaremos la capacidad de transferir la autoridad sobre las entidades de un servidor a otro, así como poner nuevos servidores en línea y cerrar los antiguos. Esto nos permitirá mover la carga de procesamiento de un servidor que está en riesgo de sobrecargarse a uno que actualmente está subutilizado. Si ninguno de los servidores existentes tiene suficiente capacidad de reserva para manejar un aumento en la carga, simplemente podemos alquilar más servidores de nuestro proveedor de plataforma en la nube. Y cuando algunos servidores no tienen suficiente carga para que sean rentables,

¿Cuántos jugadores podrán verse en un espacio? ¿Cuál es el máximo que estás planeando?

Ésta es una pregunta difícil de responder, y la mejor respuesta que podemos dar en este momento es que depende.

Suponiendo que la pregunta es sobre el límite de cuántos jugadores podrán verse desde la vista de un cliente, lo dicta principalmente el cliente del juego. Esto se debe a la simulación del lado del cliente, como la física y el código del juego, así como al costo de renderizado.

Además, también depende en gran medida del escenario; 100 jugadores en combate FPS son más baratos de simular y renderizar en el cliente que 100 jugadores que luchan en naves espaciales monoplaza, disparando misiles y láseres entre sí.

El equipo de gráficos está trabajando activamente en Vulkan, lo que nos permitirá aumentar las llamadas de sorteo y debería mejorar la cantidad de jugadores / naves que podemos representar al mismo tiempo, mientras que el equipo del motor está muy centrado en las optimizaciones del código del juego para aumentar la cantidad de objetos del juego que podemos simular a la vez.

Nuestro objetivo es aumentar nuestro recuento de jugadores y nuestra expectativa es que apoyaremos escenarios en los que 100 jugadores puedan verse entre sí a velocidades de fotogramas razonables. Sin embargo, a medida que empezamos a escalar nuestros fragmentos para admitir recuentos de jugadores más altos, la probabilidad de que todos los jugadores dentro de un fragmento puedan ir a la misma ubicación física y verse sin problemas de rendimiento disminuirá.

Aquí es donde tendremos que comenzar a implementar mecánicas de juego que eviten que estos escenarios sucedan con demasiada frecuencia.

El límite absoluto es difícil de predecir hasta que algunas de las nuevas tecnologías estén en línea y podamos comenzar a medir el rendimiento.

Harroway
Si hago una base en una luna, ¿se reflejará mi base en los otros fragmentos en los que no estoy?
El equipo de Planet Tech planea implementar la construcción de bases teniendo en cuenta los fragmentos de servidor. Reclamar tierra para su base reclamará esta tierra en todos los fragmentos, y planeamos replicar su base en todos los fragmentos.

Sin embargo, solo un fragmento tendrá una versión 'activa' de la base, y otros fragmentos generarán una versión de 'acceso limitado / solo lectura' de esa misma base. Por ejemplo, una base dará acceso completo y la capacidad de expandirse en el fragmento en el que el propietario juega actualmente, mientras que en todos los demás fragmentos, esta base puede aparecer con puertas cerradas en un estado inmutable. El diseño completo aún no está 100% establecido y, sin embargo, puede cambiar.

¿El verdadero objetivo final es un solo fragmento para todos los jugadores?

Esta es nuestra ambición, sin embargo, dar una respuesta definitiva no es posible en este momento.

Comenzaremos con muchos fragmentos pequeños por región y reduciremos lentamente la cantidad de fragmentos. El primer objetivo principal será reducir esto a solo necesitar un solo fragmento por región. Para llegar allí, nuestro plan es aumentar gradualmente el recuento de jugadores por fragmento y mejorar constantemente la tecnología del backend y del cliente para admitir a más y más jugadores.

No solo se requieren cambios tecnológicos para lograr este objetivo, también se necesitan nuevos diseños y mecánicas de juego. Sin una mecánica que evite que todos los jugadores vayan a la misma ubicación, un mega fragmento grande será muy difícil de lograr, especialmente para el cliente. Por ejemplo, podría haber una mecánica para cerrar temporalmente los puntos de salto a lugares abarrotados o crear nuevas capas para ciertos lugares.

Si bien el backend está diseñado para escalar horizontalmente, el cliente del juego se ejecuta en una sola máquina y está limitado a un número definido de núcleos de CPU / GPU, así como a memoria.

Solo una vez que superemos estos obstáculos y logremos un mega fragmento por región, podremos enfrentar al jefe final: fusionar fragmentos regionales en un mega fragmento global.

Esto viene con su propio conjunto de problemas, ya que la localidad juega un papel importante en la experiencia del jugador. Por ejemplo, la latencia entre servicios dentro del mismo centro de datos es mucho menor que la latencia entre servicios alojados en dos centros de datos separados por regiones. Y aunque diseñamos el backend para admitir un fragmento global, es un desafío operativo implementar el backend de una manera que no favorezca a un grupo de jugadores sobre otro.

¿Será la economía del universo independiente en cada fragmento o unida?
La economía será global y se reflejará en cada fragmento.

Por ejemplo, echemos un vistazo a las tiendas. Si bien cada tienda tiene un inventario local (artículos que están actualmente en exhibición), las tiendas se reabastecen a partir de un inventario global compartido entre todos los fragmentos. Si muchos jugadores comienzan a comprar un arma específica en la tienda de armas de Port Olisar, el precio de esa arma aumentará en esta tienda en todos los fragmentos. Eventualmente, el inventario de esta arma se agotará, por lo que las tiendas de todos los fragmentos ya no podrán reabastecer esta arma.

¿Qué evitará que grandes grupos de "azules" y grandes grupos de "rojos" terminen en fragmentos de cámara de eco? La dinámica social implicaría grandes concentraciones de personas que tendrán amigos y estarán en organizaciones que tienen los mismos intereses. ¿Habrá una solución que asegure una mezcla adecuada de lo bueno, lo malo y lo intermedio?

Los jugadores no serán asignados permanentemente a fragmentos, ya que el sistema de emparejamiento asigna un nuevo fragmento para la región seleccionada en cada inicio de sesión. Al principio, esto provocará una distribución natural, ya que comenzaremos con muchos fragmentos más pequeños en paralelo.

A medida que comencemos a escalar nuestros fragmentos (y, por lo tanto, reduzcamos el número de fragmentos paralelos), esta pregunta se volverá más relevante. Planeamos abordar esto con nuestro nuevo sistema de emparejamiento.

El nuevo sistema de emparejamiento actualmente en desarrollo junto con Server Meshing nos permite emparejar jugadores con fragmentos en función de múltiples parámetros de entrada. Esos se utilizan para unir a los jugadores en fragmentos con sus amigos, o donde dejaron la mayoría de sus elementos en el mundo abierto. Sin embargo, también nos permite utilizar parámetros más avanzados, como la reputación y otras estadísticas ocultas del jugador que rastreamos.

Esto nos permitirá intentar y asegurarnos de que cada fragmento tenga una colección semidiversa de individuos. Por ejemplo, podríamos asegurarnos de no cargar inadvertidamente un fragmento con solo jugadores legales, lo que podría no ser muy divertido si parte de lo que quieren hacer es cazar jugadores criminales.

¿Tu personaje y tu barco estarán siempre en el juego cuando te hayas ido? es decir, si me desconecté de la plataforma de mi nave en un planeta, ¿mi nave seguirá allí, lo que significa que la gente podría intentar entrar o destruir mi nave?

Cuando una entidad está "desalojada" en un fragmento (existe físicamente en el fragmento), existe permanentemente dentro de ese fragmento hasta que el jugador "guarda" la entidad en un inventario. Esto se puede hacer recogiendo un arma y colocándola en su mochila, o aterrizando un barco en una plataforma de aterrizaje, lo que almacenará el barco en un inventario de plataforma de aterrizaje específico. Una vez que una entidad está dentro de un inventario, se almacena en la base de datos global y se puede deshacer en cualquier fragmento. Esto permite a los jugadores mover elementos entre fragmentos.

También planeamos una mecánica llamada 'Almacenamiento / Desarmado de artículos de héroe'. Esto tomará todos los elementos de héroe propiedad del jugador y los guardará automáticamente en un inventario de transición de fragmentos específico del jugador. El almacenamiento automático generalmente ocurre cuando no hay otros jugadores alrededor y la entidad se transmite. Los elementos de este inventario de transición de fragmentos seguirán a un jugador automáticamente, por lo que cuando un jugador inicie sesión en un fragmento diferente, tomaremos entidades y las volveremos a colocar en el nuevo fragmento en la posición donde el jugador las dejó.

Cuando aterrice su barco en la luna y cierre sesión, el barco saldrá y se guardará automáticamente si no hay otros jugadores alrededor en ese momento. Ahora, cuando inicie sesión en un fragmento diferente, su barco se desestimará en el nuevo fragmento. Si, por alguna razón, el barco permaneció más tiempo en el fragmento antiguo y se destruyó mientras no estabas conectado, es posible que te despiertes en un lecho médico.

Ferron ringworld Kray
¿Cuánto depende el contenido nuevo de Server Meshing ahora?

Si bien Server Meshing nos permitirá comenzar a aumentar la cantidad de jugadores que pueden jugar juntos en Star Citizen, también nos permitirá comenzar a agregar nuevas experiencias de contenido. En este momento, estamos enfocados en usar esto para agregar nuevos sistemas estelares. Server Meshing es una de las tecnologías clave para que los puntos de salto funcionen en el juego al permitir que los sistemas estelares entren y salgan de la memoria sin problemas sin necesidad de pantallas de carga. Los jugadores verán esto por primera vez el próximo año cuando la primera iteración de Server Meshing entre en funcionamiento con la introducción del sistema Pyro.

A medida que refinamos la tecnología y nos alejamos de Static Server Meshing hacia Dynamic Server Meshing, los diseñadores pueden usar esta tecnología para tener áreas más grandes e interesantes (como asentamientos más grandes o interiores de barcos grandes) con números más densos de IA y personajes de jugador. Server Meshing podría abrir las puertas a experiencias de juego en las que nuestros diseñadores ni siquiera han pensado todavía.

¿Qué grado de mejora del rendimiento podemos esperar?

La mayor ganancia será el rendimiento del servidor. En este momento, el rendimiento de nuestro servidor es bastante limitado debido a la gran cantidad de entidades que tenemos que simular en un servidor. Esto da como resultado una velocidad de fotogramas muy baja y una degradación del servidor, lo que hace que el cliente experimente retrasos en la red / bandas elásticas y otros problemas de desincronización de la red. Una vez que tengamos incluso la malla estática en su lugar, esperamos que la velocidad de fotogramas del servidor sea considerablemente mayor, lo que provocará menos de estos síntomas.

En el FPS del cliente, el mallado del servidor en realidad tiene muy poco impacto. El cliente ya solo transmite entidades que están en el rango visible. Puede haber algunas mejoras leves, ya que podemos ser un poco más agresivos con la selección de rango en el cliente, ya que, en este momento, algunos objetos tienen un radio de transmisión inflado para que funciones como el radar o los misiles funcionen correctamente. Con Server Meshing, podemos desacoplar el radio de transmisión del cliente y del servidor. Sin embargo, estas mejoras serán mínimas para el cliente. Aún así, un servidor FPS más rápido mejorará la experiencia general ya que el retraso de la red se reducirá considerablemente.

Sé que es posible que aún no haya una respuesta a esto, pero, tras el lanzamiento inicial de Server Meshing, ¿cuántos fragmentos anticipa que necesitará tener? 10, 100, 1000, ¿más? Sabemos que el cambio de DGS significa más jugadores por área de juego, pero no estoy seguro de cuántos anticipa.
La respuesta corta es que no podemos avanzar un número.

El concepto del fragmento es la parte "maleable" de la arquitectura de mallado, y solo podremos decir el número de fragmentos necesarios una vez que todas las piezas del componente estén en su lugar y planeamos llegar allí de forma iterativa.

Con la primera gota de transmisión persistente (no mallado), queremos comenzar imitando el comportamiento actual que ve en línea al tener un fragmento por instancia de servidor y un replicante (llamado híbrido). La única diferencia es que todas las entidades de esos fragmentos seguirán siendo persistentes. Esto nos permite lidiar con el peor de los casos al tener una gran cantidad de fragmentos persistentes y replicantes muy grandes para probar la mecánica de crear / sembrar, simular con jugadores activos y girar para reciclar o destruir. Queremos que la creación y destrucción de fragmentos en esta primera fase sea óptima, rápida y rentable.

Este enfoque tiene varias ventajas, ya que podemos probar la persistencia de fragmentos antes y, lo que es más importante, podemos medir métricas activas en muchos fragmentos.

Por ejemplo (¡no exhaustivo!):

Cuántas entidades permanecen en un fragmento persistente a lo largo del tiempo (tasa de crecimiento del fragmento)
Tamaño del gráfico global (tasa de crecimiento global)
Cuántos jugadores puede manejar una sola base de datos de fragmentos (uso del jugador)
Efecto de varias mecánicas de juego en las actualizaciones de entidades en la base de datos de fragmentos (efectos de juego)
Perfil de rendimiento de las colas de escritura, tiempos medios de consulta de los clústeres de bases de datos de fragmentos (métricas de bases de datos de fragmentos)
Perfil de rendimiento de las colas de escritura, tiempos medios de consulta del clúster de base de datos global (métricas de base de datos global)
Eficiencia de la fragmentación de la base de datos (¡otro nivel de fragmentación!) Del gráfico
Si bien tenemos estimaciones adecuadas y mediciones internas para estos, nada reemplaza a los jugadores reales que generan una carga representativa en el sistema.

A medida que pongamos en juego los otros componentes de la malla, principalmente la malla estática, planeamos reducir gradualmente la cantidad de fragmentos, agrupando a los jugadores en fragmentos cada vez más grandes hasta que nos sintamos cómodos con el rendimiento de los replicantes, DGS y el gráfico de entidad. Por supuesto, la malla estática sufrirá problemas de congregación y solo podremos continuar yendo a fragmentos mucho más grandes una vez que la malla dinámica esté en su lugar.

En última instancia, con la malla dinámica, nuestro objetivo es admitir fragmentos muy grandes.

¿Puede un activo tan pequeño como una bala viajar a través de fragmentos de servidor?
La respuesta corta es no.

Puede ver los fragmentos como una instancia completamente aislada del universo simulado, muy similar a cómo tenemos actualmente diferentes instancias aisladas por servidor dedicado. Para que los artículos se transfieran entre instancias, estos artículos deben almacenarse en un inventario antes de que se puedan desembalar en un fragmento diferente. Por ejemplo, si un jugador toma una pistola en un fragmento, la coloca en su mochila. Ahora, cuando el jugador se conecta a un fragmento diferente, el jugador puede sacar el arma de su mochila y colocarla en el nuevo fragmento.

Dentro de un fragmento, una entidad como un misil podrá viajar a través de múltiples nodos de servidor si estos nodos de servidor tienen el misil dentro del área de transmisión del servidor. Solo un nodo de servidor tendrá el control (tiene autoridad) sobre ese misil, mientras que los otros nodos de servidor solo verán una vista de cliente del mismo misil.

Las viñetas en realidad se generan en el lado del cliente. Entonces, se genera una versión única de la viñeta en cada nodo de cliente y servidor, por lo que utilicé una entidad replicada en red como un misil en el ejemplo anterior.

Cuando maneja diferentes regiones del mundo, ¿planea alojar cuatro granjas de servidores principales, como EE. UU., UE, China, Oceanic? ¿O planeas hacer "One-Global-Universe"? Si es global, ¿cómo manejaría eso el equilibrio de jugadores con variaciones extremas de ping?

Todavía planeamos mantener la distribución regional de servicios sensibles a la red. En la implementación inicial de Persistent Streaming, la base de datos global será verdaderamente global. Los propios fragmentos se distribuirán regionalmente, por lo que un cliente de juego que se conecte a la región de la UE se combinará preferiblemente con un fragmento de la UE. A medida que los fragmentos crecen en tamaño (tanto para los jugadores como para las entidades), planeamos volver a visitar este modelo y también introducir servicios a nivel regional para brindar datos más cerca de la localidad.

Obliterate quantum matrix engines
Vivo en Europa del Este. Después de iniciar Server Meshing, ¿podré jugar con amigos de EE. UU.?
No planeamos limitar qué fragmento y región puede elegir un jugador.

Un jugador tendrá la libertad de elegir cualquier región para jugar y, dentro de esta región, permitiremos una selección limitada de fragmentos. Por ejemplo, el fragmento con tus amigos o el fragmento en el que jugaste por última vez.

Dado que todos los datos de los jugadores se almacenan en la base de datos global, los jugadores pueden cambiar entre fragmentos de manera similar a como pueden cambiar entre instancias en la actualidad. Los artículos almacenados se transferirán con el jugador y siempre estarán accesibles independientemente del fragmento.

La capa de replicación muere: ¿Qué experimentarán los jugadores si una capa de replicación se cierra / 'muere'?
Sabemos que el gráfico de la entidad recopilará la información inicial y la enviará de nuevo a una nueva capa de replicación, pero volveremos al menú principal si la capa de replicación muere en comparación con si un nodo del servidor muere, o tendremos algún tipo de carga pantalla que automáticamente nos convierte en una nueva capa?
Para responder a esto correctamente, primero necesito dar más detalles sobre cómo se verá nuestra arquitectura final. En última instancia, la capa de replicación no será un solo nodo de servidor. En su lugar, consistirá en varias instancias de un conjunto de microservicios con nombres como Replicant, Atlas y Scribe. Una ventaja de esto es que la propia capa de replicación podrá escalar. Otra ventaja, más relevante para esta pregunta, es que aunque un solo nodo / instancia en la capa de Replicación puede fallar, es muy poco probable que toda la capa de Replicación falle a la vez. Desde el punto de vista del cliente, los nodos replicantes son los más importantes, ya que son los que manejarán la transmisión de entidades en red y la replicación del estado entre los clientes y el juego. El Replicante está diseñado para no ejecutar ninguna lógica de juego y, de hecho, ejecutará muy poco código; sin animación, sin física, solo código de red. Construirse a partir de una base de código tan pequeña debería significar menos errores en general. Entonces, después de algunos inevitables problemas iniciales, esperamos que los Replicantes sean bastante estables. También es importante saber que, en cualquier momento, un solo cliente puede ser atendido por varios replicantes (pero esos replicantes también atenderán a otros clientes al mismo tiempo). La última pieza del rompecabezas es la capa de puerta de enlace: los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee. Construirse a partir de una base de código tan pequeña debería significar menos errores en general. Entonces, después de algunos inevitables problemas iniciales, esperamos que los Replicantes sean bastante estables. También es importante saber que, en cualquier momento, un solo cliente puede ser atendido por varios replicantes (pero esos replicantes también atenderán a otros clientes al mismo tiempo). La última pieza del rompecabezas es la capa de puerta de enlace: los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee. Construirse a partir de una base de código tan pequeña debería significar menos errores en general. Entonces, después de algunos inevitables problemas iniciales, esperamos que los Replicantes sean bastante estables. También es importante saber que, en cualquier momento, un solo cliente puede ser atendido por varios replicantes (pero esos replicantes también atenderán a otros clientes al mismo tiempo). La última pieza del rompecabezas es la capa de puerta de enlace: los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee. También es importante saber que, en cualquier momento, un solo cliente puede ser atendido por varios replicantes (pero esos replicantes también atenderán a otros clientes al mismo tiempo). La última pieza del rompecabezas es la capa de puerta de enlace: los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee. También es importante saber que, en cualquier momento, un solo cliente puede ser atendido por varios replicantes (pero esos replicantes también atenderán a otros clientes al mismo tiempo). La última pieza del rompecabezas es la capa de puerta de enlace: los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee. Los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee. Los clientes no se conectarán directamente a los replicantes, sino a un nodo de puerta de enlace en la capa de puerta de enlace. El servicio de puerta de enlace está ahí para dirigir los paquetes entre los clientes y los diversos replicantes con los que están hablando. El servicio de puerta de enlace utilizará una base de código aún más pequeña que el replicante, por lo que debería ser incluso menos probable que se bloquee.

Entonces, ¿qué experimentará un cliente si uno de los replicantes que lo atiende se bloquea repentinamente?

El cliente permanecerá conectado al fragmento, pero parte o la totalidad de su simulación se congelará temporalmente. La capa de replicación activará un nuevo nodo replicante para reemplazar el que se bloqueó y recuperará el estado de la entidad perdida de la persistencia a través de EntityGraph. Las puertas de enlace del cliente y los nodos DGS que estaban conectados al replicante antiguo restablecerán la conexión con el nuevo. Una vez que todo se vuelva a conectar, el juego se descongelará para los clientes afectados. En este punto, el cliente puede experimentar algún chasquido / teletransportación de entidades. Esperamos que todo el proceso lleve menos de un minuto.

¿Qué experimentará un cliente si la puerta de enlace que lo atiende se bloquea repentinamente?

El servicio Gateway no tiene ningún estado de juego y tendrá su propia forma de recuperación de fallos. Dado que es un servicio mucho más simple que un replicante, el tiempo de recuperación debería ser mucho más rápido, más del orden de segundos. Mientras la recuperación está en progreso, el cliente experimentará una congelación temporal seguida de algunos chasquidos / teletransportación.

¿Qué pasa con el servicio híbrido?

Durante su presentación CitizenCon sobre Persistent Streaming y Server Meshing, Paul y Benoit hablaron sobre la capa de Replicación en términos del servicio híbrido. El servicio híbrido es, como su nombre indica, un híbrido de los servicios Replicant, Atlas, Scribe y Gateway que mencioné anteriormente (pero no EntityGraph), así como un puñado de otros servicios aún no discutidos. Hemos optado por desarrollar esto primero antes de dividirlo en sus componentes de servicios, ya que reduce la cantidad de piezas móviles con las que tratamos de tratar todas a la vez. También nos permite centrarnos en probar todos los grandes conceptos en lugar de la repetición de que todos esos servicios individuales se comuniquen correctamente. En esta implementación inicial, la capa de replicación será un único nodo de servidor híbrido. Si este nodo híbrido falla, entonces la situación será similar a la que experimentan los clientes ahora cuando un servidor de juegos dedicado falla. Todos los clientes volverán al menú de la interfaz con el infame error de 30k. Una vez que haya comenzado el híbrido de reemplazo, los clientes podrán volver a unirse al fragmento y continuar donde lo dejaron. Con suerte, podremos implementarlo de manera que los clientes reciban una notificación en pantalla de que el fragmento está disponible nuevamente y una sola pulsación de tecla los hará coincidir con el fragmento (similar a cómo funciona para la recuperación de fallas del cliente).

Vimos mucha conversación en el panel sobre qué nodos tienen autoridad de escritura dentro de un fragmento, pero ¿qué pasa con la autoridad de escritura entre fragmentos separados? ¿Se mantienen bases de datos de persistencia separadas para fragmentos separados o los estados de los elementos del mundo se sincronizarán eventualmente entre fragmentos incluso si se dejaron en diferentes estados (es decir, se deja una puerta abierta en un fragmento y se deja cerrada en otro? su estado en la base de datos, actualizando el estado de la puerta en el otro fragmento?)
En términos generales, cada fragmento es su propia copia única del universo, y cualquier elemento dentro del fragmento no compartirá el estado con un elemento de un fragmento diferente, ya que cada fragmento tiene su propia base de datos. Por otro lado, tenemos una base de datos global para datos de inventario de jugadores. Esta base de datos se utiliza para almacenar cualquier elemento en el inventario de un jugador, y los elementos se pueden transferir entre fragmentos si primero se almacenan de un fragmento en un inventario y luego se desechan en otro fragmento.

Algunas características, como los puestos avanzados de jugadores o los recursos extraíbles, implementan un código especial que replicará un estado global en todos los fragmentos, por lo que un puesto avanzado puede existir en varios fragmentos en paralelo y lentamente (en relación con la velocidad del juego en tiempo real) replica su estado. entre fragmentos. Esta no es una replicación instantánea (la apertura / cierre de una puerta no se replicará), sin embargo, un estado persistente como una puerta bloqueada o desbloqueada puede replicarse entre fragmentos.

Es similar para los recursos extraíbles: si bien cada fragmento tiene una versión única de una roca extraíble, la cantidad total se replicará entre los fragmentos, por lo que cuando los jugadores comiencen a extraer una determinada área, el mapa de recursos global para esta área se modificará y el número de rocas extraíbles en esa ubicación se verán afectadas en todos los fragmentos.

Cuando tiene una parte moviéndose (viaje cuántico u otro) de un objeto a otro, y otro nodo, objeto o instancia de DGS está lleno, ¿T0 / Static Meshing creará otro nodo de DGS de forma preventiva? ¿O cómo se manejará esto?
Con Static Server Meshing, todo se arregla de antemano, incluida la cantidad de nodos de servidor por fragmento y qué servidor de juego es responsable de simular qué ubicaciones. Esto significa que si todos en el fragmento deciden dirigirse a la misma ubicación, todos terminarán siendo simulados por el mismo nodo del servidor.

En realidad, el peor de los casos es si todos los jugadores deciden distribuirse entre todas las ubicaciones asignadas a un único nodo de servidor. De esa manera, el servidor pobre intentará lidiar no solo con todos los jugadores, sino que también necesitará haber transmitido en todas sus ubicaciones. La respuesta obvia es permitir más servidores por fragmento, por lo que cada nodo de servidor tiene menos ubicaciones en las que puede necesitar transmitir. Sin embargo, debido a que se trata de una malla estática y todo está arreglado de antemano, tener más nodos de servidor por fragmento también aumenta los costos de funcionamiento. . Pero tenemos que comenzar en algún lugar, por lo que el plan para la primera versión de Static Server Meshing es comenzar con la menor cantidad posible de nodos de servidor por fragmento mientras aún probamos que la tecnología realmente funciona.

Por lo tanto, no espere que la cantidad de jugadores aumente mucho con la primera versión. Eso evita el problema de que un solo nodo de servidor se llene antes de que lleguen los jugadores, ya que limitaremos el número máximo de jugadores por fragmento en función del peor de los casos. Una vez que tengamos esto funcionando, veremos cómo funcionan el rendimiento y la economía y veremos hasta dónde podemos llevarlo. Pero para que una mayor expansión sea económicamente viable, tendremos que pensar en hacer que Server Meshing sea más dinámico lo antes posible.

Con el gran volumen de datos que viajan entre los clientes y los nodos del servidor, y la necesidad de una latencia extremadamente baja, ¿puede describir o profundizar en cómo está administrando eso o qué tecnologías está utilizando para ayudar a acelerar las cosas, o más bien mantenerlas? de desacelerar?
Los factores más importantes que afectan actualmente a la latencia son la tasa de ticks del servidor, el ping del cliente, la generación de entidades y la latencia de los servicios persistentes.

La tasa de tick del servidor tiene el mayor efecto de estos y está relacionada con la cantidad de ubicaciones que está simulando un servidor de juegos. El mallado del servidor debería ayudar con esto al reducir la cantidad de ubicaciones que cada servidor de juegos necesita para transmitir y simular. Menos ubicaciones significarán un recuento de entidades promedio mucho más bajo por servidor y los ahorros se pueden usar para aumentar la cantidad de jugadores por servidor.

El ping del cliente está dominado por la distancia del servidor. Vemos que muchos jugadores eligen jugar en regiones de continentes completamente diferentes. Parte de nuestro código de juego sigue estando autorizado por el cliente, lo que significa que los jugadores con un ping alto pueden afectar negativamente la experiencia de juego de todos los demás. No hay mucho que podamos hacer al respecto a corto plazo, pero es algo que queremos mejorar después de que Server Meshing esté funcionando.

La generación lenta de entidades puede causar latencia al retrasar el momento en que las entidades ingresan a los clientes. Esto puede causar efectos indeseables, como ubicaciones que no aparecen por completo hasta minutos después de un viaje cuántico a una ubicación, caer a través de pisos después de reaparecer en una ubicación, barcos que tardan mucho en aparecer en las terminales ASOP, cambiar la carga del jugador, etc. esto se encuentra principalmente en el servidor. Primero, las entidades no se replican en los clientes hasta que se hayan generado por completo en el servidor. En segundo lugar, el servidor tiene una única cola de generación que debe procesar en orden. En tercer lugar, cuantas más ubicaciones necesite un servidor para transmitir, más generación tendrá que hacer. Para mejorar las cosas, hemos modificado el código de generación del servidor para hacer uso de colas de generación paralelas. El mallado del servidor también ayudará,

Todavía estamos usando algunos de nuestros servicios persistentes heredados, adecuados según su diseño, pero se sabe que tienen problemas de rendimiento y escalabilidad bajo nuestras demandas. Esto puede resultar en largas esperas al obtener datos persistentes de los servicios para saber qué generar, como generar un barco desde una terminal ASOP, examinar un inventario, cambiar la carga del jugador, etc. aumentar drásticamente la cantidad de datos que necesitamos para persistir, sabíamos que teníamos que hacer algo al respecto. Es por eso que Benoit y su equipo en Turbulent han reinventado por completo la forma en que conservaremos los datos en forma de EntityGraph, que es un servicio altamente escalable construido sobre una base de datos altamente escalable que está optimizada para exactamente el tipo de operaciones de datos que realizamos. Además de eso, También estamos desarrollando la capa de Replicación, que actúa como una caché en memoria altamente escalable del estado actual de todas las entidades en un fragmento, eliminando la necesidad de la mayoría de las consultas que hemos estado enviando a los servicios persistentes heredados. Así es, ¡serán servicios altamente escalables hasta el final!

Para ayudar a reducir / eliminar cualquier latencia adicional que pueda introducir la capa de Replicación, la estamos construyendo para que sea impulsada por eventos en lugar de tener una frecuencia de tic como un servidor de juegos tradicional. Esto significa que a medida que ingresan los paquetes, los procesará inmediatamente y enviará la respuesta y / o reenviará la información a los clientes y servidores de juegos relevantes. Una vez que se complete el trabajo en la versión inicial de la capa de Replicación (el servicio híbrido), realizaremos un pase de optimización para asegurarnos de que responda lo más posible. Y, aunque esta es en última instancia una decisión para DevOps, los implementaremos en los mismos centros de datos que los servidores del juego, por lo que la latencia de la red en el cable debido al salto adicional entre la capa de replicación y el servidor del juego debería ser menor. que un milisegundo. Oh, ¿y mencioné que la capa de replicación será altamente escalable? Eso significa que si detectamos que la capa de Replicación causa puntos de latencia en partes particulares del verso, podremos reconfigurarlo para solucionar el problema.

Descargo de responsabilidad
Las respuestas reflejan con precisión las intenciones de desarrollo en el momento de escribir este artículo, pero la empresa y el equipo de desarrollo se reservan el derecho de adaptar, mejorar o cambiar características y diseños en respuesta a comentarios, pruebas de juego, revisiones de diseño u otras consideraciones para mejorar el equilibrio o la calidad. del juego en general.

Olvídalo ooootra vez xD

Mira, solo tienes que ver en cuantos hilos diferentes del foro ha participado y con qué mensaje de troleo se estreno en el foro EOL. Vamos que está aquí para lo que está e igual es seguramente hasta un clon de alguien xD

Mándale ya al exilio a estudiar, como yo hice con SECHI y el tal Snake ese