Aquí se explica el ciclo completo de una jam: buscar equipo con roles definidos, publicar avances con capturas y notas de proceso, organizar retos mensuales con plazos claros y resolver dudas técnicas sobre Godot o Unity en hilos donde el código se puede reproducir.
Estas son las capacidades que sostienen el ciclo real de una jam: buscar equipo, documentar el proceso, resolver dudas técnicas y cerrar retos con material que sigue sirviendo después. Nada de vitrinas ni promesas: herramientas y espacios concretos para trabajar.
Publica un hilo indicando qué necesitas: programación, arte 2D, diseño de niveles o sonido. Puedes filtrar por motor (Godot, Unity) y por experiencia previa, para que un estudiante de primer año y alguien con varias jams publicadas se encuentren sin ruido.
Sube capturas de prototipos pixelados, fragmentos de código y notas de proceso tal como salen. La idea es que quede registro de las decisiones, no solo del resultado final. Los hilos admiten ediciones posteriores para anotar qué funcionó y qué se descartó.
Cada mes se abre un reto con una temática distinta y un plazo cerrado. Los envíos quedan documentados en el foro para consulta posterior, así que sirven como referencia cuando alguien quiere ver cómo se resolvió un problema parecido en otra jam.
Dudas sobre Godot o Unity se resuelven con ejemplos reproducibles: versión del motor, pasos para llegar al error y captura del resultado esperado. Se pide lo mínimo para que otra persona pueda replicar el caso sin adivinar.
Los comentarios se centran en el prototipo, no en quien lo hizo. Se distinguen bugs, decisiones de diseño y gustos personales para que la crítica sea útil y no desanime a quien acaba de publicar su primer proyecto.
Comparte el enlace de tu build, el peso del archivo y en qué plataformas corre. La interfaz oscura con tipografía monoespaciada y avatares visibles ayuda a reconocer rápido a quien responde y a seguir hilos largos sin perder el hilo.
Si quieres ver cómo encajan estas capacidades en el día a día, revisa el proceso de trabajo o pasa por servicios para conocer los formatos disponibles.
No todos llegan al foro en el mismo punto. Algunos buscan equipo para la jam del fin de semana, otros quieren dejar constancia de cómo montaron su prototipo en Godot y hay quien solo necesita que alguien lea su código y le diga por qué el salto no responde. Estos son los formatos que funcionan mejor según el caso.
Pensado para jams de 48 horas y proyectos que arrancan desde cero. Defines roles concretos (programación, arte 2D, diseño de niveles, sonido), indicas motor y nivel de experiencia, y filtras por disponibilidad horaria. La gente responde en el mismo hilo con enlaces a su itch.io o a prototipos previos.
Aquí se publica el proceso tal como ocurre: capturas pixeladas del prototipo, fragmentos de GDScript o C#, decisiones que salieron mal y notas de la última hora antes de la entrega. No hace falta que el juego esté pulido para escribir. Muchos devlogs empiezan con un cubo que se mueve y terminan siendo referencia para otros.
Cada mes se lanza un reto con temática distinta y plazo claro. Al terminar, los hilos quedan abiertos para consulta: sirven para ver cómo resolvió otra persona el mismo problema. En paralelo, los hilos técnicos sobre Godot o Unity funcionan mejor cuando incluyes versión del motor, mensaje de error y un ejemplo mínimo reproducible.
Si dudas entre varios formatos, revisa primero qué ofrece la comunidad y luego elige el que encaje con tu tiempo disponible esta semana.