Star Citizen #HG

#18093 Pues sera cosa mia pero vamos, esta bajando a unos tristes 150kb/s y si pongo cualquier otra cosa a bajar se descarga al maximo sin problemas (2MB/s)

#18098 ¡Por supuesto!

Esperate a la venta que se hará el próximo 19 de noviembre ,que a lo mejor sacan a la venta la aurora mr aniversario .

1- Como productores tenéis la oportunidad de echar un vistazo en profundidad al juego y a la gente que trabaja en sus diversos sistemas. ¿Hay algo que siempre quisisteis hacer (u os gustaría poder hacer) si tuvieseis las habilidades apropiadas? ¿En qué os gustaría trabajar?

Eric Kieron Davies: Si habéis visto el Meet the Devs, mi trasfondo estaba en animación y cuando salí de la Facultad quería ser animador. Conseguí el grado de Animador e Interpretación... todo lo que necesitaba para obtener una sólida animación de un personaje. Y ese era el camino que yo seguía... Así que para mi, me gustaría meterme en el lado de animación de interpretación y personajes para transmitir una historia. Me encanta contar una historia.

Darian Vorlick: Así que este es tu Papel Protagonista como Productor Senior... (risas)

Eric Kieron Davies: (risas) Supongo...

Darian Vorlick: Te has entregado a ti mismo el papel de Productor Senior y ese es tu guión... (risas)

Eric Kieron Davies: Si, por supuesto. ¿Y tú?

Darian Vorlick: Probablemente el aspecto de escritor y de la ficción del proyecto. Dada mi trayectoria como editor me encantaría ser un Administrador de Proyecto vigilando como se desarrolla la escritura. Crear una mitología es algo que me parece muy interesante. Tengo un amor muy arraigado por las publicaciones impresas tradicionales. Hay algo romántico y clásico en sujetar un libro entre tus manos y saber que tú tuviste algo que ver en su creación. Pero... bueno, me gusta en realidad lo que hago, interactuar con los desarrolladores e ingenieros. Es diferente de cualquier otra cosa que haya hecho y me gustan las cosas nuevas.

Eric Kieron Davies: Ahí tenéis nuestra respuesta.

2- Como productores supervisáis el desarrollo del proyecto y coordináis las diferentes disciplinas (Arte, Diseño etc) para unificarlo en un producto acabado para el juego (una nave, localización, etc); pero para hacer esto debéis poneros al nivel de detalles del proyecto. ¿Cómo hacéis para mantener las distancias y el objetivo final frente a perderos en la "conejera" de los detalles? Dadnos un ejemplo.

Darian Vorlick: Hemos estado esperando y preparándonos para responder a esta pregunta.

Eric Kieron Davies: Es muy difícil. Más adelante hablaremos sobre esto; pero la idea es contratar a nivel de producción a gente con diferentes especialidades y gustos para que te proporcionen diferentes perspectivas. Si es algo técnico es mejor tener a algún productor que controle en esos aspectos para darte las respuestas. Como Darian dijo en un mensaje: "conoce lo suficiente para ser peligroso".

Darian Vorlick: Si. En realidad esa cita es de Jason Hutchins.

Eric Kieron Davies: Totalmente cierta. En general, depende en lo que te tengas que meter. Es bueno tener un plan general y un calendario que haces con tus jefes de departamento, pero en cierto sentido tienes que meterte en los detalles para profundizar. No deberías hacer sólo una de las cosas, si no ambas en el momento apropiado.

Darian Vorlick: Cuando empecé aquí yo no era un programador o un ingeniero, por lo que había una sensación de estar fuera de lugar al llegar. No estaba seguro de que podría hablar al nivel necesario para comunicarme con los diseñadores y los ingenieros; pero a base de pura saturación siento que puedo tener una conversación semi-inteligente sin tener que utilizar señales y gruñidos. Ser capaz de tener una conversación sobre el sistema de objetos o el sistema de tokens de identidades. Debemos ser capaz de hacer preguntas sobre cómo va el progreso de algo y saber cuando algo nos está, en cierto sentido, engañándonos para poder anticipar las necesidades de esa disciplina. No hay que ser expertos en ella para poder tener una conversación sobre ellas y administrarlas.

Eric Kieron Davies: Para daros un ejemplo, tenemos el sistema de tokens de identidades. ¿Cómo lo administraste?

Darian Vorlick: Tuvimos una conversación esta mañana con el programador de Reino Unido, Stephen Humphries, que está escribiendo la secuela de GOST: el sistema de tokens de identidades. Yo no se hablar gráfico de flujos en CryEngine; pero como sé lo suficiente sobre lo que quieren lograr con este nuevo sistema puedo prever sus necesidades o si alguien abandonase esta parte del proyecto qué podemos hacer para solucionarlo. Saber quien tiene qué habilidades es útil para llenar ese vacío.

Eric Kieron Davies: Saber equilibrar vista general y detalle es la propia razón por la que existen los productores. Somos la perspectiva externa del proyecto y por lo tanto, de manera intrínseca, esto nos permite tener esta vista de pájaro que nos permite entenderlo.

Darian Vorlick: A veces tener conocimientos técnicos es una hoja de doble filo, porque te puedes poner sin darte cuenta a corregir errores del código o diseño en vez de administrar y coordinar a los programadores y diseñadores que se deberían dedicar a ello.

3- ¿Cómo hacéis estimaciones de tiempo en situaciones en las que aparecen "bloqueadores técnicos"?

Darian Vorlick: No es un problema especial respecto a otros problemas de desarrollo. Simplemente preguntamos al experto cuanto tiempo creen que les llevará respecto a cosas similares que ya han hecho en el pasado y nosotros como productores miramos la escala de lo que hacen para hacer el ajuste proporcional.

Eric Kieron Davies: Si.

Darian Vorlick: Cuando aparecen problemas técnicos... bueno, es lo de siempre. Cuando publicas un calendario de fechas interno se convierte instantáneamente en algo obsoleto porque las fechas y el tiempo de una tarea cambia cada día. A veces algo que podría llevar poco tiempo se alarga porque necesitamos a una persona esencial para resolver rápidamente otro bloqueador técnico que se ha presentado. Debido a que tenemos una cantidad limitada de recursos el tiempo que un desarrollador entrega a una tarea es todavía más valioso. Ser capaz de de planear el tiempo que va a llevar algo así es muy difícil.

Eric Kieron Davies: Al final siempre se añade un tiempo extra adicional del 5 o 10%. Si lleva 2 semanas te daré dos semanas y media, por ejemplo. En general la producción real suele extender un poco más que ese búfer que has creado pero se hace para proteger al equipo, porque no sólo quieres cumplir si no impresionar con lo que entregas.

Darian Vorlick: También hay que entender la diferencia entre 5 días de trabajo y 5 días hábiles. Si durante esos 5 días hábiles Mark Abent ha estado trabajando en otras cosas el tiempo de finalización se puede extender.

Eric Kieron Davies: Estar en producción de un juego ya lanzado (ndt: la pre-alpha), más desarrollo, más pre-producción y producción tienes que añadir tiempo adicional porque a veces tiene que resolver bugs aquí y allá. Es una buena pregunta, pero al final es conocer el equipo y hacer una buena estimación.

4- Se ha comentado varias veces que CIG está reuniendo sus recursos en distintas partes del mundo, poniendo a gente con el mismo tipo de habilidades en el mismo lugar y de esa manera evitando los problemas de trabajar con gente en distintas franjas horarias. Desde un punto de producción, ¿Cómo ha mejorado esto la eficiencia del proyecto? ¿Ha afectado, por ejemplo, a la velocidad en que se está remodelando la Freelancer?

Darian Vorlick: ¡Ese es un ejemplo sospechosamente específico!

Eric Kieron Davies: ¡Si! No sé por qué nos habrá puesto la Freelancer de ejemplo... Chris explicó esto en su carta y a la gente le gusta mucho leer entre líneas; pero en realidad no hay nada que ver entre ellas. Simplemente estábamos mirando cómo hacer lo mejor para el proyecto. Cómo hacerlo de manera más rápida y eficiente. Y hacemos esto constantemente. Verás cambios de este tipo en el desarrollo de cualquier videojuego, rehaciendo el equipo de desarrollo. En mis viejos empleos reorganizábamos el equipo cada año o cada seis meses (ndt. Blizzard): es muy común. Si sabes que puedes hacer una nave más rápidamente no necesitas tanta gente en el equipo. O necesitas más gente para acabar antes. Sea cual sea el caso, así es la industria.
Este cambio está en marcha en estos mismos momentos y nos estamos moviendo para terminarlo cuanto antes. Un ejemplo de por qué esto será bueno es nuestro equipo de Sonido en Reino Unido, dirigido por Lee Banyard: trabajan bien y rápido, entregando materiales cuando se solicitan. ¿Por qué son tan buenos? ¡Por que están todos juntos en el mismo sitio! Cuando algo pasa, se giran y trabajan en equipo para arreglarlo. No tienen que esperar 24 horas para que llegue un email. Todavía tenemos múltiples estudios porque tiene sentido tenerlo así, pero estamos unificando disciplinas y veréis sus efectos durante los siguientes meses.

Respecto a la Freelancer... ¿Darian?

Darian Vorlick: No tengo nada que comentar al respecto.

Eric Kieron Davies: Muy bien. (sonrisa maligna) Investigaremos al respecto y ya te informaremos.

5- Como productores hacéis de Administradores del Proyecto y por lo tanto tenéis un enorme papel vigilando el desarrollo del juego. ¿En qué momento juzgáis oportuno intervenir cuando veis que una persona o una subcontrata está teniendo problemas con la tarea que se les asignó? ¿Qué acciones habéis tomado en esos casos? Adicionalmente, ¿Los equipos están formados por individuos trabajando en tareas solitarias o en equipos pequeños dirigidos por un líder más experimentado?

Darian Vorlick: En nuestra jerarquía de equipos tenemos un Líder para cada equipo: Diseño, Ingeniería, Arte. Estos Líderes dirigen esos equipos. Cuando creamos una tarea para alguien son generadas en colaboración con los líderes del equipo, de manera que estos siempre estén al tanto de lo que hacen sus subordinados. Y nosotros como producción tenemos una vista general de lo que debe ser hecho.
Si por ejemplo vamos a añadir unas características para el siguiente parche nos sentamos con los líderes de equipo y averiguamos que hace falta para que sean terminados. Las dividimos en tareas individuales y las empezamos a mirar qué desarrolladores con las habilidades apropiadas están libres.

Eric Kieron Davies: Respecto a qué acciones hemos tomado cuando algo es díficil...

Darian Vorlick: Hablamos con ellos.

Eric Kieron Davies: Cualquier cosa. Evaluamos si la tarea fue increíblemente mal planeada y en vez de dos días hacen falta tres meses. Un gran error y tenemos que reunirnos con los líderes. Quizá tenemos problemas informáticos o quizá les hemos retirado demasiado tiempo de sus tareas para resolver bugs. Quizás no funciona en nuestra estructura actual. Un ejemplo de esto es mover cadenas de montaje enteras a distintas localizaciones de nuestros estudios porque tenemos la gente apropiada para hacerlo allí, no porque la gente estaba fracasando en su trabajo y queríamos deshacernos de ellos. Hacemos lo que tiene más sentido y se evalúa constantemente mediante nuestras prácticas de contratación.

6- ¿Qué desafíos aparecen cuando hay cambios de trabajadores en un departamento? ¿Qué pasa cuando se cambian productores? ¿Hay que reasignar algunas responsabilidades? ¿Tenéis responsabilidades divididas entre vosotros o todos tenéis una vista general de lo que sucede? ¿Tenéis problemas de comunicación por tener idiomas o culturas distintas?

Eric Kieron Davies: En esta industria, especialmente en las del entretenimiento, la gente cambia de trabajo. Es algo normal. Consiguen otro trabajo, se les promociona, se casan, tienen que mudarse a otro país, tienen hijos que van a la escuela... La gente va y viene. Es algo muy fluido y no tiene nada de nuevo.
Para nosotros es una cuestión de tener planes de contingencia y saber quien puede dominar algo en el entorno presente de desarrollo. Cuando alguien se va nunca hay, para nada, la expectación de que todos los productores lo sepan todo. No hay manera de hacer esto, sería algo que superaría a cualquiera con el nivel de producción de esta compañía. Así que si, lo dividimos en responsabilidades. Darian por ejemplo trabaja con el equipo de Ingeniería de Santa Mónica, con los lanzamientos públicos y también vas a hacer X, Y y Z. Probablemente estarás implicadas en estas tres cosas y también oirás de otras cosas porque estás en ese mismo estudio; pero no se te requiere saberlo todo. De hecho, tenemos que confiar los unos en los otros.
Así que cuando alguien me dice: hey, he conseguido un fantástico trabajo, mi mujer tiene que hacer tal cosa, o mi marido esto, no pasa nada: tenemos el plan de contingencia. O se reparte sus responsabilidades y trabajo o miramos si es posible contratar a alguien nuevo y filtramos eso de nuevo. Por muy mal que suene, tenemos un plan de contingencia para cualquiera aunque "les atropelle un bus". Si. Queremos asegurarnos de que la gente sepa lo suficiente de los demás para que puedan echar una mano si es necesario.

Darian Vorlick: Siempre es una buena señal de que estás haciendo buenas prácticas cuando la compañía no se desmorona cuando alguien se va. Si eres tan esencial y central que si te vas las cosas se van al garete.. eso recalca las ineficiencias de la prácticas de vuestro estudio. Como Administrador del Proyecto tengo que asegurarme de que si yo me voy las cosas sigan funcionando como un mecanismo de relojería.

Eric Kieron Davies: Sobre las barreras de cultura e idioma, somos personas adecuadas a las que preguntar esto. En anteriores trabajos tuve que hacer negocios en China por múltiples razones, poner en marcha ciertas operaciones y para mi esto fue un desafío, sea por frases que utilizas, terminología o jerga de email o poner ejemplos de deportes que no conozco como el fútbol. ¡Usa términos de beisbol o algo así! Son ejemplos de un poco tontos, porque nuestra oficina de Frankfurt habla perfectamente en inglés y trabajan muy bien; pero hay desafíos.

Darian Vorlick: Ricky Jutley de Reino Unido estuvo por aquí y viceversa, por lo que estamos creando algo de intercambio cultural y hace que la compañía sea mucho más homogénea.

Eric Kieron Davies: Siempre consideramos que las cosas se hacen por un esfuerzo de equipo y no queremos andar por ahí diciendo a la gente que "es culpa tuya". Echar la culpa a los demás no funciona, ni en tu familia ni en los negocios.

Darian Vorlick: Crea animosidad y toxicidad. Es una reacción innata señalar con el dedo y decir: "Es culpa vuestra".

Eric Kieron Davies: Si, se trata más de encontrar la raíz del problema y solucionarlo a gran escala. Por supuesto, si alguien ES un problema se toman las apropiadas decisiones de negocios al respecto.

7- ¿Cómo hacéis para tener múltiples versiones de desarrollo al mismo tiempo? Ejemplo: 1.3, 2.0 y Star Marine. Además, ¿podríais explicarnos la importancia de unificar el código en 1.3 para el proyecto y si hace que sea más fácil desarrollar?

Eric Kieron Davies: El 1.3 y su unificación del código ayudó inmensamente porque todo el mundo, a nivel global, usamos el mismo código. Rompió algunas cosas unificar todo esto; pero ahora estamos todos mirando la misma versión y trabajando en la misma. Queremos mantener este conjunto unificado de desarrollo.

Darian Vorlick: Eso y que además queremos poner mucho énfasis en la estabilidad del sistema y puede que os hayáis dado cuenta de que ha mejorado mucho últimamente desde que hacemos esto.
Respecto a tener varias versiones del juego al mismo tiempo en desarrollo... ¡Esa es la razón por la que tenemos múltiples equipos! Una persona puede estar trabajando en una versión propia, mientras otros trabajan en una versión más pública y esto reside en tener un buen equipo de Control de Calidad que detecte los bugs que van a apareciendo en el parche 1.3 y que podrían afectar a la versión principal de desarrollo. Hay que estar atentos a lo que sucede en cada versión, vigilar los hitos del proyecto que deben ser alcanzados y utilizar Jira de manera muy eficiente. Tenemos una interfaz que nos permite saber qué tareas y bugs tenemos en cada versión en desarrollo, qué bugs bloqueadores, críticos y triviales hay allí y hablamos diariamente sobre qué tareas o bugs deben ser atacados el día siguiente.

Eric Kieron Davies: Si. Respecto a cómo nos ayuda: enormemente. Esto permite trabajar en la versión pública 1.3 que ya tenéis mientras se automatiza sus arreglos que se añaden a la versión principal para que no haga falta orquestar esos arreglos en la versión principal cuando tengan que sacar otra versión pública.

Thomas Henessy (Cámara): ¡En el programa de hoy, Darian y Eric discuten las ventajas de cruzar los streams! (Ndt: juego de palabras en referencia a "nunca cruzar los rayos" en Ghostbusters y a cruzar otro tipo de chorros fisiológicos XD)

Eric Kieron Davies: ¡Me gusta!! Asegúrate de editarlo de manera que no sea muy pervertida.... ¡Siguiente pregunta!

8- ¿Si algo se vuelve muy complicado para ser finalmente implementado en el juego se elimina o se simplifica? Y además, ¿Qué métodos utilizáis para criticar el trabajo ajeno, fechas de entrega etc? ¿Palo o Zanahoria?

Darian Vorlick: Respecto a la primera pregunta, ahora mismo cuando se usa el Flowgraph (Como en la conversación de esta mañana con Humphries sobre el sistema de tokens de identidades) tenemos un ping en la red y eso hace que se saturen mucho las líneas, así que una de las cosas que estamos decidiendo es si es bueno diseñar cosas de las naves usando Flowgraph. De esto sale una conversación entre diseñadores sobre si es mejor programarlo a mano o usar flowgraphs de todas formas o usar los tokens de identidad. Todo esto se planea por adelantado y se hace I+D para ver si es posible, haciendo pruebas de concepto y prototipos y cual de ellos funciona mejor.

Eric Kieron Davies: Si. Sobre la siguiente pregunta sobre palo o zanahoria.. Yo no creo en esas dos opciones, porque este viejo adagio te lleva a nunca conseguir esa zanahoria y eso acaba cansando. Es mejor trabajar a través de los líderes de departamento, presentando pequeños objetivos fáciles de lograr y motivar de manera consistente y constante diariamente. Amenazar o sobornar no lleva a ninguna parte, sobre todo trabajando en un ambiente tan creativo como este en el que se crea entretenimiento y experiencias divertidas. No estamos haciendo un engranaje o un coche, algo probado y hecho millones de veces: estamos haciendo algo nuevo y vamos improvisando sobre la marcha como hacerlo. Requiere de mucha más sutilidad que ese tipo de viejas prácticas.

Darian Vorlick: Es cierto. En los estudios en los que se gobierna con puño de hierro... es algo anticuado y que al final es contraproducente porque nadie aporta sus propias ideas. Es mejor usar un esfuerzo colaborativo, un toma y un daca, conversando diariamente con nuestros compañeros locales e internacionales sobre los bloqueadores y problemas que tienen y qué ideas pueden aportar.

Eric Kieron Davies: Además, si estás usando el método de la zanahoria y el palo es que estás forzando a alguien a hacer algo que odia.

Darian Vorlick: Y no queremos compulsar a nadie.

Eric Kieron Davies: ¡Nos encanta trabajar en esto y nuestra pasión nos lleva a trabajar cada día en este proyecto! No hace falta usar esos métodos forzosos. Respecto a la crítica positiva y negativa... ¡queremos ambas cosas! Es cierto que siempre queremos hacer las cosas mejor y las miramos de manera negativa y crítica para hacerlas mejor, pero tenemos que motivarnos señalando lo que nos gusta y lo que ha salido bien para ir hacia delante. Las críticas negativas están bien, como en los foros, porque nos señalan lo que creen que hicimos mal y las buenas nos indican qué puntos fuertes tuvimos y en qué tuvimos éxito. Eso nos ayuda a mejorar las cosas.

Darian Vorlick: Y si, a veces tenemos que poner el pie en el suelo y trazar una línea. Sé que te encantaría añadir esta nueva característica a la nueva versión pero no podemos porque no tenemos ni tiempo ni recursos para hacerlo bien. Mejor esperar al siguiente parche y mientras tanto ajustarlo y pulirlo más.

9- ¿Qué proporción de vuestro trabajo no veremos en mucho tiempo comparando con cosas que veremos a corto plazo? ¿Estamos viendo lo último recién salido del horno o estamos disfrutando de viejo contenido ya pulido? ¿Qué estilo de desarrollo tenéis: en cascada o ágil? ¿El entorno de trabajo se parece más a Mad Max o a Jurassic Park?

Eric Kieron Davies: (risas)

Darian Vorlick: Bromeamos sobre que a veces pinchamos al equipo para conseguir lo que queremos, pero siempre lo decimos en broma. ¡Muy raramente tenemos que obligarles a hacer algo, por eso tengo una gran espada en mi oficina!

Eric Kieron Davies: (risas)

Darian Vorlick: Es una pregunta interesante porque una gran parte de lo que hacemos ha sido planeado hace muchos meses, pero muchas veces mientras trabajamos para un evento hasta el último momento. Hay cosas que intentamos arreglar y meter en el juego hasta el último día que entran en el parche o tenemos una mecánica nueva que lleva mucho tiempo en desarrollo pero que no se mostrará hasta que llegue un evento. Realmente vemos la versión terminada de nuestro trabajo cuando lo veis vosotros en directo.

Eric Kieron Davies: Si.

Darian Vorlick: Esto es parecido a trabajar en una película. Los actores sólo ven sus líneas y se las aprenden. No ven la película acabada hasta que van a una presentación privada previa al estreno. A menudo lo vemos unido días antes o a veces en directo. Si nos veis en los vídeos estamos animando tanto como vosotros por lo que vemos, porque es fantástico, podemos ver el resultado de lo que hemos estado haciendo los últimos meses.

Eric Kieron Davies: Si, mantenemos la cabeza gacha y a veces es difícil ver cómo de gran somos. Tenemos una mezcla de ambas cosas: una lista maestra en el calendario y constantemente nos aprovechamos de ella para hacerla realidad. Las cosas que os mostramos es gran parte de lo que tenemos, lo hacemos tan a menudo como podemos y a menos que sea una gran revelación como el Discurso de Bishop, que queremos que sea excitante cuando llegue, intentamos mostrar todo lo que tenemos pero todo esto son partes de lo que todavía está en construcción de un gran universo. Por eso Chris lo dividió en módulos, para que vieseis su partes.

Darian Vorlick: Cuando enseñamos en Around the Verse un Sneak Peak de una nave o concept art es porque estamos trabajando de manera activa en ese arte, por lo que para cuando llegue el momento de lanzarlo en Arena Commander será la culminación de meses de trabajo que vosotros habréis visto antes gracias a la transparencia que tenemos con nuestro desarrollo. Respecto a metodología de desarrollo..

Eric Kieron Davies: ... es bastante ágil, si. No es 100% ágil, hardcore, pero al mismo tiempo tomamos cosas de la cascada alcanzando ciertos objetivos y se unifican entre ellos. La agilidad es la micro en la macro de la cascada.

Darian Vorlick: Yo uso la metodología de mi hermano, la metodología Dwit: Do Whatever It Takes (haz lo que sea necesario).

Eric Kieron Davies: Hazlo.

Darian Vorlick: Respecto a si es Mad Max o Jurassic Park (risas), voy a hacer un chop de la cara de Eric sobre la de Chris Pratt de Jurassic World y pondré las caras del resto de los desarrolladores sobre las de los raptors cuando está en el pozo de estos dinosaurios (risas).

Eric Kieron Davies: Es una pregunta dura. Una expresión habitual es "pastorear gatos", porque cuando tienes gente tan creativa mantenerles unidos es un desafío.

10- ¿Cómo usáis Jira? ¿Es la fuente de la verdad, modificada y ajustada para llevar vuestro desarrollo al día, o usáis tablas de cálculo para llevar el día a día?

Eric Kieron Davies: Tenemos una metodología más que implementada a estas alturas y Jira es una de nuestras herramientas de producción y estamos animando a la gente a mantener su estado al día para mejorar comunicación y trabajo entre estudios y saber qué trabajo queda por hacer. Gracias a esto y hacer buenos calendarios te puedes hacer una idea del tiempo, recursos y tareas que quedan por hacer para completar tus objetivos. Jira sirve para recolectar toda la información y ver qué lo bloquea para quitarlo del medio y llegar a la siguiente versión. "Si no está en Jira, no existe": ese es nuestro mantra.

Darian Vorlick: También sirve para tener responsabilidades. Cuando alguien inicia una tarea en Jira tenemos un registro sobre el tiempo invertido en una tarea, qué gente está en ello y cuanto tiempo falta. Esto es lo que nos permite acelerar las cosas, hacer reuniones de coordinación más eficientes.

Eric Kieron Davies: Cualquier herramienta de producción es tan buena como la gente que la use y que la mantenga al día. Saber que Calyx está trabajando en algo y ha terminado otras cosas nos permite asignar otras tareas que ya son posibles o allanar el camino a la que tiene en marcha. Así se toman decisiones más rápidas.

Darian Vorlick: Si Zane decide un día hacer un HUD de interfaz para naves de tipo capital y no está en su lista le decimos que esto está genial, lo metemos en el calendario, pero le conminamos a que haga las tareas que necesite el proyecto en este momento. Respecto al flujo del trabajo y tablas de cálculo: yo soy un hombre Excel. Lo he usado mucho y lo amo.

Eric Kieron Davies: No creo que nunca dejemos de usarlo, porque es una gran herramienta para planear escenarios y situaciones. Puedes mover las cosas con rapidez hasta que tengas todos los datos. Jira necesita datos reales.

Darian Vorlick: Hemos usado también Microsoft Project, Shotgun... todos trabajan simultáneamente en el proyecto a su manera.

Saludos, ciudadanos.

¡Esta última semana ha pasado volando! Nos complace presentaros el segundo informe semanal acerca de en qué se ha avanzado tanto en "Star Citizen 2.0" como en "Star Marine".

¿Las novedades más molonas? ¡AHORA LAS NAVES SE PUEDEN PARTIR EN DOS (o más) TROZOS! Sí, los equipos de código y de diseño técnico han estado trabajando duro y haciendo que esta emocionante característica funcione en el motor del juego, y han conseguido finalmente implementarla... ¡por lo que a partir de ahora seréis capaces de reventar las naves en distintos trozos cuando les hayáis infligido daño catastrófico! Ahora podréis darles realmente candela a vuestros peores enemigos causándoles daños irreparables a sus naves, como, por ejemplo, partir una Constellation en cuatro trozos distintos. El sistema todavía necesita recibir un poco de cariño antes de que podamos ponerlo a vuestra disposición, pero en cuestiones de funcionalidad técnica, hemos hecho unos avances rompedores (¡perdón por el juego de palabras!).

Todo el mundo ha estado puliendo detalles y corrigiendo bugs, y todavía nos están llegando algunos contenidos procedentes de varios departamentos, contenido que incluye más elementos de audio que suenan fabulosos. Nuestro especialista en diálogos ha estado en Pinewood Studios (famosos por las películas de James Bond y el juego "Privateer 2: the Darkening") y en SIDE UK para grabar más fragmentos de diálogo referentes a grabaciones de audio, que están resultando ser un elemento de exploración muy divertido de buscar.

Todavía nos estamos peleando con el sistema EVA para conseguir alcanzar ese punto en el que nos parezca que está perfectamente terminado, pero al menos le estamos sacando más jugo a los sistemas de la nave en lo que concierne al comportamiento de la IA. La IA tendrá en cuenta ahora los nuevos encuentros y escenarios a los que los jugadores se enfrentarán en Crusader. Por ejemplo, la construcción del mapa está equilibrada para que si el jugador se aleja demasiado de la seguridad de las zonas de la UEE, puede que tenga algún mal encuentro, o a lo mejor tiene suerte y no sufre ningún disgusto. ¿Quién sabe? La belleza de todo ello es que es todo una jugabilidad con enfoque sistémica en la que cada encuentro posee su propio potencial único.

¿Y qué pasa con la parte relacionada con "Star Marine"? Con nuestras botas en el suelo, estamos viendo algunas mejoras notables en las animaciones de recarga de armas del FPS, apuntar con la mira y empezar a moverse y parar, por lo que estamos muy contentos de que todo esté empezando realmente a cobrar forma, y no sólo es que los personajes tengan mejor aspecto, sino que el entorno también lo tiene. El equipo de Entorno ha estado ocupado con las distintas estaciones espaciales en sus etapas finales de diseño artístico, y la Central de Carga Covalex justo acaba de recibir una pasada completa de iluminación, ¡por lo que estamos seguros que va a dejar apabullada a la gente!

Crusader en todo su conjunto parece ahora mucho más vivo y con más interacción con los bots de reparaciones y la implementación de los sistemas de simulación de tráfico de fondo, ¡que servirá para darle auténtica vidilla al mapa con todos esos comerciantes y patrullas de la UEE deambulando de aquí para allí! Éste es otro de esos primeros pasos que Star Citizen dará con esta versión, ya que el universo empieza a cobrar vida poco a poco gracias a la creación de todos los sistemas que producirán de forma orgánica las economías y comunidades con las que podrás jugar.

Por último, hay algunas grandes mejoras referentes al rediseño de las IU de las pantallas internas de las naves, rediseño que se ha hecho para que tengan en cuenta todas las mecánicas de juego nuevas asociadas a las naves multitripuladas. El equipo de diseño de IU está realmente emocionado por el aspecto que está adquiriendo todo, y cualquiera de nuestros lectores al que le guste trastear con aparatitos se sentirá entusiasmado cuando pueda por fin manejar la primera implementación de la pantalla de ingeniería, que permite un mayor control sobre la distribución de potencia y los sistemas de escudos de vuestras naves. Esta nueva pantalla, además, se centra en la funcionalidad para permitirte pasar tu atención de forma rápida y sencilla a cualquiera de las pantallas individuales que hay distribuidas en tu puesto. Las IU de estas pantallas necesitaba tanta consideración porque supondrán los cimientos de todo el resto del sistema durante los próximos años, y nos permitirán irles añadiendo cada vez más funcionalidad a medida que naves más y MÁS grandes van llegando al juego.

A continuación tenéis un resumen general de en qué está atareado cada uno de nuestros departamentos...

JUGABILIDAD E INGENIERÍA

• Las naves llegan con mayor precisión al final de las sendas de vuelo de IA.
• Las naves que siguen sendas de vuelo de IA utilizan mejor la esquina dinámica de obstáculos.
• Se ha mejorado la conducta de huida de una nave cuyo caso haya sufrido daños graves.
• Se ha mejorado el uso de misiles por parte de las naves.
• Las naves son más precisas a la hora de esquivar obstáculos.
• Se ha cambiado la relación entre los brazos del personaje y la cámara, lo que mejora el apuntado con la mira y los disparos desde la cadera.
• Se han solucionado problemas con los saltos del jugador.
• Se han pulido los conjuntos de movimientos de la pistola para que estén al mismo nivel que los del fusil.
• Se ha mejorado el uso de las físicas de "muñeca de trapo".
• Las partidas en red tienen ahora en cuenta el combustible cuántico.
• Se ha añadido un test de colisión antes de iniciar el viaje cuántico. Sirve para informarte de si hay objetos entre ti y el destino programado.
• Se ha añadido soporte para balizas de navegación para viaje cuántico descubribles.
• Se ha mejorado/pulido la funcionalidad del dron de reparaciones.
• Optimización de la red.

IU (interfaz del usuario)

• Mejoras en el HUD de viaje cuántico
• Ahora hay círculos alrededor de los puntos de interés
• Se ha añadido la cantidad consumida de combustible cuántico
• Se ha añadido un mensaje de "fuera de alcance" se tratas de hacer un salto para el que no tienes suficiente combustible.
• Casi todas las naves tienen ahora HUDs de viaje cuántico
• Se ha entregado la primera iteración del gestor de misiones
• 5 pantallas para el mapa de Crusader
• Se ha entregado una implementación básica de las pantallas de Ingeniería con apartados de Potencia, Escudos, Resumen General y menú minimizado (hace falta ponerla a prueba).
• Se ha pulido la pantalla de Ingeniería.
• Implementación de "spawneo" de naves.
• Mejoras en el gestor de misiones.
• Ahora aparece una lista de las misiones completadas.

ARTE

• Nuevas iteraciones del Cutlas, el Retaliator y la Constellation en sus pasos finales de la cadena de montaje.
• Mejoras finales del arte y efectos visuales para el entorno.

ANIMACIONES

• Más iteraciones de las interacciones con el entorno, EVA, movimiento y uso de armas en FPS, reacciones al sufrir impactos y morir, y secuencia de "dejarse caer".

SONIDO

• Sesión de grabaciones de diálogos para algunas frases adicionales y regrabado de algunas ya hechas antes.
• Se ha empezado a trabajar en mejoras en el audio de las naves.
• Implementación de más música para mejorar el "feeling" de cada zona y "venderte la escena".
• Se ha trabajado en parámetros de "rigores del vuelo" que serán aplicados a tu nave bajo ciertas condiciones.
• Se ha empezado a diseñar audio para esas condiciones.
• Mejoras en el sonido de las armas y utensilios del FPS.
• Se está ampliando la variedad de sonidos de pisadas que se pueden oír en cada superficie.
• Se está trabajando en mejor las cualidades atmosféricas de las estaciones espaciales.

BLOQUEADORES

• A los personajes les faltan secciones interiores de sus cascos.
• Las armas balísticas causan un cuelgue del juego y hay otros problemas de estabilidad que deben arreglarse.
• El sistema de "tirar y empujar" parece estar en conflicto con algún otro sistema de control, ¡porque ahora mismo catapulta al jugador hacia lo más profundo del espaciooooooo!
• Las partículas parecen dejar de renderizarse en algunas zonas con gravedad, ¡pero no en todas¡ ¡Esto hay que investigarlo!

MIRANDO HACIA EL FUTURO

¡Uf, vaya semanita! Como podéis ver, estamos haciendo muchos progresos en lo que parece ser la versión más emocionante de Star Citizen hasta la fecha. Tras la publicación este mismo día (en el momento de colgar este artículo en la página de RSI) de la versión pública de "Star Citizen Alpha 1.3", ¡nuestro siguiente objetivo es la versión PTU de "Star Citizen Alpha 2.0"! No podemos esperar a que podáis explorar (y, para seros sinceros, ¡romper!) el Mini PTU. Todo el equipo está trabajando lo más duro posible para ponerlo a disposición de los backers para que puedan probarlo.

Tened en cuenta que aunque durante esta semana nos hemos centrado sobre todo en la Aplha 2.0, el informe de la semana que viene traerá más detalles sobre "Star Marine".

Traducción por Vendaval para Ciudadano Estelar

#18110 El FPS va a ser parte del siguiente parche 2.0 (se va a poder hacer FPS en estaciones espaciales y tal), pero el Star Marine como tal (el rollo PVP enlatado tipo CS) saldrá en un parche posterior. Por el momento se quieren centrar en unificar todo y luego sacarán la parte más competitiva para equilibrar cosas.

En reddit lei que si no lo ponen se entiende que de momento lo tienen controlado, pero no implica que este limpio al 100%. Ya les ha pasado otras veces que lo consiguen eliminar como bloqueador y les vuelve en la siguiente build interna.

COMIENZO
El parche 1.3 está fuera y la gente se ha vuelto un poco loca con los Buggies. Ben admite que están un poco bugueados; pero necesitaban hacer un test de carga de las mecánicas de colisión. 1.3 es un parche post-fusión de todas las versiones del juego que han estado en desarrollo paralelo los últimos meses, pero también metió la nueva zona de la Galería y un par de armas nuevas en Arena Commander.

El equipo de la Comunidad irá a Austin en un par de semanas para grabar un ATV allí. También harán allí un evento en un bar de Austin para los mecenas de la ciudad.

NOTICIAS

CIG Santa Mónica - Arena Commander Eric Kieron Davies y Vince Sinatra.

• Vince Sinatra, Jede de Control de Calidad en L.A., se ha unido al equipo de allí para ayudar a probar las mecánicas de la nave durante su diseño.
• Se está trabajando en el anillo de atraque de la Constellation, de la mano de Olwin Bachiller, así como en los LODs de la nave.
• Randy Vazquez está haciendo el diseño técnico de la Caterpillar.

CIG Austin - Universo Persistente Jake Ross, que regresó de sus vacaciones en las Smoky Mountains

• La UI de Compra está siendo mejorada entre Tony Zurovec, Zane Bien y Carl Jones, de la que pronto tendremos una previsualización de su aspecto y de como fluirá.
• Casaba Outlet, la tienda de ropa, ya está toda hecha en whitebox y están haciendo el modelado final para que se puedan mover por dentro los jugadores bien y accedan a las estanterías de la ropa bien.
• Trabajando en un efecto de "amortiguación" de la cámara en primera persona durante los emotes, ya que algunos eran realmente molestos al seguir la acción del personaje con la cabeza, especialmente bailando.

CIG Manchester - Escuadrón 42 Tom Kewell y Simon Vickers

• Tom ha estado trabajando en Star Citizen Alpha 2.0 en la mecánica temporal de reparación que van a meter mientras se desarrolla la mecánica real que tendrá el juego, en la que podremos ensuciar nuestras manos. Lo están haciendo así para que se repare rápidamente y se pueda explorar y testear el 2.0 por ahora.
• Simon ha estado poniendo Eventos de Fondo en el sistema para mostrar al jugador el estado de este cuando lo visita, como cuando vas a localizaciones como una estación de reparación. Hay una posibilidad de que algo aparezca en esa localización, como una nave IA, que te muestre el tráfico normal de esa localización. En el caso de 2.0 encontraremos un conflicto entre los piratas y las fuerzas de la UEE, con apariciones de patrullas de la UEE o emboscadas piratas o mercaderes independientes buscándose la vida. Todas las IAs reaccionarán entre si de manera sistemática: las patrullas atacarán a los piratas si los ven o el pirata intentará atacar mercaderes para robarles su carga. Estas naves visitarán las estaciones de reparación de Tom de la misma manera que la de los jugadores, recibirán daños etc para crear un pequeño diorama de lo que será finalmente el juego.

CIG Frankfurt - FPS/Motor Gráfico Brian Chambers

• Brian nos hace un pequeño tour a las nuevas oficinas de Frankfurt a partir de 9:26-12:00. No mucho que comentar aquí, salvo que han aumentado la plantilla a 30 desarrolladores y en sus amplias y cómodas oficinas tienen espacio para 49.

ENTREVISTA CON PETE MACKEY Y JOHN PRITCHETT SOBRE MODELOS DE VUELO

Jared Huckaby: Hola a todas. Han tenido lugar recientemente algunas conversaciones sobre los próximos cambios por los que pasará el Modelo de Vuelo. Conmigo hoy tengo al Diseñador Pete Mackey y al Programador de Físicas John Pritchett para hablar algo del mensaje de Modelo de Vuelo que con suerte publicaremos al final del día de hoy para explicar cómo avanzará este tema de ahora en adelante.
Para empezar las preguntas, ¿cómo hemos evolucionado hasta tener el modelo de vuelo que tenemos hoy en día?

John Pritchett: Los dos objetivos principales que me plantee desde un principio con el modelo de vuelo fue:

• Asegurarse de que el comportamiento durante el vuelo fuese bueno y suave, porque en el vuelo espacial quieres notar que las naves tienen mucha inercia y
• Que este fuese altamente dinámico y adaptable a variaciones y condiciones inesperadas que nos encontrásemos. Desde un principio queríamos que hubiese daños a los impulsores, por lo que no quería ir administrando esto de nave en nave y era obvio que necesitábamos un sistema de respuesta. Y eso es lo que hice. El Algoritmo de Control de Respuesta es básicamente un control de aceleración exponencial, que nos da algo mejor que un cambio de aceleración instantáneo, que es lo que tenemos con movimientos de segundo o tercer orden: las aceleraciones no pasan de 0 a máximo instantáneamente, lo hacen gradualmente. Lo malo de esto es que el tiempo de ajuste exponencial puede ser muy largo y los jugadores notarían eso cuando pasan de máxima velocidad a cero, y es algo que quería mejorar.

Jared Huckaby: Pete, ¿qué opinas del modelo de vuelo actual?

Pete Mackey: Lo que los jugadores han reportado en algunos casos es que parece poco riguroso. El efecto secundario que obtienes al tener una aceleración exponencial es que es un poco inestable en su extremo de la curva. (risas)

Jared Huckaby: Muy bien. Hemos tenido el modelo de vuelo ya durante un año. ¿Qué es lo que hace que este sea el momento adecuado para cambiarlo?

John Pritchett: Nos llevó algo de tiempo tener el tiempo para ponerlo en las manos de los jugadores y obtener sus opiniones sobre lo que debía cambiar, pero una vez que nos dimos cuenta de esto no quise dar un paso atrás en la calidad del movimiento y su adaptabilidad, por lo que me llevó algo de tiempo encontrar la solución apropiada. Lo que se me ocurrió fue que utilizásemos movimientos del tercer orden: un cambio de aceleración que no asume que la aceleración pueda cambiar instantáneamente. Me llevó tiempo hacerlo funcionar de manera apropiada con el complejo sistema que tenemos.

Jared Huckaby: (risas)... el complejo sistema que tenemos... Esto era algo que siempre estaba planeado que sucediese. No es que sea una nueva idea que se nos acaba de ocurrir hace unas semanas. El desarrollo de juegos es iterativo y esto siempre iba a ser el siguiente paso.

John Pritchett: Si, bueno... volviendo un poco a los comienzos, podría utilizar el sistema como un sistema de respuesta de manera que cuando introduzcas un cambio a tu velocidad se introdujese un nuevo punto de velocidad que el sistema de respuesta de control suavizaría por ti para solucionar el error de velocidad actual hasta llevarlo al deseado; pero eso es lo que introduciría ese tiempo de respuesta, esa falta de reacción torpe de la que hablamos.
Tras haber reconocido eso, tomamos la decisión de introducir un perfil de movimiento más óptimo que se aprovechase del todo de la aceleración y velocidad de la que disponía la nave, para que pueda cambiar de un estado al otro en la menor cantidad de tiempo posible optimizando lo que puede hacer la nave.

Pete Mackey: Respecto al tiempo que nos ha llevado.. esto es algo de lo que hemos hablado yo y John desde Diciembre del año pasado, inicialmente, y le presentamos nuestra idea a Chris oficialmente en Abril o Mayo, por lo que recibimos la luz verde para empezar a trabajar en ello hace unos cuatro meses. No sólo trabajamos en el movimiento estándar del que estamos hablando ahora, si no todo el paquete que estamos bautizando como IFCS 2.0.

Jared Huckaby: Gran introducción. Hablemos de lo que vendrá con 2.0. ¿Quien quiere empezar?

Pete Mackey: Además del trabajo que ha estado haciendo John con los algoritmos de control de movimiento, también hemos estado haciendo otras mejoras de jugabilidad. Estamos añadiendo tres nuevos modos a IFCS y esto nos proporciona mucho más control en diferentes circunstancias. Tenemos:
1 - Modo de Precisión: que te pone un límite en la velocidad máxima y escala tu aceleración en función a la cantidad de movimiento que le des. Esto da mucho más control cuando estas cerca de una plataforma de aterrizaje o extrayendo mena de un asteroide o haciendo salvamento de materiales. (Risas)
2 - SCM, Velocidad de Maniobra Espacial: superficialmente es muy similar a lo que tenemos actualmente, pero en vez de tener una velocidad máxima estáticamente definida ahora estará determinada por tu aceleración. Así que cualquier cosa que altere tu capacidad de acelerar modificará tu velocidad máxima. Cualquier cosa que cambie tu masa (como la configuración de tu nave, añadir carga, mejorar tus impulsores) alterará tu velocidad máxima.
3 - Modo de Crucero: Mientras que SCM se trata de controlar tu velocidad máxima, Crucero se trata de obtener la velocidad máxima que puedas al precio de sacrificar tu maniobrabilidad. La velocidad máxima será significativamente mayor que en velocidad de Maniobra. Si ahora mismo los máximos están en torno a los 300 m/s, crucero los puede elevar hasta los 1.000 m/s. Aún estamos intentando determinar qué máximo será apropiado para el Universo Persistente, pero ahora mismo está en 1.000 m/s. A esta velocidad es muy fácil perder la consciencia y es muy difícil recuperarse de una maniobra de deslizamiento, por lo que aplicamos un límite de giro a la rotación de tu nave: la orientación de tu nave está fijada en la misma dirección que tu vector de velocidad. Maniobrar a esta velocidad va más de hacer correcciones de dirección y menos de hacer giros. (risas) Definitivamente, no es una velocidad que quieras utilizar en un campo de asteroides o en un lugar donde hay muchas naves volando por ahí.

Jared Huckaby: ¡Acepto el desafío!

Pete Mackey: (risas) Ah, y otra cosa que me olvidé mencionar es que junto a SCM tenemos los Posquemadores también aplicados a tu aceleración en el nuevo sistema, lo cual permite que tu velocidad máxima también sea incrementada dinámicamente durante esos períodos. Este incremento de velocidad te permitirá mantener relativamente el mismo grado de control sobre tu nave. Como no queríamos perder que este incremento de aceleración fuese útil para maniobrar cerca de asteroides, por ejemplo, hemos separado el Modo Postcombustión (Afterburner Mode) del Modo de Impulso (Boost Mode) para que puedas tener la maniobra ágil sin incrementar tu velocidad máxima, lo cual proporciona mayor control. El Modo Postcombustión te da el mismo control pero mayor velocidad máxima. Ahora tienes esta elección dual, tienes que escoger en qué inviertes tu combustible: ¿Postcombustión o Impulso? Ambos estarán disponibles con sólo pulsar un botón.

Jared Huckaby: ¡Mola! Eso significa que habrá cambios a la interfaz de usuario, ¿no?

Pete Mackey: Si, tenemos algunos cambios. Zane y el departamento de UI te ayudará en esto, indicándote en que modo de vuelo te encuentras y a cual cambiarás si usas el botón de modo de vuelo, pero creo que tiene planes a más largo alcance sobre esto... (risas) aunque no quiero hablar por él.... para mostrar del todo las capacidades de este sistema.

John Pritchett: Voy a intentar cazar unas cuantas capturas de pantalla. Si no lo tenemos listo para este vídeo lo veréis cuando salga 2.0.

Jared Huckaby: ¡Mola muchooo! (risas)

Pete Mackey: El mensaje es muy largo, así que dejaremos para ello algo allí y que se lo lean, pero John, quería que hablases algo sobre el error antes de que terminemos esto. ¿Qué nos puedes contar sobre el sistema de errores?

John Pritchett: Uno de los problemas que tuvimos con el sistema desde un principio es que era demasiado perfecto. El movimiento podía parecer tan mecánico que parecía un videojuego. Uno de los principales principales objetivos del sistema es que se pudiese adaptar bien a condiciones cambiantes e inesperadas, por lo que estamos empezando a aprovecharnos de esto ahora que tenemos el tercer orden de movimientos, el nuevo perfil que tenemos ahora, que te dice cómo debería moverse la nave... pero no hay ninguna expectación de que se mueva así por una serie de razones. Esas razones podrían ser, por ejemplo, imperfecciones en la respuesta de los impulsores que se pueden incrementar a medida que son dañados. Puedes decirle al impulsor que empuje en cierta dirección con cierta potencia; pero no va a hacer eso a la perfección, y eso lo percibes como la turbulencia de un avión al desplazarse. Estamos trabajando en esto para que sea algo cosmético, no queremos que sea una molestia o tenga un enorme impacto sobre cómo se comporta el vuelo para los jugadores, por lo que lo ajustaremos según pase el tiempo. Queremos que la nave tenga algo de movimiento y no se sienta tan rígida al maniobrar.

Jared Huckaby: Si. Queremos que cada nave tenga su propia personalidad, no sólo en su aspecto si no en sus característica de vuelo.

Pete Mackey: Por supuesto.

John Pritchett: Si.

Jared Huckaby: Así que, a partir de ahora y de ahora en adelante esto no será el fin de los cambios del equilibrio del modelo de vuelo. Es sólo el comienzo de la siguiente fase. Pondremos este mensaje en la página web y recibiremos sus opiniones en los foros cuando salga el parche 2.0. Vosotros os habéis presentado voluntarios a pasaros por allí de vez en cuando y responder a las preocupaciones de la gente y leer sus opiniones, descubrir lo que es relevante y lo que podéis incorporar a vuestro plan. ¿Qué pueden hacer, de ahora en adelante, para ayudaros?

Pete Mackey: Ahh, bueno, estamos mirando todas sus opiniones, sean dirigidas específicamente a nosotros o comentarios puestos aquí y allá. Pero déjame volver un poco atrás. El cambio del modelo exponencial al modelo de tercer orden es significativo a nivel de sensaciones de pilotaje. Aunque las naves entreguen el mismo rendimiento en lo que respecta al tiempo que les lleva completar una acción, la sensación de eso no se parecen en nada. Eso va a cambiar y eso es lo que vamos a utilizar para dar a cada nave su propia personalidad. Estaremos mirando en dos direcciones distintas. ¿Funciona este equilibrio para las naves? ¿Las naves se perciben idénticas al maniobrar con naves de rendimientos similares pero diferente diseño? Estas son las dos cosas principales que vigilaremos y cualquier opinión que recibamos en este sentido será más que bienvenida.

Jared Huckaby: Aseguraos de indicar que nave estáis pilotando y, una vez que el sistema de itemización esté implementado, aseguraos de indicar también qué impulsores estáis utilizando y la configuración. Siempre estamos leyendo.

Pete Mackey: (Risas) ¡Por supuesto!

Jared Huckaby: Yo siempre leo. Chicos, muchas gracias. El mensaje debería salir más tarde y este vídeo debería estar incrustado en él si no lo viste. John, Pete, gracias por hacer esta conferencia conmigo.

Ben Lesnick: Calyx, Pete, y John han estado duramente trabajando en hacer este mensaje realidad.

CÓMO SE HIZO EL SONIDO DEL MAPA ESTELAR 29:30 El Mapa Estelar del Arca ha sido nominado en múltiples premios web, incluyendo ganar el Premio CSS.

Philip Smallwood: Hola, soy uno de los diseñadores de sonido de Foundry 42. Cuando empezamos a trabajar en el sonido del mapa, yo y Matt nos dividimos el trabajo a partes iguales. Estuve feliz por combinar nuestros esfuerzos.

Una de las primeras cosas que me encargaron fue los puntos de salto cuando se viaja de un sistema solar a otro. Lo diseñé tomando una serie de sonidos de un puñado de bibliotecas de sonido que tenemos a nuestra disposición. Aquí los podéis ver en el programa de edición, efectos de viento, de retumbes, truenos. Tenía unos sonidos del Cometa Rosetta que molaban mucho; pero no pude utilizarlos por razones de copyright. (risas)

Lo que intentamos conseguir fue tener un aspecto elemental, así como uno más digital; porque es una representación digital del espacio y conexiones a lo largo de la galaxia, pero también queríamos que tuviese un "peso" estilo ciencia ficción. Una mezcla de elemental con interfaz de usuario

Matteo Cerquone: La primera cosa que hice, obviamente, fue escucharme el sonido que Philip había ya creado.

Philip Smallwood: Lo que hago típicamente es arrastrar un montón de recursos sonoros al editor y entonces procesarlos para obtener unos elementos más ciencia ficción de ellos, como esta explosión real pasada por un efecto de cristalización y volcán para darle una buena reverberación con mis plugins, que aquí no hay...

Matteo Cerquone: (risas) Yo no tengo tantos instalados como el resto de la gente, si.

Philip Smallwood: No pasa nada (risas, toquetea explosión y trueno antes de llegar a una explosión sintetizada con un toque de volcán). Y también cosas de la "vieja escuela" como "whoooshes", viejos trucos como coger una explosión, duplicarla y revertirla.

Matteo Cerquone: Yo intenté no pensármelo mucho y crear sonidos para ver cómo de bien encajaban con las imágenes en si. El problema que teníamos al principio es que cuando creábamos los sonidos, como el de punto de salto o zoom, es que eran muy potentes al poner la música. Y como la música era tan inmersiva y los sonidos la ahogaban tanto tuvimos que volver a ajustarlo. Lo que tenemos aquí es una combinación de diferentes sonidos. Normalmente, en mi tiempo libre, intento crear mis propios sonidos para poder usarlos de referencia o reutilizarlos. Es como este que tengo aquí renombrado como "sonido de arma de ciencia ficción", lo diseñé específicamente como el ruido que se hace al desenfundar un arma con un toque de ciencia ficción, pero cuando volví a revisar mi diseño de sonido me gustó mucho y decidí que lo quería tener en el mapa.
La capa de sonidos es siempre un conjunto de bibliotecas de sonidos. Yo uso todo el rato Massive, por ejemplo.

Philip Smallwood: Cuando nos asignaron el mapa estelar nos lo entregaron con unos sonidos temporales de referencia que teníamos que sustituir. Lo que hicimos fue buscar las cosas que molaban más del mapa y quedarnos con ellas. Yo me quedé con los puntos de salto, zoom in y out y entre yo y Matteo hicimos los sonidos.

Matteo Cerquone: De nuevo, es difícil explicar lo que hicimos en realidad porque básicamente lo que hacemos es darle al botón de grabar y empezar a glitchear cosas (Philip sonrie), por lo que hicimos estas regiones muy grandes de sonidos y regresamos a ellos para editarlos cuando los oíamos de nuevo para tomar los elementos que más molan.

Philip Smallwood: No hay un rendimiento en esto. Tienes que grabarlo y toquetear cosas aquí y allá. Una gran parte de lo que hacemos son felices accidentes y no obtienes lo que quieres. ¡Lo difícil es recrear lo que hiciste!

Matteo Cerquone: Exacto.

Philip Smallwood: Saber lo que pensabas cuando lo hiciste. Intentamos ir en nuevas direcciones y también usar sonidos muy reconocibles en la cultura popular.

Matteo Cerquone: Al final, no hay reglas fijas. Como era en el espacio queríamos que fuese algo artístico y bello que encajase con la música en vez de intentar hacerlo muy específico.

Philip Smallwood: Es encontrar un punto medio y crear algo especial.

EMPIRE REPORT, ÚLTIMAS NOTICIAS 36:30

Alan Nuevo: Estamos recibiendo noticias de que ha tenido lugar una gran explosión industrial en Marte. Conectaremos ahora con Victoria Hutchins, la cual estaba allí en otra comisión cuando tuvo lugar el siniestro. ¿Victora?

Victoria Hutchins: Así es, Alan. Fue hace aproximadamente una hora. Estaba paseando junto a muchas otras personas en Port Renatus cuando tuvo lugar una gran explosión. Aunque los detalles aún no han sido confirmados, una gran humareda parece que se eleva desde la Refinería de Shubin Interstellar, la cual opera una muy atareada operación geológica aquí. De nuevo, no hay nuevas noticias sobre la extensión de los daños o las heridas que hayan tenido lugar en estos momentos.

Alan Nuevo: Gracias, Victoria. Más detalles en cuanto estén disponibles y esperad ver una actualización completa sobre esta noticia en el Empire Report de esta noche.

MVP
Stargazer, que voló junto a la Agencia Espacial Francesa y llevó su modelo de la Constellation para que volase en gravedad cero.

• También agradecemos a los miembros de Operation Pitchfork que nos hayan enviado su manual de operaciones para nuestros escritores, que incluye los parches de logos que han creado... es un proyecto que mola mucho y que tenemos muchas ganas de masacrar sin piedad.

SNEAK PEAK
Otra versión de la Khartu-al