❇️ Star Citizen - Respuesta de Dev #1
Saul "Havok" Specter
Selección periódica de respuestas ofrecidas por desarrolladores de Cloud Imperium Games resolviendo cuestiones de interés.
🔹 Número de artistas vs número de desarrolladores en Star Citizen
13 Agosto 2020
¿Qué porcentaje del equipo de CIG son artistas y qué porcentaje son Devs?
No sé directamente el número de artistas, pero definitivamente hay más artistas que programadores, sin embargo eso no es exclusivo de nuestro estudio, la mayoría de los estudios hoy en día son así dada la mayor fidelidad en los juegos modernos. Tenemos un número bastante grande de programadores en el proyecto, alrededor de 90 en total, incluyendo desarrolladores en el juego así como dev ops. Sin embargo, siempre estamos buscando expandirnos, y si miras la página web de la compañía verás que hay puestos de programador disponibles para todos los estudios. La compañía en su conjunto se acerca (o quizás ya hemos superado) a unos 600 empleados a nivel mundial en todos nuestros estudios. También para los que estaban buscando, Linkedin no es un buen recurso para medir los niveles de empleados porque mucha gente no tiene cuentas o incluso si las tienen no las mantienen al día.
@CIG_ChadMcKinney
17 Agosto 2020
https://robertsspaceindustries.com/spectrum/community/SC/forum/3/thread/only-90-developers/3318081
¿Sólo 90 developers? Si CIG tiene en torno a 600 empleados, me sorprende que solo 90 sean devs.
Otras personas han mencionado esto, pero para ser claros dije 90 programadores, no 90 desarrolladores. Los artistas son desarrolladores, también lo son los diseñadores, el equipo de audio, la narrativa, la animación, etc. etc., esencialmente cualquiera que trabaje directamente en el juego es un desarrollador, a diferencia de algo como el marketing o las instalaciones que son esenciales pero no trabajan directamente en el desarrollo del juego en sí. Tenemos más de 90 desarrolladores, muchos más y los desarrolladores en CIG son la mayoría del personal.
@CIG_ChadMcKinney
🔹 Entity Component System
14 Agosto 2020
¿La arquitectura de Entity Component System es multihilo?
Tenemos un sistema de actualización multihilo para los componentes, además de la reproducción asíncrona y en hilo. Nuestro motor es el motor de juego más multihilo que he visto, especialmente en el lado del código del juego. Si miras otros motores populares como Unreal y Unity, su principal bucle de juego sigue siendo de un solo hilo. Mike Acton está trabajando duro para cambiar eso para Unity con el empuje del Data Oriented Tech Stack (DOTS) lo cual me alegra ver, pero por ahora es más una alternativa en desarrollo que la manera principal en que la gente usa su motor.
@CIG_ChadMcKinney
🔹 Guardar artículos
13 Agosto 2020
https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/stowing-items/3311473
¿Por qué tarda tanto en guardar los artículos? Cuando quiero guardar un objeto que recojo del suelo en el inventario tarda mucho y es molesto.
Es un efecto secundario de la baja velocidad de fotogramas del servidor, la sobrecarga del servicio y las peticiones asincrónicas. Estamos trabajando duro para mejorar estos puntos actualmente.
@CIG_ChadMcKinney
🔹 Spawn con el server meshing implementado
14 Agosto 2020
¿Cómo haremos respawn cuando llegue el server mershing?
Definitivamente hay interrogantes sobre el diseño, pero hay que considerar algunas cosas:
1.- El universo es muy grande, y tenemos más que suficientes inmuebles para todos en el juego.
2.- Los hangares de los jugadores, los Habs y los Outposts serían una cosa, y así no todos los jugadores harían spawn en las principales zonas de aterrizaje
3.- Las zonas de aterrizaje tendrán habitaciones alquilables que son efectivamente como contenedores de carga, son modulares, de modo que los jugadores que se conecten se colocarán en el espacio disponible.
4.- Los jugadores pueden y seguirán pudiendo entrar y salir desde las camas de las naves.
@CIG_ChadMcKinney
🔹 Tecnología de gases
14 Agosto 2020
¿Por qué la tecnología de nubes de gas no puede ser usada para una implementación V1 de Crusader?
Esto fue algo que intentamos explorar y sobre lo que hicimos pruebas, pero al final, como esta tecnología no fue construida para ser usada de esta manera, nos encontramos con problemas. Para crear una VDB (ntd: un archivo de datos volumétricos) tan grande como debería ser, incluso para encerrar a Crusader, no fui capaz de generar una esfera con una resolución lo suficientemente alta como para no colapsar mi PC. Incluso si lo hubiéramos logrado, había una alta probabilidad de que pudieras ver cada vóxel individual y, en última instancia, no darle a Crusader la justicia que se merece.
¿Pero por qué no hacer parches más pequeños y unirlos en el motor? Buena pregunta, mi buen amigo, la cantidad de parches pequeños para poner uno al lado del otro sería enorme. Pero también se podrían ver las costuras de los parches al ser colocados uno al lado del otro.
Así que no es que no queramos, es sólo que la tecnología de las nubes de gas no estaba pensada para ello. Pero para lo que estaba destinada, que es la exploración del espacio, es fantástica y se siente como si realmente se expandiera al universo. Y también es divertida de hacer.
@Medic-CIG
🔹Aumento del número de jugadores
13 Agosto 2020
En el reporte mensual de julio se mencionan mejoras en la tecnología para aumentar el número de jugadores, ¿podemos saber más sobre esto? ¿Ocurrirá antes de implementarse el server meshing? ¿Cuánto sería la mejora?
Ese párrafo se refiere al número total de jugadores simultáneos en todas las instancias del servidor, no a la capacidad de jugadores del servidor. En otras palabras, esos cambios ayudarán a los servicios de backend a escalar para manejar la carga de más servidores de 50 jugadores corriendo al mismo tiempo. Esto debería ayudar a reducir el tiempo y la frecuencia con la que los jugadores tienen que esperar en una cola de inicio de sesión antes de poder jugar en momentos de mucha actividad. Estos cambios también pueden ayudar a reducir la latencia en algunas interacciones con los servicios de backend, como aceptar misiones, el spawn de vehículos y el comercio. No sabremos con certeza cómo de efectivos serán esos cambios hasta que los pongamos en marcha para nuestros backers y monitoricemos su rendimiento bajo una gran carga.
El aumento de la capacidad de jugadores por servidor requerirá una mayor optimización de los propios servidores de juego.
Pero ¿no son actualmente los servidores independientes de otros?
Sí, los servidores de juego individuales son independientes unos de otros y así será hasta que se implemente el server meshing. Sin embargo, todos estos servidores de juego hacen uso de un conjunto compartido de servicios de backend, por lo que ser capaz de escalar estos servicios para manejar una mayor concurrencia de jugadores es una parte importante de la ecuación global.
¿Los servidores adicionales sólo se están utilizando como una solución provisional para los problemas actuales? ¿O es esto parte del proceso de avanzar hacia un eventual server meshing?
El server meshing unirá los servidores del juego para formar instancias con más jugadores. A su vez la optimización de los servidores de juego nos permitirá aumentar la capacidad de los jugadores en cada uno de ellos. Por último escalar los servicios de backend a un mayor número de jugadores simultáneos nos permitirá tener más servidores en la red. Así que todos estos esfuerzos diferentes se dirigen hacia el mismo objetivo.
@cjohnson
🔹Signed Distance Field
14 Agosto 2020
¿Alguna actualización sobre el Signed Distance Field? ¿Explicación de cómo se pretende utilizar?
Sólo puedo hablar desde el punto de vista de VFX, así que tenedlo en cuenta.
El SDF es sólo un tipo de datos pero uno realmente genial. Los Distance Fields o "campos de distancia" se generan para un objeto específico y los datos almacenados en ellos están hechos a la medida de ese objeto. Así que un campo de distancia de una Gladius sería una textura 3d donde cada píxel almacena la distancia más cercana a la superficie de la Gladius. ¿Cómo pueden los píxeles almacenar la distancia? Bueno, cada píxel puede almacenar hasta 4 números (rojo, verde, azul, alfa). Normalmente estos números representan colores, pero en los juegos nos saltamos muchas reglas y usamos texturas para almacenar datos. Para la distancia sólo necesitamos un número y es por eso que las texturas SDF sólo necesitan un único canal. La palabra Signed o "Firmado" se refiere al hecho de que el píxel puede almacenar valores por debajo de 0 (como -42.123 o -0.123123). Las texturas sin signo sólo pueden almacenar valores >=0. Y sí, los píxeles negativos no se pueden mostrar en tu pantalla (a menos que tengas un monitor de la NASA que pueda mostrar luz negativa).
Bien, pero ¿cómo los usamos? Nuestras partículas pueden colisionar con los SDFs. Esto es genial porque perdimos mucha funcionalidad de colisión cuando cambiamos del sistema de partículas de la CPU al de la GPU. No porque estuviéramos holgazaneando, sino porque es realmente difícil hacer colisiones con el entorno para cualquier sistema de partículas de la GPU (no sólo el nuestro, sino cualquier sistema de partículas en los juegos en general). Tienes que tener alguna forma de representación geométrica a la que la GPU pueda acceder fácilmente y las texturas son el equivalente al billete dorado de la fábrica de colisiones de partículas de Willy Wonka. Tuvimos colisión del búfer Z durante bastante tiempo pero eso tiene la limitación de no poder colisionar con objetos que no están renderizados (incluyendo la parte trasera de la geometría).
Debido a que podemos colisionar con los SDFs, podemos utilizar la funcionalidad del sistema de partículas existente para generar otras partículas en el punto de colisión. Las partículas también pueden evitar los SDF (tratando los SDF como una fuente de fuerza negativa), ser atraídas por ellos o fluir a lo largo de la superficie. La nueva entrada atmosférica utiliza mucho esto. Literalmente estamos disparando partículas invisibles a una nave y cuando colisionan engendramos partículas de entrada atmosférica realmente visibles y las dejamos deslizarse a lo largo de la superficie.
¿Qué más? Definitivamente me perdí algunos casos de uso de los SDF que tenemos en el VFX, ya que no consulté al equipo antes de responder a esta pregunta, pero... ¡el cielo es el límite! Es un dato muy bonito, compacto, eficiente y útil y estoy bastante seguro de que con el tiempo encontraremos otros casos de usos locos para ellos. Hay mucho que hacer con los SDF en Inteligencia Artificial y en la parte física de las cosas. Pero no soy un experto en eso, así que me quedaré callado!
@mpiatek-cig
24 Agosto 2020
Me entra curiosidad sobre cómo afectará la tecnología SDF a los escudos.
1 ¿Se eliminarán los agujeros en los escudos?
2 ¿Alguna novedad extra de la vieja tecnología de escudo vs SDF Shield?
3 ¿Nuevas armas de proyectiles posibles? ya que de tu explicación parece que esta nueva tecnología podría potencialmente abrir una nueva forma de colisión y por lo tanto nuevas armas o tipo de proyectil como las armas Beam (ntd: rayo laser continuo)?
4 ¿Proyección de escudo? es decir, una nave de apoyo dedicada? que puede proyectar un escudo o algo?
1) No estoy seguro, es una pregunta para el equipo de Física, creo.
2) Bueno, uno de los grandes beneficios de tener SDFs en comparación con la actual tecnología de escudo es que la burbuja del escudo debe reajustarse después de perder un ala o cualquier otra parte, ya que los SDFs son elaborados por cada parte. La tecnología de escudo actual funciona con una geometría preestablecida que se basa en una silueta original de un vehículo. Como resultado, incluso si pierdes una o dos partes, la burbuja del escudo seguiría teniendo la forma del vehículo 100% original.
3) Una vez más, una cuestión más de física y para el Equipo de Armas (si vamos a tener armas de rayos). Desde mi punto de vista personal, solía jugar mucho a "Homeworld", así que estoy a favor de las armas de rayos. Me encanta cómo se ven en el campo de batalla, pero en última instancia, la decisión no es mía.
4) Lamentablemente, no puedo responder a nada. ¡Es una pregunta para el equipo de gameplay!
@mpiatek-cig
🔹Vulkan API
11 Agosto 2020
1 ¿Tendremos más detalles gráficos una vez que esté implementada la API de Vulkan?
2 ¿Se notará mejora en el rendimiento?
3 ¿Cómo testeais las diferencias entre APIs?
4 ¿Hay alguna build del juego que utilice Vulkan internamente?
5 ¿Se planea introducir más opciones gráficas después de implementar Vulkan?
1) No. Bueno, puede ser, pero no está relacionado entre sí
2) Si la conversión funciona, no habrá ninguna diferencia visual en absoluto y el rendimiento será mejor (en los casos en que la carga de trabajo de los gráficos de la CPU estaba limitado)
3) Estamos trabajando en dos aspectos. Primero, tenemos un nuevo renderizador, llamado arbitrariamente Gen12, que envuelve la API de gráficos en una interfaz que obliga a las cosas a ser amigables con Vulkan. El backend D3D11 para Gen12 ya está funcionando y estamos pasando las características a él, así podremos probar el viejo D3D11 comparándolo con el nuevo D3D11 en un conmutador, característica por característica. Al mismo tiempo, se está trabajando en escribir el backend Vulkan para el mismo renderizador, así que la gente que está trabajando en eso puede comparar la nueva-D3D11 vs. Vulkan en cualquiera de las cosas que ya han sido portadas a Gen12.
4) Es posible ejecutar el backend de Vulkan, pero no funciona en el sentido de estar en un estado jugable.
5) Introducir más opciones gráficas es completamente ortogonal al soporte de Vulkan. Es algo que obviamente necesita hacerse, pero no está relacionado entre sí.
Dicho esto, ajustar el significado exacto de alto/medio/bajo probablemente debería hacerse después del cambio.
@BParry_CIG
🔹Polvo espacial
17 Agosto 2020
¿Cómo funcionará el polvo espacial cuando los planetas orbiten?
El polvo espacial toma la zona local del jugador como marco de referencia, creo. Así que si estás en el espacio exterior y tu velocidad es 0 el polvo espacial no se mueve (a menos que tenga alguna velocidad definida en los ajustes del sistema de partículas). Hay una magia de zonas que nunca puedo entender, que es probablemente la razón por la que no soy un programador de motores, que ocurre cuando te mueves de un espacio a otro pero "simplemente funciona". Visualmente, si estás en una nave y tu velocidad es 0 las partículas de polvo espacial no se mueven. Bueno, sí se mueven un poco porque tienen algún impulso interno. Si eres empujado por algo o enciendes tus propulsores, viajas a través de este campo de partículas siempre en bucle.
Todo eso utiliza la brillante funcionalidad del bucle espacial que hemos tenido durante bastante tiempo. Creo que lo hemos demostrado en el pasado, tal vez durante la Citizencon de 2017? No estoy seguro, pero me sorprendería si nunca hemos mostrado los bucles espaciales.
@mpiatek-cig
🔹Nubes de gas
26 Agosto 2020
¿Son posibles las nubes de gas con esta alta resolución?
Hay un par de cosas a tener en cuenta con tu imagen. La apariencia de coliflor que mencionaste sólo tiende a ocurrir realmente cuando hay atmósfera, así que tenderías a verlas en los planetas como nubes que se forman y se hacen más gruesas, las nubes erupcionarían un poco y ganarían la forma de coliflor que estás describiendo. Estando en el espacio, no existen, tienen una apariencia más desordenada. Las nubes atmosféricas es algo que podríamos ver en el futuro, no estoy seguro ya que no manejo ese aspecto como imagino que sería similar a la tecnología de nubes que se usará en Crusader.
Pero las nubes de gas por otro lado, ese es mi trabajo. En cuanto a la resolución, me gustaría decir que cada vez que miro lo que los artistas han hecho y la resolución y calidad que están produciendo semana tras semana sólo está mejorando. Así que como tu referencia es una imagen, es como comparar manzanas con naranjas. Así que piensa en las nubes de gas como la geometría tradicional. Los modelos en Star Citizen son bastante salvajes y esperamos y planeamos que la calidad de las nubes de gas esté al mismo nivel. Pero conseguir esa apariencia de coliflor fue algo que logramos cuando empecé a construir las herramientas para el juego, fue curiosamente la primera herramienta que hice.
¿La tecnología que usaís no es algo anticuada? (Ejemplo Microsoft Flight Simulator)
¡Oye! Gracias por la pregunta.
Como trabajo en las nubes de gas y no tengo nada que ver con la tecnología de las nubes atmosféricas, no tengo información para darte.
Por lo que he visto de nuestro motor, no creo que sea demasiado viejo o "anticuado" como ves, ya que estamos constantemente haciendo mejoras y ha seguido evolucionando para crear algo como SC. Pero podría decir que estos "nuevos chicos" no tienen tecnología de nubes de gas como nosotros, donde puedes tener nubes hechas a mano por mis artistas para que realmente el arte dirija exactamente lo que quieren. En cuanto a lo que puedo ver en otros juegos con tecnología de nubes en la atmósfera, parece ser un sombreador y generado por procedimientos. Podría estar equivocado en esta parte.
Pero si vas a decir que estamos gastando tiempo en tener que hacer a mano nubes de gas donde las nubes de los planetas como en Flight Simulator se hacen por procedimiento, seguramente nuestra tecnología es peor? no es cierto, ya que tenemos herramientas para crear hidráulicamente estas nubes de gas del motor para luego importarlas. Podría hacer funcionar mi máquina durante la noche y volver por la mañana y tener miles de variaciones, e incluso esto permite a los diseñadores bloquear sus niveles utilizando nubes de gas en lugar de la geometría, ya que es un poco más difícil visualizar un nivel que se supone que es una nube de gas para ser construido con la geometría. Se trata principalmente de lo que necesitábamos primero, necesitábamos tecnología de nubes de gas antes que de nubes de planetas, ya que necesitábamos construir The Coil.
@Medic-CIG
🔹Efecto de entrada atmosférico
24 Agosto 2020
El efecto de entrada a la atmósfera se difumina demasiado rápido cuando realmente cuanto más entras en la atmósfera es más densa y es cuando se debería notar más el efecto de entrada, no al principio. ¿Hay alguna razón para que funcione así?
También estoy de acuerdo en que los desencadenantes de los efectos de entrada en la atmósfera no son actualmente los ideales, sin embargo son la solución que hemos encontrado y que funciona mejor con el sistema y la escala actual de los planetas.
Antes de que Leo (programador senior de VFX) cambiara los valores a lo que son ahora, estábamos usando un enfoque más realista usando la densidad y la velocidad. El problema con eso se debe a la forma en que los planetas están configurados actualmente y a los límites de velocidad en las naves, los efectos no se producían y sólo lo hacían cuando estaban casi a nivel del suelo. Como un compromiso que funciona tanto para las expectativas del jugador como para la estética de la experiencia de entrada en la atmósfera, los valores son "artísticamente" retocados.
Al idear la apariencia, también pensé en las implicaciones de la entrada atmosférica, el ángulo de ataque, el daño potencial de una mala entrada, la mecánica orbital usando el QT orbital como tirachinas para conseguir la suficiente velocidad para disparar los efectos usando el enfoque más físico que queríamos, etc. Esto podría venir más tarde con un QT orbital expandido y más granular, pero no hay un tiempo estimado de llegada.
En cualquier caso, la base del sistema de efectos visuales está ahí, y como es muy fácil asignar la entrada atmosférica a cualquier nueva nave, variante o reelaboración, significa que podemos centrarnos en hacer que otros aspectos de la experiencia de la nave se vean bien.
@TeoBarraultCIG
🔹iCache
31 Agosto 2020
¿Cada servidor de juegos tiene su propia instancia de iCache ?
El iCache es una serie de servicios que están, como se dice, escalados horizontalmente, que pueden ser cambiados dinámicamente hacia arriba o hacia abajo según las necesidades, y sus números están completamente separados de las instancias específicas de los servidores. Los servidores no tienen sus propias bases de datos, pero los shards o "fragmentos" (en nuestro uso esto será una colección de servidores en una malla trabajando juntos) tendrán sus propios registros, y los elementos y la base de datos variable de estos fragmentos estarán efectivamente separados unos de otros ya que en su mayor parte los fragmentos no interactúan entre sí (siendo el caso de los jugadores que se mueven entre los fragmentos de las sesiones de juego).
Algo que creo que se perdió un poco en la edición de último Calling All Devs es que no saltaremos inmediatamente a un solo fragmento global, sino que será un proceso gradual. Una vez que introduzcamos el server meshing, las mallas no serán tan grandes y densas como nuestros objetivos futuros. En su lugar actuarán como nuestras instancias de servidor, pero permitiéndonos aumentar la cantidad de jugadores por encima de 50. A medida que probemos, mejoremos, optimicemos, arreglemos los errores, etc., podremos aumentar el número de jugadores para alcanzar los objetivos más grandes que pretendemos, pero no ocurrirá el primer día.
¿Accederán los servidores mallados a la base de datos de los demás para acceder a los datos o intercambiarán constantemente datos relevantes directamente entre ellos?
Los servidores mallados se comunicarán entre sí constantemente, de manera similar a cómo los clientes y los servidores se comunican entre sí constantemente, pero las consultas basadas en la persistencia irán a la icache, no a otros nodos servidores en la malla.
En el Calling All Devs parecía que iCache, Meshing y Persistencia se requerían mutuamente, pero entonces el iCache y Persistencia existen ahora mismo? Fue poco confuso, ¿podrías aclararlo un poco?
En cierto sentido, todos ellos se requieren mutuamente para trabajar en la versión final a la que estamos destinados, por lo que a veces puede resultar confuso explicarlo, ya que ambos tenemos que explicar la visión final del sistema y, simultáneamente, desglosar la forma en que nos introducimos en segmentos del sistema completo de tal manera que puedan funcionar sin el resto del sistema. En resumen, el objetivo es el server meshing o "mallado de servidores", pero para ello necesitamos tanto la persistencia global como la icache. El icache no requiere técnicamente el server meshing, pero no estás del todo equivocado en que parece que hay alguna relación con él que necesita algún concepto de un fragmento para empezar. La forma en que esto funciona es tratando efectivamente las instancias de un solo servidor como una malla de un solo nodo de servidor. La persistencia global está en estos momentos en un estado global del mundo persiste, pero sólo por instancia de servidor, y sólo en la memoria interna (no almacenada en una base de datos). Con el icache estamos primero moviendo esta persistencia basada en la instancia del servidor fuera de la memoria del servidor y dentro de una base de datos apropiada, donde será analizada de acuerdo a los shards o fragmentos (como mencioné anteriormente). Y como dije, antes de que el server meshing funcione, eso significará que cada instancia del servidor es una malla de un solo servidor, lo que significa que también tendrá su propio registro de persistencia de fragmentos. Una vez que tengamos la malla del servidor funcionando, los fragmentos aumentarán la densidad del servidor (primero estáticamente, después dinámicamente) y entonces las cosas empezarán a parecerse a nuestro objetivo final, hasta entonces será una serie de pasos incrementales y algún trabajo temporal para sostenernos mientras llegamos allí. Es como construir una escalera mientras se sube simultáneamente.
@CIG_ChadMcKinney
🔹Room System y Chris Roberts
11 Septiembre 2020
¿En qué estado se encuentra el room system después de 4 años? (ntd: es la tecnología que controla la presurización entre otros aspectos)
Esto lo responde el mismísimo Chris Roberts después de muchos meses sin saber de él, se trata de una respuesta muy larga que se puede encontrar traducido por el compañero RazielFireEye en el siguiente enlace:
https://telegra.ph/Sobre-el-ROOM-SYSTEM-Respuesta-de-Chris-Roberts-en-Spectrum-09-11
🌐Historial🌐