El desarrollo de un videojuego

Hoy vamos a empezar a ver como funciona una desarrolladora de videojuegos.

En el articulo 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 mierda de la mala. Porque, una vez el editor confía en el proyecto, llega la siguiente fase.

La producción
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.
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 quedemonos 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.


¿Se han 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. Pueden 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 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. Habran leido 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.

Beta
Aquí ya es cuando el juego tiene la pinta que tiene que tener. En este punto, el juego esta terminado a nivel de programación y arte; y el equipo se dedica a cerrar todos los bugs que pueda.

No solo hay bugs de programación, también hay bugs de arte: los tipicos agujeros en el mapeado, texturas que se ven mal, problemas en el modelado o la animación, etc. O problemas de diseño: scripts que no funcionan bien, armas demasiado poderosas, ajustar los niveles de dificultad, etc.

En Beta el equipo va cerrando los bugs en orden decreciente de importancia, desde los bugs más graves tipo crashes o bloqueos del juego porque un script no se lanza, hasta los bugs menores,del tipo de textos que no salen donde toca, errores tipográficos o glitches menores.

¿Porque a veces salen juegos con bugs? Pues no es porque no se testeen bien ... Si te aparece a vos, ¿crees que a un equipo de testers que se pasa 8 horas al día jugando al mismo juego no le habrá ocurrido?
Y si ahora se preguntan , ¿porque a veces salen juegos con bugs? Pues no es porque no se testeen bien, que se testean. Si te aparece a vos, alma de cántaro, ¿crees que a un equipo de testers que se pasa 8 horas al día jugando al mismo juego no le habrá ocurrido en algún momento? Tampoco salen porque los programadores sean malos, malvados o no quieran trabajar. Si te caes por el escenario, o un script te falla es porque, seguramente, durante el desarrollo tuvieron que escoger entre que el juego crasheara en un sitio más o menos reproducible o arreglar un bug que pasaba a veces y que se arregla reiniciando.

Así que, sobretodo ahora que parchear es factible (luego hablare un poco más de esto), se opta por arreglar primero lo imprescindible y luego lo que de tiempo hasta gold.

Certificacion, Code Release, Release Candidate
Cuando hablamos de juegos en consolas, tenemos que introducir un tiempo intermedio en el que el licenciatario del hardware tiene que aprobar nuestro juego. Esto tiene un coste, adicional al económico (que también), y es que, cada vez que te devuelven el juego sin aprobar, tienes que arreglar lo que pidan, y enviárselo de nuevo.

Por esto se suele intentar que lo que les llegue a Microsoft, Sony o Nintendo este lo mejor posible y, si se puede, pasemos a la primera. Es bastante importante pasar la certificación rápido ya que, especialmente durante los periodos de muchos lanzamientos, el tiempo entre que envías y te responden puede ser muy largo y te puede retrasar el lanzamiento.

Esta fase es un problema tanto en físico como en digital. En digital, en el caso de Xbox, el numero de juegos por semana esta limitado, así que si te retrasas tienes que volver a la cola. Y en físico, si te retrasas puedes perder tu reserva en la fabricación de los CD's.


El equipo de la certificación no valora si el juego tiene una calidad determinada, por mucho que estampen un sello dorado de calidad, lo que prueban exhaustivamente es que el juego cumpla los requisitos técnicos que han establecido en su plataforma. Seguro que han visto muchísimos juegos con bugs en las tiendas (pueden buscar en YouTube vídeos), pero no encontraréis ningún juego sin el aviso de no apagar la consola mientras graba, y les costará encontrar un juego que no tenga algún tipo de animación en las pantallas de carga.

El equipo de la certificación no valora si el juego tiene una calidad determinada, por mucho que estampen un sello dorado de calidad, lo que prueban exhaustivamente es que el juego cumpla los requisitos técnicos.
Durante esta etapa se van enviando varias release candidate, y la versión que nos aprueban es la que se denomina gold master. Este termino viene de la industria musical, que usaban CD's dorados para grabar el master sobre el que realizaban la duplicación en CDs plateados. Esta versión es la que se usa como copia base de los discos que se distribuirán en las tiendas.

Parches
Usualmente, una vez que se llega a GM se suele bajar el ritmo de trabajo (después del apretón, la gente se toma vacaciones), pero es común tener un buen puñadito de bugs arreglados durante la certificación, todo lo que no hubiera podido corregirse antes de nuestra ultima Relase Candidate se puede sacar como parche 1.01. Por eso muchos juegos los tienen un parche el día de salida, porque durante el proceso de manufactura y distribución da tiempo a subir un parche, especialmente ahora que la distribución es por Internet (antes con las revistas era más difícil).

Un problema que tienen las consolas es que, dependiendo del licenciatario, parche implica recertificar y/o costes de descarga, así que a veces se opta por parchear menos y juntar los fixes en menos parches. Aunque, a veces, las circunstancias exigen lanzar parches puntuales si una plataforma tiene algún problema.

Para que se hagan una idea del coste, Tim Schaffer ha comentado esta semana que parchear en consola cuestsoberbia de 40.000 dolares.

Fuente Game Over