A quién le sirve. Aficionados a la estrategia que quieren hacerse un juego propio y no temen pasar semanas probando; es un caso personal y largo.
Qué hicieron
Quien lo cuenta dice que hizo Hexwardia en dos semanas, un juego 4X (de explorar, expandirse, explotar y conquistar) que funciona entero en el navegador. Usó Grok como constructor principal y para el repositorio, y Gemini como auditor que revisaba la lógica en una segunda pasada. Hizo que los modelos escribieran sistemas como el combate, la niebla de guerra, la generación de mapas y una IA por reglas, y limitó los arreglos a parches quirúrgicos que solo cambiaban líneas concretas en vez de reescribir archivos enteros.
Cómo salió
El juego estaba en línea en versión alfa 0.04.x, cargaba en menos de un segundo y las partidas apuntaban a 15 a 30 minutos. En los comentarios, un jugador ajeno contó que el ciclo de juego estaba completo, que la IA planteaba un reto real y que no encontró fallos, aunque criticó la profundidad de las ciudades, la claridad de los roles de las unidades y lo creíble del mundo.
Conviene saber
Su consejo práctico principal fue exigir parches que solo editan, sin reescribir, lo que según él redujo el gasto de tokens (la unidad con la que cobran estos modelos) en más de un 60 %. También dice que paga 30 $ por SuperGrok y 20 $ por Gemini.
Qué necesitas
- Dos asistentes de IA, uno para construir y otro para revisar, como Grok y Gemini en el caso
- Un sitio donde guardar el proyecto, como un repositorio, que es la carpeta donde se guarda el código y su historial de cambios
- Un navegador donde probar el juego
- Un plan por sistemas: mapa, combate, niebla de guerra y rivales controlados por reglas
- Ganas de leer algo de código y mensajes de error
Cómo hacerlo tú, paso a paso
- Define el juego: género, nombre y las piezas que tendrá, como generación de mapas, combate, niebla de guerra y rivales controlados por reglas.
- Elige un asistente como constructor principal y otro como revisor.
- Empieza por un solo sistema, por ejemplo la generación de mapas, escrito en piezas pequeñas que se puedan probar.
- Ejecuta cada pieza en el navegador y comprueba que funciona antes de pasar a la siguiente.
- Pasa el resultado al segundo asistente y pídele que revise la lógica y busque fallos.
- Para los arreglos, exige parches que solo cambien las líneas necesarias, sin reescribir archivos enteros.
- Cuando se pueda jugar una ronda básica, pide una lista de lo que construir después y haz que alguien ajeno lo pruebe.
Ayúdame a crear un juego de [género] para navegador llamado [nombre del juego] en [HTML y JavaScript, o el marco que prefieras]. Empieza por [primer sistema, por ejemplo la generación de mapas, el combate o la niebla de guerra], escríbelo en piezas pequeñas que se puedan probar y ejecútalo para que lo pruebe. Habrás terminado cuando pueda abrirlo en un navegador y jugar una ronda básica, y entonces enumera qué construir después.
Consejos
- Pide siempre parches que solo editen. Al autor le redujo el gasto de tokens, que es la unidad con la que cobran estos modelos.
- Haz que alguien ajeno pruebe el juego. En el caso, un jugador externo señaló fallos de fondo, como la poca profundidad de las ciudades.
- Divide el juego en sistemas pequeños y prueba cada uno antes de unirlos.
Preguntas frecuentes
¿Por qué usar dos asistentes?
Uno construye y el otro revisa, como dos personas distintas. Así se detectan fallos de lógica que el primero no ve.
¿Hace falta ser programador?
No para empezar, pero con un juego de este tamaño acabarás leyendo código y errores. Prueba antes con un juego más pequeño, de un solo sistema.
Fuentes
En el directorio desde el 10 de octubre de 2026.