Artículo: Las fases de desarrollo de un videojuego
Destripando la industria.
Este artículo forma parte de la sección del podcast Game Over. Si te gusta el artículo puedes leer más contenido suyo en su apartado.
Este mes toca empezar un tema nuevo. Después de dedicar las primeras secciones a tratar temas económicos del desarrollo, vamos a empezar a ver como funciona una desarrolladora de videojuegos.
En el articulo de este mes, veremos por encima cual es el proceso de desarrollo de un juego; desde la idea inicial hasta como se termina, y veremos que es más complicado de lo que parece. Más adelante entraremos a fondo en los diversos roles, o en algunas partes concretas, como la traducción o el testeo, pero hoy vamos a dar una visión global de todo el proceso.
El principio...
No siempre es el desarrollador quien decide "el juego que se hace".
Todo empieza en la fase de pre-producción, y en este punto el equipo se intenta mantener lo más pequeño posible. Idealmente esta fase se dedica a preparar la producción: aquí se suelen hacer todas las pruebas necesarias antes de ponerse a "producir" como un loco.
Por ejemplo, cuando estaban preparando Dead Rising, seguramente hubo alguien en Capcom que se preocupó por ver cuantos zombies podía mover su motor en la nueva consola de Microsoft. Más adelante, cuando quisieron portarlo a Wii se dieron cuenta que no podían meter entornos tan grandes y tantos zombies y repensaron un juego acorde.
El resultado depende de cada proyecto y cada estudio/editor, pero suele ser un prototipo con todo lo generado en esta etapa, más la suficiente documentación, tanto de diseño de juego como de logística (el plan del desarrollo), como para que no haya problemas.
¿Es aquí cuando se decide que juego se hace?
Cuando el desarrollador decide, si. Pero no siempre es el desarrollador quien decide "el juego que se hace". A veces, se parte de una idea base, por ejemplo una secuela, o continuar con el género que la compañía trabaja para aprovechar el conocimiento (know-how). También se puede partir de un encargo externo: va a salir una nueva película de Spiderman y nos encargan hacer el juego, o hemos conseguido licenciar una IP, como por ejemplo, una competición deportiva.
Es difícil conseguir desarrollar una nueva propiedad intelectual. Porque, en muchos casos, un segundo objetivo de la pre-producción es conseguir un editor que nos financie el juego en cuestión o, en otros, la aprobación del proyecto por parte de quien pone el dinero, o el propietario de la licencia.
En esta parte del desarrollo todos los juegos son pardos. En este punto todos los juegos parecen el mejor juego que jamas ha hecho la desarrolladora, futuro GOTY del año que salga y Metacritic superior 90. Pero ya sabemos que no siempre es así, sino que, a veces, salen juegos del montón o morralla de la mala. Porque, una vez el editor confía en el proyecto, llega la siguiente fase.
Es difícil conseguir desarrollar una nueva propiedad intelectual. Porque, en muchos casos, un segundo objetivo de la pre-producción es conseguir un editor que nos financie el juego en cuestión.
La producción
En este punto es cuando el equipo en pleno se pone a "hacer el juego". En este punto, lo que tiene que hacer el desarrollador, valga la redundancia, es terminar el juego.
Ya veremos que este proceso de terminar es más complicado de lo que parece, pero quedaos con que los perfiles "productivos" del equipo están a pleno funcionamiento programando, modelando y re-diseñando. Porque, muchas veces, el papel lo aguanta todo pero luego no es divertido, así que toca refinar mecánicas, rehacer niveles, etc.
Aquí es donde, en una producción normal, se tuercen las cosas. Los pocos desarrolladores que tienen el lujo de trabajar hasta que este acabado, pueden permitirse dedicar el suficiente tiempo a dar vueltas sobre la idea hasta que lo que tienen es un juego excelente. Pero, en la mayoría de los casos no se puede pulir todo lo que los desarrolladores querrían, así que cuando se acaba el tiempo, siempre queda algo por mejorar.
¿Os habéis fijado que en muchas sagas actuales, en la segunda parte tenemos, realmente, el titulo excelente? Uncharted o Assassin's Creed son un par de ejemplos. Podéis apostar a que los desarrolladores sabían bien que es lo que habían hecho mal en el primero y lo arreglaron en las secuelas.
Durante la producción, pueden hacerse algunas demos o vídeos para enseñar en ferias, pero el primer gran hito y el que marca el principio del fin, es alpha.
Alpha
El juego, cuando esta en alpha tiene todas las mecánicas que tendrá cuando salga.
Generalmente, alpha es la primera gran milestone del proyecto. En proyectos muy grandes, con una producción más larga, o si el tamaño del equipo es muy grande y/o el género del juego requiere mucho testeo, se puede añadir un hito intermedio: el first playable, con la primera versión que se puede jugar, aunque no tenga ningún tipo de menús o falten partes importantes del juego. Con esta versión se puede empezar a iterar sobre la jugabilidad del titulo mientras se terminan el resto de características del juego.
Porque, casi siempre, alpha es feature complete. Esto significa que, el juego, cuando esta en alpha tiene todas las mecánicas que tendrá cuando salga, aunque puede tener bugs y crashes terribles, estar mal optimizado o, incluso, no ser divertidas.
En este punto, los testers desnudos de los que hablaba Iskhendar esta semana empiezan a trabajar a pleno rendimiento, ya que, a partir de este punto, los programadores empiezan a dedicar tiempo a resolver los bugs del juego.
Hay un momento que idealmente ocurre entre alpha y beta: la code freeze. Es cuando se decide dejar el código tal como está y dedicarse solo a arreglar bugs. Esto, para los profanos en programación, se hace porque optimizar o rehacer cosas puede añadir nuevos bugs fácilmente, así que en algún momento (si quieres sacar el juego cuando toca) tendrás que parar de añadir cosas o mecánicas al juego.
Este code freeze tiene más implicaciones de lo que parece. Habréis leído esta semana que Mass Effect 3 no tiene soporte de gamepad en PC. Manveer Heir comento en Twitter que el equipo de GUI no tenia tiempo de añadir soporte de los botones a las pantallas. Eso significa que alguien evaluó cuanto tiempo tardarían en añadirlo, y se salía del plan. Lo que no esté hecho para la code freeze, se va para un futurible parche o una expansión. El objetivo de estos recortes es poder sacar el juego el día que se planea sacarlo.