Autor Tema: Around the Verse - Episodio 3x07 - 16 Septiembre 2016  (Leído 936 veces)

16 de Septiembre de 2016, 20:11:33
Leído 936 veces

Havok Specter

  • Información
  • Mensajes: 3737
  • En el espacio impera la ley del oeste


Traducción por Frost en Ciudadano Estelar.



COMIENZO
Chris y Sandi presentan de nuevo el programa esta semana, una semana más cerca de CitizenCon.

ACTUALIZACIÓN DEL ESTUDIO DE AUSTIN John Erskine

SONIDOS MEJORADOS



Jason Cobb (Diseñador de Sonido Senior): He estado trabajando en el sonido de la chatarra a través de la que vuelas si estás detrás de una nave que acaba de explotar en el juego. Durante las dogfights hay un montón de explosiones geniales visual y sonoramente; pero les falta ese toque sonoro a la hora de atravesar la nube de restos que han quedado flotando en el vacío. Para hacer eso hay que admitir que no es razonable tener una partícula física para cada trocito de chatarra que se genera, por lo que yo tomo todo el sonido que he generado uno a uno y los pongo en una estación de trabajo de sonido para editar el sonido que se crea al entrar y al salir de una nube de estas características. En este caso estoy usando Altiverb para generar las reverberaciones de un modelo Sikorsky, de manera que ponemos los sonidos dentro de un espacio. De manera que luego tomamos todos estos sonidos y los pasamos a través de un efecto y eso puede ser una nave, y si estamos haciendo este efecto para una nave un poco más grande tendremos que generar otro efecto para esa nave en particular. Existe la posibilidad de que estos efectos puedan ser hechos en tiempo real, pero ahora mismo en esta fase de prototipado estamos cocinando todo esto en un archivo con la reverberación.



(3:00 Se pone a atravesar explosiones y chatarra para demostrar el efecto, os recomiendo escucharlo vosotros mismos. Ha apagado el resto de sonidos del juego para que se pueda percibir mejor.)

Quizá estén muy altos en este momento respecto a las explosiones y haya que ajustar la mezcla. Quieres sentir que estás atravesando una explosión, pero no quieres que dure demasiado tiempo tampoco. En general funciona bien, sobre todo cuando visualmente ves que se acerca un gran trozo de chatarra y el sonido coincide dices "oh, Dios mio, eso fue perfecto", y en otros casos... "bueno, ¡quizá no me ha dado!"
También he preparado el sonido para que se oiga aunque tu nave esté quieta. Es algo que no sucede mucho jugando habitualmente, pero supongo que podría suceder si explota una nave que está junto a la tuya. Tenemos que trabajar en todas las posibilidades.

Este es un nivel de decoración y pulido que añade una capa adicional a la acción, porque antes veías y escuchabas todo esta explosión, pero te preguntabas ¿dónde está el sonido de todas esas piezas que salen volando? No sentías que estaba afectando a tu nave, por lo que este es uno de esos pequeños detalles que requieren de una cantidad sorprendente de trabajo pero añade algo que completa la experiencia en si del combate espacial. Esto te proporciona una reacción más visceral al hecho de que" si, allí antes había una nave y ahora hay un montón de trocitos y los he atravesado." Esto dará más satisfacción a cada una de estas explosiones.



ENTREVISTA CON EL EQUIPO DE DEV OPS

Mike Jones (Director de IT y DevOps): Este equipo está hecho a partir de tres funciones principales que como eran pequeñas pusimos bajo el mismo título de DevOps. Tenemos una sección que se dedica a:
- Hacer Builds (Versiones). Básicamente administra y configura todos los sistemas que utilizamos para hacer las versiones del juego que hacemos en la compañía y también producir aquellas que han pasado Control de Calidad y son publicadas al PTU y finalmente al servicio público.

- LiveOps. Hace la mayoría de las herramientas y sistemas automatizados que usamos en nuestras publicaciones para los jugadores, cosas que automatizan la construcción de los servicios que usamos en el PTU o la versión pública. También hacen las herramientas que usamos para el desarrollo interno, desde cómo interactuamos con el código fuente, cómo entregamos versiones internamente etc
- Publishing, estos son los que publican el juego, los que se dedican a llevar el proceso desde el PTU hasta el servidor público. Esto conlleva cosas como tomar la versión bruta de la versión, empaquetarla, subirla a los servidores y luego administrar el proceso de producción de los parches.



Logan Nelson (Ingeniero de DevOps): Creo que DevOps es como Scotty (haciendo una referencia a Star Trek). En la tripulación de la nave tienes al capitán que guía la nave, el médico que se dedica a cuidar de la salud de la tripulación... pero si la nave no funciona, si su reactor de curvatura está roto... no va a ninguna parte. Nosotros somos los que estamos dando martillazos en la sala de máquinas asegurándonos de que la nave sigue funcionando, es una parte muy crítica de la misión.



Mike Johns: Lo que pasa en el sistema actual de parcheo es que los nuevos datos son comprimidos en estos grandes archivos .pak y estos son empaquetados y puestos en un parche. El problema de este sistema es que si sólo 3 archivos cambian en un archivo .pak de 2 gigas todo el archivo debe ser descargado de nuevo. Si cambias muchos archivos en múltiples paks de 2 gigas acabas con un parche que descarga 20 gigas. Lo que estamos haciendo es desmantelar todo esto para que ahora el parcheador pueda mirar sólo a los archivos que han cambiado dentro de los grandes paquetes y esperamos que con esto puedas tener parches un 10% más pequeños que los que entregamos ahora. Creo que mucha gente estará contenta con esto, meterá muchos más jugadores en el PTU para poder descargar rápido los parches, especialmente la gente que vive en las periferias y no tienen banda ancha o un límite de datos mensual.

Es algo que es bastante difícil para nosotros, porque va al núcleo mismo de cómo carga archivos el motor gráfico desde el disco duro. Estamos haciendo cambios al propio motor con la ayuda de nuestro equipo en Alemania y esto nos permitirá usar este nuevo proceso de parcheado. Esto será algo muy importante para el juego, para muchos jugadores y va a ayudarnos a mejorar los tiempos de entrega de las versiones.



Andy Anderson (Ingeniero de DevOps): Todas las viejas herramientas que teníamos fueron interesantes en su tiempo y tuvieron todo un desarrollo aparte, pero las nuevas herramientas que estamos desarrollando hacen que sea realmente fácil para nosotros cambiar las cosas realmente rápido... y cuando digo rápido digo unos minutos, porque a veces esperas eso para que simplemente se cambie una línea de código en un servicio. Ahora se siente de verdad que podemos enviar órdenes a todo el despliegue y simplemente obedecer. Es genial.



Mike Johns: Creo que lo que hacemos está tan entre bambalinas que la gente nunca tiene la oportunidad de ver todos los detalles de cómo funciona esto en realidad. ¿Qué es necesario para configurar un nuevo servidor? ¿Qué es necesario para hacer funcionar 50, 100 o 150 servidores y hacer que lo hagan correctamente y mantenerlo seguro al mismo tiempo? Es un trabajo que es muy satisfactorio porque sin este backend y automatización que estamos construyendo para que vayan fluidas las cosas no creo que nos sería posible construir las cosas a la velocidad que quiere Chris que nos movamos y a la velocidad que se mueve el desarrollo del juego. Y esa es una experiencia satisfactoria.



SHIP SHAPE: DRAKE HERALD con Josh Coons

Mathew Sherman: Con 2.6 estamos emocionados de lanzar la Herald de Drake. Es nuestra primera nave Corredora de Información y esto significa que tienes estos grandes bancos de datos fuera de tu nave y que pueden almacenar un montón de volumen de recursos de inteligencia, localizaciones donde se puede recopilar información de investigación, localizaciones de minería, localizaciones de salvamento, cajas negras de naves... Cualquiera de las cosas intangibles que puedas imaginar será responsabilidad de un Corredor de Información y las transportará por la galaxia.



Josh Coons (Modelador 3D): Una de las cosas que os daréis cuenta en cuanto voléis una Drake Herald es que la nave es realmente rápida. Creo que es la nave con el mayor porcentaje de motor por masa hasta el momento, por lo que es básicamente una nave espacial de drag (ndt: 950 m/s a velocidad de Crucero). Son realmente difíciles de alcanzar, super-rápidas, y están cargadas hasta los topes de contramedidas.



Cuando miré la función y el modelo de la nave, lo que hice fue tomar algunas palabras clave como las que inspiraron mi diseño y modelado de esta. Para esta nave las palabras fueron "velocidad", "ciencia", "tecnología", "evasión"... y el aspecto visual de Drake debía estar integrado a la hora de diseñarla: equipada con lo justo, cables expuestos y un acabado no tan bonito como el de otras naves pero que cumple su función.




Matt Sherman: Parte del rediseño fue hecho en parte para asegurarnos de que todo fuese construído a las métricas estándar que necesitábamos de esta nave: cómo de grandes son los cañones, cómo de grandes son los componentes, cuanto espacio necesita un jugador para andar por dentro y a través de la nave. Algo que siempre tiene buen aspecto en las películas de ciencia ficción son los corredores estrechos y angustiosos pero desafortunadamente la lógica de los juegos requiere que tengan un poco más de espacio para que el hombre medio en pie pueda moverse libremente por su interior. Esto se puede ver claramente en el interior de la Herald, en que su asiento de operaciones te permite deslizarte dentro y fuera de la estación para optimizar el espacio tanto como sea posible, pero para permitir que una estación en uso permita el movimiento libre alrededor se rediseñó la parte de atrás por si alguien se estaba levantando de ese asiento. De esta manera otro jugador o PNJ puede moverse limpiamente sin tener que hacer clipping en los mamparos o rebotar por el interior.




Patric Salerno (Artista Técnico Asociado): Cuando comenzamos el proceso de Diseño para el sistema de destrucción del vehículo me gusta pasar a hablar con arte y diseño para acordar tanto en 2D como en 3D el sistema de despiece y destrucción de la nave. Para empezar miraría dentro del modelo. El daño llega en capas, son toda una serie de características que trabajan juntas. Está el casco exterior de la nave y bajo este se encuentra una "piel" subyacente y una serie de "gubbins" (ndt: jerga de modelador, son chismes y detalles para rellenar modelos y referirse a sistemas internos).



La razón por la que tenemos esto es porque hemos añadido un shader de daño que probablemente habéis visto (ndt: ejemplo, Gladius) para deformar metales, agujerearlos y abrirte paso hasta el interior de la nave. Todo este efecto es creado por el cascarón externo, los "gubbins" que hay por debajo y la geometría subyacente. Todas estas cosas deben unirse bien al final del día, por lo que parte de mi trabajo consiste en comprobar todas las partes de la geometría en los U/Vs (que es donde se ponen las texturas que proporcionan el aspecto al modelo) y revisar los UVs secundarios, que es donde trabajan los estados de daño.



Lo que veis en la esquina de arriba a la izquierda son los UVs secundarios, en los que se aplican los shaders de daño, de manera que cuando tu nave sea alcanzada veas esos bonitos efectos de ondas, distorsión, metales retorcidos y agujeros. Además de esto tengo que añadir unas "cargas explosivas" alrededor de toda la nave. La mayor parte de mi trabajo es preliminar: coger el modelo y prepararlo para su destrucción, romperlo en piezas, asegurarme de que todo funciona como debería y preparo todo para otra gente.



Luego llegan los chicos de Partículas y para ellos pongo unos "helpers" (asistentes), unos pequeños cubos verdes con sus direcciones X/Y/Z y básicamente son pequeñas cargas explosivas. Ahí arriba podéis ver una serie de asistentes que he añadido y que representan efectos generales que ponemos en todas las naves: explosiones, arcos, fuego, etc etc Cuando una pieza recibe un 100% de daño se desacopla, se activa la explosión y se crean más daños a los shaders. Todo esto son capas: salpimentas la nave con los agujeros de tus cañones, explotan partes, todo se va fundiendo y al final del día... acabas teniendo una nave que está bastante rota.



Ya hemos entrado en MAX, hemos configurado inicialmente la Herald, hemos comprobado que la nave tiene una malla de UVs secundarios, que tiene por debajo la geometría subyacente para los shaders que se muestren al dañarla con agujeros de bala. Los shaders molan mucho porque te permiten hacer agujeros en las mallas con lo que llamamos colores vertex, así que cuando entro en MAX y voy a la malla a configurar áreas donde hay transparencias, es más diáfana, etc para que el daño pueda atravesarlas. No todas las áreas necesita que sea atravesada, tienes que asegurarte que no estás malgastando geometría y empeorando el rendimiento en cosas internas que no se ven y no son necesarias; pero también quieres asegurarte de que cada pieza se secciona apropiadamente, de que es un efecto bonito cuando se eyecta y así sucesivamente.



Como podéis ver algunas piezas se alejan flotando y otras simplemente se quedan donde están: esos son vectores de pequeños empujones de fuerza que han sido configurados en el XML y dice a la pieza con cuanta fuerza debe alejarse de la nave y en qué dirección. Me muevo alrededor de la nave buscando zonas en las que el sistema no funciona correctamente. En el área justo detrás de la carlinga funcionan correctamente los UVs secundarios, mientras que en la zona de la carcasa de los motores ya sé que no funciona y podéis ver que no sucede mucho más que un agujero ahí... eso significa que tengo que entrar de nuevo en MAX y descubrir por qué pasa esto. Quizá es necesario re-proyectar los UVs secundarios y así sucesivamente. Se prueban diferentes tipos de daño, como la pistola láser, para ver si funciona correctamente y cual es su aspecto bajo distintas fuentes de luz y asegurarme de que las piezas explotan correctamente. Es una mezcla de 3D Studio MAX, CryEngine... es un proceso muy iterativo de ida y vuelta hasta que está refinada la nave y se lo pasas a los profesionales que ajustan los efectos especiales, la salud, la iluminación...

Chris Roberts: estoy excitado por el potencial más naves especialistas que no están centradas en el combate en el universo de Star Citizen, especialmente a medida que nos movemos hacia 3.0 y un más completo universo persistente.

Sandi Gardiner: Y es más rápida que una M50 en línea recta, eso es lo que me hace feliz a mi. (risas)



ACTUALIZACIÓN DE LA COMUNIDAD con Tyler Witkin
- La M50 ganó la votación a la nave de carreras más sexy y estará a la venta 1 semana. Seguirá a la venta 24 horas.
- Esta semana terminará mañana la votación entre la Vanguard y la SuperHornet, la ganadora también pasará a la tienda.
- Mañana saldrá la JumpPoint para los suscriptres, centrada en la Anvil Terrapin.
- Fue el Bar Citizen de Austin esta semana y habrá otro en Orlando (Florida) este mismo Sábado.
- Mañana habrá un artículo de Evil Hertzog sobre la estabilización de la vista en la cabeza en un vídeo a 60 fps, así que no os lo perdáis.

MVP
J. Coren por su Guía de Viaje para CitizenCon.



COMO SE HIZO: LÓGICA DE LA MÚSICA

Sam Hall (Programador de Sonido Senior): Desde el punto de vista de código tenemos un sistema que será activado por eventos musicales. Funciona porque Ross puede decidir qué sucede cuando hay uno de estos eventos, desde un punto de vista musical. Si quiere que la música se incremente en intensidad cuando tu nave sea alcanzada por un disparo el decide cómo de intenso será eso con las herramientas dirigidas por datos que hemos creado



Ross Tregenza (Diseñador de Sonido Senior): No importa lo que estés haciendo, nos estamos asegurando de que el sistema de música sabe lo que estás haciendo y está respondiendo de una manera que es apropiada, que mola y que sea cinemático. Os mostraré algunos ejemplos.



3 Estados de Música Ambiente (23:30)

Un ejemplo muy bueno en el que estamos trabajando es en la música ambiental, que suena cuando no hay combate o sucede nada importante: estás explorando el espacio. En este momento suena música de este tipo para FPS porque el motor de sonido sabe que estamos a pie y por lo tanto interpreta la ligeramente sintétizada y tensa música ambiental.



Cuando subimos a la nave (23.55) pasamos a una música más filtrada hacia la exploración, y eso sucede porque sabemos que estás en la nave, que los motores están encendiéndose.



Si salimos de la nave y saltamos de la plataforma de gravedad artificial a dar un paseo en EVA oiréis cómo transiciona la música (24:26), momento en el que podéis oír esta molona y etérea melodía estilo Kraftwerk... toda esta música creada por supuesto por Pedro Macedo Camacho (el compositor de Star Citizen). Todo esto sucede porque estamos flotando y no estamos en ningún peligro inmediato, por lo que tenemos esta hermosa música exploratoria que te da una sensación de maravilla ante el universo. Al aterrizar en la plataforma (25:00) no hay peligro pasamos de nuevo a la música FPS.



Música de Vuelo de Combate 25:10

En el momento en que detectamos a dos pilotos desconocidos la música se vuelve más tensa de inmediato y en cuanto abrimos fuego aumenta el parámetro de tensión (Pirata: "¿Por qué tienen siempre que dispararnos a nosotros?" XD) En cuanto somos alcanzados por disparos de los piratas notamos cómo el sistema musical aumenta su intensidad y comienza a volverse loco a medida que los escudos son impactados. Tus impactos y los de tus enemigos son constantemente enviados al sistema de lógica de la música, pasando de música de ambiente entre acción baja, acción media y luego acción alta. Si destruyes a uno de los enemigos (26:04) el parámetro de música recibe un subidón y recibes un "sting" (ndt: es un término musical que indica un punto de inflexion dramático como el infame Parabará! de James Horner al aparecer un villano o como una corta melodia para introducir una parte regular de un programa, como "sting del Tiempo" o "Sting de los Deportes" en un telediario) cuando destruyes a uno de los malos "tadá!. Esto nos ha empujado al "estado heroico", añadiendo grandes secciones de viento, pero vuelve a decrecer en cuanto continua el combate.



Vuelo de Combate con nuestro sistema de Debug 26:46

El código que me ha proporcionado Sam es increíblemente valioso, toda esta información de debugging: esto me dice todo lo que está sucediendo y los stings que se van a activando, como saltos, naves que pasan cerca (puede que hayáis escuchado un pequeño trompeteo cuando una nave pasa cerca...), activando algo, impactando con éxito a los malos... Luego tenemos la intensidad que es nuestro "gran número" que sirve de médula espinal a este sistema, el talante.. todo esto puede ser afectado o dirigido por el sistema en base a datos numéricos. Toda esta información de debugging me indica que todo está funcionando de la manera pretendida y que no se vuelve muy loco con la música y que se mete demasiado rápido en la música de acción. Aunque esto está para el modo de vuelo nos estamos asegurando de que transiciona para el modo FPS en el parche 2.6 y también para el combate en EVA, de manera que no importe lo que estés haciendo porque la música será apropiada a tus acciones y cambiará para ajustarse a ellas.



(29:00) Voy a simular unos cuantos eventos musicales como si estuvieses siendo atacado por un enemigo que te acaba de ver y que le disparas y le matas. Podéis como va ascendiendo de manera coral la gentil música EVA por estar en combate... de nuevo, esta es la genial música de Pedro en acción.

(29:25) También tenemos música siniestra para cuando las cosas no te van tan bien en combate y eres alcanzado en combate repetidas veces. Es el mismo sistema, y se vuelve mucho más sintetizada, más oscura y alcanzas ese gran nivel de música espacial... y a medida que pasa la situación podeís escuchar cómo va disminuyendo su intensidad.

Esto estará de fondo en tus aventuras por las distintas partes de la galaxia y a medida que te muevas de un sistema a otro todo el conjunto de música cambiará de una localización a otra, pero habrá un "lenguaje comprensible" entre todas estas al que te acabarás acostumbrando. Estará funcional y servirá para toda la vida del juego, es un sistema que se auto-administra de manera realmente autónoma y "simplemente funcionará".



Así que esto es lo que yo y Sam hemos estado construyendo en DataForge. Estamos realmente orgullosos de lo lejos que ha llegado. Estará disponible ya en 2.6 y será sólo el principio, se volverá cada vez más y más grande. Espero que lo disfrutéis.

Chris Roberts: Ese sistema de lógica de música es en realidad una evolución del sistema de música dinámica que cree yo primero para Wing Commander, llamado OriginFX. Obviamente es mucho más potente y robusto, ¡pero mola mucho!

Sandi Gardiner: Si, porque da a cada jugador una experiencia personalizada y les dará la sensación de estar en su propia película.

Chris Roberts: ¡Esa es la idea! (risas)

FINAL
- Mañana será RTV y podréis hacer preguntas al equipo de Austin junto a unos vídeos exclusivos.
- Ben Lesnick hará un streaming sobre el aniversario del lanzamiento del Wing Commander 2, el sabado.
 
Los siguientes usuaríos te invitarían a una cerveza por este mensaje: Kamil, Malkav Nozam, Phantel


Lo siento, este hilo está cerrado. Sólo admins y moderadores pueden responder.