Mamá, quiero hacer un videojuego

Conviene recordar que es muy probable que la gente con la que trabajas lo esté haciendo gratis. Aunque no fuera así, siempre enriquecerá tu documento contar con sus ideas y opiniones. Convoca brainstorming y no seas demasiado hermético con tu idea ni tampoco dejes que se te cambie el juego entero si no quieres por miedo de perder su colaboración. Si existe algún bloqueo toma decisiones. Tu misión es terminar el juego, y para ello es importante conseguir que el proyecto sea de todos, y que nadie se sienta obligado a hacer algo que no quiera hacer. Tú mismo incluido.

Al igual que el Concept, el GDD es un documento vivo, así que a veces surgirá la necesidad de modificarlo, cambiarlo, etc. Conserva las versiones antiguas (nunca sabes cuándo vas a necesitar echar mano de algo que desechaste), y mantén un orden en la numeración de los documentos. Debes asegurarte siempre de que todos estáis trabajando en la misma versión del proyecto.

Simultáneamente al GDD, se puede hacer el TDD (Technical Design Document), donde especificaremos las tecnologías que vamos a utilizar, los programadores esbozarán un diseño de la arquitectura del proyecto, y a partir del cual, muchas veces descubriréis que por puro pragmatismo hay que ir cambiando algunas cosas del GDD.

Sobre estos dos documentos ya escribiré un artículo, igual que prometí que haría con el Concept.

El TDD es nuestra guía de trabajo. Si el GDD es el alma, el TDD es el cuerpo. Es hora de organizar tareas, establecer hitos, y quizás ayudarte de aplicaciones como el Project Manager para dirigir el proyecto. Una de las cosas más difíciles es calcular los tiempos. Los miembros del grupo deberían ser conscientes del tiempo que van a emplear en realizar cada tarea, pero por lo general los desarrolladores solemos pecar de optimistas. Seguro que encontraréis un montón de trucos para poder acertar con los tiempos, pero uno que me comentó una compañera y que me da buen resultado es multiplicar por 4 el tiempo que creemos que vamos a tardar. Por lo general no sólo llegaremos bien al plazo, sino que nos sobrará algo para afinar un poco el trabajo o adelantar en otras cosas.

Lo más probable es que en nuestro primer proyecto tengamos la suerte (buena o mala) de que ningún Publisher se haya fijado en nuestro trabajo. Lo bueno es que nadie nos va a imponer unos tiempos de entrega, así que podemos permitirnos ser sinceros con nosotros mismos y ser realistas con el esfuerzo que el grupo va a invertir en el trabajo. Aunque no estéis obligados a cumplir ese tiempo, poneros hitos y tratar de llegar a ellos es una forma de aseguraros que el proyecto no va a abandonarse por dejadez.

Y ya sólo queda picar, modelar y componer todos los elementos que hemos definido en el GDD de la forma que hemos especificado en el TDD.

Las fases de un  proyecto, las expondré en otro artículo.

Un consejo: no debéis obsesionaros con la documentación. Aunque la metodología es muy importante y os ahorrará más de un dolor de cabeza, no os garantiza que no vaya a surgir ningún problema. Para juegos pequeños, quizás queráis prescindir de algunos (o todos) los documentos. Lo importante es que siempre seáis conscientes de todo lo que tenéis que hacer, no os olvidéis de nada importante porque no lo apuntásteis y que contéis con los recursos necesarios para hacerlo. Si pensar que tienes que escribir no se cuantas páginas va a hacer que te eches para atrás, no las escribas.

Es tu juego y sólo tú sabes qué estás dispuesto a hacer para llevarlo a cabo.

Y un último apunte. Sólo hacer un juego ya constituye un éxito. Da igual que no venda o que a nadie le guste. Os habéis propuesto una meta difícil y la habéis cumplido. Muy poca gente puede decir lo mismo. Pensad en todo lo que os ha aportado: ilusión, conocimientos, buenos momentos, recursos para futuros juegos y, sobre todo, un entrenamiento de fuerza de voluntad que os ayudará con vuestro próximo proyecto. Analizad tanto vuestros éxitos como vuestros fracasos y aprended de ellos.

¡Ánimo!