¿Necesito experiencia previa para entrar a una jam de 48 horas?
No. Mucha gente publica su primer prototipo aquí. Lo que sí ayuda es llegar con un alcance pequeño y ganas de probar cosas rápido, aunque el resultado sea feo.
India Game Jam es un foro en español donde desarrolladores independientes, estudiantes de diseño y programación comparten avances reales: builds a medias, dudas de Godot o Unity a las tres de la mañana, devlogs sin editar y búsquedas de equipo para jams de 48 horas. Sin vitrinas de marketing, solo feedback honesto entre quienes están construyendo lo mismo que tú.
Si buscas cómo funciona el foro por dentro, revisa los servicios de la comunidad, o pásate por las capacidades del equipo antes de escribir tu primer hilo.
Recogemos las dudas más repetidas entre quienes llegan por primera vez y entre quienes ya llevan varias jams encima. Respuestas cortas, sin letra pequeña.
No. Mucha gente publica su primer prototipo aquí. Lo que sí ayuda es llegar con un alcance pequeño y ganas de probar cosas rápido, aunque el resultado sea feo.
Depende de lo que quieras hacer y de con quién trabajes. Godot arranca más ligero para 2D; Unity tiene más material listo cuando algo se rompe de madrugada. En el foro hay hilos comparando ambos con proyectos reales.
Publica qué rol cubres, qué motor usas y cuántas horas reales puedes dedicar. Los hilos con esa información reciben respuesta mucho antes que los que solo dicen "busco gente".
Uno que documenta decisiones, no solo capturas bonitas. Cuenta qué probaste, qué descartaste y por qué. Eso es lo que otros pueden reutilizar en su propio proyecto.
Sí, y de hecho es cuando más sirve. Aclara en el hilo qué parte quieres revisar y qué prefieres dejar fuera de la discusión por ahora.
No. El espacio está pensado para prototipos, aprendizaje y colaboración entre creadores. Cualquier contenido de azar, apuestas o material para adultos queda fuera.
Si tu duda no está aquí, puedes escribirnos desde contacto o revisar las condiciones de uso antes de publicar.
En India Game Jam no hay un comité que valide lo que subes. Pero sí hay acuerdos que la comunidad sostiene desde el primer día, y conviene tenerlos claros antes de abrir un hilo o pedir equipo.
Un prototipo es una idea jugable, aunque tenga placeholders, sprites prestados y un solo nivel. No hace falta que esté pulido ni que tenga tienda. Si se puede abrir, mover al personaje y entender la mecánica, sirve para pedir feedback.
Publicar un devlog significa mostrar el proceso real: capturas feas, decisiones descartadas, bugs que siguen ahí. Lo que no entra son notas personales sin relación con el proyecto ni capturas de pantalla de conversaciones ajenas.
Cuando buscas equipo para una jam de 48 horas, estás buscando compañeros de fin de semana, no colaboradores remunerados. Se aclara el rol, el motor y la disponibilidad horaria. Nadie está obligado a aceptar a quien llega sin presentarse.
Un comentario útil describe qué se probó, qué se sintió confuso y qué se podría cambiar. No es una nota final ni una sentencia sobre el autor. Si algo no te gusta, dilo, pero explica en qué contexto lo jugaste.
Los retos tienen temática y fecha de entrega, pero no hay ranking oficial ni premio. El objetivo es terminar algo pequeño y comentarlo con el resto. Publicar tarde no invalida el trabajo: se avisa y se sigue el hilo.
Aquí se resuelven dudas sobre Godot, Unity y otras herramientas entre quienes las usan a diario. Nadie está obligado a responder, y una pregunta bien planteada, con versión del motor y captura del error, recibe ayuda mucho antes.
Si algo de esto no encaja con lo que buscas, probablemente este no sea el espacio. Si encaja, ya sabes cómo empezar: preséntate en el hilo de bienvenida y cuenta en qué estás trabajando.
No es una vitrina de lanzamientos. Es un taller abierto donde se muestran prototipos a medio hacer, se piden manos para una jam y se documenta el proceso aunque el resultado no sea brillante.
Publica qué rol cubres (programación, arte, sonido, diseño) y qué te falta. Los hilos de reclutamiento se ordenan por fecha de inicio de la jam para que nadie llegue tarde al cierre de inscripciones.
Errores de exportación, físicas que se comportan raro, escenas que no cargan. Se responde con capturas del editor y fragmentos de código, no con enlaces genéricos a documentación.
Cada mes se propone una restricción distinta: una paleta limitada, un solo botón, un género mezclado. El objetivo es terminar algo jugable, no ganar. Al final del plazo se abre un hilo para comparar enfoques.
Aquí se cuenta lo que salió mal: la mecánica que hubo que tirar, el arte que no llegó a tiempo, la build que se rompió la última noche. Documentar el proceso vale más que presentar un resultado pulido.
Se comenta el prototipo, no a quien lo hizo. Se distingue entre bug, decisión de diseño y gusto personal. Si algo no funciona, se explica por qué y se sugiere una alternativa concreta.
Comparte el enlace de tu página, pide pruebas en otras máquinas y recoge impresiones antes de seguir iterando. También sirve para quien lleva años publicando y quiere una mirada externa.
Si buscas cómo encajan estas piezas dentro del foro, revisa las capacidades de la comunidad o mira los servicios que ofrece el espacio.