1- ¿Creéis que el desarrollo de Star Citizen se volverá más estable (más fácil de preveer a la hora de los lanzamientos) una vez estén terminados los sistemas de instanciado, Grandes Mundos, FPS y AR 2.0? ¿O habrá mucha fricción cuando todo esto se integre? ¿Cómo vais a mantener estable la versión pública/PTU del juego mientras estáis integrando cosas en la versión Main/desarrollo?
Travis Day: ¡Buena pregunta! Es la primera pregunta relacionada con producción que hemos tenido en el programa.
Las cosas que destacas en la primera pregunta son nuevas características para el CryEngine que están en I+D, por lo que requieren mucho trabajo por parte del equipo de programación. Tienen un objetivo que quieren alcanzar, pero la ruta para llegar allí no está inmediatamente clara desde el principio y es una cosa que se descubre a medida que se avanza. Y esto hace que sea menos predecible saber cuando se terminará su producción: tienen un "bajo cociente de predictividad" (he creado un nuevo término). Así que si, estas cosas aumentan impredeciblemente la llegada de nuevos lanzamientos y esto afecta en cascada a otras cosas: si algo utiliza Grandes Mundos y no sabemos cuando estará listo, las cosas que dependen de esto no se sabe cuando llegarán.
Respecto a tu pregunta principal: Una vez que estás cada vez más cerca va quedando más claro a medida que se añade y mantiene el proyecto cuando saldrán las cosas y por lo tanto, cuando más cerca estemos del final del proyecto y hay menos I+D, y menos nuevas características y más creación de simple contenido, será infinitamente más fácil predecir cuando estarán listas las cosas. Producir contenido es muchísimo más predecible: arte, niveles, modelos... Ahora mismo estámos cruzando la encrucijada en la que se dejan de producir tantas nuevas características nuevas para el producto y se empieza a producir más contenido: menos características y jugabilidad nueva, más contenido en producción.
2- Cuando se hace un calendario de lanzamiento, ¿Cómo tenéis en cuenta lo inesperado? Imagino que el desarrollo de juegos tendrá un montón de dependencias inesperadas que hacen que el retraso inesperado en uno retrase todo lo que está tras ello. ¿Añadís al calendario el inevitable tiempo que se perderá con estos problemas inevitables de desarrollo? ¿Hay ciertos aspectos del desarrollo que son más predecibles que otros?
Eric Kieron Davis: Yo diría que esto se hace más preciso cuanto más cómodo estás con el equipo con el que trabajas y los que toman decisiones en tu equipo guiarán esto. Para mi, hacer un calendario implica tener en cuenta todo lo que pueda meter en ellos. Una cosa es hablar con un artista y preguntarle cuanto va a tardar en hacer una cosa ( "cinco días" ) y tú dices, "fantástico, cinco días", y lo apuntas. Pero hay muchas cosas que influyen eso. ¿Esos cinco días implican simple trabajo sin reuniones ni ninguna distracción? ¿Incluye esto iteraciones con tu supervisor, jefe o director del proyecto? ¿Tiene esto en cuenta conexiones inesperadas con otros trabajos? Si eso es así, son 5 días. Y como Travis ha dicho antes, una vez que conoces tu equipo y tu proyecto, puedes empezar a tener en cuenta la "impredicibilidad", si es que esa palabra existe, en tus calendarios. Hay que tener en cuenta cómo es la dinámica de toma de decisiones y la dicotomía de tu grupo.
Creo que hay una frase hecha que reza algo así como "el plan de batalla es la primera baja al encontrarse con el enemigo".
Travis Day: Si, algo así.
Eric Kieron Davis: Si, el plan sale por la ventana y como productores nuestros trabajos implica iterar ese plan y que se nos ocurran ideas para hacerlo realidad. La predicibilidad no es una palabra que tengamos oportunidad de disfrutar a menudo en el desarrollo de videojuegos... o en cualquier tipo de creación relacionada con el entretenimiento. No estamos necesariamente haciendo algo nuevo, pero estás intentando hacer cosas nuevas y no existe un modelo de negocio que seguir con este tipo de cosas.
Travis Day: Eso es lo importante: estas cosas son nuevas para el equipo, no se habían hecho antes. Es un punto importante que resaltar, porque mucha gente tiene la impresión de que te sientas al principio de un proyecto, haces el presupuesto de todo el proyecto, haces el calendario y te sientas y te aseguras de que se cumpla eso desde algún tipo de torre que lo ve todo.
Eric Kieron Davis: Si, te sientas y observas.
Travis Day: Se parece más a ser un sargento en el frente de la Segunda Guerra Mundial, lanzando granadas y ladrando órdenes. Es más algo que se vive al momento.
Eric Kieron Davis: (risas) Si, creo que por mucho que queremos ser predecibles como productores a la hora de hacer un plan y calendario y presupuesto, es muy difícil cumplirlos. Es un montón de trabajo y comunicación e iteración, comprendiendo como avanzan las cosas. Una vez que entiendes todas las partes que están implicadas en el proceso... En el pasado he hecho cosas similares, calendarios, con equipos con los que había trabajado antes y eso ayuda un montón, porque conoces las personalidades y habilidades de estas fantásticas personas y eso te ayuda a planear el trabajo mejor.
Espero que esto haya respondido tu pregunta.
3- ¿Es posible dar un ejemplo de cuanto tardará en hacerse una característica o un recurso artístico nuevo? Por ejemplo, ¿qué porcentaje se invierte en concepto, diseño, programación y pulido? ¿Se desglosan todas de manera similar o algunas requieren más recursos en algunas áreas? Si es así, ¿hay algún indicador de que un recurso llevará más tiempo en un área que otro y esto se tiene en cuenta?
Travis Day: No, todas las cosas son diferentes, cada característica nueva del juego es su propio copo de nieve único. Las naves por ejemplo son más predecibles, en función a su diseño y tamaño pasarán una cantidad determinada de tiempo en la cadena de montaje. Pero si se compara un sistema de radar con un sistema de misiles... las cosas se vuelven mucho más nebulosas.
Respecto a porcentajes, es fácil de hacer con cosas como naves. El concepto-diseño-revisión de modelo 3D 20-30%
Eric Kieron Davis: Y hay que tener en cuenta que concepto es una fase en la que queremos invertir mucho tiempo, porque los diseñadores responden preguntas, los grupos de jugabilidad responden preguntas, arte pregunta cosas etc
Travis Day: Tienes razón: puede ser visto como la preproducción del juego. Quieres quitar todas las dudas y problemas predecibles del medio para que nadie se pueda quejar y decir: "¿Y qué pasa si la bicicleta necesita una cadena?"
Eric Kieron Davis: Exacto.
Travis Day: Y luego modelado es el 70% del tiempo, y se lleva la mayor parte del tiempo, y tiene que quedar bien y estar perfecto. Y luego viene el a menudo olvidado pero siempre importante 5% final, que es sonido y efectos especiales, que es el 5% restante.
Eric Kieron Davis: Si, y aunque las fechas se pueden expandir a menudo todo el tiempo se comprime para el 5% final y tienes que hablar con el jefe de sonido y decirles "si, bueno... no te queda mucho tiempo para terminar". Y no debería ser así, quieres que el sonido sea tan creativo como pueda ser posible y se planea para que hagan cosas por adelantado, implicándoles cuanto antes sea posible, en el concepto, pensando qué ruidos hará la nave, que partes móviles tendrá.
4- Cuando se recluta personal para un proyecto , ¿Cómo de rentable es hacer una subcontrata en vez de contratar a un nuevo miembro del equipo? ¿Cómo se toma esta decisión?
Travis Day: Me gusta esta pregunta, porque es un debate constante en la propia industria.
Eric Kieron Davis: Si, si, si. Para mi es una cuestión de: ¿Cuanto tiempo tienes libre para el proyecto? ¿Cuanto dinero tienes para el proyecto? ¿Cuando tiene que salir el proyecto? Y estas preguntas guiarán la calidad del proyecto y te ayudarán a hacer una mejor decisión. Tienes en cuenta cosas como contratarles de manera local, nacional o internacionalmente. O si hace falta mucha gente inicialmente para pre-producción, por lo que reclutas mucha gente al principio pero no de manera permanente. La idea es contratar a cuanta más gente sea posible en la industria, creando empleos y grandes juegos, pero la realidad acaban volviendo a ¿Cómo hacemos la mejor calidad por la menor cantidad de dinero?
Travis Day: Las subcontratas han recibiendo muy mala reputación en nuestra industria, porque se dicen cosa como: "¡Nos han quitado nuestros trabajos!" o "Eso te dará menos calidad." En realidad, hay mucha gente con muchísimo talento trabajando como sub-contratas. Pero luego tienes a gente como Chris Smith, que ha hecho muchas de las más bellas naves de nuestro juego, y le puedes poner a hacer 34 variantes de macetas, barriles y plantas... no voy a hablar por él (puede que le gustase hacer eso); pero creo que se estarían malgastando sus talentos porque no hay mucha gente que haga naves de su calidad, pero si que hay mucha gente que puede hacer esas macetas o unas cajas.
Eric Kieron Davis: Y para mi es perfecto dar la oportunidad a alguien de nivel junior para hacer este tipo de cosas. Les metes en la industria, aprenden a saber cómo encajan las cosas en la cadena de montaje... Acaban de salir de la escuela o están buscando un trabajo, y es bueno. Intentamos crear cuantos más trabajos sean posibles, pero también tenemos que tener los objetivos del proyecto en mente.
Travis Day: Otra de las cosas con las que han tenido problemas durante mucho tiempo los estudios de nuestra industria es el cuarto de personas que tienes que echar una vez has producido el material suficiente para lanzar tu juego: no puedes sostener toda esa gente a largo plazo. Luego está otra idea popular, que es la de tener dos equipos distintos: uno en pre-producción y el otro en producción a saco y pasas la mayor parte de la gente del segundo equipo al primero cuando terminan su proyecto y los que quedan en el segundo pasan a trabajar en pre-producción del siguiente proyecto... y eso funcionó durante una temporada.
Lo que las subcontratas nos ha permitido, que es muy importante para Chris, es que quieres que aquellos que contratas sepan que te has comprometido con ellos, que los vas a educar, hacer crecer como profesionales, y a cambio obtenemos de ellos este magnífico arte, código o lo que sea. Todo el mundo quiere tener esa seguridad y esa confianza y fe en el trabajo. Así que las subcontratas permiten escalar el proyecto sin correr el riesgo de no poder honrar ese contrato.
Eric Kieron Davis: Las subcontratas tienen mala fama porque se piensa que son extranjeros o de paises lejanos, pero en realidad muchos son locales: simplemente no trabajan directamente para nosotros en nuestras plantillas.
Travis Day: Como los tíos de Ether...
Eric Kieron Davis: Hay tipos hay fuera que son contratados por múltiples estudios como artistas, programadores o lo que sea y trabajan con compañías como nosotros. Y en realidad es una gran industria que crea un montón de trabajos.
Travis Day: Y otra cosa importante a tener en cuenta es que todo su modelo de negocio depende de nosotros. Ellos proporcionan trabajo estable a tiempo completo a gente que en otras circunstancias serían freelancers (que suelen pasar de festines a hambrunas) y se ocupan de encontrarles algo que hacer en 20 proyectos distintos. Y su compañia a su vez tiene trabajos estables gracias a esto. Es un ecosistema interesante.
Por cierto, nunca me había dado cuenta de lo nerd de la producción que soy hasta que me había puesto a responder estas preguntas...
Eric Kieron Davis: (riasas) ¡Si!
Travis Day: Me emocionan mucho.
Eric Kieron Davis: Si. Volviendo a la pregunta original: tenemos en cuenta todos estos factores y tomamos la decisión que es adecuada al proyecto en cada momento, porque cada proyecto es distinto.
Travis Day: Tiene que ser una pesadilla tener que re-hacer jerseys cada vez que haces otro juego de una franquicia.
Eric Kieron Davis: Si, horrible, o divertido, si te gustan hacer esas cosas.
Travis Day: Me imagino a un tipo dedicándose a hacer tazas para, por ejemplo, un GTA.
Eric Kieron Davis: Si, lo adora, hacer a tiempo completo tazas virtuales durante años.
5- Cuando tienen lugar retrasos en la producción como la que ha tenido lugar con el módulo FPS, ¿que es lo que hacen los productores para minimizar el efecto que produce sobre la producción general del juego? Sé que los distintos módulos están siendo producidos en paralelo para ayudar a reducir el impacto; pero, ¿se están haciendo otras cosas específicas en este sentido de las que no esté al tanto?
Travis Day: Esta es una gran pregunta para Sean Tracy (risas), Jeremy Masker, que siempre discuto y debato sobre cual es la mejor manera de minimizar los riesgos de que esto retrase las otras versiones del juego en desarrollo.
Eric Kieron Davis: Sanas discusiones.
Travis Day: Tenemos saludables discusiones. Es importante en producción estar muy abierto al concepto de que "mi idea no es la mejor siempre". Y esta es una buena regla a seguir en el desarrollo de videojuegos. Tomando un término de nuestros amigos en Activision "Es una batalla por tener la mejor idea". Y es cierto. Me encanta tener esas conversaciones porque puedes pensar que tienes razón, pero te lo replanteas y ves que no es así.
De vuelta a tu pregunta, si, tenemos una estructura muy interesante de desarrollo que se parece mucho a dos pirámides en contacto por sus cúspides. En el medio está Main, y por debajo está Desarrollo del Juego: FPS, Social, Multi-tripulación, Universo Persistente. Cada uno de estos grupos trabaja en su propia área delimitada. Y hay unas versiones intermedias que están siendo sincronizadas constántemente y eso hace que dos tipos de diferentes versiones puedan trabajar en el mismo archivo, porque el sistema de main se dará cuenta, les enviará un email automático de que resuelvan su problema de interacción y todo lo que queda que es bonito y estable (en teoría) se propaga al Main.
El Main tiene unas versiones de lanzamiento hacia la pirámide superior, como la del módulo Star Marine que queremos lanzar a continuación. Y esta versión tiene sus propias versiones que acabarán llegando a la versión pública. Desde el estable Main se sacan versiones, se pulen, se eliminan bugs y, para la insatisfacción de Sean, a veces desarrollo de nuevas Características. Y una vez está lanzado, esto se devuelve por la pirámide de vuelta al Main.
Así que esta es la estructura técnica de cómo estamos configurando Perforce para mitigar el impacto que produce un lanzamiento sobre otro. Pero también hay otras cuestiones como, digamos, el impacto sociológico-de marketing- de respirar que tiene un lanzamiento, por lo que queremos espaciarlos entre si para que puedan respirar por si mismos y que el equipo se pueda centrar en el siguiente y así no se queme en múltiples cosas a la vez.
¿Tienes algo más que añadir a esto?
Eric Kieron Davis: No. Has dominado esa pregunta, fantástico. No tengo mucho que añadir. Creo que intentamos mitigar que un módulo impacte negativamente el desarrollo de otro y eso es de lo que hablamos. Como productores nos centramos en evitar este tipo de cosas.
Travis Day: Y creo que todos sabemos que esto sucede; pero lo intentamos minimizar. Un montón de cosas en producción a la vez lo hacen complicado,. pero puedo prometer que hacemos cosas para minimizar su impacto y así es.
Eric Kieron Davis: Exacto. Tenemos el plan de acción principal y eso es lo que queremos hacer, pero si acaso tenemos en la manga otros 10 planes secundarios para entrar en acción en caso de que las cosas no salgan como queremos.
6- Como Productor Senior, ¿Cual es el aspecto más difícil del trabajo? ¿Administrar gente/tiempo, cumplir el calendario de lanzamientos, facilitar la comunicación o no salirse del presupuesto?
Eric Kieron Davis: Todas ellas. Lo más difícil es equilibrar TODAS estas cosas. Cada una de estas son difícil y requieren tener habilidades especiales como productor, como tener mano izquierda para tratar a la gente y comunicarse bien. Ya lo comenté en Around the Verse antes: hay distintos tipos de productores senior. Cada uno tiene habilidades que complementan las de los demás y en conjunto se hace un buen equipo. Hay algunos que son más técnicos o burocráticos, cada uno tiene habilidades en sincronía.
Travis Day: Nosotros dos somos un ejemplo de esa teoría.
Eric Kieron Davis: Por completo, si.
Travis Day: Yo soy pasable a la hora de los calendarios, no es mi parte fuerte. Tú eres mejor que yo en ese aspecto y tienes más mano izquierda al tratar a la gente y cumplir plazos en el lado de arte. Mis habilidades se centran más en los aspectos técnicos y de diseño. Y por eso formamos un buen equipo.
Eric Kieron Davis: Estoy de acuerdo. Ninguno de estos aspectos nos costaría mucho, pero siempre hay que tener en cuenta saber dónde residen tus habilidades y ayudar a la gente adecuada en tu equipo. Nostromo (el suscriptor de la pregunta) ha definido perfectamente los tipos de productores que buscamos y contratamos en función a sus especialidades. Pero tener un buen equilibrio es sin duda lo más difícil.
Travis Day: Si, es como hacer malabares. No sé cuantas veces he usado esa analogía, pero es cierto.
7- Al planificar algo, ¿cuanto es una "ciencia" calculable y cuanto es un "instinto"? ¿Y cómo clasificáis la precisión de un desarrollador para implementar una característica nueva?
Travis Day: Primero responderé la segunda pregunta... Cada desarrollador es completamente distinto a otro. Es difícil obtener estimaciones de tiempo de un desarrollador hasta que lo conoces bien y puedes hacer un cálculo mental de que "cuatro horas para el significa dos" o "cuatro horas para él significa ocho". Y no quiere decir que uno sea más rápido o lento que el otro, es simplemente cómo piensan lo que llevará hacer algo.
Eric Kieron Davis: Es lo que dije yo antes, la precisión que obtienes al tener un equipo con el que llevas trabajando años y años y años. Sabes exactamente lo que quieren decir o no tienes necesidad de preguntarles cuanto tiempo les va a llevar algo, te haces una idea y les preguntas para confirmarlo por si a caso. La ciencia es comprender tu equipo y el proyecto...
Travis Day: Y los detalles técnicos del proyecto. Llegó un momento durante el crunch del Arena Commander 1.0, por ejemplo, y el 90% de mis estimaciones eran correctas y las podía asignar sin problemas. Otro gran juego que jugar, para los aspirantes a productores, es jugar al "¿Qué hubiese pasado si?" con cada uno de los que te dio una estimación. ¿Qué pasa si alguien se pone enfermo? ¿O se le muere el perro? Es un poco maligno pensar todas las cosas que pueden ir mal y retrasar algo que debería llevar 3-4 semanas; pero hay muchas cosas que la gente no tiene en cuenta. De hecho, se han hecho estudios al respecto y libros como "Drive" de Daniel Pink, que es excelente.
Eric Kieron Davis: Ese es bueno.
Travis Day: Como seres humanos tenemos una tendencia a subestimar una gran tarea y sobreestimar una pequeña tarea. Y se aplican unos modificadores básicos matemáticos, como que alguien trabaja un 70% de una jornada de 8 horas (entre comer e ir al baño y blablaba), así que 40 horas de tareas llevará 1 semana y media de trabajo. Esas son las pequeñas cosas que se pueden hacer. También empiezas a estudiar tu propio ritmo de trabajo de resolución de bugs y en el caso del lanzamiento de Arena Commander 0.8 aproximé que saldría el 30 de mayo y salió el 4 de Junio.
Eric Kieron Davis: No está mal.
Travis Day: Estuve muy orgulloso de mi aproximación. (risas) Así que así es, matemáticas y experiencia.
Eric Kieron Davis: Exacto. Cuanto más experiencia tienes trabajando con tu equipo y más experiencia tienes en ese tipo de producto, como por ejemplo hacer montones de FPS durante una década, mejor puedes aproximar. Y siempre tienes que estar atento a nuevas cosas, nuevas técnicas, nueva tecnología, nuevos desarrollos...
Travis Day: Si, hay cosas que no se parecen en nada a cómo se hacían hace 30 años.
Eric Kieron Davis: Una buena base de experiencia es buena.
8- ¿Que hacen los productores para mejorar sus habilidades? Actividades como dormir bien, software especializado, ejercicio físico, libros sobre los que inspirarse..
Travis Day: Al leerlas en los foros esta mañana y escogerlas me puse a responderla.
Eric Kieron Davis: Bueno, pues ya está...
Travis Day: No no no, esta es una buena pregunta y hay que responderla.
Eric Kieron Davis: Hay muchas cosas que se pueden hacer y habilidades que puedes aprender para mejorar. Travis mencionó Drive, a mi me gusta "Break all the Rules" También está el Game Developers Handbook, Team Leadership de Seth Spaulding (que amo en particular por su visión de cómo son los pequeños estudios)... Hay muchos grandes libros ahí fuera.
Travis Day: El libro de Cómo Influenciar Gente, de Dale Carnegie es todo un clásico.
Eric Kieron Davis: ¡Si, ese es fantástico! Lo que mola, o es extraño, sobre este trabajo es que tenemos tantos elementos distintos que podemos aprender de muchas cosas, aunque sea ser un administrador de una pequeña comunidad: ser responsable, responder de tus actos, ese tipo de cosas... Hay montones de personas ahí fuera haciendo juegos con una multitud de SDKs y eso sin tener en cuenta los montones de escuelas que aparecen por todas partes para enseñar a hacer juegos. Hay montones de proyectos que buscan escritor, artista o lo que sea y te puedes animar a proponerte como productor aunque no tengas ni pajolera idea sobre el tema, porque todo aprendizaje es bueno. Así puedes aprender a formar un equipo, hacer que logren un objetivo, un rápido esprint, usar diferentes paquetes de software de producción como Scrum, Agile, Waterfall... hay montones de cosas que puedes aprender para ser bueno en este trabajo. Jugar a videojuegos es genial, pero sólo es una pequeña parte de este trabajo: tienes que amar HACER juegos tanto como amas jugarlos.
Travis Day: Hay muchos grandes libros de todo tipo, como en psicología, administrar gente... etc Una gran parte de tu trabajo es como tratar con la gente. Una gran cosa que he aprendido es aprender a manejar el software que ellos utilizan para hablar su mismo idioma y entender lo que te están diciendo y así comprender el tiempo que va a llevar.
Y luego hay otras cosas que se aprenden estando en la propia industria, como estar siempre consciente de tus actos. Es horrible decir esto, pero la mayor parte de mi tiempo libre en el baño, en el sofa o la cama está dedicado a darle vueltas a viejas decisiones, cosa que dije, repasando cómo traté un problema o persona y posibilidades sobre cómo podría haberlo tratado. Es como correr una retrospectiva constante de tu vida sobre en qué la cagué, qué hice bien pero podía ser mejor y qué hice perfecto y hay que repetir.
Otras cosas buenas son los eventos como E3, GDC, Gamescom y crear tu propia red de compañeros de la industria, mentores, camaradas... Muchas veces, cuando tengo un gran problema o gran pregunta, voy a mi pequeño consejo y se lo comento para recibir sus opiniones.
Eric Kieron Davis: Programas que hay que conocer: 3D Max, Maya... cosas de producción como Jira, Shotgun... Todos estos tienen versiones gratuitas de prueba.
Travis Day: Y creo que Visual Studio va a ser gratuito en breve, y podrás hacer tus pinitos. Harás cosas a lo mejor estúpidas, como yo, que hice una calculadora en MS DOS, pero esos cimientos te servirán para apoyarte sobre ellos.
Eric Kieron Davis: Y siempre es importante tener tus propios hobbies y pasiones privadas. Yo hice mucho estudio de arte y me gusta trabajar con artistas. Es un mundo que me interesa y prefiero trabajar con ellos, pero no quiere decir que no quiera trabajar con programadores o diseñadores; pero cuanto más sabes, más sabrás cuando los tiempos que lleva hacer algo son reales o no.
9- Mucha gente piensa que añadir cosas nuevas al juego es como arreglar bugs en Bugsmashers, añadiendo algo de código que mágicamente hace que las cosas funcionen desde la mente de un programador. ¿Nos podrías dar una guía de cómo se hace, paso a paso, para implementar una característica nueva en el juego? Desde su aparición en la mente de Chris Roberts u otro diseñador a llegar a nuestros ordenadores, incluyendo los obstáculos habituales. Un ejemplo que me interesaría a mi sería algo como las parrillas de físicas locales, GOST o Manos Asidoras.
Travis Day: Un buen ejemplo es GOST, que estamos haciendo ahora mismo. Y no, no se parece en nada a solucionar un Bug y de hecho esto es una fase final a la hora de implementar una nueva característica en el juego. En realidad una nueva Característica, como GOST, es un nuevo paquete de GOST que todavía tienes que añadir y luego solucionar, esto va a pasar si o si. Tenemos los mejores ingenieros del planeta y Control de Calidad sigue encontrando bugs regularmente. Hacen errores, y se acumula cosas que no se pueden predecir.
En el caso de GOST tenemos una necesidad que cumplir en el juego (al contrario que otras características, que parten de una idea que tiene alguien y esta se añade al juego) de saber dónde está el jugador en una nave y que esta responda de manera apropiada dependiendo del estado en el que se encuentre y lo que haga el jugador con esta. Ejemplo: no poder subir en una torreta cuando ya hay alguien en esa torreta, o que sepa que la escalerilla ya está desplegada y que ya puedes subir por ella, en vez de activar de nuevo la animación de la escalerilla o detectar la presencia el jugador para encender luces a su alrededor.
- Estas necesidades identificadas por Chris y Diseñadores. Hacen una lista y esta va al Documento General de Diseño o tu Documento de Diseño de Niveles o el Documento de Diseño de Características.
- Esto es entregado al Equipo de Ingeniería y ellos te dicen cual es la mejor manera, escribiendo un Documento de Diseño de Ingeniería, que revisan entre todo el el equipo y luego con los diseñadores y su propio documento, asegurándose de que esta sea la mejor solución general a todos los problemas que tienen en ese aspecto.
- Una vez están todos satisfechos, se aprueba y se forma un equipo para llevarlo a cabo. Y estas cosas llevan su tiempo, normalmente 6 meses o puede que mas. Empiezan con lo más básico y la estructura y construyen sobre eso, añadiendo cada vez más cosas.
- Hacia el final Control de Calidad lo revisa, se arreglan bugs y se integra en la versión del juego que sea apropiada. Se construye en la parte inferior de la doble pirámide que mencioné antes, en el caso de nuestro ejemplo en la rama de versión de desarrollo de Arena Commander, Característica Nueva-> GOST.
- Luego se integra en Arena Commander, se suele necesitar una semana para solucionar los problemas que surgen. Y ya está.
Esta es una versión super-básica del proceso y podría hablar mucho tiempo sobre el tema a fondo; pero este es el proceso de idea a integración.
Eric Kieron Davis: Muy buena pregunta. ¿Última pregunta me toca? Esto ha ido rápido...
10- Imaginad que tenéis dos diseñadores, artistas o ingenieros en CIG que tiene dos versiones sobre cómo se podría hacer algo y no se ponen de acuerdo. ¿Cómo determináis que versión utilizar y cual eliminar? ¿No es difícil decirle a un compañero que trabaja duro que su manera de hacer las cosas no encaja con cómo queréis que sea? ¿Tenéis alguna herramienta para reducir las posibilidades de que suceda esto?
Eric Kieron Davis: Gran pregunta.
Travis Day: Yo no creo que sea una buena pregunta.
Eric Kieron Davis: Ohhh....(risas)
Travis Day: ¡Ahora tenemos que resolver esto! (risas)
Eric Kieron Davis: ¡Buen ejemplo! ¡A interpretarlo! Esta es una gran pregunta y está relacionada con la mano izquierda a la hora de trabajar con gente y es importante que todo el mundo entienda que sus ideas importan y son tenidas en cuenta. Travis comentó antes que es importante tener ese debate profesional (ndt: Con Sean Tracy) en el que al final puedes llegar a un compromiso. Para mi es importante entender qué es lo que buscan los dos y la mejor herramienta es reunirse con los dos en la misma habitación y discutirlo. En esta industria todos somos profesionales. Estamos apasionados por lo que hacemos y estamos en el entretenimiento.
Travis Day: Pero en general, todavía tengo que encontrar alguien egoísta. Todo el mundo quiere lo mejor para el proyecto.
Eric Kieron Davis: Si, la mejor versión posible para el proyecto. Así que ahora tu objetivo como productor es llegar a un compromiso, de saber qué es lo que está bien de lo que dicen los dos y se puede utilizar. Te reúnes, les dejas hablar, haces que estén presentes todas las personas relacionadas con el tema que sean claves en su producción y la esperanza es salir de esa reunión con una solución que nos guste a todos. Puede que no nos siente muy bien que nos digan que nuestra idea está muy bien pero no la vamos a utilizar; pero cuando estás junto a otras personas y te comprometes en la reunión, eres un profesional y entiendes que es lo mejor para el proyecto.
Travis Day: Lo que Eric ha menciona es la mejor solución a un problema como este, que realmente no tienes que solucionar, porque probablemente esta situación podría haber sido eliminada antes de aparecer dando roles y responsabilidades más claras a ambos trabajadores. ¡Estos dos tipos al parecer estaban trabajando en lo mismo, compitiendo con diferentes metodologías antes de sentarlos a escoger una! Eso sería un error nuestro, en un primer lugar.
Eric Kieron Davis: Si.
Travis Day: Es culpa de un productor tener a dos personas trabajando en el mismo proyecto.
Eric Kieron Davis: Tienes razón. Lo que tenemos aquí es claramente un problema de producción al no haber definido roles muy claros en el equipo. Una vez que lo entendemos, puedes tener tus opiniones sobre el trabajo de los demás; pero cada uno tiene tiene su ámbito en el que es experto y debe ser respetado.
Travis Day: Hemos tenido un claro éxito en CIG dando "propiedad" de partes del juego o de Características a la hora de desarrollarlas. Zane (Bien) es el primero en acercarse y preguntar cómo mejorar las cosas, aunque esté trabajando más horas que un reloj haciendo una cantidad increíble de arte. "¿Os gusta lo que hice o no?" Todos están abiertos a comentarios y opiniones, y sin embargo son dueños de su parte del proyecto.
Eric Kieron Davis: Es cierto, todo el mundo es así. Te acercas a alguien y le preguntas qué opina a ver cómo se puede mejorar. Todo el mundo quiere hacer un gran producto para nuestros mecenas, así que luchamos entre nosotros por lograr ese objetivo.
Travis Day: Gracias, y estas han sido fantásticas preguntas (¡sin hablar mal de las anteriores!). Os veremos la próxima vez.
