Hola. Hace poco hice por mi cuenta un juego móvil llamado ‘Sumbi’. Es un roguelike vertical inspirado en el muljil de las haenyeo de Jeju. Es un juego en el que entras al mar con una sola bocanada de aire para recolectar mariscos y decides si quieres arriesgarte por más o volver ahora.
El 2 de julio empecé el diseño, el 9 de julio subí la primera build a Google Play, y seguí corrigiendo las partes que me parecían deficientes al jugarlo; el 19 de julio subí a producción la build v1.1.
Lo que me daba curiosidad desde el principio no era simplemente “qué tan rápido puede escribir código la IA”. Quería probar hasta dónde se puede crear un juego realmente publicable si se asignan roles distintos a varios modelos de IA y se los hace funcionar como un solo equipo de desarrollo.
Qué tipo de juego es
‘Sumbi’ toma su nombre del ‘sumbisori’, la respiración similar a un silbido que exhalan las haenyeo al subir a la superficie después de bucear.
Una partida dura entre 10 y 30 segundos. Con una mano mueves a la haenyeo para bajar más profundo o recolectar mariscos cercanos. Como debes llegar sano y salvo a la superficie para conservar íntegramente lo recolectado, estás evaluando constantemente si conviene arriesgarte un poco más o regresar ahora. Al subir, liquidas lo recolectado, mejoras tu capacidad pulmonar, tus aletas, tu mangsari y tu ojo clínico, y vuelves a bucear.
Incluí un draft roguelike en el que eliges una de tres habilidades en cada partida, una enciclopedia con 60 tipos de mariscos, equipo y árbol de progresión, ascenso de rango de haenyeo y un sumbgol que se extiende hasta los 100 m. Dejé los controles simples, pero hice que los récords y builds que buscas cambien a medida que repites inmersiones.
No usé la IA como un desarrollador todoterreno
Si un solo modelo se encarga de todo, desde el diseño hasta la implementación y su propia revisión, es fácil que trate sus propias premisas como respuestas correctas. Por eso dividí los roles así.
- Fable 5: estructura del juego y especificación de funciones, objetivos de balance económico, diseño de criterios de finalización
- Opus 4.8: implementación en Flutter·Flame, escritura de tests, debugging
- Fable 5: volver a contrastar la especificación inicial con el resultado implementado para revisar omisiones y regresiones
- Codex GPT-5.5: revisar de forma independiente el código y los cambios, y señalar casos límite
El flujo de trabajo fue, en general, diseño → implementación → reverificación por el diseñador original → revisión de código independiente → tests automáticos y juego en dispositivo.
Al probarlo, descubrí que era más importante definir primero criterios de finalización verificables que escribir prompts elegantes. En vez de “haz que la progresión se sienta bien”, fijé números como la cantidad de compras durante los primeros 10 minutos, el tiempo hasta el primer ascenso y si en algún tramo de crecimiento se generaban periodos largos en los que no se podía comprar nada. Luego lo verifiqué con un simulador económico y tests.
Actualmente hay 627 tests automáticos y todos pasan. El análisis estático de Flutter también pasa sin errores en el alcance del código de la app, tests y herramientas.
Casos en los que la IA se equivocó de forma convincente
El primer diseño no se convirtió de inmediato en un juego divertido.
En la versión inicial, solo se podían recolectar entre 5 y 9 objetivos por partida. Para ser un juego de recolección, el mar se veía vacío. Lo probé personalmente y descarté esa estructura. Lo cambié para que el campo se volviera más abundante a medida que creces y para que volvieran a aparecer mariscos en los lugares ya recolectados. Con ciertas builds de progresión, se pueden recolectar alrededor de 40 elementos en una partida.
Con el árbol de progresión pasó algo parecido. Tenía nada menos que 290 nodos, pero la experiencia real era casi lineal. La IA cumplió el requisito de “290 nodos”, pero eso no significaba que hubiera creado diversión al elegir. Al final volví a separar la estructura en tres rutas de especialización y nodos permanentes.
La IA crea mucho código rápidamente, pero no garantiza la diversión ni las prioridades. Seguir jugando directamente y decir sin rodeos “esto no es divertido” o “hay muchas funciones, pero no se ve el siguiente objetivo” siguió siendo tarea humana.
También armé mi propio pipeline de imágenes y sonido
Los principales assets de imagen, como el personaje de la haenyeo, mariscos, equipo e íconos de cartas, los generé con la API de generación de imágenes de GPT. No usé las hojas generadas tal cual: las pasé por un pipeline de corrección con eliminación de chroma key, alineación de frames, unificación de tamaños y cuantización de píxeles, y luego las revisé. El fondo, las burbujas, los rayos de luz y otros elementos los dibujé principalmente con código.
Para el sonido, en vez de reunir assets externos, sinteticé WAV con código Dart. El sumbisori que se escucha al terminar una inmersión lo definí como el sonido clave donde se encuentran el nombre del juego y el final de una partida.
Lo que cambió en mi forma de pensar después de hacerlo
Suele decirse que “la IA funciona bien si le das buenas instrucciones”. Esta vez aprendí con más fuerza algo distinto: “hace falta una estructura para detectar sus errores”.
Separé diseñador, implementador y revisor, e hice que otros modelos examinaran el plan y el código de forma agresiva. Dejé el veredicto final en manos de los números, los tests y el juego real. Este método fue mucho más estable que encargarle todo a un solo modelo manteniendo una conversación larga.
Aunque la IA se vuelva más rápida, el cuello de botella del desarrollo en solitario no desapareció. En cambio, el cuello de botella se movió de la programación al criterio. Lo que más tiempo llevó fue decidir qué conservar y qué descartar, y por qué en ese momento no resultaba divertido.
Google Play https://play.google.com/store/apps/details?id=com.kinderia.sumbi
Como todavía es un juego hecho por una sola persona, tiene muchas cosas por mejorar. Me gustaría escuchar opiniones sobre si no es divertido o si el menú de progresión es demasiado complejo. También pueden dejar con confianza preguntas sobre el método de desarrollo o la división de roles entre modelos.
Aún no hay comentarios.