Nota introductoria: Éste es el primero de una serie de artículos centrados en la planificación de la producción de un desarrollo, especialmente durante la fase de preproducción. Vamos a ver cuales son las tareas que tiene que desarrollar el productor dentro del equipo, y ejemplos de la documentación que tiene que generar.
En cuanto tengamos una idea suficientemente clara de lo que va a consistir el juego a nivel de diseño, una de las primeras tareas que puede realizar el productor para ayudar al desarrollo del juego, es el cronograma del proyecto.
Se trata de un calendario de los eventos de alto nivel (es decir, a grandes rasgos) que tienen que ocurrir durante el desarrollo, y una estimación de cuando éstos van a tener lugar:
Cronograma de “Broken Age”, Double Fine Documentary, Episode 6
¿Para qué sirve?
La ejecución de un desarrollo profesionalizado se dá en un entorno de recursos limitados, y entre estos recursos limitados, uno de los más importantes suele ser el tiempo de desarrollo. Es de vital importancia que exista una conciencia clara en todo el equipo de que el proyecto se está desarrollando contra una serie de plazos en el tiempo. Es competencia del productor implantar esta visión cuanto antes, y mantenerla durante todo el proceso.
La utilidad de este documento es principalmente servir de guía para el resto de procesos que se tienen que dar en la producción. Ésta guía la podremos usar para elaborar el presupuesto para el desarrollo, y a partir de éste último, elaborar un plan de financiación para poder ejecutarlo. También podemos utilizar el cronograma como guía para decidir las tareas que acometemos en cada nuevo ciclo, durante los sprint meetings: además del estado del juego en sí, resulta útil tener un visión global para recordarnos a que metas deberíamos de estar llegando según el calendario.
Finalmente, el cronograma también nos sirve para negociar una serie de acuerdos entre el desarrollo del juego en sí (diseño, arte y programación) y las actividades de marketing y negocio necesarias para vender copias en el futuro. A veces, llevar una demo a una feria o presentar el desarrollo a un publisher, puede desviar el esfuerzo del equipo de desarrollo de lo verdaderamente importante: hacer un buen juego. Si planeamos estos eventos con antelación, reduciremos el impacto que tienen este tipo de tareas en el desarrollo del juego.
¿Cómo hacer el cronograma?
Supongo que no hay una sóla forma de afrontar la creación del cronograma, así que voy a comentaros cómo lo hemos hecho nosotros en nuestro desarrollo actual. Para mi, me resulta imposible empezar a hacer el cronograma sin antes tener una idea básica de en qué va a consistir el juego, por eso no suelo empezar hasta que no ha terminado una fase inicial de concepción de la idea.
Para el primer paso utilizaremos una pizarra y un puñado de post-its. Vamos a considerar que el extremo izquierdo de la pizarra es el inicio del proyecto, y el extremo derecho de la pizarra es el lanzamiento o fin del proyecto. Nosotros, además usamos colores diferentes en los post-its para estos 4 tipos de elementos: Milestones, Features, Contenidos, e Incertidumbres.
El primer ejercicio es pensar en una lista de fechas conocidas. ¿Hay factores externos que nos hayan fijado alguna fecha? Estos factores puede ser: una feria a la que nos hayamos propuesto acudir, un concurso en el que queramos participar, una convocatoria de ayudas de financiación pública (con sus plazos límite de entrega del dossier). Rellenamos un post-its para cada una, si vas a usar colores diferentes, éstos son de tipo milestone, y los colocamos en la pizarra.
En cuanto sea posible vislumbrarla, marcamos la fecha estimada de finalización del proyecto. La colocamos en el extremo derecho de la pizarra, contamos los meses que nos faltan hasta entonces y dibujamos con un rotulador líneas verticales creando una columna para cada mes del desarrollo.
A partir de aquí, empezaremos a deconstruir el desarrollo de la forma más atómica que nos sea posible, e iremos poniendo en la pizarra un post-it por cada tipo de contenido:
- Features: se trata de las cosas que puede hacer el juego, normalmente lo relacionamos con las tareas de los programadores. Colocaremos estos post-its en la columna del mes en el que esa feature debe haber quedado implementada en el juego. Algunos ejemplos: “sistema de localización”, “combate cuerpo a cuerpo”.
- Contenidos: se trata de los elementos que una vez incorporado, generan tiempo de juego. Se trata de tareas para los artistas y diseñadores: creación de modelos, texturas, sprites, montaje de niveles, guionización, sonorización, etc. Algunos ejemplos: “concept de enemigo #3”, “nivel de la playa funcionando”. Al colocarlos en la pizarra, hazlo en el mes en el que consideras que estos contenido deben estar creados y/o incorporados en el juego.
- Incertidumbres: se trata de elementos del desarrollo que en el momento de hacer el cronograma aún no se han decidido, no está claro en qué consisten o que necesitan una fase de I+D que tendrá lugar en el futuro, de la cual se pueden desprender una serie aún indeterminada de características y contenidos. Colocalos en la pizarra en el mes en que consideras que la incertidumbre ha debido quedar resuelta, se han tomado las decisiones oportunas, y se ha convertido en una lista concreta de features y contenidos. Ejemplos: “diseño del sistema de progresión”, “características en la nube”.
Una vez que hayas colocado en la pizarra todas estas tareas, convoca al resto del equipo para enseñarsela. Entre todos, repasad lo que hay en la pizarra, con el objetivo de:
- Detectar elementos se te hayan podido pasar por alto.
- Descomponer un post-it en varios, añadiendo más detalle a la planificación.
- Reordenar los post-its en el tiempo atendiendo a criterios técnicos o de diseño que no hayas tenido en cuenta.
El siguiente paso es cortar el proyecto en varias fases (no demasiadas) de varios meses cada una, siguiendo ciertos criterios:
- Podemos definir un entregable de forma concreta y contrastable para el final de cada fase. Un entregable es un trozo del proyecto terminado y tangible, potencialmente entregable a un tercero, o al público. En fases avanzadas del proyecto, normalmente será una build del juego con ciertas partes de gameplay terminadas, pero al principio también podemos considerar entregables prototipos que cumplen una determinada función, o incluso partes del GDD. Discute y acuerda con tu equipo los entregables, y anótalos para agregarlos al cronograma cuando lo pases “a limpio”.
- El paso de pre-producción a producción coincide con un cambio de fase. Procura acumular todos los post-its relativos a incertidumbres antes del paso a producción.
- Si una fase dura más de 4 o 5 meses, considera cortarla en dos. Si hay algún milestone apropiado en el interior, puede hacer coincidir éste con el entregable de la primera subfase que has generado. Si no lo hay, introduce uno artificialmente pero con sentido común. Por ejemplo, nosotros lo que hacemos es determinar que después los primeros 4 meses de producción vamos a tener un entregable que consistirá en una demo de gameplay para llevarla a una feria y hacer playtesting.
- Introduce, si no lo has hecho, un milestone para el cierre de textos. Será el momento de no retorno para tener todo el contenido de texto terminado y mandarlo a traducir.
- Normalmente, los milestones relativos a lanzamientos (publicación de una build del juego) se colocarán al final de una fase de QA (en la que vas a estar más centrado en eliminar bugs, que en añadir contenidos).
Primer intento de cortar en fases nuestro cronograma. Posteriormente, fusionamos las dos primeras fases, para volver a dividirlas de otra forma.
Una vez que habéis terminado el ejercicio de colocar el cronograma en la pizarra, pásalo a “limpio” para añadirlo a la documentación del proyecto. Yo empiezo por fotografiar la pizarra con el móvil, para referencias futuras.
A continuación genero un documento de texto, en formato A4, con una lista de milestones y entregables. Procuro destacar las fechas con un buen tamaño de fuente, y describir en qué consiste el entregable asociado al milestone.
Si tiene sentido, le añado recortes de las fotos que hice de la pizarra.
Después lo imprimo en formato A4 y cuelgo una copia en cada habitación de la oficina (el equipo está repartido en 2 salas).
El siguiente paso sería crear un diagrama de Gantt. Este diagrama respeta el formato de línea de tiempo que usamos en la pizarra para disponer los post-its, pero además permite añadir una relación de dependencia entre las tareas que hemos determinado. Yo utilizo una herramienta en la nube que se llama GanttPRO, con la cuenta básica y gratuita es suficiente para nuestros fines:
Clic en la imágen para descargar el Gantt inicial de Blasphemous en PDF.
¿Y ahora qué?
Una vez que hemos completado este paso, podemos empezar a dar los siguientes, especialmente aquellos que están relacionados con cuantizar el coste de la producción. En el siguiente artículo de la serie veremos cómo hacer el presupuesto de desarrollo.
