Juegos de jam sin terminar pero con menú de opciones: Hablemos del valor
Valor: Grado de utilidad o aptitud de las cosas para satisfacer las necesidades o proporcionar bienestar o deleite.
Hace 2 año me uní a MálagaJam, una asociación sin ánimo de lucro que, entre otras cosas, organiza la game jam más chula del mundo. A parte de repartir chuches, hablar con patrocinadores y otras tareas varias; suelo darme un paseo junto a Ricardo e Iván para ayudar a los equipos a entregar su juego: “no me compila y no sé por qué”, “he decidido quitar todos los rect transform del juego y ahora no me funciona la UI”, “hay un bug en C#”… Gracias a esto, he podido meter mano en decenas de juegos de Jam en distintos puntos del desarrollo. Y he visto un patrón: La mayoría de juegos que tienen menú de opciones el sábado, no entregan el domingo. ¿Por qué es esto?
A lo largo de la historia del desarrollo de videojuegos ha habido un problema: “¿Podemos hacer esto?”. Al final, en todos los desarrollos tenemos tiempo limitado, recursos limitados, o un coste de oportunidad (monetario o no) frente a hacer otra cosa. Aun en los proyectos hechos por el amor al arte, priorizar es algo fundamental.
Encontrar nuestra definición de valor.
Siendo que hemos practicado mucho las habilidades concretas para hacer un juego: programar, ilustrar, diseñar, etc.; normalmente las personas que hacemos juegos tendemos a empezar a desarrollar algo sin pensar mucho en por qué lo hacemos. Esto es un error.
Definiendo el valor tenemos un marco sobre el que tomar todas las decisiones de priorización del proyecto.
“Quiero aprender a usar Unity en este proyecto”, “Tiene que permitir un modelo de negocio viable en móvil”, “Quiero hacer un juego experimental de control alternativo”, “El juego tiene que ser accesible”, “Tiene que dar mucha grima el juego”, “Quiero pasarlo bien mientras desarrollo”, “Tiene que gustar a la gente fan de los metroidvania”… Todas estas pueden ser pilares de nuestra definición de valor. Se pueden tener tantas como se quiera en un proyecto pero cuantas menos haya, más “a tiro hecho” iremos.
Usando nuestra definición de valor, podemos decidir si debemos o no trabajar en algo. Si una feature va en contra la definición de valor que hemos explicitado, es muy fácil decidir no hacerlo.
Algunas de las propuestas de valor anteriores, tienen personas objetivo distintas: si “Quiero pasarlo bien mientras hago el juego”, tengo que pensar en qué quiero yo. Si “Tiene que permitir un modelo de negocio viable en móvil”, tendré que pensar en las circunstancias del mercado móvil. En caso de que una feature ponga en conflicto 2 pilares, ahí es donde podemos tomar una decisión informada, viendo qué aporta a cada uno.
Si cada integrante del equipo tiene una idea del proyecto completamente distinta a sus compañeres, el equipo no funcionará bien. Al tener una única definición de valor, todo el equipo puede ir a una.
La definición de valor puede y debe de cambiar en cualquier momento, bajo criterios del equipo. Ya sea debido a cambios en el mercado, a los intereses del equipo, o a lo que sea. Pero esa decisión debe de ser explícita.
¿Y esto qué tiene que ver con las jams?
Tenemos 48 horas para entregar un juego y aunque podemos hacer un equipo infinitamente grande, 9 personas embarazadas no tienen 1 hije en un mes; por lo que hay que priorizar.
¿Qué aporta un menú de opciones normal, en una Game Jam, donde la mayoría de gente como mucho le va a dedicar 5 minutos a tu juego, frente a literalmente cualquier otra cosa? Todo minuto dedicado a eso es tiempo que podría haber ido a tener un juego terminado, a que ese juego terminado sea más divertido o símplemente a jugar al ping pong y dormir más.
Lo bueno de haber priorizado por valor, es que en el caso de tener que cortar el desarrollo por algún problema, o por quedarnos sin tiempo, lo más importante ya está terminado y se puede entregar. Además, que estimar bien es una habilidad increíblemente difícil si no imposible en muchos casos.
Más allá de las jams
Obviamente, si hiciéramos un juego con un periodo de desarrollo de 2 años, un menú de opciones es necesario. Aun así, ¿qué valor aporta hacerlo temprano? Al hacerlo temprano, añadimos tiempo hasta que validamos que otras partes del juego funcionan o son divertidas. Un menú de opciones no es algo difuso que haya que validar que funciona, por lo que no obtenemos a penas valor al crearlo pronto y no mitiga posibles riesgos.
Obviamente hay muchas más features que los menús de opciones, y su priorización no es tan straightforward. Pensar antes de trabajar en algo que se puede ir a la basura NUNCA es una mala idea.
Lo mejor que podemos hacer en un proyecto es mantenerlo en un estado entregable todo el momento, y usar el estado actual junto con nuestra definición de valor y los riesgos conocidos para ver qué es lo siguiente en lo que debemos de trabajar.
Y tú, ¿en lo que estás trabajando ahora que valor crees que aporta?
