Clan de Star Citizen
¿Quieres reaccionar a este mensaje? Regístrate en el foro con unos pocos clics o inicia sesión para continuar.
Ir abajo
avatar
Admin
Admin
Mensajes : 179
Fecha de inscripción : 11/07/2018
http://norax.foroactivo.com

Alpha 3.12 Post mortem | Star Citizen Empty Alpha 3.12 Post mortem | Star Citizen

Mar Feb 16, 2021 8:25 am


Alpha 3.12 Post mortem

EL 17 de diciembre de 2020, lanzamos Alpha 3.12: Assault on Stanton, que introdujo una serie de nuevas características y cambios, que incluyen cubiertas de refinería, mejoras de inteligencia artificial y nubes de gas. La siguiente es una autopsia de los propios desarrolladores senior, que detalla lo que se entregó y sus pensamientos sobre cómo fue. Como nota al margen, esta autopsia se centra específicamente en el parche Alpha 3.12; lanzaremos un Comm-Link posterior a la autopsia que se centrará en el evento dinámico XenoThreat por separado.

POSTMORTEM ALPHA 3.12
Equipo de vehículos

Qué salió bien
El Vehicle Pillar apoyó principalmente el trabajo de muchos otros equipos para Star Citizen Alpha 3.12, particularmente con el combate de la nave capital antes de los eventos Arlington Bounty, CS5 UEE Navy Idris y XenoThreat. Trabajamos no solo en cómo funcionan y se desempeñan los vehículos (siendo las naves más grandes desplegadas en los servidores hasta el momento), sino que también ayudamos a lidiar con el aumento de la letalidad de los torpedos con un uso de contramedidas de IA más inteligente y efectivo.


Los jugadores también se beneficiaron de este trabajo con la capacidad de elegir el tipo de contramedida y cuántas se disparan en una ráfaga, lo que agrega una mayor elección táctica al acto de desviar los misiles y torpedos entrantes. También agregamos más elementos de HUD para permitir a los jugadores ver cuántos de cada tipo les quedan junto con el tamaño de ráfaga actual.

El último cambio a las contramedidas fue una expansión de los cambios Alpha 3.11. Esto hace que cada tipo de contramedida funcione contra todos los tipos de buscadores de misiles, pero cambia su efectividad dependiendo del tipo y número de misiles entrantes. Los señuelos reemplazaron a las bengalas como una distracción puntual por tiempo limitado, mientras que el ruido, anteriormente chaff, se convirtió en un bloqueador de señales de área de efecto (más contramedidas lanzadas brindan una mayor probabilidad de falsificación). También cambiamos los misiles para proporcionar una variación menor en su seguimiento, de modo que una contramedida exitosa no desviaría todos los misiles por igual. Además de controlar el tamaño de la ráfaga manualmente, agregamos una función de pánico que vacía el 25% de las contramedidas disponibles en un intento de dominar una oleada de misiles entrantes.

Lo que no salió tan bien
Descubrimos muchos problemas con la configuración y el equilibrio de los misiles que provocaban comportamientos extraños. Sin embargo, decidimos dejar esto hasta que los misiles se conviertan a IFCS 2.0 en Alpha 3.13, ya que requiere una resintonización completa de todos los comportamientos de los misiles. En el futuro, queremos expandir las contramedidas brindando a los jugadores mejores comentarios sobre sus propias firmas y habilidades de misiles, que comenzarán a estar en línea con el modo de operador de misiles.

La identificación de entrada de vehículos fue una característica de calidad de vida muy solicitada ( basada en las notificaciones de aparición de hangar de ASOP de Alpha 3.11) que permite a los jugadores identificar rápidamente los puntos de entrada a un nave. Estos marcadores se actualizan dependiendo de si el nave está aterrizado o en gravedad cero, eliminando una queja común que tenían los nuevos jugadores de no poder averiguar cómo entrar en su nave. Ocasionalmente, estas pantallas se desvían enormemente del vehículo, que estamos investigando, pero ese fue prácticamente el único problema negativo con la función y, en general, fue bien recibido.

La entrega de contenido principal en Alpha 3.12 fue Esperia Talon y Talon Shrike, que son un par de cazas ligeros que amplían la alineación en el juego. En general, estos fueron bastante bien y discutimos su desarrollo en múltiples episodios de ISC , incluido nuestro trabajo en Hard Surface Shader y materiales iridiscentes.

Desafortunadamente, hubo algunos problemas en el lanzamiento que pretendemos solucionar en parches futuros. Estos incluyen la pantalla que requiere alternar en Arena Commander (también presente en el Prowler) y los lanzadores de misiles del Talon Shrike que a veces dejan de funcionar después de que se ha disparado un gran número.

Director de vehículos John Crewe
Equipo de funciones de juego de la USPU
El cuarto trimestre para el equipo de la USPU siempre está ocupado. No solo para nosotros, sino para toda la empresa. Aquí hay un breve resumen de nuestras iniciativas más importantes que pudimos poner en sus manos durante el trimestre. Afortunadamente, para bien o para mal, no teníamos una demostración masiva de CitizenCon para preparar este año, pero eso no nos impidió estar extremadamente ocupados.

Exposición Aeroespacial Internacional ( IAE )
Qué salió bien
Ampliamos con éxito nuestro contenido IAE en el estilo de arte de alta tecnología, que tuvo lugar en New Babbage en el planeta microTech. Agregamos varias cosas nuevas al evento de este año que intentaron satisfacer los comentarios de los fanáticos. En primer lugar, hicimos funcionar la sala de exposiciones de cada fabricante durante dos días consecutivos en caso de que los fanáticos se perdieran el primero y extendimos el período de alquiler gratuito de un día a dos. Ojalá estas dos cosas les dieran a todos la oportunidad de alquilar las naves que estaban ansiosos por probar. También teníamos dos salas de exposiciones en funcionamiento todos los días. Obviamente, esto permitió que los jugadores vieran más cosas y, con el espíritu de "más cosas que ver", decidimos exhibir muchos de los componentes y armas de nuestra nave en la sala principal. Entre dos salas activas cada día y todos los elementos adicionales, Este fue un verdadero testimonio de que nuestra tecnología se está optimizando cada vez más, ya que nunca hubiéramos podido hacer eso en el pasado. Finalmente, para intentar ampliar la accesibilidad, agregamos una serie de quioscos de alquiler en la sala "Best In Show", que estuvo en funcionamiento durante cuatro días. En estos quioscos, colocamos todos los vehículos que se mostraron durante el transcurso de la feria y les dimos el mismo período de alquiler de dos días. Entre todo esto, creemos que fue la iteración más atractiva que hemos creado hasta la fecha.

Lo que no salió tan bien
Tuvimos dos vehículos que se introdujeron al juego en el IAE. Mostrar que realmente se redujo al cable en términos de su desarrollo. En última instancia, esto no nos permitió bloquear la compilación hasta unos días antes del espectáculo. Debido a que este programa está abierto al público en noviembre, tuvo que ser lanzado como un parche puntual para la versión Alpha 3.11. No poder bloquear la compilación antes de pasar a la compilación Alpha 3.12 causó algunos dolores de cabeza en la administración de archivos. Todavía se están realizando correcciones críticas en la versión puntual y esas mismas correcciones también deben estar en el contenido de la transmisión recién ramificada. Esto inevitablemente conduce a que el trabajo sea pisoteado aquí y allá y, al final del día, consume un tiempo valioso que podría usarse para corregir otros errores o hacer cosas nuevas. Además, se filtraron algunas cosas que teníamos la intención de mantener en secreto hasta un poco más cerca de la hora del evento. Este no fue un problema importante,

Qué haremos de manera diferente en el futuro
Algunas cosas en las que realmente quiero centrarme a medida que avanzamos con este evento son:
Modularidad / reutilización de activos de eventos anteriores. Cuanto más rápido podamos hacer que ocurran estos eventos, más tiempo tendremos para enfocarnos en nuevas ideas de contenido u otros sistemas solares.
Planificación de preproducción. Sabemos que el evento volverá a suceder el próximo noviembre, así que me gustaría arreglar cosas como el esquema de color, los logotipos del evento, la ubicación, etc. lo antes posible. De esta manera, cuando llega el momento de trabajar en el contenido, nadie está esperando que se decida nada y podemos simplemente agachar la cabeza y trabajar.
Obtenga todo el contenido del evento en la compilación para que podamos evitar requerir un lanzamiento de puntos. Como se mencionó anteriormente, tener dos flujos / ramas de lanzamiento ejecutándose en paralelo es simplemente buscar problemas.

Sistema de reputación
Qué salió bien
Otro sistema importante que se agregó en el cuarto trimestre fue el sistema de reputación que siempre quisimos tener. Si bien esto aún no es visible para los jugadores, pueden experimentarlo a través de nuestros donantes de misiones y algunas de nuestras cadenas de misiones (la cadena de cazarrecompensas es la serie más notable que se desbloquea actualmente por ganancias de reputación). No todas las misiones se han convertido al nuevo sistema, aunque será un proceso continuo durante el próximo trimestre o dos. Este nuevo sistema de reputación será la base de una cantidad significativa de sistemas de juego a medida que avancemos. Esta no solo será la forma principal en que se publica el contenido para los jugadores, sino que también estará vinculado a cosas como NPC.respuestas (que se ven actualmente en los donantes de misiones), ventajas y beneficios que se pueden obtener participando en el contenido, para rastrear el progreso del jugador a través de trayectorias profesionales, para dictar relaciones entre las organizaciones dentro del juego y una serie de otros bucles de juego esenciales. Sentimos que esto era tan importante para entrar en el juego que decidimos lanzarlo sin que ningún jugador se enfrentara a la interfaz de usuario (que está en progreso para el lanzamiento de Q1 / Q2). Pero debido a que esto va a estar tan arraigado en una cantidad significativa de sistemas en el futuro, sentimos que valió la pena el sacrificio. No solo estará representado en una interfaz de usuario de reputación independiente que permitirá a los jugadores ver sus trayectorias profesionales con varias organizaciones, sino que también hará un seguimiento del NPC clave.s con los que han interactuado junto con su posición actual con cada uno. Las reputaciones se expondrán en esta interfaz de usuario a medida que las encuentren en el universo para que anime a los jugadores a viajar e interactuar con el contenido para exponerlas. Además, actualizaremos Mission Manager para incluir la visibilidad de los jugadores sobre qué tipo de requisitos de reputación necesitan para adquirir misiones. La reputación será una de las mecánicas de progresión más grandes que Star Citizen tendrá fuera de la economía, ya que somos un juego de caja de arena basado en habilidades que no está impulsado por sistemas de "nivelación" o "árbol de talentos". La reputación ahora también depende del servicio en el backend. Esto significa que todas las ganancias de reputación se pueden conservar entre parches, lo que será una gran cosa para los jugadores.

Lo que no salió tan bien
En cuanto al desarrollo general de esta función, se desarrolló sin problemas una vez que nos pusimos manos a la obra. Habíamos comenzado a trabajar en él aproximadamente un año antes de esto, pero desafortunadamente nos llevaron a algunas cosas de mayor prioridad en ese momento. Si tuviera que hacerlo de nuevo, habría mantenido al equipo en esto hasta que estuviera hecho y tuviera los cambios de UI / UX deseados para acompañarlo. No tener la interfaz de usuario en su lugar con su lanzamiento, si bien no rompe el juego, es una pieza fundamental de esta función. Garantizar que todas nuestras funciones sean intuitivas a menudo se basa en este tipo de comentarios visuales.

Qué haremos de manera diferente en el futuro
En el futuro, me gustaría intentar y presupuestar el tiempo necesario para lanzar una función más "completa". Si bien no siempre es posible convertir todo el contenido existente de un juego en nuevos sistemas como este, me gustaría intentar asegurarme de que podamos hacer más cuando se produzcan grandes cambios como estos en el futuro. Me alegré de haber logrado algo más que la intención original, pero me hubiera encantado tener más tiempo con el Equipo de Misión para ayudar a convertir incluso más que nosotros. La próxima vez que surja algo tan fundamental como esto, me gustaría personalmente hacer un mejor trabajo para generar conciencia global en toda la empresa para que podamos convertir la mayor cantidad posible.
Conversión de front-end a bloques de construcción
Qué salió bien
Pudimos convertir las dos pantallas iniciales en la interfaz para utilizar nuestra tecnología Building Blocks. En general, creo que este proceso salió bastante bien. No requirió mucha gente y fue un trabajo bastante autónomo. También tuvimos la oportunidad de arreglar algunas cosas que queríamos abordar desde que agregamos el servicio de "nuevos amigos" en el primer trimestre de 2020. Cambiar esto a nuestro nuevo sistema de interfaz de usuario también nos permitió desvanecer todos los elementos de la interfaz de usuario juntos. Pasar por este proceso nos dio algo de tiempo para pensar críticamente a través de la interfaz, ya que el proyecto ha evolucionado mucho en los últimos años. También lo configuramos para que la solución actual pueda escalar a medida que agregamos más sistemas solares. Limpiamos la pantalla principal para poder tener una mejor vista de las imágenes de fondo. Me alegra que pudiéramos atribuir una imagen diferente para cada posible zona de aterrizaje; Creo que realmente ayuda a que los nuevos jugadores sepan qué tipo de ubicación están eligiendo.

Lo que no salió tan bien
La interfaz está muy arraigada con el conjunto de herramientas CryEngine original con el que comenzamos originalmente. El sistema Building Blocks funciona en función de entidades, lo que significa que nuestros datos centrales deben cargarse para que tengamos una entidad sobre la que ejecutar el lienzo. Además de eso, el sistema original requiere que se cargue un nivel. Debido a esto, no pudimos reemplazar ningún elemento antes de seleccionar qué modo de juego quieren jugar los jugadores (al menos no con la tecnología / implementación basada en Building-Blocks). La solución definitiva es reelaborar por completo esta base de código, pero eso estaba muy fuera del alcance de lo que pudimos tratar, ni era nuestra directiva principal aquí.

Qué haremos de manera diferente en el futuro
La conclusión aquí es que el juego en el que basamos nuestra interfaz original es muy diferente del juego que estamos construyendo hoy. No estoy seguro de cuánto cambiará el equipo de la USPU la interfaz en el futuro, pero la próxima vez que hagamos cambios aquí, realmente me gustaría trabajar hacia la visión final. Esto nos permitiría optimizar realmente la nueva experiencia del usuario para que entrar al juego por primera vez, o volver al juego para los jugadores que regresan, sea lo más simple e intuitivo posible. Debido a que hemos estado incorporando nuevas funciones una a una, esta parte del juego ha sufrido como resultado. Si esto se puede redefinir desde cero, hay muchas cosas que haríamos de manera diferente en función de cuánto ha evolucionado el juego.

Rob Reininger
, diseñador jefe de sistemas y PROPIETARIO DE producto de la USPU
Equipo de herramientas y servicios sistémicos
Qué salió bien
El equipo de herramientas y servicios sistémicos ( SST ) continuó trabajando en la simulación Quantum e integrándola en los servicios junto con presentaciones internas de nueva tecnología que nos complace compartir pronto con la comunidad.

El trabajo administrativo ocurrió el último trimestre para cambiar los recursos internos de CIG para SST . El equipo aumentará de tamaño para adaptarse a la creciente necesidad de servicios y soporte para Quantum en muchos aspectos del juego.

Fuera de los servicios y el trabajo de simulación, SST creó nuevas herramientas para respaldar el próximo sistema de reputación y la forma en que la reputación se distribuye en todo el universo del juego. SST continúa apoyando la economía de Star Citizen con herramientas de datos para ayudar a aliviar la enorme cantidad de datos mientras nos preparamos para que Quantum tome las riendas.

Lo que no salió tan bien
A medida que pasamos a un departamento más grande, tuvimos algunos problemas de crecimiento con nuestros tiempos de respuesta a otros equipos. Características como el servicio de refinería no recibieron la atención inmediata que necesitaban mientras nuestra atención estaba en otra parte.

Qué haremos de manera diferente en el futuro
Buscamos formas de optimizar y distribuir mejor el trabajo que llega a SST para el equipo en crecimiento. Además, hemos configurado la mensajería automática para complementar la comunicación que sale de SST a los equipos dependientes.

Jake Muehle
Diseñador técnico sénior
Equipo de diseño
IA interceptando torpedos
Qué salió bien
Las torretas de interceptación de los torpedos de la Idris funcionan bien y crean algunos momentos muy interesantes cuando interceptan con éxito.

Lo que no salió tan bien
La precisión de la IA no es lo suficientemente buena como para derribar de manera confiable los torpedos entrantes dependiendo de la velocidad de fotogramas del servidor.

Qué haremos de manera diferente en el futuro
Buscaremos mejorar la precisión de la IA para poder tener un mayor control sobre cuántos torpedos se deslizan a través de las defensas de las torretas.

Uso del modo de fuego de IA y prioridades de orientación
Qué salió bien
La IA que usa ráfagas de fuego mejora enormemente el aspecto del fuego de la torreta de la IA. Además, las prioridades de orientación aseguran que la IA esté atacando un objetivo sensible para su clase de nave / tamaño de torreta.

Lo que no salió tan bien
Por el momento, el uso de ráfagas de fuego pone a la IA en desventaja en comparación con los jugadores, ya que el disparo completamente automático aumenta el daño.

Qué haremos de manera diferente en el futuro
Reequilibraremos el disparo por ráfagas de IA cuando se introduzcan los condensadores para reducir la efectividad de mantener presionado el botón de disparo.

Convergencia de precisión de IA
Qué salió bien
El nuevo sistema de precisión actúa de una manera más creíble, ya que rastrea la posición del objetivo y continúa disparando en esa posición hasta que el objetivo se mueve. Esto es preferible al antiguo sistema en el que el objetivo de la IA se balanceaba violentamente cuando intentaba fallar los objetivos estacionarios frente a ella.

Lo que no salió tan bien
La IA no es lo suficientemente precisa como para representar un nivel decente de amenaza para el jugador en ese momento. Y, el nuevo sistema tiende a fallar detrás del movimiento del objetivo en lugar de al frente, por lo que los jugadores no ven que les están disparando tanto.

Qué haremos de manera diferente en el futuro
Queremos mejorar la precisión en general y hacer que los diferentes NPC tengan una diferencia de precisión más notable entre la IA calificada y la no calificada. El sistema de precisión también se repetirá para que se sobrepase en lugar de sobrepasar el objetivo con más frecuencia.

Comportamiento de combate de la nave capital
Qué salió bien
Las naves capitales ahora ponen una buena cantidad de consideración en la distancia y la posición relativa cuando se enfrentan a otras naves. Las naves capitales sin cañones frontales intentarán acercarse lo suficiente como para utilizar todas sus torretas, mientras que aquellas con cañones frontales grandes intentarán mantenerse fuera del alcance del enemigo y utilizar sus poderosas armas de largo alcance.

Lo que no salió tan bien
La selección de tácticas no considera suficientemente la fuerza de la nave de la IA en relación con el objetivo. Por ejemplo, cuando el Idris está luchando contra una cañonera o una nave capital, intentará mantenerse a distancia y usar su cañón de riel. Esto a menudo tiene sentido, pero puede llevarlo a huir de las naves de combate más pequeñas que podría soportar fácilmente en una pelea de bofetadas a corta distancia.

Qué haremos de manera diferente en el futuro
Repetiremos la selección de tácticas para que la IA considere su propio nave y objetivo con más detalle que solo la clase de nave. Además, queremos permitir que los rasgos de los personajes del piloto también afecten el comportamiento de la nave capital.

Paneles de ascensor
Qué salió bien
Pusimos con éxito el trabajo preliminar para futuros paneles de ascensores (y otras pantallas rediseñables), haciendo que hereden sus estilos del sistema de tránsito y se puedan usar en cualquier forma de lienzo. Esto significa que todos los paneles futuros pueden usar los mismos dos archivos, pero aún lucir diferentes.

Lo que no salió tan bien
El sistema de tránsito es muy difícil de configurar y probar en su forma actual: el equipo de UI no pudo hacerlo funcionar correctamente y tuvo que confiar en Level Design para implementarlo. Sin embargo, la interfaz de usuario y el diseño de niveles no funcionaron en la función al mismo tiempo, lo que provocó que el trabajo comenzara y se detuviera en diferentes transmisiones y se perdieran errores. Los nuevos estilos de Building Blocks requieren mucho tiempo de implementación debido a la falta de herramientas y la imposibilidad de fusionar archivos.

Qué haremos de manera diferente en el futuro
Nos aseguraremos de que la función se desarrolle, implemente y pruebe de una sola vez en un flujo de funciones para que los errores se detecten y solucionen antes de que "finalice". También nos aseguraremos de que el equipo propietario de la función tenga tiempo para solucionar problemas de código como parte del ciclo de desarrollo de la función y de que el equipo de UI se centre en la UI.

Refinación basada en estaciones
Qué salió bien
Terminamos el ciclo de juego inicial para el refinamiento, completo con refinerías que tienen sus propias especializaciones de materiales, cargas de trabajo y la capacidad de refinar, recolectar y vender materiales refinados en varios lugares de la galaxia. Las cubiertas de la refinería en sí se ven espectaculares y la interfaz de usuario de la terminal de la refinería en sí está en un excelente lugar para expandir el ciclo de juego con muy poco en la forma de reelaborar las cosas, lo que debería significar una iteración más rápida en el futuro.

Lo que no salió tan bien
Nuestra planificación para cada paso fue extremadamente minuciosa; sin embargo, debido a varias situaciones fuera de nuestro control, no pudimos llegar a un punto lo suficientemente temprano en el que pudiéramos equilibrar el ciclo de la refinería de la manera que pretendíamos. Por lo tanto, presentamos otro conjunto de cambios ya previstos en la forma del reequilibrio minero inicial para compensar lo mejor que pudimos hasta que podamos llevar el equilibrio de la refinería al nivel que queríamos originalmente. Este reequilibrio minero tuvo la ventaja adicional de que hizo que el MISC Prospector fuera un poco más atractivo para que las personas comenzaran o alquilaran, además de brindar más experiencias de juego para Argo MOLE o para varios jugadores con Prospectors.

Qué haremos de manera diferente en el futuro
Haz que prueben el arte de la interfaz de usuario antes. Algunos jugadores no sabían con qué partes de la pantalla podían interactuar y esto nos habría permitido tener más tiempo para hacer cambios.

Refactor de interfaz de usuario de minería
Qué salió bien
Reelaboramos toda la interfaz de usuario de minería para que funcione con Building Blocks. Esto fue mucho más fluido de lo que cualquiera de nosotros podría haber esperado, ya que gran parte de la configuración del bucle del juego de minería realmente funcionó con Building Blocks directamente sin necesidad de muchas modificaciones en absoluto. Esto nos dio margen para agregar más a la interfaz de usuario de minería de lo que pretendíamos originalmente, lo que significa que no solo pudimos proporcionar una interfaz de usuario completamente nueva que es escalable en tres vehículos de minería diferentes, sino que mostramos esa escalabilidad iterando rápidamente en piezas de lienzo de interfaz de usuario. para apoyar los sistemas introducidos previamente. Esto incluyó carga volátil y agregó una pieza de bodega de carga completamente nueva que brinda a los jugadores la información que siempre quisimos brindar pero que nunca tuvimos la capacidad de hacerlo.


Lo que no salió tan bien
El pase inicial de la refactorización de la interfaz de usuario de minería fue más complicado de implementar que de construir, con diferentes vehículos que tenían diferentes espacios disponibles para la interfaz de usuario, lo que significa que se requirieron muchos ajustes detrás de escena para mostrar la interfaz de usuario en una forma cómoda. Esto todavía se está afinando y, con la tecnología futura próximamente, esperamos transmitir la interfaz de usuario de una manera un poco más atractiva visualmente que funcione mejor que la implementación actual.

Qué haremos de manera diferente en el futuro
En el futuro iteraremos más rápidamente en cosas como esta, ya que ahora tenemos una comprensión más sólida de Building Blocks y sus beneficios.

Todd Papy
Star Citizen Director en vivo
Pilar central del juego
Viga de tractor multiherramienta
El Tractor Beam de herramientas múltiples es una adición emocionante al 'verso' y es una pieza central de funcionalidad que desbloquea varios bucles de juego en los que estamos trabajando, como el transporte de carga y los espacios transversales de EVA . El caso de uso principal del Tractor Beam en Alpha 3.12 es permitir una recolección más fácil de cajas de carga en EVA, ya sea durante misiones perdidas en el espacio o para la recolección de botín posterior al combate de la nave Si bien en la superficie, Tractor Beam es una herramienta de apuntar y disparar, están sucediendo muchas cosas bajo el capó, y creo que el equipo hizo un trabajo fantástico al crear una función verdaderamente sistémica que es accesible y fácil de usar.

El primer desafío al que nos enfrentamos es que queríamos que funcionara en varias configuraciones de gravedad diferentes y que utilizara el peso de un objeto. Esto generó varios problemas, ya que en zero-g todo es ingrávido, por lo que significaba que potencialmente podía mover algo enorme que pesaba muy poco. Por ejemplo, una bola de poliestireno del tamaño de un planeta. Diseñamos el Tractor Beam en torno a dos conceptos básicos: volumen y fuerza. El volumen dicta el tamaño general del objeto que puede levantar, mientras que la fuerza dicta la cantidad de esfuerzo que debe aplicar la pistola para levantar el objeto. Esto significa que para cualquier elemento que tenga un colisionador de masa y física (que todos los elementos ya deberían tener), la fuerza requerida para levantarlo se calcula automáticamente utilizando la gravedad del entorno.

El segundo desafío fue cómo explicarle al jugador lo que puede y no puede levantar sin tener que hacer ADS en todo o, lo que es peor, usar prueba y error. Afortunadamente, la Multi-Tool ya tiene una pequeña pantalla en la parte posterior que nos permitió implementar una iconografía simple junto con un sistema de codificación de colores de semáforo. Esto significa que podemos mostrar claramente los cinco estados de un objeto con solo mirarlo:
El objeto se puede levantar
El objeto se puede levantar pero está fuera de alcance
El objeto es demasiado pesado
El objeto nunca se puede levantar
Viajarás al objeto

W i bien que hicimos proporcionar información adicional en las ADS ver, todo lo que necesita saber es en la parte posterior de la herramienta y, estaba muy satisfecho hemos sido capaces de extraer tanta información a una pantalla tan pequeña.

Lo que no salió tan bien
Al planificar cualquier función, desea identificar la experiencia principal y luego describir cualquier mecánica secundaria que mejoraría esa experiencia. Por ejemplo, una mecánica de salto en sí misma es una característica independiente, pero puedes decidir que el control en el aire (una mecánica secundaria) mejora esa experiencia central. Con el Tractor Beam, nos sentamos e identificamos la experiencia central de poder manipular objetos y usarlo como un gancho de agarre en EVA , y creo que cumplimos con esto. Pero había algunas mecánicas secundarias que me hubiera gustado enviar y que se nos acabó el tiempo. Específicamente, permite la manipulación de su trayectoria usando los propulsores de su traje cuando usa la funcionalidad de gancho de agarre en gravedad cero.

Desafortunadamente, los dos sistemas no funcionaron bien juntos, y la fuerza utilizada para arrastrarlo anuló cualquier fuerza utilizada por los propulsores del traje. Tampoco ayudó que EVA también se cambiará para usar IFCS al mismo tiempo y esto nos llevó a tener que hacer una llamada prioritaria para enfocarnos en la experiencia central y asegurarnos de que estuviera lo más pulida posible para su lanzamiento. Esto sucede todo el tiempo con las características y es la naturaleza del desarrollo del juego, pero fue una pena que se perdiera la primera iteración. Agregaremos esta funcionalidad en una versión posterior.

Qué haremos de manera diferente en el futuro
La entrega de una función para su lanzamiento requiere que muchos equipos diferentes se coordinen juntos, desde VFX hasta Audio y el equipo de funciones que trabaja en la funcionalidad. Una de las cosas más importantes que estoy tratando de mejorar es darles a los diseñadores de misiones más tiempo para permitirles integrar todas estas características diferentes en el verso de una manera significativa. Si ha leído mis autopsias anteriores, probablemente verá una tendencia de que esto es algo que estoy tratando de mejorar activamente, pero como están involucrados múltiples equipos y horarios, se necesita un poco de tiempo para reajustarlo. Si pudiera retroceder en el tiempo, probablemente habría intentado poner una versión simple en manos de los diseñadores de misiones / niveles antes para que pudieran haber jugado con ella un poco más.

Puesta a cero de armas
Qué salió bien
La puesta a cero de armas, como sugiere el título, te permite poner a cero armas a diferentes rangos, lo que te permite disparar con precisión a distancias mucho mayores. Esto significa que el visor considera la caída de la bala en un rango específico y le permite ajustar la mira para que aún pueda apuntar su retícula al objetivo. Es decir, no tienes que apuntar por encima del objetivo. Ya tenemos muchos ámbitos disponibles y el primer desafío fue decidir qué ámbitos deberían poner a cero y luego decidir si deberían poner a cero automáticamente o manualmente. Esto llevó a una discusión mucho más amplia en torno a los fabricantes y sus características específicas, como alta o baja tecnología. Si bien el equipo podría haberse centrado en la función y haberla lanzado, también ha entregado un plan a largo plazo para los accesorios de alcance no solo para los fabricantes actuales sino también para los futuros.

Esto es algo en lo que creo fundamentalmente: que aunque estamos trabajando en un producto en vivo, deberíamos tomar decisiones sobre la experiencia final en el juego lanzado. A veces eso es difícil, ya que puede significar que ciertas características no se ven de la mejor manera en la primera inspección o que los jugadores no las comprenden a corto plazo. Pero es mi trabajo asegurarme de que estamos trabajando hacia la visión final y el equipo hizo un trabajo fantástico al proporcionar una función que es divertida de usar pero escalable en el futuro.

Lo que no salió tan bien
Esta fue la primera característica en la que trabajó uno de los miembros más recientes de nuestro equipo. Como tal, nos aseguramos de que tuviera suficiente tiempo para entregarlo mucho antes del lanzamiento real. De hecho, la funcionalidad (no las imágenes) se entregó el trimestre anterior e hizo un gran trabajo. Ahora, en la mayoría de los casos, esto es fantástico, ya que significa que podemos concentrarnos en la experiencia y asegurarnos de que sea de la más alta calidad. Sin embargo, en este caso, debido a otras prioridades y esto se hizo con mucha antelación al lanzamiento, el equipo de pruebas no se centró por completo, ya que estaban (legítimamente) ocupados comprobando que las cosas se pusieran en marcha de forma inminente. Desafortunadamente, esto significó que se pasó por alto un caso de borde fundamental hasta justo antes del lanzamiento, que era que la puesta a cero no funcionó cuando se difundieron los parches físicos para el entorno.

Déjame explicar. Cuando un personaje aparece en un planeta, aparecen una serie de parches (cuadrados) a su alrededor en tamaños cada vez mayores. Estos parches cubren la calidad de renderizado (gráficos) y la colisión física, y los parches más alejados tienen menos detalles y, finalmente, ninguna colisión (ya que la física es relativamente cara). Ahora, cuando te mueves, los parches se actualizan dinámicamente, pero no es uno a uno. Por lo tanto, un parche en el que podría haber estado todavía puede tener su colisión, ya que es posible que desee volver allí y es más eficaz mantenerlo allí a corto plazo que seguir cargándolo y descargándolo. En este caso, sin embargo, significó que cuando un diseñador cargó en el editor para probar la función, se cargó el parche y luego se alejaron 2 km para probar la puesta a cero del arma y funcionó. Aunque si un jugador nunca hubiera ido a la posición original, no habría colisión y, por lo tanto, el visor no tendría nada contra lo que probar. Esto significaba que en condiciones normales de juego no funcionó como se esperaba, por lo que tuvimos que volver a autorizar el código de puesta a cero del arma para probarlo con la geometría de renderizado en lugar de la física. Si bien este cambio no fue importante, no fue ideal, ya que habíamos planeado trabajar en otras funciones.

Qué haremos de manera diferente en el futuro
Si pudiera retroceder en el tiempo, definitivamente me aseguraría de que la función haya sido probada a fondo cuando se haya completado en lugar de esperar a que el proceso sea más tradicional. Si bien no afectó el lanzamiento de la función, sí tuvo efectos secundarios para el trabajo futuro, ya que tuvimos que cambiar las prioridades durante el trimestre.

Rifle de francotirador Gemini A03 y Behring FS-9 LMG
Qué salió bien
Al igual que con todas las armas que agregamos al juego, siempre debemos asegurarnos de que encaja en la matriz de armas existente y ofrece algo único que aún no existe. Con el rifle de francotirador Gemini A03, la intención era hacer un rifle de tirador liviano y sensible con un calibre más bajo que sus contrapartes más pesadas pero de alta velocidad y precisión. Creo que el equipo realmente cumplió con esa intención y logró un buen equilibrio entre los rifles de francotirador de alto calibre como el P6-LR y las armas más orientadas al asalto como el Gemini S71. Si bien el A03 fue una adición simple, el Behring FS-9 fue un poco más complicado. Las LMG como categoría de arma no están en un gran lugar en este momento, ya que son superadas por SMG/ escopetas a corta distancia y superadas por rifles de asalto a media y larga distancia. Esto es algo de lo que somos muy conscientes y hemos estado trabajando entre bastidores para mejorar. El Behring FS-9 establece el estándar de lo que queremos que sean las LMG : ametralladoras de alta capacidad que permiten a los jugadores suprimir un área sin una gran pérdida de precisión.

Lo que no salió tan bien
Mientras trabajábamos en el FS-9, también estábamos trabajando en las intenciones de diseño para todas las demás LMG para poder ofrecer una actualización general en una versión. Desafortunadamente, nos quedamos sin tiempo con las armas existentes, aunque logramos hacer algunos ajustes para aumentar su efectividad. Planeamos actualizar las LMG existentes para elevarlas al mismo nivel de calidad que el FS-9, pero eso significa que a corto plazo es muy superior a las otras armas de la misma categoría. Pero como mencioné anteriormente, siempre daré prioridad a las decisiones en torno a cuál queremos que sea el objetivo final para que avancemos constantemente.

Qué haremos de manera diferente en el futuro
Tenemos un plan para revisar todas las categorías de armas y, con suerte, podrás ver que cada arma que lanzamos mejora ligeramente las anteriores. Con esta intención, habría agregado más tiempo para pulir las LMG existentes, ya que me hubiera gustado lanzarlas todas juntas. No importa la experiencia que tenga, siempre está aprendiendo y esto es algo que implementaré para futuras armas.

Richard Tyrer
Core Director de juego
Ubicaciones
Cubiertas de refinería de la estación espacial
Qué salió bien
Para este lanzamiento, pudimos introducir cubiertas de refinería en algunas ubicaciones específicas de estaciones espaciales. Estos espacios están temáticos en torno a los bucles de juego de minería y refinación y también sirven como ubicación para futuras oportunidades de juego. Dentro de la plataforma de la refinería, creamos un espacio específico para refinar y procesar junto con un espacio de tienda y gremio debajo.


Después de ver la respuesta a las cubiertas de carga y los interiores de la nueva estación espacial en Alpha 3.11, estuvimos de acuerdo con los comentarios sobre los jugadores que querían ver una conexión más visible con el exterior para comprender físicamente dónde se encuentran en la estación. Aunque estábamos bastante lejos en el desarrollo del interior de la plataforma de la refinería, pivotamos y adaptamos el espacio para incluir la mini plataforma de observación junto a los vestíbulos de los ascensores. Visualmente, habíamos querido explorar una experiencia de estación espacial más enfocada hacia la actividad industrial durante algún tiempo, incluida la composición global de la estación en el interior caluroso y ruidoso.

Lo que no salió tan bien
Fue una pena no ver el lanzamiento de cargas de NPC específicas con las cubiertas de la refinería o poder expandir algunos de los usables específicos. Sin embargo, todos están planeados, por lo que esperamos verlos pronto en línea.

Qué haremos de manera diferente en el futuro
Como se mencionó anteriormente, presentamos la plataforma de visualización bastante tarde en el proceso, por lo que podríamos haber diseñado un espacio superior con esto en mente durante el concepto y el whiteboxing.

Mejoras y pulido de Stanton Planet
Qué salió bien
Continuando con las mejoras planetarias realizadas a lo largo de 2020, esta fue la primera oportunidad que tuvo el equipo para presentar los flujos de trabajo nuevos y mejorados desarrollados al crear los planetas y lunas de Pyro en Stanton.


La mejora del flujo de trabajo incluyó tener el tiempo y el enfoque para profundizar en el proceso de pintura global. Para planetas como Stanton I y IV, la pintura global se rehizo por completo para ser más precisa a los parámetros de temperatura y para tener una mejor combinación y distribución de matices. Como segunda parte de la pintura, todos los objetos presentes y los conjuntos de reglas de distribución se realizaron desde cero. En general, el enfoque fue hacer más con menos. Entonces, en lugar de usar muchos tipos de geología en el mismo espacio, solo use uno o dos que funcionen muy bien juntos. El resultado final es algo mucho más realista y natural. Un buen ejemplo de esto está en Daymar. Otra área que queríamos mejorar era el aumento del uso de objetos de dispersión terrestre para complejizar la lectura del terreno. Combinamos una mezcla de activos geológicos como placas, pedregal,

Además, algunos paquetes de geología sobresalientes se convirtieron para usar el sombreador orgánico y se procesaron correctamente a través de Houdini como parte de nuestra tubería.

Algunas características tecnológicas nuevas se pusieron en línea durante este lanzamiento que estábamos emocionados de aprovechar, la primera fue el desplazamiento del terreno que reemplaza a POM . Por lo tanto, ahora puede ver cómo la geometría del terreno se tesela y se desplaza, lo que proporciona una profundidad real e intersecciones más complejas con los objetos. La segunda característica es la acumulación de bioma, lo que significa que los activos pueden recibir de forma procedimental una fina capa de material en su superficie superior, según el bioma. Por ejemplo, la arena se acumula en la cima de las rocas en Daymar.

Lo que no salió tan bien
Mientras intentábamos cerrar el año y llegar al lanzamiento de Alpha 3.12, algunas lunas no pudieron llevarse al nivel de pulido que queríamos. Además, como parte de la introducción de nuestros nuevos flujos de trabajo y metodología en el sistema Stanton, notamos que los estilos visuales entre algunas lunas se están acercando demasiado y estamos perdiendo algo de diversidad.

Qué haremos de manera diferente en el futuro
Más activos ayudarán a reducir la fatiga del arte y mejorar la diversidad visual, por lo que, entrando este año, estamos invirtiendo tiempo y energía en más paquetes de activos.

Paisajismo espacial del sistema Stanton
Qué salió bien
Todos estábamos realmente emocionados de poder mostrar la tecnología de la nube de gas como parte de la PU en Alpha 3.12. Muchos equipos hicieron un gran trabajo para crear esta nueva función, por lo que el proceso consistió en establecer un equipo dedicado a crear contenido para Stanton y luego comenzar a ver qué podíamos hacer por los puntos de Lagrange.

Teniendo en cuenta que esta fue la primera versión de lanzamiento de la tecnología, creo que creamos una variedad de escenarios visuales para mostrar el potencial de la tecnología.

Lo que no salió tan bien
Como esta fue la primera versión, obviamente había mucho que resolver en términos de rendimiento, y hay mucho que podemos hacer en términos de refinamiento de la canalización. También hay algo de ruido visible en algunos escenarios de iluminación que nos gustaría reducir en el futuro según lo permita el rendimiento.

Qué haremos de manera diferente en el futuro
Ya estamos mejorando nuestro flujo de trabajo de desarrollo y buscando formas de mejorar el proceso. Estamos explorando cómo podemos unir el paisaje espacial de fondo en formas más basadas en minisistemas, lo que luego conduce a bolsas de gas volumétricas más pequeñas. Para futuras oportunidades de juego, estamos buscando fomentar el juego de riesgo / recompensa dentro de las bolsas de gas con elementos como rayos, radiación, rangos de temperatura y manejo de vuelo.

Ian Leyland
Star Citizen Director de arte
Tecnología
Para Alpha 3.12, el equipo de gráficos se centró principalmente en mejorar la estabilidad y corregir errores con las diversas funciones gráficas utilizadas en la versión. Muchas de las correcciones de errores relacionadas con la introducción de nubes de gas, como arreglar un patrón de oscilación visible cuando el sol está oscurecido por una nube y evitar que las nubes de gas y las partículas se recorten dentro de las naves espaciales, mejorando los sistemas de selección volumétrica y de partículas. Tales problemas eran esperados, pero en gran parte inevitables porque, aunque la tecnología se ha utilizado ampliamente en el desarrollo de SQ42, el arte y los escenarios son bastante diferentes en el PU. Además, la naturaleza sandbox de la PU y las pruebas exhaustivas que recibe significaron que se descubrieron o dieron prioridad a muchos problemas previamente desconocidos.

El equipo también se las arregló para resolver docenas de otros errores, que van desde sombras emergentes hasta exposición de cámara demasiado brillante cuando se transmite un planeta. La proporción de tiempo dedicado a la corrección de errores en comparación con las nuevas funciones fue mayor de lo que nos hubiera gustado idealmente, pero Siempre se hace hincapié en la estabilidad y la calidad al final del año y el trabajo de funciones ya se ha reanudado, por lo que esto no es motivo de preocupación. A pesar de la desaceleración en el trabajo de las funciones, logramos mantener un buen progreso en el nuevo renderizador Gen12, que será nuestro enfoque principal para principios de 2021.


El equipo de física trabajó en el prototipo volumétrico de cuerpo blando, así como en la representación relacionada de la deformación volumétrica. Además, se realizaron varias optimizaciones en física. Por ejemplo, mejoramos el enhebrado de varios subsistemas, agregamos consultas de cuadrículas espaciales más rápidas, eliminamos la contención para acceder a la cola de comandos local y eliminamos la contención para las funciones de paso de actor / entidad viviente (mejorando el rendimiento de paso de la entidad viviente en un factor de 2x - 5x). También implementamos una mejor manera de pre-fisicalizar los parches de terreno planetario utilizados para las comprobaciones de colisión. Con respecto a la detección de colisiones, también solucionamos un problema de larga data que podría introducir contactos fantasmas adicionales lejos de donde se estaban procesando los contactos reales. Además, se realizaron mejoras en la cola de eventos.Se mejoró la compatibilidad con SDF y se inició una investigación sobre mejoras en la configuración de la vegetación de flexión táctil.

En el renderizador, continuamos con nuestra transición Gen12 en curso y la refactorización relacionada. Por ejemplo, agregamos un conjunto de características parametrizables para la canalización diferida, implementamos actualizaciones del conjunto de recursos por objeto (incluida la actualización RTT para pinceles) para la representación de escenas Gen12 y el almacenamiento en caché del estado de la canalización heredada (para guardar la API de DXllamadas mientras todavía estamos en plena transición a Gen12). En el sistema de sombreado, limpiamos todo el código de recarga de sombreadores, lo que mejorará la edición de sombreadores durante el desarrollo y dará una respuesta mucho mejor al cambiar la configuración de especificaciones del sistema (por ejemplo, configuraciones de gráficos que requieren el uso de diferentes combinaciones de sombreadores). También comenzamos una refactorización más grande del sistema de backend de la caché del sombreador, ya que está bastante desactualizado y es una fuente constante de dolor con respecto al mantenimiento y la aptitud de Gen12. Se realizaron varias optimizaciones en el código del renderizador. Por ejemplo, se simplificó y optimizó la forma en que se cargan las constantes de material en la GPU .

En el lado de los gráficos, se proporcionaron varias correcciones para la profundidad de campo. El sombreador de cabello recibió varias mejoras, como la capacidad de deshabilitar los reflejos especulares en las pestañas, la oclusión de límites mejorada en las líneas del cabello, la compatibilidad con las luces ambientales en el sombreado hacia adelante y la calidad del cabello mejorada durante los cortes de la cámara. Se mejoró la aproximación de doble lóbulo para el sombreador de piel y el sombreador de ojos también recibió un par de mejoras. En lo que respecta a las atmósferas, las nubes y el raymarcher unificado, las mejoras mencionadas en la autopsia anterior ahora están disponibles en Alpha 3.12. Con eso fuera del camino, la mayor parte del tiempo se centró en la representación volumétrica de la nube. Se implementó el borrador inicial del renderizador en la nube y el trabajo sobre sombras volumétricas de nubes avanzó a buen ritmo. Se iniciará el trabajo de mejora de la configuración de la nube local.


Para el sistema de motor central, implementamos una ruta de selección de zona dinámica en el sistema de zona. También arreglamos algunos errores de selección relacionados con la distancia de visualización relacionados con objetos del tamaño de un píxel que se incluyeron en Alpha 3.11. La gente ya ha notado que ahora pueden ver a los jugadores a más de 1000 metros de distancia en lugar de solo unos cientos más o menos. Se proporcionaron muchas correcciones de errores y mejoras para las áreas de visualización, como una solución para la transmisión de mallas para áreas de visualización animadas y la capacidad de agregar áreas de visualización a CGAarticulaciones. El sistema de la entidad recibió varias mejoras y optimizaciones para evitar actualizaciones y búsquedas innecesarias. De manera similar, el administrador agregado de la entidad recibió optimizaciones de bajo nivel para mejorar el equilibrio del trabajo y reducir el uso de la memoria y la contención al trabajar con burbujas de entidad. También se realizaron algunas mejoras menores en el programador de actualizaciones de componentes de la entidad. Se ha mejorado la lógica de selección del árbol de radix, con su lógica de subprocesamiento ajustada para reducir la contención y SIMDSe implementó el sacrificio selectivo para verificar hasta cuatro burbujas frente a objetos por nodo. Con respecto al rendimiento, el progreso continúa en el perfilador del motor, que experimentó muchas mejoras. Pronto comenzará el trabajo en un generador de perfiles de muestreo en tiempo real basado en seguimientos de eventos. Se implementaron varias optimizaciones en el sistema de entidad, actualizaciones de componentes y sistema de zona. Con base en la telemetría de la PU y la PTU , continuamos nuestras investigaciones en curso sobre el uso de la memoria. Como tal, el asignador de memoria de todo el motor y el sistema de seguimiento de memoria, incluida su cadena de herramientas, se refactorizaron y mejoraron sustancialmente. Para proporcionar un aumento de rendimiento adicional a nuestros servidores, Linux DGSse cambió a un ejecutable monolítico para permitir que el compilador genere un mejor código (en particular, el acceso al almacenamiento local de subprocesos). Como parte de nuestra iniciativa para crear un sistema de regresión de rendimiento, también agregamos una prueba de esfuerzo para la transmisión de contenedores de objetos.

Con respecto al manejo de fallas, ahora capturamos una pila hexadecimal del hilo de renderizado y la incrustamos en mini volcados que usted (opcionalmente) nos envía en caso de que el juego se bloquee. Esto nos permite recuperar la pila de llamadas del hilo de procesamiento completo durante la depuración post mortem sin la necesidad de binarios de terceros (que pueden ser parte de la pila de llamadas o el controlador de video) para desenrollar completamente la pila. Esto ahorra bastante tiempo ya que no tenemos que descargar los diversos controladores que usan los jugadores.

En el lado de la animación, arreglamos el código para que las formas de combinación de personajes y la plataforma de iluminación dinámica no cambien demasiado tarde en cada corte de cámara al renderizar escenas de corte.

Por último, se habilitó la compatibilidad con C ++ 14 para la totalidad del editor del servidor cliente y los proyectos de herramientas relevantes.

Tecnología en línea
Marco de prueba de equilibrio de carga
El calentador de pestilencias para Alpha 3.12 recibió importantes actualizaciones. En primer lugar, el calentador ahora usa el nuevo sistema de identificación JWT que le permite buscar muchas fichas con fines de suplantación de identidad muy rápidamente. Esto tiene 10 veces el rendimiento de instancias más cálidas que podemos ejecutar al mismo tiempo.

Se agregó un subsistema importante que permite que el calentador se conecte como un servicio a la puerta de enlace de difusión, lo que permite ejecutar escenarios de carga que se coordinan como un cliente conectado a través del hub y como un servicio en la red de difusión.

Mejoras de simultaneidad de backend
Pudimos aumentar el rendimiento del servicio variable, las cargas y el servicio de caché de persistencia principal. La estabilidad del backend aumentó enormemente, superando el rendimiento y la confiabilidad que teníamos en versiones anteriores. Nuestro código de red de bajo nivel se actualizó para mejorar el rendimiento, la escalabilidad y la solidez. También realizamos varias correcciones y optimizaciones en el servicio de transacciones, los alquileres y nuestro procesador de derechos.

Registro unificado y centralizado
Con nuestro nuevo sistema de registro centralizado unificado, todos los servicios envían mensajes JSON formateados a una base de datos Elasticsearch centralizada. Cada evento de registro está etiquetado y los datos dinámicos como ID de cuenta, ID de jugador, etc. se extraen en campos con nombre, lo que hace que la búsqueda de eventos o campos específicos, como un "AccountID", sea muy eficiente. Esto permite a los desarrolladores acceder fácilmente a los registros desde un lugar centralizado y rastrear mensajes complejos y eventos que ocurren entre múltiples servicios.

Tecnología persistente
Creación de entidades y desacoplamiento de generación
En preparación para la transmisión persistente, el proceso de creación de la entidad se desacopló del desove de la entidad. Esto nos permite "sembrar" el estado inicial del universo en la base de datos persistente mediante la creación de todas las entidades dinámicas antes de la simulación. Los procesos de DGS luego transmitirán entidades persistentes (generación / desaparición) de esa base de datos durante la simulación. Este es un trampolín importante para un universo completamente persistente.

Colas de aparición paralelas
Como optimización, introdujimos varias colas de generación paralelas en cada servidor de juego. Esto nos permite generar múltiples ubicaciones distintas (como Lorville y New Babbage) en paralelo en subprocesos separados en el mismo servidor. Las versiones anteriores tenían una sola cola y, por lo tanto (en este ejemplo) no comenzaríamos en New Babbage hasta que Lorville estuviera completamente generado. En servidores ocupados, esto realmente puede reducir el tiempo de espera en algunos casos. Por ejemplo, cuando se generan oleadas de naves de IA o reaparecen en un hab.

Tecnología de red
Hora y desincronización
Cómo mide el motor el paso del tiempo se sometió a una revisión completa. Se mejoró la precisión tanto en la medición del tiempo como en su sincronización entre servidor y clientes. Se cambió la forma en que el motor usa el tiempo para actualizar su lógica y la simulación física para eliminar errores que podrían hacer que el tiempo de simulación pase de manera diferente en el servidor y los clientes. También se corrigieron muchos errores más pequeños que habían causado que los errores de sincronización crecieran en servidores de larga ejecución. La sincronización de la red de vehículos y objetos físicos se actualizó para aprovechar al máximo las mejoras. El resultado acumulado de todos estos cambios fue una reducción significativa de los problemas de latencia y desincronización en muchas áreas, incluso en condiciones de prueba rigurosas para el rendimiento de la red y el servidor. Además de mejorar la experiencia general del jugador,

API DE autoridad
En preparación para el mallado del servidor, el equipo realizó un barrido en las tareas restantes para convertir el código a la API de autoridad . Durante los últimos 12 meses, todos los equipos han realizado un esfuerzo coordinado para actualizar el código del motor del final del juego a este nuevo sistema. Gracias a su trabajo, la gran mayoría de estas tareas se han completado. Con un impulso concertado, hemos reducido la cantidad de tareas restantes a un solo dígito.

Flujo de conexión
En una malla de servidores, un cliente puede conectarse a muchos servidores diferentes durante una sesión de juego. Parte del trabajo hacia el mallado del servidor requiere separar el proceso de conectar un cliente a un servidor en distintas etapas. Estas etapas se pueden ejecutar de forma independiente sin necesidad de que el cliente abandone por completo su sesión de juego existente. Se ha logrado un progreso significativo en este sentido, aunque queda más trabajo por hacer.

Marco Corbetta
VP de tecnología


¡Nos vemos en el 'Verso!
Creemos que brindar este nivel de conocimiento sobre nuestro proceso de desarrollo es muy valioso, especialmente cuando puede leer los procesos de pensamiento, las reflexiones y los aprendizajes directamente de nuestros desarrolladores senior. Como se mencionó la última vez, estamos comprometidos con el desarrollo transparente y continuaremos proporcionando parches post mortems trimestrales en el futuro.
Volver arriba
Permisos de este foro:
No puedes responder a temas en este foro.