Emparejamiento de roles para jams de 48 horas, hilos de soporte técnico sobre Godot y Unity, retos mensuales con reglas claras y devlogs donde se documenta el proceso sin adornos. Todo el apoyo circula entre pares, sin intermediarios.
No es una lista de promesas: son espacios concretos que ya funcionan dentro de la comunidad. Cada uno tiene su propio ritmo y sus reglas, y todos se sostienen con la participación de quienes publican, comentan y devuelven el feedback que reciben.
Publicas qué necesitas y qué aportas: programación en GDScript o C#, pixel art, diseño de niveles, música o efectos. Se forman equipos de tres o cuatro personas con roles claros antes de que arranque el reloj.
Dudas de física, exportación a web, gestión de escenas o errores que aparecen a las tres de la mañana. Se responde con capturas, fragmentos de código y la versión exacta del motor, para que la solución sirva a quien lea el hilo después.
Cada mes se abre una consigna distinta y un plazo acotado. Las reglas se publican al inicio, se aceptan prototipos inacabados y al cierre se comentan los envíos en un hilo común.
Aquí se documenta el proceso tal como ocurre: decisiones que no funcionaron, mecánicas descartadas, capturas de prototipos pixelados y notas de la build. Menos escaparate, más cuaderno de trabajo.
Un hilo para contar en qué estás, qué motor usas y qué te gustaría aprender. Sirve para que otros te encuentren cuando buscan un rol concreto en la siguiente jam.
Se comenta en tres capas: qué funcionó, qué resultó confuso y qué se podría probar distinto. Todo el apoyo es entre pares, sin intermediarios ni costes ocultos.
Si quieres ver cómo se aplican estas dinámicas en la práctica, revisa las capacidades del foro o lee el devlog sobre cómo preparar tu primera game jam de 48 horas.
Dudas reales de quienes están preparando su primera jam, buscando equipo o queriendo publicar un devlog sin que nadie les venda humo.
No. Muchos equipos se arman justo para que alguien haga su primer prototipo. Lo que sí pedimos es que digas en qué eres honesto: si apenas estás aprendiendo Godot, dilo y busca un rol de apoyo. Nadie espera que llegues sabiendo todo, pero sí que cumplas lo que prometes dentro del plazo.
Publicas en el hilo de la jam en curso qué sabes hacer (programación, arte, diseño, sonido) y cuántas horas reales puedes dedicar. Otros miembros responden o te escriben si encajas. No hay intermediarios ni asignaciones automáticas: el equipo se cierra cuando las personas se ponen de acuerdo y confirman el alcance antes de empezar.
Sí, y de hecho conviene. Hay hilos separados por motor para que las respuestas no se mezclen, pero también comparativas cruzadas cuando alguien duda qué usar para un prototipo corto. Si pegas un error, incluye versión del motor, sistema operativo y qué intentaste antes: así la respuesta llega en minutos y no en días.
Cada mes se propone una temática y un límite de tiempo, normalmente un fin de semana o unas dos semanas según el reto. Las reglas se publican al abrir el hilo: alcance máximo, si se permiten assets externos, cómo entregar la build y dónde subirla. El objetivo es terminar algo jugable, no ganar. Se comenta en el mismo hilo y se documenta lo que quedó fuera.
Hablamos del juego, no de la persona. Estructura sencilla: qué funcionó, qué se sintió confuso y qué probarías distinto. Si es un bug, descríbelo con pasos para reproducirlo. Si es una decisión de diseño, argumenta desde la experiencia de juego. Evitamos frases tipo "esto no sirve" sin más, porque no aportan nada al que está aprendiendo.
Precisamente para eso están. Un devlog sin filtros documenta decisiones, dudas y errores, no solo capturas bonitas del resultado final. Puedes subir avances parciales, prototipos rotos o cambios de mecánica a mitad de camino. Si algo no funcionó, contarlo ayuda más a la comunidad que esconderlo.
Si tu duda no está aquí, puedes escribirnos desde contact.html o revisar las condiciones de uso en terms.html.