Producción de Proyectos: Quick And Dirty Prototype (QDP)

En esta entrada voy a introducir un sistema de producción de proyectos que vi en Gamasutra por Paraluman Cruz, y que utiliza un pequeño estudio asiático llamado Boomzap Entertainment. Es un método de producción que sirve muy bien a nuestros propósitos pues su objetivo es tener lo mas rápido posible un prototipo jugable, de forma que podemos por una parte trabajar sobre el código mientras por otra parte también podemos crear los gráficos de forma casi independiente.

Los 3 Puntos Fundamentales de QDP

“Quick and dirty prototyping” esta basado en tres ideas fundamentales

1. Hacer un prototipo que funciones lo mas rápido posible
2. Mantener los gráficos de prueba hasta el ultimo momento posible
3. Revisar o desechar el contenido hasta que sea divertido

El método está basado en la eficiencia y la velocidad. Haciendo versiones diarias, usando elementos de prueba e iterando rápidamente, se puede conseguir avanzar hasta el final del proyecto.
 

El Prototipo rápido: El Quick de QDP

En el articulo de Paraluman Cruz, explica como hacen ellos para tener siempre a punto un sistema que permita a los grafistas y los programadores trabajar por separado. Básicamente se basan en una hoja de Excel en donde los grafistas, los diseñadores de script, los músicos e ingenieros de audio introducen los elementos que están creando y los programadores con posterioridad pueden ejecutar un script que haga la versión diaria y probar lo que se ha hecho.
Como nosotros vamos a trabajar solos, o con menos especialización, ya que haremos los gráficos y los sonidos nosotros. Adaptaremos un poco el sistema.
El principal punto es poder hacer pruebas rápidas de las ideas que tenemos. Una de las piedras en el camino que me he encontrado ha sido que cuando empezaba un nuevo juego, la idea genial y excitante que tenia en mente en seguida se topaba con el aburrido mundo de los gráficos. Se diluía mi entusiasmo mientras trataba de encontrar los gráficos que me gustaban o incluso los hacia yo. En resumen trataba de encontrar o hacer los gráficos perfectos antes incluso de haber escrito una línea de código. Y eso es un ERROR!
Ahora lo que hago son sustitutos (placeholders). Para ello extraigo de mi diseño y mi visión del juego todos los elementos que voy a necesitar. Los distintos botones del menú, el numero de enemigos y que gráficos van a tener, las decoraciones y fondos que necesitare, etc.
Todo ello lo apunto en un papel y también calculo los tamaños, haciendo un pequeño bosquejo en inkscape (un programa de dibujo vectorial). A partir de esta lista y tamaños creo un rectángulo u otra forma geométrica que tenga el mismo tamaño, el mismo nombre de archivo y la misma ubicación en el disco duro que tendría el elemento definitivo.
Por ejemplo, un fondo es un color solido con un texto que diga “Fondo 1” o “Fondo de Selva”., o un botón el menú que ponga “icono atrás” o solo “atrás”. Lo importante es que desde el principio tengas un modelo de organización. Después es sentarse y empezar a programar usando esos sustitutos.
Como esto es un proceso iterativo, es decir, cada vez que acabes una elemento del juego, empezaras o mejoraras haciendo una nueva versión con el prototipo de la nueva característica. Así que el numero de elementos gráficos, etc. aumentaran según vayas desarrollando el juego.

Los gráficos feos: El Dirty de QDP

Los chicos de Boomzap Entertainment empiezan y mantiene los gráficos feos hasta el final. El objetivo es permitir que el resto del equipo avance mientras los grafistas se dedican ha hacer su arte. Mientras que programar, probar y pulir un elemento del juego puede hacer en cuestión de horas o unos pocos días, un elemento gráfico que sea bonito y funcione puede tardar semanas.
En nuestra adaptación, como seremos nosotros los que hagamos también los gráficos, significa que podemos dedicarles el tiempo que queramos en el momento que queramos. Hay veces en que uno está poco inspirado en la programación y dejar que se “enfríe” el código es ha veces una buena manera de recuperar la inspiración. En esos momentos, podemos dedicarlos a pulir los sustitutos y empezar a darles forma.
Otra ventaja es que si conseguimos que un juego a base de figuras geométricas de colores solidos sea divertido, es seguro que tendremos un juego de éxito.

nota:

Aquí entramos en el resbaladizo terreno de que hace que un juego sea un éxito.
Si preguntamos a un grafista dirá que lo más importante de un juego será que el juego sea bonito y espectacular.
Si preguntamos a un programador o a un diseñador dirá que lo más importante es que sea divertido.
Recuerdo una discusión que tuvimos en Revistronic el director de arte y los programadores a cuenta de un carromato en medio de un nivel de combate.
El grafista insistía que el carro tenia que estar en medio del área de combate, “por que si no no se ve lo bonito que es”, mientras que el programador de IA decía de mandar a tomar viento el carro pues hacia que los enemigos se atascaran e interrumpía el flujo del combate.
Ganamos los programadores :D

Revisar, Revisar, Terminar.

El tercer punto de QDP es revisar o desechar lo que se ha hecho. Es decir, que los chicos de Boomzap, cada vez que tienen una nueva idea, un nuevo puzle u otro elemento para un juego, hacen un prototipo rápido dentro del juego y luego lo revisan. Si es un buen punto para el juego lo pulen hasta obtener un buen elemento o si no funciona lo tiran directamente a la basura.
Una de los problemas de trabajar solo es que tenemos que ser lo suficientemente honestos como para poder descartar algún elemento que nos parecía divertido, pero que al final no acaba de encajar.
El ego que ideo esa característica siempre nos estará dando la vara con que va a funcionar, que tenemos que seguir puliéndolo, etc. Hay que saber dar una patada en el culo a los egos que se meten en nuestro trabajo.
Lo importante es que sea divertido. A la hora de revisar hay que pensar como el jugador no como el programador.
Otro punto importante que Paraluman Cruz apunto en su articulo es que hay que saber cuando parar de revisar. Podemos entrar en un bucle infinito de revisar, pulir, revisar, pulir… Y nunca llegar a terminar esa característica, haciéndonos perder un tiempo precioso.
Al fin y al cabo,No hemos hecho un juego hasta que lo publicamos. Así que por mucho que revisemos y lo dejemos súper perfecto, si nunca lo publicamos para que otros lo juegos y disfruten, nunca seremos creadores de videojuegos, solo aficionados a programar.

Conclusión

El sistema QDP, adaptándolo a nuestras características, es un buen sistema para equipos de desarrollo pequeños o para crear juegos en solitario, pero requiere de un tipo de personas que sean capaces de adaptarse al sistema y tengan la capacidad de ver el camino hacia el producto final.
Hasta aquí la entrada de esta semana. Espero que os sea útil. Gracias por vuestra atención.