Wingman’s Hangar Episodio 59

 Resumen

Captura de movimientos y facial para el juego, cogiendo cada detalle facial como en Avatar para hacer que las expresiones pasen al motor gráfico.

Estados de Destrucción de las Naves. La hornet por ejemplo tiene 100 partes que se rompen a diferentes porcentajes según donde alcances (carlinga, turbinas, alas, spoiler trasero, arma principal, motor, impulsores…) Ahí podéis ver en detalle cómo se rompen las naves y cuales van a ser sus efectos.

- Comentan que están testeando el Backend de los servidores y que están crasheando bastante. Sabían que iban a tener problemas con ellos, porque funcionan en directo pero no en el cloud y desde diferentes partes del mundo.

- En las preguntas dan algunos detalles, como que si eres un cazarrecompensas puedes matar a un fugitivo pero no tomar su nave como tuya porque, como en la vida real, sería un robo. Si quieres ser un cazarrecompensas/pirata, allá tú.

- Pregunta sobre misiones de investigación, y dicen que algo habrá con cazarrecompensas pero que la investigación más seria la quieren hacer, está en su documento de diseño post-lanzamiento, pero probablemente no estará para el lanzamiento.

- Habrá compresión de tiempo en el juego, pero como nos dijo Chris en su entrevista con Ciudadano Estelar, todavía no tienen claro cuanta van a meter. Irán tocándola durante la alfa hasta que sea cómoda para todos.

- También comentan chorradas que la gente pregunta, como si la nave estará dañada en tu hangar tras una batalla en el Módulo de Combate (no, es una simulación), que las animaciones de los personajes van a ser retocadas y cambiadas a lo largo de todo el desarrollo hasta que queden bien (la gente se quejaba de que son lentas en combate), o si van a poder cambiar la voz de la IA de tu nave (no por el momento).

- Han enseñado la versión física del último año de JumpPoint y que estará a la venta para los suscriptores interesada en ella.

 

Estados de Daño: Respuesta de Chris Roberts en los foros

“Lo que acabais de ver en el video es PARTE del sistema de daño. Hay otras capas como quemaduras de lásers, impactos, agujeros de bala que se consiguen con decals y height maps.

Algo que la gente puede que no haya detectado es que mientras que tenemos estados discrecionales de daño para cada parte, cada estado tiene múltiples piezas (paneles, armas, etc) que pueden romperse. Al comienzo del estado todas las piezas están sujetas a la geometría básica y entonces se empiezan a romper si un láser o un proyectil impacta cerca de ellas. Así que entre los decals de ipacto, trozos de la geometría desprendiéndose cerca del punto de impacto, va a parecer que la nave está respondiendo exactamente donde la has impactado.

Las transiciones entre los estados, la cual es flexible en un número de estados por parte, ya que realmente depende del tamaño de la parta alcanzada y cuanta fidelidad necesitas para que la progresión tenga un aspecto adecuado (y tiempo disponible por el artista) – es más absoluta (por ej, yendo desde un 25% de daño a un 50% los mismos sucesos tienen lugar aunque los impulsos de la geometría que se desprenda será aleatoria), por lo que el ala se romperá en dos o se apartará cuando alcances un 50% de daño (aunque si se hace suficiente daño puede que se salte por completo un estado, lo cual tendrá un efecto y sensación visual completamente diferente).

También estamos rastreando con precisión todos los impactos de proyectil, de manera que si una bala se abre paso a traves de los escudos y el blindaje su camino será rastreado dentro y si el proyectil colisiona con un componente interno infligirá daño al mismo.

Cada sistema de la nave tiene una localización física y una geometría de colisión aunque no tenga una geometría renderizada (lo cual sería el caso de un sistema interno). Si ese sistema es dañado o destruído, este afectará a la nave de una manera sistémica. El ejemplo más obvio es la planta de potencia – si es dañada (y no explota) su salida de potencia será reducida o se detendrá. Cada sistema tiene una entrada de energía y si no la está recibiendo ya dejará de funcionar o en el caso de potencia reducida puede que funcione a menos potencia o se detendrá por completo (dependiendo del cacharro). Por supuesto, si tienes algunos capacitadores/baterías en los sistemas todavía tendrán potencia de reserva antes de que empieces a tener problemas. Una ilustración menos obvia es que la computadora principal de la nave se ocupa con sus ciclos de CPU de las aviónicas (puedes, a nivel de gameplay, entender esto como potencia de computación, en vez de potencia de energía). Si la computadora de la nave es destruía o dañada, la computadora de puntería no será capaz de darte una resolución de tiro o funcionar adecuadamente (porque una computadora de tiro necesita potencia, ciclos de CPU y un radar que funcione). Todos los sistemas de la nave tanto producen como generan algún tipo de consumible (potencia, ciclos de CPU, calor, fuel) o lo usa. El calo es un consumible negativo (quieres deshacerte de él, no almacenarlo) – la mayor parte de las armas y algunos sistemas generan calor y si no te ocupas de él de manera eficiente (o tus disipadores de calor son dañados) correrás el riesgo de dañar tu nave y sus sistemas y por lo menos incrementar tu firma de calor, lo cual te convierte en un objetivo más fácil de detectar por el radar o el sistema de apuntado de otra nave (Ndt: pensad en los misiles, niños XD).

Todos esto está construído en las naves con un sistema de plug and play por lo que creamos “puertos” del objeto en la nave y “enchfuamos” armas, radar, plantas de ptencia, motores, impulsores, tanques de fuel, baterías, CPU (más núcleos implican más ciclos), sistema de apuntado, computadora de navegación, motor de salto, disipadores de calor /radiadores etc dentro y ellos se enchufan a las diferentes “cañerías” que llevan la potencia, ciclos de CPU, fuel o calor.

Todos estos sistemas tienen sus PROPIOS estados de daño (por los que acabáis de ver).

Así que podeis ver que hay un nivel de fidelidad en lo que estamos haciendo que yo no he visto antes en un juego y el video de ayer sólo os mostró un ventanuco dentro de una parte de las cosas que estamos haciendo para mostrar gráficamente el daño…

Hablando de Snowdrop (NdT: motor gráfico de Tom Clancys: The Division) – es un motor gráfico muy bueno y se lo enseñé al equipo en el momento que se hizo la demo en el E3 porque yo estaba muy impresionado. Habiendo dicho esto, no es que en realidad pueda hacer mucho más o de una manera distinta de lo que hace CryEngine – el daño “procedural” que es demonstrado en el video es algo que ha podido hacer el CryEngine durante años (un decal de una bala impacta, rompiendo un plano de cristal, agujereando neumáticos y el coche cae sobre su llanta). Está muy bien hecho (arte precioso y una ilumación adecuada) pero no he visto nada que no podamos hacer con la tecnología que tenemos en Star Citizen y que no estemos planetando hacer nosotros (bueno, supongo que no puedes disparar a los neumáticos de una nave, pero podrías hacerlo a un buggy!). Ha sido mi experiencia que los motores de alta calidad (CryEngine, Unreal 4, Frostbity) son todos más o menos equivalentes en features y capacidades – es más un tema de cómo de buenos son tus artistas y si tus programadores están encontrando una manera que mole para demostrar las features del motor gráfico.

Última nota (en mi muro de texto):

 He conocido desde hace mucho a los chicos de BeamNG y hable con ellos tan pronto como Diciembre de 2012 acerca de trabajar en Star Citizen. ¡Incluso tengo un test prototipo que hicieron con la Hornet volando en el espacio y chocando contra un asteroide, usando su sistema! El problema de su acercamiento (y las físicas de cuerpo blando en general) es que es realmente muy pesado de calcular para la computadora y la simuación. Es fantástico para videos de demostración o algo como un juego de coches (hay una razón por los coches de Forza o Gran Turismo siempre tienen tan buen aspecto, y es porque están simulando menos cosas que las que simularías en un FPS como Crysis 3). Entre los problemas de ancho de banda en la red y problemas de renderizado del cliente y simulación (simular cuerpos blandos de 50 naves y tener un frame rate por encima de los dos dígitos), un sistema de cuerpos blandos para Star Citizen todavía no es tecnológicamente práctico para Star Citizen incluso en los PCs de alta calidad que esperamos que todo el mundo posea para el lanzamiento.

Eso no significa que esté en contra de intentar hacer una versión simplificada del modelado de daño – tenía la esperanza de que los chicos de BeamNG hiciesen algo de I+D en una versión básica del sistema que sólo se centrase en el modelado de daño y la deformación (no tanto en la simulación física completa de cada perno etc) para Star Citizen pero en la época que hablé con ellos tenían otros compromisos (como terminar la universidad) y querían trabajar en su propio juego de coches por lo que nunca acabamos por finalizar el tema – lo cual no significa que no me gustaría revisitar esto porque tienen un montón de talento pero ahora mismo parece que les va bien y están viviendo el sueño de hacer su propio juego (¿Y quien soy yo para entrometerme en él?).

Esto no significa que no tengamos un modelado procedural del daño a través de la deformación en nuestra lista de I+D para el equipo de Ingenieros Gráficos de Star Citizen (el cual es de 4 programadores a nivel interno por el momento). ¡Necesitamos esto para las naves capitales porque querríamos ver esos enormes cascos hundirse o deformarse de impacos y colisiones y si hacemos algo con lo que estamos contentos (y es adecuado para nuestro criterio de rendimiento) probablemente lo aplicaremos también a las naves más pequeñas añadiendo un nivel de detalle adicional!

Así que la versión TL, DNR es ¡Tened paciencia, pequeños saltamontes!”