Lo que vale un creador de juegos con IA en una jam de 48 horas
Un hackathon es un problema de alcance con un reloj pegado. La generación te compra horas de verdad en algunos sitios y las gasta en silencio en otros, y saber cuál es cuál decide si entregas.
Publicado el 2026-08-18 · Game design
Una jam es un problema de alcance disfrazado
Casi todas las entradas que no llegan a entregarse fracasan por la misma razón, y nunca es que el equipo no fuera lo bastante rápido. Es que se comprometieron con algo demasiado grande en las primeras tres horas y pasaron las cuarenta y cinco restantes descubriéndolo.
Eso significa que la pregunta útil sobre cualquier herramienta en una jam no es cuánto más rápido te hace. Es si cambia la cantidad de trabajo que tienes delante, y si cambia tu capacidad de estimar esa cantidad. La velocidad con el plan equivocado no salva una entrada.
La generación cambia de verdad lo primero. Quita un bloque real de horas de ciertas partes del fin de semana, y son horas que los equipos de jam han quemado históricamente de la forma menos gratificante posible.
Y perjudica activamente lo segundo. Hace que los planes ambiciosos parezcan alcanzables, y un plan que parece alcanzable en la hora tres es la forma clásica de acabar sin nada en la hora cuarenta y siete. Los dos efectos son reales y van en direcciones opuestas, por eso hay que pensarlo y no simplemente adoptarlo.
Lo que te compra de verdad
La fontanería es lo grande. Un juego de jam sigue necesitando un menú de pausa, un reinicio, un marcador, una transición de escena, guardar la puntuación máxima, una forma de salir y una pantalla de título. Nada de esto es interesante, todo es obligatorio, y en una jam normal se come una tarde entera. Es exactamente la categoría de trabajo que maneja bien un modelo que escribe código en un proyecto de verdad, porque es patrón y no criterio.
El arte provisional es lo segundo. Un prototipo todo de cajas grises es de verdad más difícil de juzgar que uno con arte tosco, porque gran parte de si algo se lee es visual. Tener un conjunto de sprites u objetos toscos en las primeras horas significa que el resto del fin de semana se juzga algo más parecido a un juego.
Bocetar el espacio es lo tercero, si trabajas en tres dimensiones. Una geometría tosca que existe para recorrer la distancia entre dos puntos y notar si la sala aburre vale más tenerla el primer día que el segundo.
El sonido es lo cuarto y lo más infravalorado. Un prototipo en silencio se juzga injustamente, por ti y por todos los demás, porque buena parte de si una acción se siente bien es la respuesta que produce. Los impactos y pitidos cortos generados tienen justo el nivel de calidad adecuado para un fin de semana, y meterlos pronto cambia lo bien que puedes evaluar tu propio juego.
Lo que te cuesta en silencio
El primer coste es la ilusión del alcance. Ver aparecer una mecánica que funciona en diez minutos recalibra tu sentido de lo que cabe en un fin de semana, y lo recalibra mal, porque la mecánica de diez minutos es la mitad fácil. La integración, el ajuste y el nivel construido a su alrededor son las otras cuarenta horas y no se volvieron más rápidas.
El segundo es depurar algo que no escribiste. Cuando aparece un error en la hora treinta en un código que nadie del equipo ha leído, estás en mala posición. Normalmente se recupera describiendo el síntoma con precisión y pidiendo un arreglo acotado. Es mucho peor si intentas llegar a la causa leyendo con el reloj encima. Decide de antemano que informarás de síntomas y no diagnosticarás, porque en la hora treinta no tendrás la calma para decidirlo.
El tercero es la trampa de regenerar. Si un cambio es fácil de pedir, tienta pedir uno grande tarde, y un cambio grande en la hora cuarenta puede llevarse por delante cosas que funcionaban. Pasada la mitad, cada petición debería ser acotada e ir seguida justo después de jugar el juego.
El cuarto es la parálisis de las variantes. Los intentos baratos hacen fácil generar once versiones del enemigo y no elegir ninguna. En una jam, la segunda mejor opción elegida en la hora seis gana a la mejor elegida en la hora veinte.
Una forma para el fin de semana
Las horas cero a dos son para decidir, y nada de lo que pase en ellas debería ser construir. Elige una mecánica, un verbo, una razón por la que quien juega seguiría, y apunta la condición de derrota. Escribe la propuesta en una sola frase. Si necesita dos frases, es demasiado grande para el tiempo que tienes.
Las horas dos a ocho son para el corte vertical. Una cosa jugable con un inicio, una acción, una consecuencia y un final. Debería ser fea. Tiene que poder jugarse, porque todo a partir de aquí se juzga contra ella y un plan no se puede juzgar.
Las horas ocho a veinticuatro son la pasada de contenido. Más salas, más enemigos, el nivel de verdad, la entrada del arte provisional. Aquí es donde más vale la generación, porque es la fase con más volumen de trabajo de poco criterio.
Las horas veinticuatro a cuarenta son para ajustar y recortar. Juégalo una y otra vez, ajusta los números a mano y borra la función que no se gana el sueldo. Todo el mundo se arrepiente de no haber recortado antes y nadie se ha arrepentido nunca de recortar.
Las últimas ocho horas son para la build, la entrega y dormir. Que es la parte que más hay que decir.
Saca una build de verdad a mitad de camino
Hagas lo que hagas, produce una versión entregable a la mitad, por vergonzosa que sea. Empaquétala como pide la entrega, ponla donde tenga que ir y confirma que un equipo que no es el tuyo puede ejecutarla.
La razón es que empaquetar falla, y falla de formas que no tienen nada que ver con tu juego. Falta un archivo. Una ruta solo existe en el equipo donde se construyó. La exportación tarda veinte minutos y le habías dado cinco. Un asset que funcionaba en el editor no está en la build. Cada una de estas cosas es trivial con dieciocho horas por delante y fatal con cuarenta minutos.
Esto vale todavía más cuando no escribiste el código, porque tienes menos intuición sobre qué partes del proyecto son frágiles. La build es la única prueba honesta y cuesta media hora hacerla.
Los equipos que lo hacen entregan. Los que lo dejan para el final a veces no, y el juego normalmente estaba terminado. Es la forma más evitable de perder un fin de semana de trabajo.
Disciplina con lo provisional cuando corre el reloj
El arte generado es un buen sustituto provisional y un asset final flojo, y una jam es el único contexto donde esa distinción casi deja de importar, porque una entrada de jam es un prototipo por definición y nadie espera otra cosa.
Casi. El fallo que sigue mordiendo es la coherencia. Dos llamadas no coinciden, y un juego hecho de cuarenta imágenes decentes por separado que no se ponen de acuerdo se ve peor que uno dibujado en un solo estilo plano. En una jam no te puedes permitir un proceso de dirección de arte, así que usa un sustituto barato. Elige una paleta pequeña en la primera hora. Genera todo contra la misma descripción corta del estilo, y acepta un listón de calidad más bajo a cambio de que el conjunto esté de acuerdo consigo mismo.
Luego haz una pasada, cerca del final, a las tres cosas que más mira quien juega. El personaje, el enemigo principal y lo que haya en pantalla cuando empieza el juego. Mejorar esas tres mueve la impresión del conjunto más que mejorar treinta objetos de fondo.
Todo lo demás puede quedarse tosco. Nadie ha bajado nunca la nota a una entrada de jam por una caja provisional.
Implementar rápido cambia sobre qué discute el equipo
En un equipo, el cambio interesante es por qué se pelea la gente. Cuando implementar era lento, la discusión era qué se podía hacer en el tiempo. Cuando implementar es rápido, la discusión es qué se debería hacer, que es una discusión mejor y más difícil de cerrar.
Nombra a alguien para decidir. No para tener el mejor gusto, solo para tener la última palabra. En un proyecto de cuarenta y ocho horas, el coste de un desacuerdo sin resolver se mide en horas. El coste de una decisión un poco equivocada normalmente no.
Repartíos por áreas y no por capas. Una persona en la mecánica central y su sensación, otra en el nivel y su disposición, otra en arte y sonido. Repartirse por capas significa que todo el mundo toca las mismas cosas y os pasaréis el fin de semana chocando.
Y que haya una persona cuyo trabajo incluya jugar la build actual cada hora y decir qué falla. En un equipo de tres esa persona también hace otra cosa, pero el papel debería existir de forma explícita, porque si no nadie juega el juego hasta el final.
Di lo que usaste
Muchas jams ya lo preguntan, y donde no lo preguntan, decirlo igualmente no cuesta nada y resuelve una duda que la gente tendría. Una línea en la descripción sobre qué se generó y qué se hizo a mano es suficiente.
Comprueba las reglas antes de empezar y no después de entregar. Algunos eventos restringen los assets generados, otros el código generado, otros ninguna de las dos cosas, y a otros solo les importa que lo declares. Estas reglas varían y cambian de un evento a otro, así que lee las actuales en lugar de suponerlas.
Ser directo con esto también suele producir mejores conversaciones después. A la gente le interesa mucho más lo que decidiste que lo que produjo tus rocas.
Para qué es de verdad el fin de semana
El resultado de una jam no es el juego. Es la respuesta a una pregunta, y si elegiste bien la pregunta, la respuesta vale mucho más que la entrada.
Decide en la primera hora qué intentas aprender. Si esta mecánica es divertida. Si te gusta trabajar así. Si una idea concreta sobrevive al contacto con alguien que juega de verdad. Así, cuando acabe el fin de semana, tienes algo, sea buena o no la entrada.
Las herramientas más rápidas lo mejoran en lugar de empeorarlo, porque sube el número de preguntas que puedes responder en un fin de semana. Esa es la ganancia real aquí, y es mayor que una entrada un poco más pulida.
Después, lo útil es coger la única parte que funcionó y reconstruir el resto a su alrededor a propósito. El código de una jam es código de jam, lo escribiera quien lo escribiera. La idea es lo que te quedas, y la idea es la parte que no produjo ninguna herramienta.
Descarga Flockbay
Decide en la primera hora qué debería enseñarte el fin de semana, y saca una build de verdad a mitad de camino.