COMIENZO
Sandi y Ben inician el programa repasando los contenidos de este episodio y el Señor Lesnick comenta que el Parche 2.2 está muy muy cerca de salir ya en el PTU. Tan pronto como el equipo de Control de Calidad interno lo haya purgado de los peores bugs lo pondrán en el PTU, estad atentos al commlink.
Star Citizen ya se ha separado de la campaña para un sólo jugador, Escuadrón 42 Episodio I. Ahora mismo se pueden comprar Star Citizen por separado y Escuadrón 42 en un bundle junto a Star Citizen. Escuadrón 42 se venderá por separado a partir del lanzamiento de 2.2, porque necesitan algo de tiempo para asegurarse de que los poseedores de ese pack tengan un acceso funcional a Arena Commander.
BBC Click hizo un reportaje de Star Citizen que fue muy bien recibido y consideraron bastante objetivo. Echadle un vistazo si os interesa. (ndt: no dicen nada nueve en ese vídeo, así que tampoco hace falta traducirlo). También hicieron otro evento BarCitizen en Montreal con los chicos de Turbuent y Behaviour, que se reunieron con los fans como hicieron en el pasado en Austin o Los Ángeles.
NOTICIAS
CIG Los Ángeles - Arena Commander Eric Kieron Davies y Adrian Banninga
- Gurmuckh está trabajando en arte conceptual adicional para la Caterpillar febrilmente.
- Documento de Diseño de Escudos en revisión.
- Arte conceptual adicional para personajes, especialmente los BDUs (Battle Dress Uniforms, uniformes de faena), de mano de Omar (Aweidah) y Jeremiah (Lee).
CIG Manchester - Escuadrón 42 Jake Ross y Tom Johnson
- Jake está de visita por Manchester así que les pareció buena idea que presentase desde la "soleada" Inglaterra, donde están planeando futuros calendarios y mucho trabajo interesante en Microsoft Project del que no pueden hablar. Tienen que estar muy sincronizados entre las zonas horarias europeas y las americanas para solucionar bugs y trabajar juntos.
- Jason Eli de Austin está trabajando con los de Turbulent para traer por fin persistencia al 'verso, creando una comunicación entre la plataforma web y el servidor del backend.
- Para Compras en el 'verso están trabajando en una fórmula de precios para cada uno de los artículos de ropa que podremos encontrar y comprar en Casaba Outlet. Tendrán unas cuantas opciones de ropa y luego variantes de las cada una de estas.
CIG Frankfurt - FPS/Motor Gráfico Brian Chambers
- Están repasando la información que obtuvieron de las reuniones con Tony y Chris y Erin durante las semana pasada, y discutieron las escenas que tienen ya bloqueadas, el trabajo coordinado de cinemáticas entre Inglaterra y Alemania, el sistema de aprobación de trabajos etc
- Se ha aprobado los cambios que harán al motor gráfico durante 2016 dando prioridad a algunas cosas y retrasando otras.
- Se centraron mucho en la tecnología procedimental de los planetas y cual debe ser el estandar y las normas que utilizará el arte que crearán para los mismos.
- Tuvieron discusiones sobre la tecnología de asteroides y cómo estos serán escalables una vez que los jugadores los puedan probar.
- Muchas discusiones sobre IAs, ya que es bastante densa en este juego y empujando mucho lo que tradicionalmente se hacer con una IA: conversar, interactuar, sus reacciones positivas y negativas... Tienen toda una serie de terminología especial para estas cosas, pero como no sabe lo que han publicado oficialmente se corta y no comenta nada más, excepto que se habló mucho sobre IA de personajes, de naves espaciales y sobre la arquitectura IA que controla todo esto, de cuales necesidades tienen en el Universo Persistente y Escuadrón 42 para ver cuales se solapan.
- En Producción han mirado que contrataciones tienen que hacer para los siguientes 6 meses y qué gente necesitan.
- Diseño miró los sistemas de misiones en el Escuadrón 42.
- Tony habló mucho de los módulos prefabricados que se usarán en el Universo Persistente y el sistema de conductos que utilizarán los entornos igual que las naves, como se comentó en esta misma sección en pasadas semanas por parte de Todd Papy.
- Han clarificado responsabilidades y trabajos entre cada departamento y estudio, lo cual siempre es bueno.
- Finalmente, agradece a los mecenas el apoyo que les han dado, cómo han apreciado el trabajo que hacen en Frankfurt y comenta lo contentos que están de trabajar en este proyecto y en un equipo global con tanto talento. Se lo están pasando genial.
ENTREVISTA CON ADRIAN BANNINGA, ADMINISTRADOR DE ARTE SENIOR
Jared Huckaby: Muy bien. Eres el Administrador de Arte Senior en la oficina de Reino Unido. ¿Qué es lo que haces?
Adrian Banninga: Soy el tipo que ayuda al Director de Arte, que las tareas asignadas al Equipo de Arte fluyen adecuadamente hasta que estén terminadas y que Producción no le mate.
Jared Huckaby: (risas) Han habido unos cuantos atentados a lo largo de los años, si... ¿Para qué tipo de cosas usamos a artistas externos subcontratados?
Adrian Banninga: Depende de nuestras necesidades en cada momento, básicamente. Los usamos para conceptos de naves, personajes, animaciones, creando algunas naves que hicimos en el pasado también... Lo que necesite arte en ese momento.
Jared Huckaby: En estos momentos tenemos artistas externos trabajando en la Prowler de Esperia.
Adrian Banninga: Bueno, la Prowler no está siendo trabajada en estos momentos porque hemos decidido ponerla en pausa porque decidimos volver a la especie Tevarin y conceptar apropiadamente su civilización. Hemos adaptado la Cadena de Montaje de Naves para que hagamos las cosas más estructuradamente que lo que hacíamos en el pasado. Primero tenemos que hacer la especie físicamente, hacer su guía de estilo artística de especie y a partir de ahí moverse adelante con las naves de la especie.
Jared Huckaby: ¿Quién está trabajando en los Tevarin ahora?
Adrian Banninga: Mark Skelton está dirigiendo a Chris Olivia a la hora de crear el concepto original de los Tevarin, y eso está sucediendo en estos momentos. Una vez que tengamos unos diseños bocetados se los enseñaremos a Chris y él eligirá los que le gusten, los iteraremos un poco más y refinaremos más las formas.
Jared Huckaby: Y entonces cuando estemos felices con los Tevarin, enviaremos la Prowler a un artista externo, ¿no?
Adrian Banninga: Cuando la especie tevarin esté definida el equipo de arte hará su Guía de Estilo, cosas como qué tipo de ropa visten, qué tipo de diseños tienen, qué tipo de arquitectura tiene su civilización siguiendo la ficción que han creado los escritores y a partir de ahí diseñamos la nave.
Jared Huckaby: Estás aquí de visita durante una semana. ¿Qué estás haciendo aquí?
Adrian Banninga: Repasando los artistas subcontratados externos que tenemos, viendo cómo podemos mejorar el proceso que tenemos, mantenerme al día revisando artísticamente lo que les hemos encargado y pensando en qué necesidades tendremos de contratación externas en el futuro, en 1 o 3 meses, y cómo podemos acomodar esto.
Jared Huckaby: El desarrollo de videojuegos es iterativo, por lo que siempre estás evaluando y reevaluando tus procesos para hacer mejor tus procesos.
Adrian Banninga: Si.
Jared Huckaby: ¿Cuanto tiempo llevas con CIG?
Adrian Banninga: Empecé hace 7 meses y medio.
Jared Huckaby: ¿Y dónde estuviste antes?
Adrian Banninga: Trasfondo muy variado. Antes estuve trabajando en un juego indie mío, llamado Darkout. Un pequeño juego basado en Terraria en un universo de ciencia ficción con una mecánica de luz y oscuridad cazando criaturas de las sombras con luz, intentando hacer algo distinto a lo que hicieron los chicos de Terraria. Los sandboxes eran muy populares cuando empecé a desarrollarlo, pero el proceso fue más largo de lo que imaginé, no me estaban pagando porque me prometían royalties futuros y es mucho más difícil que tener un juego completamente financiado.
Jared Huckaby: ¿Cuanto tiempo trabajaste en él?
Adrian Banninga: Unos tres años.
Jared Huckaby: ¿Está disponible ahora?
Adrian Banninga: Si, está en Steam.
Jared Huckaby: Mola, pues está allí si os interesa.
Adrian Banninga: Tuvo buena recepción en el aspecto visual, es un juego muy bonito.
Jared Huckaby: No quiero hacer esto muy largo, ¿pero dijiste que cruzaste a vela el Océano Atlántico cuando eras más joven?
Adrian Banninga: Si.
Jared Huckaby: Estábamos antes intercambiando historietas de nuestra juventud y ¿dijiste que cruzaste desde Ciudad del Cabo al Caribe? ¿Cuanto tiempo te llevó?
Adrian Banninga: Me llevó unos tres meses.
Jared Huckaby: ¿Por quéeee? ¿Por qué lo hiciste?
Adrian Banninga: A mis padres se les metió en la cabeza esta idea loca cuando yo tenía 16 años de construir un barco y surcar los mares. Y yo me apunté enseguida: ¿Quien quiere ir a la escuela cuando puedes irte a navegar? Así que acabamos construyendo en nuestro jardín nuestro barco y cuando tenía 19 años terminamos. Y nos llevó 3 meses ir desde Ciudad del Cabo al Caribe. Empezamos bien el viaje con una bonita tormenta en el Cabo, esa fue su propia aventura. Y luego todo lo que vino. No lo cambiaría por nada, fue una fantástica aventura.
Jared Huckaby: Es curioso tener alguien que construyó su propio barco dirigiendo la Cadena de Montaje de Naves espaciales (Risas)
Adrian Banninga: Cierto... ¡No lo había pensado así hasta ahora! (risas)
Jared Huckaby: Si, puede que tengas experiencia en ello y otro punto de vista. Gracias por venir, Adrian.
CÓMO SE HIZO: DATAFORGE, CON MARK ABENT
Jared Huckaby: ¿Qué es Dataforge?
Mark Abent: Dataforge es nuestra respuesta para resolver todos nuestros problemas con los "datos salvados" o "metadatos" a través de XML. Nos queremos deshacernos de todos estos XMLs que se mueven por todas partes en el motor gráfico para tener sólo una localización central a la que se envían los datos, donde se pueden modificar y almacenar los datos.
Jared Huckaby: CryEngine usa XMLs por defecto. ¿Por qué es importante para nosotros mudarnos de ese sistema y centralizar los datos?
Mark Abent: XML tiende a provocar errores. Puedo modificar una pequeña cosa y ahora todo eso está roto. Esto ha pasado muy a menudo con los XMLs de nuestras naves. Añades un pequeño comentario (a mi no me gusta esto, porque CryEngine no puede tener un comentario dentro de un comentario) y todo el XML se rompe. Puedes tener cosas sencillas como esas, doble citas o la cosa equivocada allí y de repente toda tu nave ha desaparecido y no sabes lo que has hecho mal. Y se vuelve especialmente problemático cuando tienes a mucha gente trabajando en los mismos XMLs y modificándolos al mismo tiempo. Cuando los fusionas se vuelve un lío.
Jared Huckaby: Y por supuesto, el juego en el que estamos trabajando es un poco más grande que lo que CryEngine fue diseñado originalmente a hacer.
Mark Abent: Si.
Jared Huckaby: Creo que nos estamos moviendo a una fase en la que los XMLs no son lo suficientemente robustos para nosotros.
Mark Abent: Si. Estaba bien al principio cuando tenías a alguien como Calyx, trabajando en solitario en ellos, pero ahora tenemos una docena de estudios trabajando en las mismas cosas y se ha convertido en una pesadilla.
Jared Huckaby: Cuatro estudios internos y subcontratas, no hemos crecido de la noche a la mañana y nos hemos expandido a 12 sin decirle nada a nadie.
Mark Abent: (risas)
Jared Huckaby: ¡Va a haber un hilo sobre esto, lo va a haber! ¿Así que Dataforge es una herramienta interna creada por Ashley Cunning?
Mark Abent: Si, Ash y David Gill. Ash es el programador principal, pero David le ayudó en algunas cosillas.
Jared Huckaby: ¿Y Ash empezó a trabajar en esto hace un año, año y medio?
Mark Abent: Se unió al proyecto hace dos años, en el momento en que se abrió la oficina de Manchester. No iba a trabajar originalmente en esto, iba a ser un Programador de Jugabilidad, pero un par de meses después de que le contratamos decidimos que necesitábamos una solución como esta y Dataforge era la respuesta. No sabíamos lo que iba a ser; pero necesitábamos que alguien trabajase en ello y Ash dijo "yo lo haré" (risas)
Jared Huckaby: ¿Por qué no nos enseñas un XML y lo que puede hacer Dataforge por nosotros?
Mark Abent: Aquí tenemos un proyectil de 20 mm que está dividido en dos XML: el que maneja los datos del diseño, la interfaz, y el que maneja los efectos gráficos. Tuvimos problemas a la hora de trabajar en estas cosas porque los diseñadores y los artistas se pisoteaban los unos a los otros en el trabajo, por lo que lo dividimos en dos.
Jared Huckaby: Incluso algo tan sencillo como una bala tenía 2 XMLs. Okey....
Mark Abent: La otra razón por la que teníamos dos es que solíamos usar algo llamado ScriptMonkey, algo que escribí yo para que en Excel tuvieses las propiedades de diseño de las armas y proyectiles y generase automáticamente los XMLs. Cuando alguien se pone a modificar las estadísticas usamos eso y el problema es que reajustaba todo y rompía lo que hacían los artistas, algo que no sabíamos en aquel momento. Si un artista entraba ahí y cambiaba el color de un láser y otro detalle y luego un diseñador tocaba algo y generaba el nuevo XML todo se iba al garete y se borraba.
Así que queríamos mantener el diseño de poder scriptar estas cosas, cambiando el diseño en un simple XML y que generase los cambios, sin tener que repasar cada uno de los XMLs del juego; pero también queríamos que los artistas pudiesen cambiar los XMLs, por lo que se tuvo que duplicar la cantidad de XMLs.
E incluso ahora se rompe de vez en cuando y de hecho dejamos de usar ScriptMonkey porque se volvió horrible de mantener tener por un lado un Excel y un XML; la gente iba directamente al XML. Hasta hoy en día hay algunos conflictos divertidos....
Jared Huckaby: Muéstranos qué puede hacer por nosotros Dataforge.
Mark Abent: En Dataforge no usamos XMLs ya, en vez de eso usamos el programa en si. Almacena todos nuestros datos: modos de juego, sistemas de conversación, personajes, ropa y... específicamente, para nuestros proyectiles, tenemos este patrón maestro que tiene todas las propiedades que queremos que tenga por defecto esta bala en particular: tiene daño, tiene un tiempo de vida, sonidos, efectos... Así que tenemos un montón de balas con las mismas propiedades, pero no tenemos por qué copiar los datos una y otra vez: a Ash se le ocurrió el sistema de variantes. Con este puedes hacer botón derecho en una variante, copias el patrón maestro y cambias cosas aquí y allá.
Pero esto es tedioso para los diseñadores que aman el EXCEL, así que puedo importar ciertas propiedades al patrón maestro desde la página de EXCEL. Y puedo crear nuevas propiedades o quitarlas.
Pero la belleza de este sistema es que un artista no tiene porque usar EXCEL, puede ir directamente a Dataforge y añadir partículas y efectos para esa variante en particular. Es un poco lo mejor de ambos mundos.
También es bueno que si un diseñador decide que algo ha dejado de existir, como este proyectil, los artistas se enteran automáticamente y dejan de trabajar en eso. También aseguramos el archivo para que sólo una persona pueda modificarlo al mismo tiempo.
Jared Huckaby: Tenemos aquí una lista de cosas como velocidad física, daño físico... Estos no son valores finales. Fue configurado así para la demostración, así que no os excitéis con lo que veáis en el programa.
Mark Abent: De hecho los autogeneré con un script antes de empezar a grabar esto. Tenemos que pasárselo a los diseñadores para que metan los valores reales.
Jared Huckaby: Veo que aparte de munición tenemos ahí niveles del juego, modos de juego...
Mark Abent: Tenemos propiedades para los niveles del juego y ciertas cosas. Si tenemos que añadir algo a un modo lo marcamos así, como que no puedas disparar en el modo de carreras.
Jared Huckaby: Dataforge no sólo es una herramienta elegante para crear XMLs, ¿almacenamos los datos de una manera distinta que en un XML, no?
Mark Abent: En la primera fase se introducen los Datos a partir de XML para salvar la información. Esto es sólo en el lado de los desarrolladores. Cuando llega a los jugadores se almacena en un blob (ndt: blob, no hay traducción perfecta así lo dejé igual) de datos binarios y lo que eso significa es que no tenemos que cargar un XML distinto cada vez que se dispara un proyectil, que aparece una nave... Si no que ya tenemos esa información en algún lugar de la memoria y cogemos la que nos hace falta. Es muy rápido.
Jared Huckaby: Estamos hablando de milisegundos, pero cuando hablas de cientos de miles de personas jugando a un juego... los milisegundos importan.
Mark Abent: Importan... tremendamente. Cuando tenemos docenas de personas (ahora puedo usar esa palabra) que tienen armas como una Gatling que puede disparar 900 balas por minuto vas a estar cargando un montón de XMLs y no queremos hacer eso: vamos a blob de datos binarios y cogemos la información que queremos.
Jared Huckaby: ¿Ahora mismo tenemos almacenadas esos blobs de datos binarios en un servidor?
Mark Abent: Ahora mismo están almacenados en nuestros servidores dedicados, pero en algún momento del futuro tendremos un servidor centralizado del que podrán tomar información los demás servidores. Con Dataforge tenemos la habilidad de "cambiarlo en caliente" o sobre la marcha, cambiando un blob de datos binarios por otro que hayamos modificado y los cambios se reflejarían al momento. Así podremos equilibrar cosas sobre la marcha en el futuro.
Jared Huckaby: ¿Es Blob Binario (Binary Blob) su nombre oficial?
Mark Abent: Es usado en todas partes internamente, así que supongo que así se bautizará. (risas)
Jared Huckaby: Los cambios hechos aquí se actualizarán al juego. ¿Podemos ver un ejemplo aquí de cómo actualizas un arma?
Mark Abent: Si, mira, es como si estuviese preparado de antemano. Mira, aquí bajamos la velocidad de 1180 m/s a 118 m/s y puedes ver cómo el proyectil va mucho más despacio. Que no os extrañe que "caiga", esta demo está en una caja con gravedad.
Jared Huckaby: Ralentizar algo está bien, pero ¿Puedes convertirlo en algo completamente distinto como una nave?
Mark Abent: Voy a quitarle el material, porque todos usan el mismo solenoide, y voy a poner una M50. ¡Y ahora estoy disparando M50s! (risas)
Jared Huckaby: Ponle un efecto de sonido, a ver como suena...
Mark Abent: Pew, pew, pew...(risas)
Jared Huckaby: Revierte eso a su estado normal antes de que me meta en problemas.
Mark Abent: (risas)
Jared Huckaby: Gracias por darnos este breve tour del Dataforge que ha estado más de un año en desarrollo. Es excitante poder almacenar todo en un mismo sitio, ahorrarnos todos esos milisegundos llamando a memoria esos XMLs y tenerlo en los servidores dedicados.
Mark Abent: De nada.
Jared Huckaby: En serio, arregla la nave...
Mark Abent: (risas)
CLASE DE DISEÑO DE NAVES ESPACIALES
Gurmukh terminó de explicar una clase de diseño de naves en 3D y han hecho cazas monoplaza. A Ben Lesnick le emociona que vivimos en un mundo en el que se enseñe a hacer naves espaciales con los estudiantes.
Gurmukh Bhasin: El propósito de la clase era intentar que la gente se sintiese cómoda explorando conceptos en 3D. Una de las cosas que hago en Star Citizen es diseñar naves en concepto 3D completo y quería compartir mi técnica con gente que estuviese interesada en esto para explorar ideas y conceptos en 3D.
El objetivo era hacer un caza monoplaza similar a la Gladius. Quería que fuese para Aegis porque es uno de los fabricantes más bonitos del juego y quería que fuese un caza monoplaza porque el curso es de 10 semanas y creo que todos los estudiantes no habían hecho un concepto en 3D anteriormente, era su primera vez usando 3D para muchos o creando algo así para ellos.
El objetivo es que se sintiesen cómodos diseñando una nave estilo Star Citizen en 3D a partir de la nada y creo que todos los que entregaron su proyecto hicieron un gran trabajo.
MVP
El de esta semana va a Ghost sobre su vídeo "What is Star Citizen: A full explanation". Es prácticamente imposible resumir Star Citizen en 18 minutos, pero hizo un gran trabajo.
SNEAK PEAK
Asientos de la Reliant.
