¿Qué tan pequeño debería ser tu primer juego?

Tan pequeño que puedas terminarlo: una acción, una pantalla, una forma de ganar o perder y unos minutos de juego. Así se recorta una idea más grande hasta ese tamaño.

Tan pequeño que puedas terminarlo: una sola cosa que hace el jugador, una pantalla, una forma de ganar o perder, y un juego entero que se juega en unos minutos. Si puedes construirlo en un fin de semana, o en dos semanas de tardes, es el tamaño correcto. Un asistente de programación con IA te lleva antes a una versión jugable, pero no cambia la respuesta, y este artículo explica por qué. Para recortar una idea más grande, escribe el juego en una sola oración, conserva solo lo que esa oración necesita y pasa todo lo demás a una lista llamada «después».

¿Cómo es un juego pequeño?

Usa cuatro límites.

• Una acción. El jugador se mueve, o salta, o hace coincidir piezas, o apunta. Una de ellas.
• Una pantalla, o un nivel que se repite y se vuelve más difícil.
• Una forma de ganar o perder. Un puntaje que superar, un cronómetro o vidas que se acaban.
• Unos minutos desde que se pulsa «empezar» hasta ver el resultado.

Dos referencias públicas muestran que un juego dentro de estos límites es un juego de verdad.

La primera es una game jam. En la categoría Compo de Ludum Dare, una persona hace un juego desde cero en 48 horas; la categoría Jam da 72 horas y admite equipos. Sus reglas describen la entrada ideal como un juego que se juega en el navegador, en unos minutos, a solas. Así decía la página de reglas el 9 de octubre de 2026.

La segunda es un tutorial. El 2D breakout game de MDN tenía once lecciones ese mismo día: un canvas, una pelota que se mueve, paredes, una paleta, fin del juego, un campo de ladrillos, un puntaje y una victoria, vidas extra, y luego animaciones, botones y algo de azar. Esa lista muestra bien qué significa «completo» a este tamaño.

¿Por qué lo pequeño sigue importando cuando una IA escribe el código?

Porque escribir el código nunca fue todo el trabajo. Un asistente acorta la escritura. Tres cosas siguen siendo tuyas.

Igual tienes que jugar cada cambio. Alguien tiene que abrir el juego después de cada cambio, probarlo y decidir si quedó mejor que antes. Ese alguien eres tú.

Las funciones se multiplican. Una función nueva tiene que funcionar con todas las que ya están. Tres funciones forman tres pares que pueden chocar. Seis forman quince. Doce forman sesenta y seis. La revisión crece mucho más rápido que la lista de funciones.

Un pedido toca más de lo que nombra. «Agrega una tienda» suena a una sola tarea. Cambia el puntaje, la pantalla de pausa, los controles y lo que se guarda, y cada una de esas cosas hay que revisarla después, sin importar quién escribió el código.

Un juego pequeño es uno que te cabe en la cabeza. Puedes describir un cambio con exactitud, leer lo que volvió y notar qué rompió.

¿Cuánto cuesta después cada función extra?

Vuelve a costar cada vez que sumas una plataforma o un idioma. Lo vimos con KittenGalaxy, el juego de disparos alojado en HeapPlay.

Cuando agregamos controles táctiles, el trabajo se contó por pantalla, no por juego: el menú, el ingreso del nombre, el vuelo, la tienda, el desafío de matemáticas y las pantallas de fin del juego y de finales necesitaron cada uno sus propios controles. Cuando el juego se llevó a diez idiomas, cada pantalla se revisó en cada uno de ellos, como consta en la página del juego.

Ninguno de los dos trabajos fue un error. Pero el tamaño de ambos lo fijó la cantidad de pantallas que el juego ya tenía. Un juego con una pantalla paga ese precio una vez.

¿Cómo se recorta una idea hasta ese tamaño?

1. Escribe el juego en una sola oración: qué hace el jugador y cómo termina. Por ejemplo: «Mueves una nave a izquierda y derecha y disparas a los invasores hasta que se te acaban las vidas».
2. Anota todo lo demás que imaginaste. Jefes, una tienda, dos jugadores, una historia. Escríbelo todo, para que nada se pierda.
3. Conserva solo lo que la oración necesita. Si la oración sigue siendo cierta sin una función, esa función va a la lista «después». Queda pospuesta, no borrada.
4. Recorta contenido antes de recortar la idea. Un tipo de enemigo, no cinco. Una oleada que se acelera, no veinte niveles.
5. Fija el tiempo antes de empezar. Un fin de semana, o dos semanas de tardes. Cuando te atrases, quita algo del juego y mantén la fecha.

Así queda ese ejemplo después del recorte.

¿Cómo mantienes ese tamaño mientras trabajas con un asistente?

• Pon la oración y la lista «después» en un archivo del proyecto, e indícaselo al asistente al comienzo de cada sesión.
• Pide un punto a la vez, y juega el juego antes de pedir el siguiente.
• Guarda una versión que funcione antes de cada pedido, como un commit en el control de versiones, para poder deshacer un cambio malo.
• Cuando un cambio trae más de lo que pediste, quita lo que sobra. Las funciones que nadie pidió también son alcance.

¿Cómo sabes que está terminado?

Decídelo antes de empezar y escríbelo. Un primer juego está terminado cuando:

• un desconocido puede iniciarlo desde un enlace sin una palabra tuya;
• los controles se muestran en la pantalla;
• se puede perder, y volver a empezar sin recargar la página;
• lo jugaste de principio a fin en cada dispositivo que dices que admite, y dices qué dispositivos no probaste.

Luego ponlo donde la gente pueda jugarlo. Un juego así de pequeño sigue siendo un juego: las reglas de envío de HeapPlay piden un juego real y jugable con un enlace oficial, y no fijan un tamaño mínimo. Puedes enviarlo sin cuenta, y un editor revisa cada envío antes de que aparezca.

¿Qué pasa con la lista «después»?

Se convierte en tu plan, en un orden que ya no tienes que adivinar. Cuando la gente juegue la versión pequeña, lo que diga te indicará qué punto tomar primero. Agrega ese, publícalo como una versión nueva y vuelve a escuchar.

Preguntas frecuentes

¿Cuánto debería tardar un primer juego? No hay una respuesta medida. Elige un límite que puedas cumplir y ajusta el juego a él. Ludum Dare da a sus participantes 48 o 72 horas.

¿Alcanza con un clon de un clásico? Como práctica, sí: ya sabes cómo se ve «terminado». Antes de mostrárselo a otros, cambia una cosa para que sea tuyo.

¿Mi primer juego debería ser el juego de mis sueños? Haz primero su parte jugable más pequeña, y deja el resto en la lista «después».

¿Puedo empezar más grande porque un asistente de IA escribe el código? Llegarás antes a una versión jugable. Jugar, revisar y decidir siguen siendo tuyos, y crecen con cada función.

¿Vale la pena publicar un juego de tres minutos? Sí, si está completo. Los jugadores pueden calificarlo y reseñarlo, y los desarrolladores verificados pueden registrar cada versión nueva y qué cambió.