La
historia del desarrollo de BioShock es una aventura casi tan épica y distópica
como lo es el propio argumento del juego. A lo largo de su desarrollo, tanto el
equipo de trabajo como el propio juego sufrieron diversos cambios. Entre ellos
destaca el hecho de que se llegó a duplicar el tamaño del equipo inicialmente
previsto, además el enfoque del producto fue alejándose de un RPG para acercarse
más a un estilo shooter, todo ello sin perder la esencia con que originariamente
fue concebido.
La
propia Finley destaca que aunque sea relativamente fácil hablar de los procesos
que se utilizaron para desarrollar el juego, es considerablemente más difícil
describir la chispa creativa que logró convertirlo (partiendo de unas premisas
alejadas de los parámetros habituales tales como una utopía fallida submarina
art decó en la década de 1960) en un shooter comercializable de notable éxito.
Algo que solo se pudo lograr mediante la toma de decisiones creativas correctas
que consiguieron llevar al juego a buen puerto, acompañado en su viaje por el
enorme talento y trabajo tanto de los equipos de diseño como de los de
desarrollo que consiguieron plasmar esta visión y transmitir todas esas
sensaciones al jugador.
PostMortem de 'Bioshock' por Alyssa Finley
¿Que fue
bien?
1. Cada demo desarrollada contaba una historia
Las demos que se crearon se convirtieron en una enorme fuente de estímulo para el desarrollo de Bioshock. Estas demos lideraron una visión global del proyecto para todo el equipo consiguiendo unificar e identificar todos los problemas y soluciones que iban surgiendo.
Además supusieron un gran aliciente que lograron incrementar el interés por el producto, de la misma forma que sirvieron de gran apoyo interno. Un ejemplo de todo esto es que el proyecto se firmó después de que en Gamespot se publicase una una demo gráfica donde se mostraba solamente una habitación.
Desde ese momento BioShock se convirtió en una IP relativamente desconocida fuera de la comunidad de desarrollo. La impresión que tuviera el público era algo fundamental para que pudiésemos encontrar ese algo necesario que lograra convertir el juego en un éxito comercial.
(Nota: Recordar que una IP proviene del término Intellectual Porperty y se conforma como un nuevo título que no es una secuela ni forma parte de una saga, ni tampoco es una adaptación de una película, libro o comic.)
Por ello cada vez que se mostraba algo al público durante el desarrollo, poníamos gran cuidado en lo que queríamos transmitir y en el contenido de lo que mostrábamos.
La primera presentación al gran público fue poco antes del E3 del 2006, aunque llegados a ese punto habíamos desarrollado una gran cantidad de contenido, todavía no habíamos logrado construir de forma satisfactoria un entorno que mostrara la experiencia de juego que pretendíamos transmitir.
La demo del E3 obligó a todo el equipo a centrarse en lo que debería ser la experiencia de juego. Para ello definimos una historia para la demostración y construimos un hilo argumental narrativo alrededor de dicha historia. Aunque el desarrollo de la demo estaba muy encorsetado y daba poca libertad al usuario, conseguimos desarrollar la experiencia de juego que pretendíamos mostrar.
Otro ejemplo de la fuente de inspiración que se consiguieron gracias a la demos, se produjo cuando realizamos la demo llamada "Caza del Big Daddy". Aunque los Big Daddies y las Little Sisters habían sido ya concebidas como parte del juego desde sus orígenes, en un primer momento se había decidido que el jugador pudiera enfrentarse a las Little Sisters directamente sin necesidad de tener que despachar al Big Daddy que los protegía.
Durante el desarrollo de esta demo, el equipo descubrió que con algunos pequeños cambios, el hecho de pelear con un Big Daddy suponía todo un reto en si mismo y se convertía en una batalla épica.
Estas batallas se convirtieron desde ese momento en una de las claves para el crecimiento del jugador dentro del juego. Por ello decidimos plantearlas como batallas itinerantes donde el jugador decidiera como y cuando comenzarlas, pero que sería necesario derrotar a los Big Daddies para crecer dentro del juego.
Otro ejemplo de esta experiencia de juego se da en los efectos gráficos que se producen cuando el jugador utiliza plásmidos (algo que salió en el primer tráiler de Biosock). En la cinemática, el jugador utiliza una aguja hipodérmica para convertir su brazo en un arma, después de la inyección en la piel del protagonista este se hincha y enojado lanza una ráfaga para atacar al Big Daddy. Cuando se trabajó con la empresa Blur para desarrollar el tráiler, éramos conscientes de que la secuencia no reflejaría con exactitud los efectos visuales del juego, pero lo hicimos porque lo que realmente nos importaba era transmitir a los usuarios la existencia de una parte de modificación genética dentro del juego.
2. Correcciones durante el desarrollo
Uno de los grandes éxitos realizados durante el desarrollo de Bioshock, fue la capacidad que tuvimos de identificar y reaccionar tomando las decisiones adecuadas cuando veiamos que el juego estaba tomando un camino diferente del que nos habíamos propuesto originalmente.
Por ejemplo, en la primera demo construimos una zona que se componía de un corredor lineal que acabó convirtiéndose en un sencillo shooter que se desarrollaba en una fábrica abandonada. Aquella demo no conseguía transmitir la experiencia de juego deseada y no funcionaba ni como shooter ni como RPG. Para solucionarlo tiramos ese prototipo y comenzamos uno nuevo desde cero, con el objetivo de construir una sencilla estancia donde se pudiera sentir la utopía submarina que nos habíamos planteado realizar desde un principio.
En la parte de arte conceptual hicimos diversas revisiones, una vez que logramos construir el concepto de trabajo que estábamos buscando usamos esa demo que consistía en una habitación individual (restaurante de Cachemira en el primer nivel del juego) como una especie de molde o pieza base. Se convirtió en un referente que nos sirvió para continuar trabajando y la utilizamos a lo largo de todo el desarrollo como guía para la creación de la estética del resto del juego, algo muy importante ya que conseguiría diferenciarlo del resto de juegos existentes en el mercado.
Cada departamento atravesó un momento de crisis similar en el transcurso del proyecto. Estos momentos llegaban con frecuencia como resultado de las demos que se desarrollaban, aunque no siempre. Hubo un momento, en el que nos enfrentamos a un déficit de programadores que provocó un desbordamiento de las tareas pendientes, por lo que propusimos eliminar la física de los objetos a favor de tener una mejor física en los personajes del juego.
Esto habría permitido pasar mucho menos tiempo ajustando y trabajando sobre la física de los objetos individuales, pero sin embargo haciendo esto habríamos eliminado un enorme nivel de interactividad dentro del juego, algo de lo que nos dimos cuenta pronto y corregimos relativamente rápido.
En términos de diseño, habíamos creado unos profundos y densos sistemas de juego que habrían encajado bien en otro tipo de juego, pero que no era adecuado para un FPS. Cuando el juego entró en fase alfa, pudimos observar que este sistema se tornaba duro para el jugador ya que disponía de demasiadas decisiones posibles y además de eso resultaban excesivamente engorrosas.
Todo esto ocurrió porque no nos habíamos planteado en un principio orientar el juego tanto hacia el estilo shooter y por ello muchas de nuestras interacciones fundamentales (armas, equipamiento, plásmidos,IA) habían sido diseñadas para una experiencia más lenta y cerebral. Visto de otro modo las pantallas llenas de estadísticas y números de los RPG no eran adecuadas para el vibrante y peligroso mundo de Rapture que estábamos creando.
Una vez que conseguimos recalibrar el juego hacia el shooter, simplificamos muchos los complejos sistemas de inventario para que se adaptasen mejor a la experiencia del usuario.También pusimos especial énfasis en las interfaces de usuario para el manejo de armas y plásmidos. En general habíamos disminuido el número de opciones generales, pero habíamos incrementado la funcionalidad haciéndolas mas comprensivas, divertidas y adecuadas que las anteriores.
Fue inevitable perder algo de trabajo al realizar todas estas correcciones pero la capacidad para reunir y abordar los problemas fundamentales fue increíble, y los resultados obtenidos bien merecieron la pena.
3. Apoyos externos
La primera prueba de enfoque externo de BioShock supuso una comprobación de nuestra cordura y nos sirvió para tener una mejor visión de lo que estábamos haciendo bien y de lo que no estaba funcionando correctamente.
Llegados a este punto ya habíamos realizado un pequeño test interno de pruebas con amigos y amigos de amigos que habían resultado ser muy positivas. Por ello, justo después de la primera versión beta, el equipo de diseño encabezado por un extenso grupo de productores de 2K fue a ver como reaccionaba un grupo de personas que no sabían nada acerca de nuestra empresa ni de nuestro juego. El resultado fue catastrófico.
Del primer nivel nos dijeron que era demasiado denso, confuso y poco atractivo. Observamos como los jugadores adquirían nuevos poderes, pero después no sabían cómo utilizarlos, lo que provocaba que solo utilizasen las armas tradicionales con la consecuente frustración al intentar enfrentarse a los enemigos más duros. Una muestra de ello era que los usuarios no interactuaban con los Big Daddies y no entendían como modificar sus personajes para poder enfrentarse a ellos.
Por otro lado los jugadores estaban tan abrumados por el diálogo y la historia, que les provocaba una falta de información clave para poder avanzar en el juego. Unos pocos jugadores consiguieron percibir la profundidad que tenía el juego, pero aun así se sentían frustrados por la dificultad que entrañaba manejar los sistemas de armas e inventario que habíamos creado.
Basándonos en el feedback que nos proporcionaron estos test y con la cura de humildad aprendida, entendimos que nuestros instintos de desarrollo no estaban funcionando correctamente. Estábamos creando un juego que no tenía en consideración la experiencia de un usuario inicial que desconociese el desarrollo y no estábamos pensando lo suficiente en cómo hacer un juego accesible para una gran variedad de jugadores.
Tras la prueba, volvimos a la mesa de trabajo para redefinir una secuencia de aprendizaje en el juego. Desechamos la jugabilidad creada en los dos primeros niveles y rediseñamos una nueva experiencia de juego con un ritmo más lento que guiaba al jugador enseñándole como jugar y como combinar los plásmidos y las armas. Para ello, cambiamos la fase del pabellón médico de tal manera, que pasó de ser un sand box a una especie de estancia cerrada por bloqueos y claves para asegurarnos que el jugador sabía utilizar al menos unos cuantos plásmidos claves.
De todo esto sacamos una regla básica y es que los futuros cambios se basarían en datos objetivos y no los basaríamos solamente en nuestras propias intuiciones como habíamos hecho con anterioridad.
Tras esta primera ronda de cambios, tuvimos otras dos rondas de prueba internas de estudios 2K liberando varias versiones de juego y solicitando comentarios sobre que armas y sistemas se disfrutaban durante las pruebas. Recibimos comentarios de analistas de 2K, de Microsoft y de otros asesores y cuando tuvimos los resultados de las pruebas apenas un mes antes de completar la programación del juego la experiencia de juego fue muy diferente al fracaso anteriormente obtenido.
Aunque todavía existían muchos jugadores que se atascaban y se sentían frustrados en diversos lugares, si conseguían comprender los sistemas de armas y de juego. Por ello aunque todavía quedaba mucho trabajo por hacer, ahora los problemas eran mucho más fáciles de solucionar que antes.
4. Pequeños equipos
Al desarrollar nuestra primera demo, nos dimos cuenta apenas unos días antes de ser completada que íbamos en la dirección equivocada. Llegados a ese punto ya era demasiado tarde para solucionar todos los problemas antes de tener la demo disponible, por ello decidimos intentar mejorar las interacciones fundamentales.
Aunque este enfoque no fue suficiente para salvar la demo original, fue reconocido en nuestro postmortem interno de la demo como un proceso eficaz que deberíamos realizar más a menudo.
Uno de los éxitos más visibles del equipo eran las posibilidades de modificación de las armas del juego. Todas las armas ya habían sido trabajadas durante varios meses, pero como el juego todavía no estaba cerrado en contenido pudimos observar que no estaban todo lo logradas que deberían.
Para reajustar cada arma, un equipo formado por un diseñador, un modelador, un programador, el especialista en efectos y un diseñador de audio celebraban una reunión donde se analizaba cada aspecto de una sola arma. Se convirtió entonces en una tarea para cada miembro del equipo trabajar uno o dos días en sus aspectos relativos al arma, para luego examinar conjuntamente los resultados.
Una vez completado se repetía el mismo proceso de forma iterativa con otra arma. En el transcurso del desarrollo, se crearon equipos multidisciplinares para trabajar en una amplia variedad de problemas, incluyendo IA, animación, efectos visuales y animaciones. Los resultados de esos equipos fueron tremendamente mejores que los logrados con el anterior proceso no iterativo.
5. Gente con talento, staff flexible
BioShock fue inicialmente pensado para ser desarrollado en dos años con un equipo de 25 personas en Boston centrados en la jugabilidad del juego y cinco personas en Australia trabajando en el motor principal.
Australia se pensó inicialmente como un pequeño equipo de tecnología de núcleo que trabajaría en el procesador, motor, herramientas y procesos para el desarrollo de la consola. Los australianos tuvieron un impacto tremendo sobre el desarrollo final del juego porque al estar centrados en las tareas de motor y de núcleo, provocaba que el equipo de programación de Boston estuviese liberado de engorrosas tareas que le permitieron centrarse en la producción y jugabilidad del juego.
Una de las maneras más rápidas y fáciles de involucrar al personal hasta cualquier objetivo recién abierto sobre el proyecto de BioShock era tirar del equipo australiano, casi todos en la oficina australiana habían intervenido en todas las partes del juego de una u otra manera. La gran ventaja de utilizar los recursos del equipo australiano era que ya conocían el motor del juego y tenían un acceso fácil a la tecnología del motor del juego.
Llegaron desde Australia para acelerar el proceso de una forma increíblemente rápida y pudieron ser productivos casi inmediatamente después de tener las tareas definidas en el proyecto. Y aunque la diferencia horaria hizo que la comunicación fuese un desafío, también significó que los fallos críticos pudieran ser trabajados literalmente de día y noche.
¿Qué salió mal?
1. Evolución del posicionamiento del producto.
La especificación de BioShock cambió mucho durante el transcurso del desarrollo ya que pasamos la mayor parte del tiempo concibiendo un juego con demasiada profundidad, lo que lo hacía interesante, pero no lograba que fuera un juego innovador que llegase a una amplia audiencia.
Desde el principio éramos conscientes de que tendríamos que realizar cambios finales, por ello planteamos en el ciclo de vida un margen de seis meses antes de darlo por concluido para realizar estos cambios, pero la enorme cantidad de modificaciones que tuvimos que realizar superaron con creces el margen que nos habíamos dado. La verdad es que fuimos muy afortunados de tener una prórroga de tiempo a última hora.
Parte de la culpa de todos estos cambios vinieron de no tener claro nuestro mensaje de producto interno desde un principio. BioShock inicialmente había sido concebido como un híbrido RPG-FPS, la decisión de centrar el juego como un FPS llegó más tarde, después de nuestra fase de producción inicial en verano de 2006. Si hubiésemos trabajado con una mentalidad de FPS antes seguro que podríamos haber realizado un mejor uso de nuestro tiempo.
Otro factor que contribuyó a la tardanza final fue que el juego se iba realizando más o menos de acuerdo al plan de desarrollo, por lo que no parecía que hubiera ninguna emergencia que necesitase la intervención de niveles superiores. Se terminaban los hitos, se cumplían los objetivos, el desarrollo parecía estar procediendo correctamente, pero cuando el juego se encontraba cerca de su fase alfa, la gente comenzó a mirar más de cerca y vio que BioShock no estaba en el camino de convertirse en el juego accesible y comercial que queríamos.
Como se mencionó en la primera parte de lo que fue bien, el verdadero punto de inflexión para BioShock llegó cuando teníamos que presentar el juego al mundo exterior, esto fue lo que nos obligó a reconsiderar cuidadosamente la historia y el mensaje que necesitábamos transmitir. En retrospectiva, deberíamos haber realizado esas presentaciones al exterior mucho antes.
2. El contenido del desarrollo narrativo sucedió tarde.
Tuvimos muchos borradores de la historia durante el transcurso del desarrollo, pero el proyecto final resultó casi ser una completa reescritura. Para colmo, fracasamos totalmente en la producción narrativa en las primeras versiones, así que una vez el proyecto se hizo definitivo y fue completado y grabado, aparecieron muchos problemas de implementación que de haber sido detectados con anterioridad habrían sido resueltos antes.
La cuestión fundamental es que teníamos una enorme cantidad de contenido pendiente mucho después de haber finalizado la beta, y el equipo tuvo que codificar para adaptarse a ese nuevo contenido correctamente mientras seguían con la corrección de otros errores. Compitieron entonces las necesidades de tiempo y de recursos, lo que significó que por desgracia, algunos de los detalles importantes narrativos del juego no fueran creados hasta el final de la reescritura y por lo tanto, requirieron bastante trabajo para readaptarlos a un juego ya existente.
Para colmo de males, los primeros comentarios que nos llegaron sobre la voz del narrador fueron extremadamente negativos. Los usuarios encontraban el carácter del personaje extremadamente desalentador, por lo que decidimos cambiarlo en el último momento.
La parte positiva de esto es que nos permitió perfeccionar varias partes del juego (incluyendo la secuencia de introducción) que nos sirvió para asegurar que el jugador sabía lo que hacía en cada momento. Por contra resultó difícil conseguir que todo el contenido estuviese depurado y pulido en el plazo que restaba hasta la finalización del juego.
3. Escala de la visión del tamaño del equipo.
Nuestras metas y una visión idealista sobrepasaron con creces nuestra capacidad de producción. Aquellas ideas que comenzaron siendo pequeñas requirieron una tremenda cantidad de trabajo y apoyo para conseguir dejarlas en un estado pulido. Aunque pudimos añadir recursos regularmente y realizamos algunos recortes en el juego, nuestra capacidad de estimar cuanto trabajo suponía plasmar las nuevas ideas en el juego desde su concepto hasta su finalización resultaron ser a todas luces erróneas, siendo estas estimaciones muy pobres e irreales.
Además, no tuvimos un proceso de revisión interno establecido y eficiente hasta etapas muy tardías en el ciclo de desarrollo donde realizamos un ciclo de revisión más regular, en la cual todas las partes integrantes se reunían con asiduidad y se registraban todos los errores. Hasta ese momento no fuimos realmente capaces de definir con exactitud la cantidad de trabajo que suponía realizar cada tarea desde su concepción hasta su finalización.
La última razón por la que pudimos sacar adelante un juego con tan alto nivel de calidad fue la enorme dedicación que el equipo tuvo durante el proyecto. Aunque habíamos previsto un tiempo extra para finalizarlo, todas las estimaciones se vieron desbordadas con creces. Ello produjo una intensificación del ritmo de trabajo con una dedicación increíble que supuso un reto largo y difícil para todo el equipo. Si hubiéramos estimado mejor los tiempos, el ritmo de trabajo hubiese sido mejor sin llegar a tener que sufrir los atracones finales de tareas al final del desarrollo.
4. Las herramientas y los procesos fueron ineficientes.
Muchos de los procesos y herramientas que utilizamos para desarrollar BioShock fueron ineficientes y muy confusos, llevándonos a lentos ciclos de iteración y múltiples errores durante su utilización.
La parte positiva fue que nuestro equipo fue capaz de desarrollar una versión jugable con la mecánica del juego en pocos meses debido a la familiaridad que tenía el equipo de desarrollo con las herramientas. Ello nos permitía desarrollar y ejecutar muy rápidamente cada avance que conseguíamos.
Sin embargo, la facilidad y la familiaridad del flujo de trabajo a menudo nos llevaron a aceptar la solución que era más rápida para implementar en lugar de tomarse el tiempo suficiente para hacerlas más eficientes.
Por ejemplo, no hubo ningún convenio adecuado para saber cómo nombrar las acciones de script. Dependiendo del sistema, una acción de secuencia de comandos podría llamarse "Cambio< SystemProperty>" mientras que otro se llamaría "Set <SystemProperty>" o "Modificar <SystemProperty>". Con cientos de acciones de secuencias de comandos disponibles, los diseñadores a menudo pasaban demasiado tiempo buscando la herramienta adecuada a utilizar.
Esto podría haberse evitado con un código de secuencias de comandos estandarizado. Ello provocó que el desarrollo para consola fuera lento y difícil. Ya que la solución consistía en rehacer mucho trabajo que estaba finalizado para igualar las versiones y poder trabajar con eficacia. Fue tremendamente doloroso malgastar tanto tiempo en este proceso, teniendo que rehacer el trabajo, cuando el equipo podría haber estado utilizando esas horas en mejorar el juego.
Deberíamos de haber puesto más energía y tiempo en haber hecho más eficaz todo desde el principio.
5. Pobre recopilación de datos.
Una de las cosas más frustrantes fue la falta de buenos datos reales sobre cómo se iba desarrollando cada parte del juego. Nuestro sistema de registro de juego era muy deficiente y se convirtió en algo completamente difícil de manejar cuando se intentaba analizar un único archivo de registro y ver como se relacionaba con otros.
No tuvimos ninguna buena metodología para definir qué información se registraba y a qué nivel de detalle se llegaba, por ello el trabajo de análisis de los registros fue doloroso, lento y terminó con resultados insuficientes e ineficientes.
Para complicar aún más el problema, la mayoría de la gente en la oficina utiliza métodos abreviados o códigos de trucos en cada inicio de un nivel para no jugar desde el comienzo del juego, algo que nos causó una gran cantidad de trabajo extra.
Blockbusting
Nuestro objetivo cuando nos propusimos realizar BioShock era muy claro, queríamos llegar más allá de lo que habíamos conseguido con nuestras franquicias de juegos más aclamadas con el fin de realizar una superproducción de éxito.
La unión de un montón de factores hicieron esto posible: por un lado el respaldo comercial de 2K; por otro lado el conocimiento de diseño del juego que habíamos adquirido tras finalizar System Shock 2; además también estaba el conocimiento tecnológico adquirido con nuestro motor Unreal utilizado en juegos anteriores.
Pero todavía teníamos que averiguar cómo lograr hacer que está superproducción superase a todo lo anterior. Muchos de nuestros problemas vinieron de subestimar lo grande que era realmente la tarea de realizar un producto triple-A para múltiples plataformas y en varias regiones.
Otros problemas procedieron de sobreestimar nuestra capacidad para resolver esos problemas mediante nuestros procedimientos y con el personal con el que contábamos.
Si algo hemos aprendido durante este desarrollo (al igual que otros muchos desarrolladores anteriormente), es que el éxito final de esta industria proviene de la iteración de procesos. Tenemos que construir, evaluar (y que los demás evalúen) y estar dispuestos a tirar cosas y volver a construirlas.
Los productos que fabricamos son demasiado complejos y nuestra industria reinventa demasiado rápido. Pero creemos que si estamos verdaderamente dispuestos a recibir una mirada crítica de nuestro propio producto y responder sinceramente a dichas críticas, al final obtendremos un producto de gran calidad.
Datos del juego
Desarrollador: 2 K Boston y 2 K Australia
Editor: 2 K Games
Plataforma: Xbox 360 y PC
Fecha de lanzamiento: 21 De agosto de 2007
El tiempo de desarrollo: 3 años
Número de desarrolladores de tiempo completo en pico: 93 programadores, 30 contratados, 8 testers internos de editor
Hardware: PC; AMD Athlon X2 dual core or Pentium 4 Intel-Duo dual core processors; NVidia Geforce 8800 graphics cards; Xbox 360 dev and test kits
Software: Microsoft Visual Studio 2005, Perforce, Xbox 360 SDK, Xoreax Incredibuild, Visual Assist X, Araxis Merge, BoundsChecker, Purify, VTune, 3ds Max 8, Photoshop CS2, ZBrush, Flash 8, SoundForge 8, Sony Vegas, Acid, Ableton Live
Tecnlogía: Unreal Engine, Bink, Havok, Fmod
Número de archivos: 3,775
Líneas de código C++ nativo: 75,8903
Líneas de código de secuencia de comandos: 187,114
Desglose de equipo
En el estudio de
Boston:
Programador: 1
Artistas y animadores: 15, además de 2 tomados de Firaxis
Diseñadores: 6 internos, 1 contratado
Contrato de Desarrolladores de audio: 2 internos, 7
Productores: 3 internos, 2 contratados.
Testers: 13 contratados, además de 8 probadores de editor.
Programador: 1
Artistas y animadores: 15, además de 2 tomados de Firaxis
Diseñadores: 6 internos, 1 contratado
Contrato de Desarrolladores de audio: 2 internos, 7
Productores: 3 internos, 2 contratados.
Testers: 13 contratados, además de 8 probadores de editor.
En el estudio de
Australia:
Programadores: 12
Artistas y animadores: 10
Diseñadores: 5
Desarrollador de audio: 1
Productores: 2
Testers: 1 interno, 7 contratados
Fuente: Gamasutra
Programadores: 12
Artistas y animadores: 10
Diseñadores: 5
Desarrollador de audio: 1
Productores: 2
Testers: 1 interno, 7 contratados
Fuente: Gamasutra
0 comentarios:
Publicar un comentario