Lecciones de una jam.

 Este año me apunté por primera vez a una jam de videojuegos. En otras ocasiones me había aprovechado de estas competiciones para conseguir usar gratuitamente herramientas de creación de juegos (concretamente, construct3, cuya licencia anual es carísima para usarlo treinta días al año), pero esta vez, animado por un correo de la gente de DragonRuby, me planteé aprovechar la ocasión para intentar llevar hasta el final algún proyecto que nunca hubiera conseguido sacar adelante.

Las normas de la Jam eran las siguientes:

• El juego tendría una resolución limitada (84x48 monocromo).
• Se podrían usar herramientas de creación de juegos.
• No se podría reutilizar código.
• No se podrían reutilizar tipografías, sprites ni sonidos, excepto los disponibles en la propia página de la jam.

La primera norma fue la que más me gustó. Nunca se me dio demasiado bien dibujar, pero tenía un trasfondo dibujando UDGs (sprites) para Spectrum y tipos de letra para MsDOS. Sin embargo, el resto me parecían un poco limitantes y en cierto sentido, desequilibradas.

Si no podías reutilizar código pero sí podías usar herramientas de creación de juegos, la gente que usara directamente código tendría que programar sus propias rutinas para TODO, mientras que los que empleasen herramientas de creación de juegos no tendrían que preocuparse por detalles como "cómo renderizar una spritefont". Y eso me preocupaba, porque yo estaba usando processing, un lenguaje bueno para renderizar tipografías vectoriales, pero que no contaba con soporte para spritefonts (y de las tipografías disponibles en la página de la jam, la única con una licencia aparentemente válida era una spritefont).

Mi proyecto se fue al traste y será probablemente el deshonroso ganador de la cucharilla de palo. Después de haberme quedado despierto de madrugada para conseguir algo compilable, porque me habían dicho que aunque no estuviera completo subiera lo que pudiera, he leído comentarios crueles como "este tío se apuntó a una jam para subir su basura". Pero voy a valorar las lecciones que he aprendido en el viaje.

1. Planifica desde el principio. Apliqué el principio del NaNoWriMo según el cual "planificar no es escribir" (luego, los escritores dicen lo contrario). No conté como "reuso de código" el probar cómo hacer ciertas cosas (por ejemplo, cómo crear un display virtual de 84x48 no difuminado y darle la caprichosa paleta de colores elegida en la jam). Pero, sin embargo, perdí luego mucho tiempo porque no había planificado ciertas cosas, o porque me salí del plan.
2. Antes de apuntarte, mira bien las fechas. En mi zona de tiempo, la jam empezaba un sábado a las 9 de la mañana, cuando yo contaba con la tarde del viernes anterior. A cambio, acababa el lunes a las 8 de la mañana, algo realmente poco aprovechable.
3. Antes de apuntarte, pídele a tu familia y amigos una agenda. Porque luego resulta que contaban contigo para un sinfín de tareas que tú no esperabas.
4. Usa una game engine. Ciertas cosas es muy difícil hacerlas con una game engine, pero con ella no te pasarás la mitad del tiempo buscando la raíz de un error.
5. Usa archivos distintos para cada clase/objeto. Yo estoy malacostumbrado por Qbasic y VBA, dos entornos en cuyo IDE puedes saltar rápidamente de una rutina a otra, de un objeto a otro, sin tener que estar continuamente pulsando CONTROL-F para averiguar cómo se llamaba exactamente ese método que permitía recorrer dos los objetos de cada habitación y pintarlos en pantalla.
6. Usa un único ordenador. Si la jam te va a pillar en casas distintas con distintos ordenadores, desiste. Porque git *a veces* te dice que ha enviado los cambios y luego no lo ha hecho, como me pasó cuando llegué a mi casa a las 21:30, actualicé desde git, estuve editando el código y a las 23:00 el compilador me dio error porque algo que había cambiado (en otro ordenador, en otro lugar) estaba como al principio. Gracias a Dios, además de git había usado robocopy y pude emplear la vieja herramienta fc de MsDOS para combinar los cambios a mano, pero perdí una hora en el momento de más tensión. 
7. Céntrate en lo importante. No planifiques por adelantado los detallitos cuando todavía no has escrito una línea del interfaz. Para el usuario, lo importante es el interfaz. He perdido horas, por ejemplo, averiguando por qué un papel pintado del fondo de la pared de una habitación no tenía el patrón que yo buscaba. (Y es algo que en mi vida cotidiana me pasa mucho).
8. Céntrate en lo importante. No pierdas el tiempo preparando una Spritefont que tenías por ahí para ofrecerla a la comunidad para la próxima jam. 
9. No subas nada si no está completo. Si te han dicho "no importa, sube lo que tengas", te lo han dicho por decir. En realidad, el jurado de una jam es como el de un concurso literario: no quiere mierdas, quiere obras de calidad. 
10. No te apuntes a jams. Te hacen perder una enorme cantidad de vida social, quedas mal con tu familia (Y ahora, ¿quién me va a hacer de canguro?) y con tus amigos. Hace que se te acumule trabajo en casa (porque para completarlo necesitas más de las 7 horas semanales de trabajo en casa que indica el contrato) y, sobre todo, hace que te sientas como un idiota.

Dicho todo lo anterior, me lo he pasado como un enano. Fuera de jam he tardado muy poco en resolver algunos de los principales errores del juego, que anoche no veía por dónde agarrar. Pero la aplicación sigue siendo fea, horrible y ENORME (processing genera minijuegos de 100 megas, porque incrusta la máquina virtual java en el .exe). Algún día subiré una versión arreglada a itch.io o a github. Pero ahora tengo unos exámenes que corregir, un sobrino al que atender y unas estanterías por colocar.