eduardomillan.com

Este fin de semana he participado por tercer año consecutivo en el Global Game Jam, una “compo” a nivel mundial de 48 horas. El último día, en el grupo comentamos las cosas que no se deben hacer en una compo del estilo. Gorka, uno de los compañeros, ha publicado ya una versión más que recomendable y muy completa, así que recalcaré algunas cosas y añadiré alguna otra. Ahí va,

Gameplay: el objetivo es tener un programa jugable. Es decir, el “core” es la jugabilidad o gameplay. Por eso mismo, hay que comenzar pensando en cómo se va a jugar a nuestro juego, cuál va a ser su base de interacción con el jugador. La historia, el interfaz… es relleno, y se puede fijar o adaptar más adelante, sobre la marcha incluso, pero nuestro “core” debe ser diseñado lo primero.

Descarta ideas. La idea del juego debe ser realmente sencilla, explicable y comprendible en menos de 30 segundos, a lo sumo. Hay que empezar por definir una mecánica base y principal, que debe ser suficiente para jugar. Las posibles mecánicas extra, se deben ir añadiendo en función del tiempo sobrante, pudiendo prescindir de ellas sin problema. Con esta premisa, la idea debe estar muy ajustada al tiempo, y debe ser desarrollable (aka estimación fiable) por un sólo programador en la mitad del tiempo dado (si son 48 horas, se tendría que poder hacer en menos de 25..). Hay géneros que tienden a no encajar en esto, como RTS, TBG, aventura gráfica… (en general todo lo que implique mucha IA, física compleja..) así que hay que descartarlos a priori o darlos tanto la vuelta que apenas parezcan ese género. Eso significa que hay que darle muchas vueltas y descartar más y más hasta tener una idea factible (y a ser posible, original!), sobre la que maquillar un diseño. Y no se programa hasta que esto no se tenga claro.

GDD, máximo un folio. Si hemos hecho bien los dos primeros puntos, deberíamos ser capaces de tener nuestro documento de diseño en tan sólo un folio. Sencillo, entendible, ágil. Si alguien tiene una duda, se lo preguntará al productor (leer punto siguiente) o directamente lo verá en un golpe de vista. No hay tiempo para leer El Quijote! ;)

Productor = diseñador. En desarrollos largos / que conlleven muchas personas, es normal y necesario que diseñador y productor no sean la misma persona. Pero en una compo, tener esos dos perfiles separados es un error y un despilfarro de recursos humanos. El producer debe estar pendiente del game designer, “pactando” con él cada tema, algo nada eficiente con un tiempo más que escaso. La comunicación y la escucha es vital en el equipo y si hay un game designer y un producer, tiende a difuminarse mucho, por la definición de ambos perfiles. Una misma persona puede encargarse de ambos roles, tanto por carga de trabajo como por ser complementarios, y será mucho más productivo a la hora de repartir tareas, ajustar el diseño, coordinar los hitos y comunicar cambios…

Código funcional, que no atractivo. Cuando hay que centrarse en tener algo operativo, no hay tiempo para currarse el código. La arquitectura deberá ser tan simple, que hasta el programador más newbie pueda entenderlo, replicarlo, añadir cosas… y debe ser totalmente modular. Si hay más de un programador, uno será quien lleve el peso, la estructura general y el gameplay. El otro, se encargará de los menús, la UI, las funciones de mecánicas secundarias…  y todo tiene que encajar sin perder horas tratando de integrar o descifrando la arquitectura. Si sólo hay un programador, habrá que reducir al mínimo todo lo que no sea gameplay básico.

Lo más óptimo suele ser tener un equipo formado por un grafista, dos programadores y un diseñador / productor. No siempre es posible, y esto puede variar mucho, pero algo que hay que tener muy claro es que hay que adaptar el juego a los perfiles con los que se cuenta. No tiene sentido hacer un juego cuya base son las animaciones “chulas” si no tenemos grafista, o un juego con cierta complejidad en la mecánica si solo hay un programador y apenas tiene experiencia… Parece obvio, pero in situ se suele pasar por alto hasta que es demasiado tarde…

Por último, las primeras tareas están muy definidas: juntar a todo el equipo para la tormenta de ideas, sobre la que decidir y descartar. Con el esbozo de la idea en mente, el productor se pondrá a diseñar el esqueleto, a darle forma al diseño, a tareas logísticas (svn, cuentas…) mientras que el programador comenzará con la base del programa y el artista a probar con el look&feel. Con la base definida, ir refinando de forma iterativa… Resumiendo todo en tres palabras, producir, ajustar y gameplay. ;)

Etiquetas: compos, desarrollo de juegos, game jam, ggj11