DEV Community

Christian Gonzales Komiya
Christian Gonzales Komiya

Posted on Edited on

[Spanish] Entrenando un kantoku artificial — Capítulo 3: Nana-Ban, el juego donde vive el kantoku

Esta serie tiene tres capítulos:

  1. Por qué no usé una red neuronal: qué es el gateball, qué es un kantoku y cómo pensé el kantoku artificial.
  2. Saihai, el agente: cómo se entrenó, qué aprendió, qué desaprendió y cómo terminó siendo un proyecto propio.
  3. Nana-Ban, el juego: el videojuego donde vive el kantoku, la demo y cómo lo construí con Claude Code.

Nana-Ban: touch, spark y golpe continuo

Todo este proyecto empezó por aquí: por las ganas de tener un videojuego de gateball. El kantoku artificial nació después, cuando me di cuenta de que la CPU acertaba pero no pensaba. En este último capítulo cuento cómo es el juego, cómo está hecho y dónde se puede jugar.

¿Qué es Nana-Ban?

Nana-Ban (七番, «el número siete») es un juego de gateball en 2D, con estética de 16 bits, en español, que se juega en el navegador. Está inspirado en los videojuegos de gateball de los años 80, pero todo lo que contiene es propio: el código, los gráficos, los sonidos y los textos.

El logo es una bola roja con el número 7. En el gateball, la bola 7 es roja, porque las rojas son las impares.

Hoy el juego tiene:

  • Partidos completos de 10 bolas, cinco contra cinco, con las reglas del gateball: las tres puertas, el poste, el touch, el spark, el golpe continuo, las faltas y el reloj de 30 minutos.
  • Cinco niveles de CPU: cuatro con una CPU sencilla (del «Torneo del barrio» al «Mundial») y el nivel Kantoku IA, donde juega Saihai.
  • Sonido sintetizado en el navegador, sin archivos de audio.
  • Una demo que empieza directo en el partido, también en el celular.

Pantalla de título de Nana-Ban

Por qué Phaser

El juego está hecho con Phaser 3, un motor de juegos 2D para el navegador, con TypeScript y Vite. La razón principal fue práctica: en Phaser todo es código en texto. No hay un editor visual donde arrastrar objetos, como en Unity o Godot. Eso es justo lo que necesita Claude Code, que trabaja leyendo y escribiendo archivos.

TypeScript atrapa errores antes de que lleguen al juego, y yo lo leo con comodidad por mi experiencia en desarrollo web. Vite hace que cada cambio se vea al instante en el navegador. Y al final, todo el juego se empaqueta en un solo archivo HTML, que se publica en cualquier lado.

La física es propia

Lo que no usé de Phaser fue su motor de física. Escribí una física propia y sencilla, porque el gateball necesita algo muy específico: el pasto.

La primera versión se sentía como billar: la bola rodaba perfecta, como sobre una mesa. Esa fue mi primera crítica como jugador, y de ahí salió un pasto con tres efectos: un freno fijo, un freno que crece con la velocidad y un pequeño desvío aleatorio. Un tiro perfectamente recto se desvía unos 5 cm a 4 metros y unos 23 cm a 14 metros. Así se siente el pasto de verdad: de cerca casi no importa; de lejos, sí.

Dos barras para cada golpe

Cada golpe se decide en tres pasos: apuntas, fijas la fuerza con una barra que se mueve y fijas la precisión con otra. Cada barra tiene una marca: si la detienes ahí, el tiro sale como lo pensaste. Cuanto más lejos el tiro, más rápido se mueve la barra de precisión. Es simple de entender y difícil de dominar, como el gateball.

El juego y el agente

La decisión técnica más importante del proyecto fue separar las reglas del dibujo. Al principio, las reglas del gateball vivían dentro de la escena de Phaser, mezcladas con los gráficos. Las saqué a un motor aparte, sin Phaser, que solo sabe de bolas, puertas, turnos y puntos.

Esa separación lo hizo posible todo:

  • Entrenar al kantoku sin pantalla. Un partido de CPU contra CPU tarda menos de un segundo en simularse. Así se jugaron los miles de partidos de cada entrenamiento.
  • Que Saihai piense con las reglas reales. Cuando simula un tiro, usa el mismo motor que el juego, no una aproximación.
  • Separar a Saihai en su propio proyecto. Hoy el motor y el agente viven juntos en el paquete saihai-gateball, y el juego lo usa como cualquier otra librería.

Así quedó el reparto: Saihai decide y el motor arbitra; el juego dibuja, anima y suena. La escena principal del juego pasó de más de mil líneas a menos de seiscientas.

La demo

Para compartir el juego con amigos, hice una demo: sin menús, empieza directo en el partido, tú con las rojas contra Kantoku IA con las blancas. La tecla R reinicia el partido, y los controles están dibujados en pantalla.

Después la adapté al celular. Se juega en horizontal (si lo pones vertical, te pide girarlo), tocando la cancha para ubicar la bola o mover la mira, con zoom de dos dedos y botones A y B en los costados, como en una consola portátil.

La demo en el celular, en horizontal

Un detalle que aprendí: en el iPhone, el navegador no permite pantalla completa, así que el botón explica cómo agregar el juego a la pantalla de inicio. La versión táctil la probé en mi Android. Si la juegas en un iPhone, me encantaría saber cómo te va.

Dónde se puede jugar

La demo está publicada en tres lugares:

La publicación es automática: cada vez que subo un cambio al repositorio, GitHub Actions construye el juego y la demo y los publica.

Cómo lo construí con Claude Code

Todo el código de Nana-Ban y de Saihai lo escribí con Claude Code. Pero «escribir con IA» no significa pedirle un juego y esperar. La forma de trabajo fue la parte que más aprendí.

Iteraciones de una sola cosa. Cada iteración tenía un solo objetivo y terminaba en algo jugable. El reparto era claro: yo juzgaba la sensación de juego; Claude Code verificaba que funcionara (que compilara, sin errores, con la mecánica nueva probada). Las fases 1 y 2 del juego, desde el primer tiro hasta las 10 bolas con touch y spark, salieron en unas pocas horas del primer día.

Mi criterio, traducido a código. Mis comentarios eran de jugador, no de programador: «se siente como billar», «me resultó muy fácil ganar», «juega bien, pero una vez se ofreció». Claude Code los convertía en cambios concretos: un pasto más rugoso, un rival más certero, un script que reproducía el turno exacto donde la CPU se ofreció.

Memoria entre sesiones. Claude Code no recuerda las conversaciones anteriores, así que el proyecto tiene sus propios documentos: un CLAUDE.md con las reglas del proyecto, un BACKLOG.md con lo que viene y un HISTORIAL.md con lo que se hizo. Cada sesión empieza leyendo el BACKLOG y confirmando el objetivo antes de escribir código.

Las pruebas como red de seguridad. Hay decenas de escenarios de reglas que se ejecutan con el motor y también con la escena real del juego en el navegador, y deben dar exactamente lo mismo. Hay pruebas que juegan un partido completo con el teclado. Y hay una prueba legal que revisa que ningún texto nombre al juego que me inspiró ni copie nada de él.

Trabajo largo, con punto de parada. La separación de Saihai fue una tarea de varias horas. La planteé como una lista de pasos numerados, con un diario de decisiones y un punto donde detenerse: el último paso, el que publica, era mío. Claude Code hizo los pasos uno a uno, sin supervisión, se detuvo donde debía y me dejó un documento con todo lo que tenía que revisar. Hasta anotó un error propio, un comando que ejecutó por descuido y que corrigió en el acto.

Medir antes de afirmar. Esta frase terminó siendo la regla del proyecto. Cada versión del kantoku se midió y se anotó con honestidad, incluso cuando el resultado era «corrige el caso, no mejora la fuerza».

Lo que viene, sin prisa

Tengo muchas ideas para Nana-Ban, varias inspiradas en esos juegos de los 80:

  • Una vista de acción, con una cámara en perspectiva que sigue a la bola.
  • Doce jugadores con atributos propios: unos certeros de cerca, otros de lejos, como en un equipo real. Con eso, Saihai tendrá que aprender a elegir quién tira cada golpe.
  • Modos de juego y un tutorial, para que cualquiera aprenda gateball jugando.
  • Arte final y música chiptune.

Pero no tengo prisa. Para mí, por ahora, lo importante era el kantoku: un rival con criterio. El juego completo irá creciendo de a poco, cuando tenga tiempo y ganas, y cada versión nueva de Saihai llegará también a la demo.

Gracias por leer

Esta serie empezó con una pregunta de jugador: ¿puede una máquina dirigir un partido de gateball como un kantoku? Después de 11 días, la respuesta es: todavía no como yo, pero ya me ganó un partido, y cada error suyo me enseña algo sobre mi propia forma de dirigir.

Si juegas la demo, me encantaría saber qué te pareció. Y si eres desarrollador y quieres hacer tu propio juego de gateball, Saihai es libre y está esperando un nuevo partido.

Enlaces

Top comments (0)