Sobre prototipos

En la GDC de este año, quizás lo más interesante era escuchar post-mortems de cómo se había abordado el desarrollo de algunos de los juegos de más éxito (en un próximo post polemizaré un poco al respecto ;-)

Un detalle sin embargo llamaba especialmente la atención: el énfasis en el uso de prototipos durante la fase de pre-producción. Lo mencionaron para el Civilization IV y, especialmente, para el Spore aqui y aqui (no olvideis leer las anotaciones si mirais las presentaciones).

Existen varios tipos de prototipos: de jugabilidad, tecnológicos (para ver la viabilidad de implementar un requisito), visuales, etc. Centrándonos en los de jugabilidad, su principal objetivo es "demostrar" que un elemento del juego funciona bien y es divertido, sin tener que esperar a tener el juego medio terminado. Durante la fase de pre-producción, mientras se refina el diseño, la jugabilidad se va evaluando mediante prototipos, descartando con un coste pequeño (el coste de implementar el prototipo) aquellas ideas que no encajan. Muchas veces prototipamos elementos de nuestro juego casi sin darnos cuenta. Si estamos haciendo un juego RTS, nos fijamos por ejemplo en cómo funcionan las formaciones en otros juegos hasta que encontramos uno que nos gusta (y ese juego es nuestro prototipo!).
En el peor de los casos, si durante la pre-producción el concepto del juego no se consigue concretar de ninguna manera, cancelar el juego tendrá también un coste bastante asequible. Ni que decir tiene que, cuanto más arriesgado o innovador es el diseño, mayor es la probabilidad de que haya que tirar muchas de las ideas durante la experimentación, y usar prototipos es la manera ideal de distinguir las buenas de las malas.

Yo he tenido la ocasion de ver y participar en varios prototipos y, a pesar de que el concepto suena muy bien, en la práctica es más difícil de sacar adelante con éxito de lo que puede parecer. El camino está plagado de trampas, que hay que conocer para poder evitar.

La idea del prototipo resulta anti-intuitiva para muchos programadores. Acostumbrados a estrictas (y necesarias) prácticas de ingeniería del software, a escribir código robusto, flexible, óptimo, fácil de mantener y bien documentado, muchos programadores se sienten incómodos escribiendo un prototipo cuyo principal requisito es minimizar el coste (en tiempo y recursos) de implementar cierta funcionalidad. Olvidados quedan criterios de eficiencia, mantenibilidad e incluso (gasp!) limpieza y elegancia. Otro pequeño obstáculo es que frecuentemente resulta más eficiente prototipar en lenguajes de alto nivel, como Python o C#, pero la mayoría de programadores se sienten más cómodos programando en C++ que, aunque genera programas más eficientes, requiere más tiempo para hacerlo.
El mejor perfil de programador para prototipar es el en ocasiones llamado "enreda". Es un programador que va directo al objetivo, y combina elementos y usa todos los trucos para llegar lo más rápido posible. Su trabajo se ve muy facilitado si cuenta con una base de código compuesta de elementos modulares, bien encapsulados, y que se pueden combinar fácilmente. No ayuda si para pintar un gráfico en pantalla es necesario, por ejemplo, inicializar el sistema de red, debido a dependencias que pueden tener sentido en el juego final, pero que suponen una carga innecesaria para el prototipo. Muchos motores pecan de demasiada rigidez en su estructura, dificultando su uso para pequeños programas de variada naturaleza y desarrollo corto, como son los prototipos.

Desde el punto de vista de filosofía, o visión, es imprescindible que el equipo crea en el sistema de prototipos para que éste tenga éxito. No es infrecuente pecar de exceso de confianza en que el diseño que se ha planteado en papel va a funcionar, aun cuando no hay ninguna prueba objetiva de que sea así. Otra posibilidad es la incredulidad en que se pueda probar que el juego es divertido hasta que está prácticamente hecho, y la mayoría de los elementos están integrados. En el mejor de los casos, eso lleva a prototipos muy grandes, llamados "vertical slice", que simulan una pequeña porción de juego, pero lo hacen con calidad casi final. El inconveniente es que el coste de implementarlos es mayor que el de pequeños prototipos individuales, y puede no resultar obvio, si el vertical slice no funciona bien, qué elementos son los responsables. El vertical slice es una buena idea, pero debe ir prececido de pequeños prototipos para aclarar dudas en elementos conflictivos. En cualquier caso, el error que nunca se debe cometer es decir "bueno, no es divertido aún, pero en cuanto incorporemos la característica X lo será". Si el juego o alguno de sus elementos no funcionan, hay que corregirlo en el momento, o correr el riesgo de pagar un precio mucho mayor más adelante.

Incluso si el equipo tiene fe en prototipar, a veces no resulta evidente cómo dividir el diseño del juego en pequeños elementos que se puedan prototipar independientemente. Esto típicamente conduce a que se trata de hacer el prototipo equivocado, y luego o bien resulta complicado de implementar, o es difícil extraer conclusiones relevantes. No se debe caer en la trampa de intentar prototipar demasiados elementos a la vez, ya que la complejidad aumenta exponencialmente. Idealmente, hay que diseñar un prototipo que busca responder, con un simple sí o no, a la pregunta de si un elemento del juego funciona. Por ejemplo, ¿es divertido/fácil usar gestos con el ratón para controlar el juego? ¿qué tal se apunta en un FPS con un pad de consola? ¿es divertido mover una pelota a la que se pegan objetos? ¿funciona conducir y disparar a la vez? Otros elementos, más abstractos, son más dificiles de aislar: ¿cómo prototipamos la sensación de libertad en GTA? Concretendolo más, podríamos prototipar si es divertido hacer de taxista, saltar en las rampas, buscar los paquetes ocultos, etc. Al final, las interacciones existentes en GTA son finitas. Separándolas y analizándolas una a una quizá no tengamos la absoluta certeza de que vayan a funcionar bien juntas, pero la probabilidad de que así sea será mayor. Además, la necesidad de concretar los elementos nos sacará del bloqueo de no saber elaborar en que consiste la "sensación de libertad". Otra ventaja de hacer la pregunta correcta al diseñar un prototipo es que las conclusiones que se extraigan serán mucho más claras y evidentes.

Los prototipos pueden tener un efecto positivo sobre la moral. En efecto, en muy poco tiempo estamos viendo elementos del juego en accion. Hay que ser precavidos, sin embargo. No es bueno crear una falsa sensación de progreso. Aunque el prototipo funcione, no tiene calidad final, y es posible que el trabajo necesario para producirlo sea grande (en términos de código, robustez, gráficos, testeo, etc).

Un aspecto importante de los prototipos es que funcionan mejor cuando se realizan como resultado de trabajo en equipo, conjunto y casi me atrevería a decir informal. Si intentamos imponer una disciplina al prototipo, dividiendo las responsabilidades, estableciendo requisitos claros, usando procedimientos de planificación y seguimiento, etc, sólo lo estaremos cargando con una burocracia innecesaria. Podemos fácilmente llegar al absurdo de que la documentación necesaria para construir el prototipo cuesta más que el prototipo mismo. Es mejor formar un mini-equipo, un programador y un diseñador, con un grafista si hace falta, y darles un tiempo (lo más reducido posible, probablemente días o pocas semanas) para elaborarlo. Durante ese tiempo, trabajan juntos, haciendo rápidas iteraciones hasta que o se obtiene el resultado esperado, o se ve que el camino no es el correcto. Lógicamente esto funciona mejor cuando tenemos gente senior en estos roles, pero es lo deseable en cualquier caso: queremos los mejores diseñadores y programadores durante la fase inicial de un proyecto, dado que tendremos mayores posibilidades de que tengan éxito.

Estos son sólo algunos apuntes sobre situaciones que pueden surgir durante la fase de prototipado. En las presentaciones del Spore se entra en detalle algo más técnico en algunos de estos aspectos, como la división que hacen del diseño en varios ejes que luego tratan independientemente. Muy recomendable.

Mostrar/ocultar resto...