Un game jam consiste en sentarse a hacer un juego en una cantidad de tiempo muy restringida, generalmente unos cuantos días. Se pueden organizar eventos con distintas magnitudes de asistencia o definirse un concepto al rededor del cual se harán los juegos.
En la ciudad de México se han organizado varios jams. Siempre hemos querido participar en ellos, pero en Tochas Studios tenemos el súper poder de enterarnos de las cosas importante en un rango de dos días del que van a pasar, ya sea en pasado o a futuro. Siempre que nos enterábamos de algún jam en la ciudad, por alguna razón de importancia intrascendente, no asistimos.
A principios de este mes surgió la idea de, al menos una vez al mes, tratar de hacer y publicar algún juego producto de un game jam.
Decidimos delinear la experiencia a modo de ejercicio. Por ser la primera vez, muy pocas cosas las respetamos como inamovibles. La idea original era sólo dedicar un día. Después de discutirlo durante una tarde, se acordó que únicamente un día, sería muy poco tiempo y se extendió a dos. Y, por esta ocasión, el principal objetivo sería la experiencia como tal y no la publicación del juego (Aún así, publicaremos lo que hicimos).
El ejercicio rindió frutos, al menos, respecto a la eficiencia del método de trabajo. Quizá lo que se vuelve más evidente es: para fines de bocetar una idea, es mejor representar, por burdo que sea, la totalidad de sus componentes; en lugar de trabajar con ligero lujo de detalle sólo algunos. (!Duh!)
De esa manera se puede contemplar más fácil un resultado más completo. Probablemente el “juego” terminará con sólo algunos de los elementos originalmente planeados y la idea general se ajustará a esa limitante. Pero el atreverse a trabajar con elementos que cumplan su función de "placeholders" es una de las principales lecciones. Perderle el miedo a tener algo incompleto en las manos.
Uno mismo sabe que de tenerse más tiempo, dinero, equipo, etc, los valores de producción mejorarían; mientras que la funcionalidad/calidad de la idea se debería probar desde antes.
Con todo eso en mente, es imposible no mirar en lo que se esta trabajando y verlo con un ligero desprecio. Pero el único propósito es ajustarse a una limitante muy estricta de tiempo y acabar con algo jugable. Poder probar pequeñas ideas al rededor de una mecánica, o buscar cómo expresar algo a través de un sistema muy simple.
De entrada termina siendo un ejercicio de planeación, ejecución e implementación. En general hacer estimados de tiempo al rededor de todo lo que involucre software, por su naturaleza, es complicado. En nuestro caso especifico, con los dos primeros desarrollos, nos hemos percatado que no tenemos buen ojo para las estimaciones temporales.
En cuestión de diseño, tienes que llegar a la esencia del sistema que conformará tu juego. De esa forma podrás ser muy cuidadoso con que sí es necesario y que cae en la categoría de “nice to have”.
Por último, el formato de game jam resulta ser muy bueno para quitarte “espinitas”. Un Jam te permite trabajar en juegos de algún género que esté siendo de tu interés. Puedes rápidamente probar muchas cosas sin estar enteramente preocupado por el resultado. Echar a andar un prototipo y estar jugando con tus mecánicas es algo que puedes llevarte como resultado de cualquier jam.
Sobre el resultado final, lo publicaremos y ya hablaremos sobre lo que se buscó específicamente con ese juego.
Después de haber estado trabajando en SodaCity durante tres años, el sentarse a probar otras ideas resulta refrescante. De todos modos sigue habiendo planes para SodaCity, se está considerando la posibilidad de implementar multijugador y ya se cuenta con actualizaciones y mejoras en otros rubros.
No comments:
Post a Comment