Los siguientes artículos tratarán de una experiencia real en el desarrollo de un Indie Game. Hablaré desde los distintos puntos de vista que he experimentado en el desarrollo de Robot Strike Bowling, desde el proceso de diseño hasta el desarrollo, incluyendo los problemas encontrados por el camino, tanto técnicos como humanos. También enseñaré código de cómo se han hecho ciertas partes del juego, las que están bien, las que son mejorables y las que están mal. Otras cosas las juzgaréis cada uno de vosotros… en esta pequeña «guía» no se encuentra la iluminación, sinó una experiencia que puede ser útil a otras personas.
Robot Strike Bowling: Los preludios
Hace mucho mucho tiempo, en una galaxia muy lejana… un programador de XNA y un grafista (Jordi Gimenez, diseñador gráfico, modelador 3D e ilustrador 2D) coincidieron en la red, no se sabe muy bien como. Comenzaron a colaborar en pequeños ejemplos que el programador desarrollaba para su blog. Ninguno de los dos había publicado jamás un videojuego completo en un marketplace, pero decidieron que debían producir uno. Todo empezó en Barcelona, en una presentación organizada por Microsoft de Windows Phone 7 y XNA, que ofrecían Javier Cantón y Eduardo Ortega. Su charla-evangelización sufrió efecto, muchos de los asistentes salimos de la sala con unos incrementados deseos de producir un videojuego, algunos no pudieron soportarl tanta emoción y se tiraron por la ventana, otros comenzaron a programar cuando todavía ni siquiera habían encendido sus ordenadores, como tecleando en el aire. Yo ya tenía experiencia en pequeños proyectos que nunca se terminaron y esta vez quería hacerlo bien, así que intentaría no cometer los errores del pasado. Para mi las decisiones más importantes en este momento fueron:
- Elegir un tipo de juego lo más sencillo posible, pero que me motivase lo suficiente hacerlo
- Asumir que, sin querer ponerme medallas, tenía los conocimientos suficientes para hacer un juego, aunque este fuera simple
- Buscar en mi interior si disponía del tiempo suficiente para terminarlo y renunciar a algunas cosas para disponer de más ratos
- Encontrar un equipo competente, de confianza y con el mismo compromiso implacable
- Decidir que queríamos presentar el juego a Imagine Mobile
Es muy importante aquí estar seguros de que disponemos de los conocimientos suficientes, y eso no es haber leído un libro… es haber programado XNA, en varias situaciones y tipos de escenarios. Si no tenemos los suficientes conocimientos y somos conscientes de ello, lo mejor será unirse a otro equipo que sí tenga la experiencia necesaria, eso será muy bueno para aprender.
Dónde y cómo buscar un equipo
Si te falta gente en tu equipo, hay varias páginas donde puedes encontrar gente que colaborará gratuitamente en tu proyecto en XNA Community, Stratos, y por supuesto en el foro de XNA Creators Club. Para empezar, no busques 10 personas para tu equipo, eso es inmanejable en un juego Indie. Si quieres que se una a tu equipo gente buena, tendrás que demostrar que tu proyecto es serio y estás capacitado para llevarlo a cabo, así que explica muy bien de qué va tu proyecto, y si es posible ten preparado el documento Game Concept, que se explica a continuación.
Y así fué. Dado que los miembros del equipo éramos distantes geográficamente (Jordi Gimenez en BCN, yo en Lleida, y más tarde se incorporaría David Yingling, para crear la música y FX de sonido, en Seattle), así que si queríamos que las cosas salieran bien debíamos intentar mantener la mejor comunicación y de forma lo más productiva posible, porqué además de hacer el juego, todos nosotros tenemos nuestros trabajos y vidas -sí, aunque parezca mentira!-, así que decidimos reunirnos todos los jueves telemáticamente el grafista y yo, que haríamos el diseño conceptual del juego. Es muy importante respetar esas reuniones, sin excusa posible, porque sinó se pierden los objetivos, las metas, y la planificación se va al garete. Pero ya me estoy adelantando…
Lo primero que hicimos fue decidir qué tipo de juego queríamos hacer, concretando la lluvia de ideas que habíamos tenido sobre el papel, o Word en este caso :-P. Primero definimos un documento al que llamamos «Game Concept«. El nombre es bastante autodescriptivo… muchas guías de diseño de videojuegos hablan de este concepto, pero resumiendo mucho, este documento básicamente contiene la idea general de lo que será el juego, las funcionalidades básicas, género, la plataforma en la que se ejecutará, etc. Todo sin entrar muy al detalle, alcanzando el documento una longitud mínima, de dos páginas (sin incluir el concept art que va en assets a parte). Nosotros utilizamos este índice para crear este documento:
- Introduction
- Background
- Description
- Key features
- Genere
- Platform
- Concept Art
Robot Strike Bowling: Planificación
Lo anterior no podía considerarse una fase de diseño con todas las de la ley, era más bien decidir qué juego queríamos hacer. Ahora que lo sabíamos, teníamos que definir una planifiación. La planificación -realizada con Microsoft Project- indicaba fechas clave en las que debíamos tener realizadas ciertas partes del juego si queríamos terminarlo a tiempo para el concurso. Aquí es muy importante no ser demasiado optimistas cuando lo que estamos haciendo es un juego Indie: no disponemos de un número de horas fijas a la semana, y mucho menos al día para trabajar! Hacer este tipo de planificación es mucho más complicado de la que haríamos en un proyecto de software en la empresa en la que trabajo desarrollando aplicaciones de gestión. Un día tendrás que ir a sacar al perro, o al siguiente puede que sencillamente no tengas ganas de alargar la jornada laboral de 8 o 9 horas 😛 así que miremos de ser lo más realistas posible, e incluso un poco pesimistas, con la planificación.
Ojo, tampoco pongamos una planificación a un año vista, porque si el proyecto se alarga demasiado, es provable que el proyecto muera por desmotivación de los miembros del equipo, o simplemente a estos les salgan compromisos personales más importantes que hacer un juego como hobby… así que centrémonos en el objetivo: hacer un juego completo, lo más sencillo posible, en el mínimo tiempo posible. En un proyecto indie los recursos (humanos) hoy están y mañana no se sabe… así que cuanto menos dure el desarrollo mejor, más posibilidades de que no nos tire ningún miembro del equipo. Un recurso es muy difícil de sustituir en este tipo de proyectos…
Otra cosa que puede parecer complicada en un principio es cuánto tiempo asignar a cada tarea. Nosotros no nos rompimos la cabeza con eso, en su lugar nos concentramos más en los hitos, si terminábamos antes de lo previsto el diseño, mejor, si se nos retrasaba… tendríamos un problema, pero había que hacer lo que fuera para terminar como mínimo, el mismo día en que se alcanzaba el hito. Esta estrategia no sería válida en proyectos profesionales, en los que un día de trabajo supone un coste, multiplicado por el número de recursos… un coste mucho mayor, y ahí sí que hay que llevar un control mucho mayor, pero no es el caso que nos ocupa…
Robot Strike Bowling: Diseño y pruebas de concepto
Esto se verá en el próximo episodio amigos…