Autor Tema: ATV - Frankfurt - Rompiendo el juego - 27 Abril 2017  (Leído 1079 veces)

01 de Mayo de 2017, 16:54:07
Leído 1079 veces

Havok Specter

  • Información
  • Mensajes: 3737
  • En el espacio impera la ley del oeste
VÍDEO OFICIAL EN INGLÉS



TRANSCRIPCIÓN EN INGLÉS

https://relay.sc/transcript/around-the-verse-breaking-the-game

RESÚMENES EN VÍDEO EN ESPAÑOL

El Hangar
Spoiler for Hiden:

El Rincón de Cuerdas
Spoiler for Hiden:

Asturino
Spoiler for Hiden:

TRANSCRIPCIÓN EN ESPAÑOL POR FROST

COMIENZO
Sandi y Chris presentan de nuevo el programa, haciendo un rápido repaso a las novedades de la semana pasada sobre el Banu Defender, sobre el evento de la BritizenCon organizado de nuevo por los fans británicos y pasan a..

ACTUALIZACIÓN DEL ESTUDIO DE FOUNDRY 42 - FRANKFURT Brian Chambers



EFECTOS ESPECIALES

Continúan trabajando, y en esta ocasión junto a los Ingenieros están dando forma a las herramientas y tecnologías necesarias para crear los planetas procedimentales. Han hecho progresos en las configuraciones manuales necesarias para hacer aparecer a los efectos en el motor gráfico y comenzamos a ver cómo las lunas comienzan a tener sus propias sutiles personalidades, lo cual mola. Aquí podéis ver los geíseres en las lunas de Cellin.



CINEMÁTICAS

Un nuevo diseñador se unió al equipo, Philip y está trabajando con Hannes para ponerse al día con el guión. El equipo continúa procesando datos de captura de interpretación y creando escenas a lo largo de todos los capítulos de Escuadrón 42. La prioridad actual son las escenas de historia que tienen lugar a bordo de la gigantesca instalación de Shubin, por lo que están dándole fuerte para que los artistas y diseñadores puedan terminar con los entornos. Además de esto, están haciendo ediciones de grandes secuencias que tienen lugar en el ecuador de la historia y progresando en terminar los panoramas que veremos durante el comienzo del juego.



ARTE DE ENTORNOS

Ha estado trabajando en dar forma a los diferentes elementos del terreno procedimental que domina el planetoide de Delamar, estando la superficie cubierta de escarpadas y afiladas montañas. Al poner la zona de aterrizaje de Levski en el planeta tuvimos un par de desafíos, tales como cual es el mejor flujo de trabajo para crear el gran agujero de perforación para la zona de aterrizaje y las carreteras que llevan a él o qué elementos específicos necesitamos para que este se fusione con el terreno de una manera natural.



El exterior de Levski ha recibido algunos cambios como la integración de garajes para que los jugadores puedan aproximarse a ella con vehículos terrestres (ndt: como Rovers Ursa o Dragonflys).  El equipo también hizo progresos en las estructuras de minería que están dentro y alrededor de agujero de perforación para que tenga un aspecto más funcional, así como una pasada de pulido.



También dieron algunos toques finales a las lunas para ayudar a darles un poco más de detalles únicos que las distinga entre si.



DISEÑO DE NIVELES

El equipo ha terminado su pasada de Diseño a los Puestos de Avanzada de Superficie y ahora se los han pasado a los chicos del equipo de Arte. Continuarán trabajando en su sistema modular durante una temporadilla. También han comenzado a integrar Levski en la versión procedimental de Delamar. Han creado un vestíbulo superior que conecta el interior de Levski a la superficie planetaria a través de esclusas de aire, así como preparar el lugar para un posible futuro sistema de comunicación por tren de superficie con otras zonas de aterrizaje aledañas. Han implementado garajes en la superficie para que la gente pueda re-aparecer o aparcar sus vehículos, así como más maneras de llegar a la propia Levski con carreteras y zonas de aparcamiento con paisajes interesantes. También hicieron algunos trabajos personalizados, como planear la red de ascensores y la zona de los trabajadores, así como haber añadido una zona de administración.



ARTE TÉCNICO

Estuvo haciendo I+D en lo que concierne a la locomoción a pie en espacios reducidos, con el objetivo final de que los pies se planten apropiadamente en el suelo a cada paso y le de al personaje una sensación realista de peso a todas las velocidades, ángulos, etc En su estado actual estamos obteniendo buenos resultados y todavía tenemos que hacer algunos refinamientos con las velocidades.
También hicieron tareas de re-skinneado para un abanico de opciones de personalización de personajes y siguieron trabajando con nuestro equipo de armas y herramientas para poder detectar problemas programáticamente en la cadena de montaje. También hicieron el rigging de animaciones de nuevas (y también actualizadas) armas.



DISEÑO DE SISTEMAS

Están progresando adecuadamente con el Sistema de Estado de Actores. Ahora incorpora todas las cosas que le pueden suceder al jugador, desde respirar, asfixiarse, aguante (stamina), fuerzas G, efectos del alcohol, ser herido etc Han añadido subsistemas para los efectos de que tu traje sea perforado en combate y la habilidad de parchear tu traje dañado, así como recargar tus tanques de oxígeno.



El Sistema de Usables está alcanzando el estado de producción completa y ahora estamos comenzando a producirlos en masa para Escuadrón 42 y el Universo Persistente. Una vez que estén implementados en los niveles estos darán una sensación de que el mundo está mucho más vivo, la IA podrá interactuar con casi cada objeto del universo... El sistema es increíblemente flexible, desde simples acciones como una IA recostándose en un muro a otras más completas como abrir un cuadro de servicio para acceder a la fuente de energía en su interior, inspeccionar ese objeto que hay en el interior, extrayendo el objeto o sustituyéndolo por uno nuevo y reiniciando la planta de energía, etc

El sistema nos permite que tanto el Jugador como la IA pueda llevar a cabo esas acciones o que tanto jugadores como IAs puedan estar interactuando con el mismo objeto usable al mismo tiempo.



En el lado social de las cosas, estamos terminando de integrar Spectrum en el juego, lo cual permitirá que los jugadores puedan acceder a funcionalidades principales de Spectrum dentro del propio juego, como creación de grupos, administración, chat, listas de amigos, organizaciones, etc El objetivo el mantener la mayor parte de las cosas integradas dentro de la aplicación de Spectrum mientras las funcionalidades principales necesarias para la jugabilidad del día a día estén disponibles directamente en el propio juego.



CONTROL DE CALIDAD

El equipo de Frankfurt ha estado probando el nuevo Sistema Stanton que tendrá el Universo Persistente, con el objetivo de encontrar bloqueadores a la jugabilidad principal. El proceso en si a la hora de conectarse al nuevo UP ha cambiado, por lo que llevó a que fuesen necesarios más ajustes y pruebas en nuestros servidores internos con la herramienta de lanzador de servidores, Catapult. Con Port Olisar ahora en el Sistema Stanton ahora podemos probar el vuelo entre las distintas lunas, así como aterrizar en ellas, etc

Se añadió recientemente al editor de Subsumption el sistema de conversaciones y estuvo disponible para hacer nuestra ronda inicial de pruebas. Todos los problemas que se encontraron fueron añadidos a Jira y enviados al estudio de Austin para que sean investigados.

También trabajaron con nuestro Diseñador de Sistemas para arreglar el nivel de pruebas de tareas básicas de las IAs y añadieron comportamientos para todos los PNJs de manera que se puedan hacer las pruebas que sean designadas. Los comprobadores de estas herramientas revisan esto cada vez que se añade nuevo código a la versión gamedev (ndt. gamedev viene a ser la versión principal de desarrollo de Star Citizen y de esta salen "ramas" que se convierten en los parches que acabamos jugando. Los prototipos que se desarrollan por separado luego se "injertan" en el gamedev y hay que ser cuidadoso con los bugs o problemas que se introducen al hacer la fusión.) Con el nivel de pruebas de la IA se puede detectar cualquier problema relevante a estas que podría estar relacionado a código nuevo que haya sido enviado.

También invirtieron su tiempo ampliando la profundidad de las pruebas que hacen en el Editor de Partículas. Se han creado nuevos Efectos Especiales al Editor y estas pruebas seguirán manteniéndose mientras recabamos las pruebas de otros testers del equipo.



ILUMINACIÓN

Ha estado dedicado a apoyar por completo el próximo lanzamiento del parche 3.0, que trae las lunas de Cellin, Daymar y Yela. Se ha dado una atención particular a los puestos avanzados de la superficie, intentando alcanzar el nivel de calidad que queremos para el parche 3.0 y las subsecuentes variaciones de estos puestos avanzados que haremos en el futuro. Es importante para nosotros dar personalidad a un nivel, interactividad y calidad a su iluminación, para que los jugadores quieran buscar y explorar estas localizaciones. Estamos sincronizados con el estudio de Reino Unido para mantener la iluminación actualizada a medida que los planos y recursos artísticos en si se acercan a su estado final.



También estamos implementado la primera fase de nuestro sistema de grupos de iluminación, que nos da la habilidad de alterar la iluminación y ambiente de los puestos avanzados en función a distintos estados, como bajo nivel de energía, luces de emergencia o condiciones peligrosas.



INTELIGENCIA ARTIFICIAL


Creció en un miembro el equipo este mes y pasaron algo de tiempo poniéndolo al día. La IA de las naves recibió un repaso para unificar el movimiento entre PNJs y naves, permitiendo que los PNJs que pilotan las naves puedan controlarlas de verdad, entre otras cosas. Esto acabará dando a las IAs un nivel de control mucho más preciso y una manera de hacer que sus acciones sean contextuales.



Los PNJs recibieron mejoras en su Pathfinding y su navegación (ndt. literalmente trayectoria, pero aquí se refiere a cómo la IA encuentra su camino [en rojo] y qué camino prefiere tomar la IA para moverse por el mapa del juego [en flecha negra]) bastante generales. A veces las IAs se quedaban bloqueadas en ciertas configuraciones de esquinas y este trabajo resolvió ese problema. También hicieron arreglos a la regeneración de la malla (ndt: mesh, aquí se refiere a la superficie de la geometría del terreno o malla) para excluir de manera correcta las zonas a las que no debería poder llegar la IA.



En el sistema de misiones se centraron en dos Capítulos distintos de misiones de Escuadrón 42, expandiendo las funcionalidades que ya había y añadiendo nuevas para los diseñadores. Ahora los Diseñadores pueden definir e inicializar a través de DataForge qué misiones por defecto son activadas cuando se entran en modos de juego específicos. A través del Subsumption Visualizer ahora son capaces de invalidar la misión inicial para un nivel en específico en el que están trabajando, lo cual hace que la configuración y revisión de los niveles sea mucho más eficiente para todo el equipo.

Los diseñadores ahora pueden crear lo que llamamos una "Plataforma", que en términos sencillos se puede definir como una lista de objetos que "viven" dentro de un contenedor de objetos con sus propias coordinadas del mundo conocidas en tiempo real. La Plataforma puede ser accedida por la lógica de la misión y personalizarla para numerosas configuraciones. Por ejemplo, una Fragata Idris podría ser una plataforma básica y en el juego podrías encontrar múltiples Idris configuradas de distintas maneras: ocupada por piratas, ocupada por la UEE etc Todas estas configuraciones estarían referenciadas con la misma plataforma básica de la Idris y tener por encima sus propias capas de personalización como los piratas, la UEE, etc



ARMAS

Han estado muy ocupados bocetando nuevas armas para el FPS. Este mes pasado han bloqueado 2 armas vanduul, 4 para Kastak Arms, 3 para Gemini y 1 para K-Hex.



En armas navales han terminado su primera pasada para los cañones balísticos de Knighsbridge Arms de tamaño 1, 2 y 3. Y esta es la primera arma naval que ha salido de nuestra nueva cadena de montaje y que está preparada para el nuevo sistema modular de mejora.
Este mes también están ayudando a hacer attrezzo al equipo de Reino Unido en su tiempo libre.



MOTOR GRÁFICO

Continúan trabajando en la carga de fondo de contenedores de objetos (Object Container Streaming) para ayudar a hacer realidad nuestro mundo sin pantallas de carga, así como en SolEd, nuestro editor interno que nos permite hacer con facilidad sistemas solares enteros.
Star Citizen y Escuadrón 42 están siendo desarrollados con el lenguaje de programación C++, conocido por su alto rendimiento. Pero debido al diseño del propio lenguaje muchos proyectos pueden sufrir de tener largos tiempos de compilación. Si no se es cuidadoso el tiempo invertido en traducir código de programación en instrucciones máquina puede ser largo. E incluso teniendo un diseño de programación cuidadoso el tiempo de compilación para proyectos de nuestro tamaño tienden a crecer, por lo que pasamos algo de tiempo haciendo limpieza del código que ya existía y para esto fue necesario retocar todos los archivos del juego (cerca de 2.000) y terminamos mejorando el tiempo de compilación en varios minutos, que tendrá un impacto positivo en toda la compañía.



El equipo del motor también invirtió tiempo en mejorar todavía más la tecnología procedimental de los planetas. Este segmento muestra la transición transparente desde la superficie del planeta hasta el espacio y muestra la mejora de la mezcla de terrenos (terrain blending) y la de estos con los objetos repartidos por su superficie, así como la mejora de la transición por disolución de estas mezclas. En el vídeo, a medida que la cámara se aleja más hacia el espacio, se puede ver como los objetos que han aparecido en la superficie van gradualmente mezclándose con el terreno hasta desaparecer de la vista.
Todavía queda trabajo que hacer para llevar a un estado completamente pulido, pero el progreso es impresionante.



CONTROL DE CALIDAD (Resumen)

En el segundo segmento del programa se presenta al jefe de Control de Calidad Justin Binford y los diversos jefes de control de calidad de los diversos estudios especializados en diversos elementos del juego, sea el FPS, planetas, controles, arte de personajes, naves, técnico. Disipan el mito de que ser un miembro de Control de Calidad sea pasarse jugando todo el día, si no romper el juego cada día de todas las maneras que haría un jugador habitual y también aquellas cosas que se le podría ocurrir a alguien aventuroso.



A menudo no saben por qué algo se rompe, exáctamente, pero se descubre cómo reproducir y se dan opiniones o sospechas sobre qué parte del código puede estar causando el bug. Trabajan para evitar que cosas ya funcionales se rompan, prueban las cosas nuevas, buscan los errores de las herramientas de producción internas, de sus editores del mundo, personajes y planetas... Es un trabajo que nunca se acaba, y que gracias a tener estudios en diversas partes del mundo se puede conseguir que nunca "se ponga el sol" sobre la solución de problemas y su aislamiento. Cuando se acerca el momento de lanzar un nuevo parche a los backers comienzan con una versión muy inestable que junto a producción van probando en sus sucesivas iteraciones, mientras indican los principales problemas a los jefes de departamento para estabilizarla. Hacen muchas cosas que se salen de lo habitual para un departamento de QA, como escribir su propio código temporal para probar cosas o soluciones.



 También hacen partidas de prueba multijugador, a veces incluyendo algunos de los desarrolladores, para probar de manera masiva ciertas cosas nuevas o para aislar ciertos bugs y de paso recolectar las opiniones de todos sobre la partida. También se ocupan de enseñar a los propios desarrolladores cómo ayudarles a reportar las cosas e informarse, porque muchos de ellos estuvieron en Control de Calidad hace años, pero las cosas han cambiado algo. Comentan lo importante que es el reporte y confirmación de bugs en Issue Council, porque siempre hay uno o dos escenarios que se escapan a sus pruebas internas y eso es lo que hacen los mecenas hacen por nosotros. Muchos de ellos predicen que van a tener largas noches de pruebas cuando llegue el momento de sacar el parche 3.0.

HAPPY HOUR MUSEUM: ARMADA, ACADEMY Y ARENA (Resumen)



En este episodio del Museum Ben se dedica a hablar sobre tres de los menores juegos de la franquicia Wing Commander, que cree que son buenas lecciones del pasado de las que aprender:



Academy (1993) -  fue una respuesta a la petición que tenía la comunidad de Wing Commander a principios de los 90 de poder manufacturar sus propias misiones. En Origin básicamente crearon un editor de misiones utilizando el motor de WC II en los que podías escoger múltiples naves (incluyendo un par de naves OP como la Wraith de la Confederación) y dejarlas caer en diferentes puntos de navegación, eliges uno de los 4 wingman para que te acompañase y te dedicabas a hacer misiones. La gente se las pasaba en persona a través de disquetes y Ben rememora sobre la época que hizo un concurso para crearlas junto con una historia que la acompañase.



Armada (1994)- fue desarrollado como un juego de estrategia en el que pones tus bases y mueves tu flota construyendo naves y luego puedes jugar cada una de las batallas como una partida típica de Space Sim. Lo mejor para Ben es el que según David Ladyman es el mejor manual que jamás ha hecho para un juego, debido a que cuenta veinte años de guerra Kilrathi en una línea temporal que incluye relatos y detalles desde ambos puntos de vista, sean de la Confederación o del Imperio. Esto incluye una carta de una niña a su padre, que le ha enviado su peluche Mr. Kat para que le haga compañía... y Ben no puede dejar de señalar que hizo mucha gracia a la comunidad y acabó siendo una de las cartas del inevitable juego de cartas coleccionables de WC. El motor gráfico de este juego ya utiliza el motor 3D que Chris Roberts desarrolló para Strike Commander y en ese momento estaba en desarrollo para Wing Commander III, por lo que sirvió de prototipo para la tecnología.



Arena (2007) - fue promocionado por un productor de EA que era fan de la saga y aprovechó una demanda del lado corporativo de hacer un shooter espacial (que por aquel entonces estaba de moda en Japón) para XBOX Live para promocionar un título nuevo de Wing Commander. Quería hacer un juego interesante de Wing Commander e iba a ser desarrollado por un pequeño estudio de NY llamado Gaia Industries, que se puso a hacer arte conceptual de naves, sus variantes, personajes que hablarían durante el juego e incluso la especie aviar firekkan.... pero nunca sucedió. Los jefes de Xbox dijeron que "la gente no quería una historia: sólo luchar", cortar las cosas que fuesen complejas, no pudieron poner el Killboard porque la palabra Kill impediría que fuese "E para todo el mundo" (así que tendría "fragboard", porque los mozos dicen frag cuando matan a alguien)... fue una muerte de mil cortes. Fue horrible. Lo único que pudo salvar Ben fue el manual, que hizo gratuitamente y para él añadió todo tipo de contenido, historias, relatos, anuncios dentro del universo (como un guiño a Tony Zurovec con el No Mercy a su Crusader), justificaciones para el juego de mierda que era... al final pusieron el mando de XBOX para que EA estuviese feliz.
« Última modificación: 05 de Mayo de 2017, 14:23:37 por Havok Specter »
 
Los siguientes usuaríos te invitarían a una cerveza por este mensaje: Esparter


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