Autor Tema: 10 for the Producers Episodio 2  (Leído 789 veces)

30 de Diciembre de 2014, 04:01:12
Leído 789 veces

Havok Specter

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


Traducción por Frost en CE.



COMIENZO

Dicen que contra toda posiblidad, aquí están de nuevo los Productores de la oficina de Santa Monica. Travis Day y Darian Vorlick.

1- ¿NECESITAN RECLUTAR MÁS DESARROLLADORES EN CIG?

Darian explica que están contratando constantemente gente nueva, de manera global. Acaba de llegar un nuevo grupo de trabajadores al estudio de Austin y de Santa Mónica, por lo que siempre están buscando el cómo crecer como compañía.
Travis Day es el que dirige gran parte del reclutamiento, porque es un gran juego que hacer. Están buscando gente en particular ingenieros de jugabilidad, ingenieros de versiones, un experto en flash para ayudar a Zane, artistas para hacer naves, diseñadores técnicos... muchos de los cuales están en el proceso de contratar. Y también productores.
Vorlick dice que lleva ya tres meses y medio en la empresa y ya en la primera semana no era el novato allí. La cantidad sube constantemente, ahora en Santa Mónica ya son más de 40. Si queremos unirnos al equipo de CIG no hace falta más que pasarse por la página web de Cloud Imperium Games y mirar qué trabajos se están buscando en estos momentos. Si tus habilidades y experiencia encajan con lo que están buscando, te contratarán.

2- ¿CÓMO DE A MENUDO TIENEN QUE REHACER LOS PROCESOS DE PRODUCCIÓN, COMO LA CADENA DE MONTAJE DE NAVES? ¿ES ESTO NORMAL EN EL MUNDO DE LA PRODUCCIÓN DE VIDEOJUEGOS?

Si, tal cual. Cada día tienen una nueva idea de cómo hacer las cosas o añadir algo al juego y tienen que planificarlo de nuevo. En el tiempo desde que tomó Travis Day el control de la Cadena de Montaje de naves en Agosto han añadido 1) Pintura de naves, lo cual necesita de un segundo conjunto de UV para todas las naves, rehaciendo todo y los estados de daño. 2) Ahora Foundry 42 está añadiendo un nuevo sistema de daño procedural a las naves, lo cual podría eliminar de la cadena un 50 o incluso 75% del trabajo que lleva hacerlos.

Como ejemplo, podemos ver como la Cutlass fue puesta en el hangar en Diciembre de 2013 y esa nave originalmente no tenía un diseño ni variantes terminados, por lo que ahora Foundry 42 tiene que hacer whitebox en torno a lo que antes no sabían cómo funcionaría: ¿que es una bahía médica? ¿cómo funciona? ¿que es caza de recompensas? ¿cómo capturas gente? ¿cómo la entregas? Ahora tienen respuestas a estas cosas y tienen que volver sobre las naves para ver con ojo crítico si estas encajan con los roles para los que han sido creadas para tener un ciclo de jugabilidad funcional.

Pero bueno, así es todo el desarrollo de juegos. Siempre es una búsqueda de ideas y cómo hacer bine las cosas. Siempre están intentando acelerar el proceso, simplificarlo, hacerlo más cómodo, pasando por cosas nimias como el documento de producción semanal y de progreso hasta cualquier parte de la producción del juego.

3- ¿YA QUE EL DINERO NO ES ACTUALMENTE UN PROBLEMA, CUALES SON LOS CUELLOS DE BOTELLA DE STAR CITIZEN? ¿HAY PROBLEMAS ESPECÍFICOS A ESTE PROYECTO, DEBIDO AL MINI-MECENAZGO?

Lo que les atasca es el "periodo de gestación". Cuando se está trabajando en algo técnico tienes a personas esenciales trabajando en ese proyecto mientras no tienen tiempo para trabajar en otras áreas. Están viendo esto, por ejemplo, en la conversión a Mundos Grandes (mapeados de 64 bits) porque tocar el código de otra persona puede romperlo todo, por lo que hace falta que un programador lo haga todo... el solito. Es más eficiente así. Es el mismo ejemplo que el de la mujer embarazada: si tienes 9 mujeres no vas a tener un niño cada mes, si no un 9 cada 9 meses. Estas cosas son normales en el desarrollo de videojuegos o software.

En el tema del mini-mecenazgo... impacta que el juego sea tan abierto a la comunidad y que tengan tantas iteraciones. La comunidad tiene un mayor efecto que de donde proviene el dinero en si, pero al menos no tienen las visitas de los "trajeados" de la corporación o notas del editor o el dueño de la licencia... por lo que tienen más libertad y tranquilidad.

Pero volviendo al tema de los cuellos de botella, hay situaciones en las que arrojar más dinero y personal a un problema no es la respuesta. Y eso es algo que cada estudio descubre tarde o temprano. ¿Debemos contratar a más gente o debemos simplificar las cosas y seguir con la gente que tenemos? Ellos empezaron con un pequeño estudio en Austin en el que tuvieron un problema de demasiados "cocineros en la cocina" con sus propias ideas, algo muy común en el desarrollo de videojuegos. En los pasos iniciales esto no va a ayudar. Es mejor comenzar de manera pequeña y decidir qué van a ser las cosas y cómo van a funcionar y una vez que lo tienes claro poner a trabajar a equipo en paralelo en cada una de las cosas. Es un proceso orgánico.

4- ¿PODÉIS EXPLICAR EL PROCESO DE RASTREO Y SOLUCIÓN DE BUGS, CON TIEMPO MEDIO DE SOLUCIONADO, GENTE IMPLICADA, ETC? ¿HAY UN SISTEMA PARA EVITARLOS?

Tienen un equipo de Control de Calidad que revisan los bugs que encuentra la comunidad, comprueban si funcionan y son añadidos a su propio software de rastreo de bugs. Los productores echan un vistazo a la naturaleza de estos, miran si tienen los recursos para solucionarlos (ej, si es un bug del HUD necesitarían a Zane.) y entonces los asignarían a cada persona. Luego intentan conseguir una estimación de estos trabajadores respecto al tiempo que llevará solucionarlos para saber el tiempo que tendrán esa semana o mes para hacer otras cosas.

¿Cuanto tiempo lleva? Depende de si es crítico, moderado, trivial, tal como sea clasificado por el software de rastreo Jira. Esto ayuda a saber que es prioritario para solucionarlo rápidamente, como hicieron para el 1.0 y meter las nuevas naves, pero que no solucionaron algunos de los "viejos problemas conocidos" porque saben que van a cambiar los mecanismos de esos bugs en si y no vale la pena solucionarlos. Es una cuestión de prioridades, sin más. Puede llevar 5 minutos arreglar un bug en particular pero a lo mejor se lo mandan a la persona apropiada tras una semana de trabajo en otras cosas. Muchos son declarados "WNF" (Will Not be Fixed, No será arreglado) y se dejan para otro parche. Si es un bug que es esquivo a la hora de ser reproducido y el empleado puede perder 16 horas en él pasa a veces a tener baja prioridad si no es un bug importante y esperan a tener mejores pistas de la comunidad o Atención al Cliente.

5- ¿CON EL RECIENTE CLAMOR POR "MAYORES, MEJORES Y MAS MALOTAS "NAVES MULTI-TRIPULACIÓN O CAPITALES... ¿SEGUIRÁ CIG HACIENDO NAVES DE TAMAÑO PEQUEÑO O MEDIANO PARA AQUELLOS QUE NO LES INTERESAN LAS GRANDES? ¿PENSÁIS QUE EL CONJUNTO ACTUAL DE NAVES MONOPLAZA-PEQUEÑAS SON SUFICIENTES?

A largo plazo, esto será informado por parte de Diseño, pero a corto plazo hay objetivos de financiación que han seguido añadiendo naves de pequeño tamaño como la Reliant de MISC, el Bulldog de Aegis... Hay un conjunto considerable de naves de ese tamaño, de 1 a 3 asientos. Una vez que tengan el Universo Persistente en marcha y lo llenen de los roles que quieren meter y tengan las escalas adecuadas de naves para esos roles, puede que encuentren "espacios" entre estos que llenar.

Esto es lo de siempre: jugar el juego mostrará qué debilidades tiene y qué necesidades tiene que suplir.

6- CHRIS DIJO EN 10FTC 46 QUE TENER INSTALACIONES DE BAÑO/DUCHAS/CAMAS/COCINAS SERÍA IMPORTANTE.. ¿HABRÁ ALGUNA NAVE MONOPLAZA DECENTE QUE CUBRA ESAS NECESIDADES?

Varias de nuestras naves monoplaza tienen camas, el Mustang Beta tiene también cocina, almohadas, baño, ducha... es tu nave de "forever alone".

7- ¿QUE PASA CON EL VIEJO SISTEMA DE MEJORA DE COMPONENTES AHORA QUE VAIS A METER EL NUEVO SISTEMA DE NAVES MODULARES?

La idea tras el sistema modular para las naves tipo Avenger, Cutlass, Retaliator etc no es que puedas cambiar disipadores, aviónicas, placas madre, motores etc. Eso ya se podía hacer y se podrá seguir haciendo. El sistema ya soporta eso. La modularidad lo que permite cambiar bloques enteros internos por otros. Lo que esto te permitiría es cambiar una bahía de carga por una bahía médica... o transportar prisioneros. Esto permite que si la nave está diseñada bien internamente puedas tener más capacidad de modularidad interna, subiendo hasta naves como la Idris o la Javelin o la Carrack, cambiando habitaciones enteras por otras que te interesen más para que puedas personalizar todavía más las funcionalidades y roles que puede cubrir tu nave.

Las mejoras de la nave son otra cosa, permiten que pasen más datos por la placa madre, o instalar más programas de aviónicas para fijar más naves, etc. Esto permitiría fijar más naves y más rápidamente que una nave sin estas mejoras.

8- ¿CAMBIAR EL CÓDIGO DE LOS MAPAS A 64 BITS AFECTARÁ A LAS ACTUALIZACIONES DEL MOTOR GRÁFICO POR PARTE DE CRYTEK O CRYTEK ACEPTARÁ EL MAPEADO DE 64 BITS COMO UN ESTÁNDAR?


Preguntaron esto a los viejos miembros de CryTek que ahora trabajan para ellos: Paul Reindell, Sean y Dan Tracy, James Wright. Sean dijo que era una buena pregunta y dijo "cambiar muchas de las implementaciones básicas de los tipos de datos hace que la implementación sea más difícil, por lo que en algunos casos la actualización será automática lo cual mitigará el problema, pero los momentos más duros llegarán cuando CryTek meta nuevas características del motor que use esos tipos de datos, por lo que tendrán que hacer su propia adaptación del código."

James explica que "el cambio del mapeado a 64 bits es muy preciso en su ámbito de posiciones en el espacio de juego y transforma pocas cosas fuera de ello. No es un cambio generalizado a 64 bits. Aunque sube la dificultad a la hora de integrar cosas, no lo hace imposible.En cierto sentido, añadir a la versión principal los mundos de 64 bits será similar a lo que es ahora integrar nuevo código de CryTek... por lo que tienen muchísima práctica a estas alturas."

En el frente de CryTek, Paul Reindell dice "el motor gráfico ya está muy alejado del motor básico de CryEngine, por lo que el cambio a 64 bits lo hará todavía más extraño al código básico. Pero esto no es extraño que esto suceda cuando licencias un middleware: los adaptas al juego que estás haciendo y sus necesidades. Baste decir que las modificaciones hechas a Star Citizen van más allá de las que nadie ha necesitado o hecho hasta ahora basándose en CryEngine."

9- ¿PODREMOS ESCUCHAR EL RUÍDO QUE GENERAN CUERPOS CELESTIALES COMO ESTRELLAS, GALAXIAS O AGUJEROS NEGROS, CON ALGUNA ESPECIE DE "RECEPTO DE RADIO" ESPECIALIZADO? HE OÍDO EN TEDTalk QUE ESTO ES POSIBLE Y AUNQUE NO SERÍA MUY ÚTIL, SERÍA MUY MOLÓN.

Travis Day dice que no había oído de esto, pero Darian Vorlick dice que lo investigó y parece que cada cuerpo celestial tiene un "sonido", como se pudo ver en el aterrizaje en el asteroide de Rosetta, recientemente. Puedes ir online y escuchar el patrón de ruído que genera Júpiter, por ejemplo, con sus frecuencias de radio. Esta es la razón por la que la exploración con radio-telescópios es un campo tan amplio de estudio, porque todo genera su propia frecuencia.

No sabrían cómo lo utilizarían, la verdad. Empiezan a hacer chascarrillos sobre poner un enorme sensor en la nave con forma de oreja o poner una trompetilla, de referencias al libro de Contact con los planos del túnel y la nave espacial que encontraron en los números de constantes matemáticas como Pi. Travis hace la broma que aparecerá un fan en una CitizenCon con barba hasta los pies y uñas sin cortarse en meses con un fajo de papeles diciendo "¡lo he encontrado!" XDDD "Mi mujer me ha dejado, pero ahora todo tiene sentido".

10- ¿Porque se aparca en una Driveway y se conduce en un Parkway?

Esta pregunta es en plan casual por decir algo y Vorlick explica que originalmente Driveway era el espacio entre las casas por el que discurrían los coches y que significaba "el camino que lleva a conducir" no "el camino en que se conduce". Por lo tanto, ambos términos se refieren hacia donde vas y no donde estás. Vaya fumada
 


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