Desde la presentación en el hilo de bienvenida hasta la publicación del prototipo en itch.io: qué ocurre en cada tramo, quién hace qué y qué se espera de ti cuando el reloj de las 48 horas ya está corriendo.
El recorrido real de quien entra al foro con una idea a medias: presentarse, montar equipo, aguantar el reloj y publicar lo que salga. Sin promesas de éxito comercial, solo el orden en el que suelen pasar las cosas.
Semana previa
Antes de apuntarse a nada, la gente se presenta: qué roles maneja, si programa en GDScript o C#, cuántas jams lleva encima y qué tipo de prototipo le apetece. Ese mensaje inicial es el que después sirve para que otros te busquen o te descarten.
Días 1 y 2
Se cierran grupos de tres o cuatro personas, se reparten arte, sonido y programación, y se decide el motor antes de tocar una línea de código. Aquí se cae la mitad de las ideas ambiciosas: mejor un alcance pequeño que un proyecto que no llega a compilar.
Durante la jam
Cada equipo publica avances con capturas pixeladas, aunque el juego todavía no se entienda. En paralelo, los hilos técnicos recogen los atascos con Godot o Unity: colisiones que fallan, builds que no exportan, animaciones que se desincronizan a las tres de la mañana.
Cierre de plazo
Cuando se acaba el tiempo, se comparte el enlace con lo que haya. Un prototipo roto pero jugable vale más que una idea perfecta sin build. Se documenta qué quedó fuera y por qué, para que el siguiente reto empiece con esa información.
Semana siguiente
Llegan los comentarios de otros creadores: qué mecánica se entendía, qué parte confundía y qué se podría probar distinto. Ese feedback se archiva junto al devlog, y muchos equipos lo usan para decidir si continúan el proyecto o lo dejan como pieza de aprendizaje.
Retos mensuales
Los retos del foro repiten la estructura: se anuncia el tema, se fija el plazo, se entrega y se comenta. Sirve para mantener el hábito entre jams grandes y para que quien nunca ha publicado se atreva con algo corto.
Desde el primer mensaje de presentación hasta el enlace publicado en itch.io. Cinco etapas que se repiten en cada reto mensual, con los mismos tiempos y las mismas reglas para todos.
Escribes qué roles cubres (programación, arte, sonido, diseño), con qué motores trabajas y cuánta disponibilidad real tienes durante el fin de semana. Sin currículum largo: dos párrafos bastan para que alguien te escriba.
Se abre un hilo por equipo con el tema asignado, el reparto de tareas y el canal donde se coordinan. Los grupos suelen ser de dos a cuatro personas; si sobra gente, se derivan a otro hilo para no dejar a nadie fuera.
Durante la jam se publican capturas pixeladas, fragmentos de código y decisiones de diseño. Las dudas sobre Godot o Unity van a los hilos técnicos, donde alguien responde antes de que el reloj apriete.
Se sube la build, se enlaza el repositorio y se documenta qué quedó fuera por falta de tiempo. Un prototipo incompleto pero jugable vale más que una idea perfecta sin ejecutar.
Cada entrega recibe comentarios sobre qué funcionó, qué se sintió confuso y qué se podría probar distinto. Si el equipo decide seguir, se publica en itch.io y el hilo se convierte en devlog abierto.
Los retos mensuales siguen este mismo ritmo: tema, plazo, entrega y comentarios. Si quieres ver qué se ha construido con este proceso, revisa los resultados de jams anteriores o consulta las herramientas y servicios del foro.