Recarga en caliente del diseño de juego, como si fuera código

La mayoría de los motores distribuyen binarios opacos. RakuAI distribuye texto que puedes diferenciar, revisar y recargar en caliente, con el sistema nervioso de IA direccionable ahí mismo en el archivo. Esa decisión es lo que permite que un equipo entero de agentes construya junto a ti.

Fin de semana de formato de archivo. La IA es un primitivo de runtime en este motor, no una función atornillada al lado. Ese es el argumento arquitectónico que ya he expuesto antes. Este post trata sobre el formato de archivo que lo hace concreto.

Si construyes un juego en la mayoría de los motores, el artefacto que distribuyes es un binario, un paquete de proyecto, una base de datos de assets, o alguna combinación de los tres. Lo que autoras vive dentro de un editor propietario. Lo que distribuyes es opaco para las herramientas que tu equipo ya usa. Diferenciar dos versiones de una experiencia significa abrir el mismo editor dos veces y confiar en que el registro de cambios sea honesto.

Nosotros tomamos el otro camino. Una experiencia de RakuAI es un archivo .raku. El archivo es JSON. Puedes abrirlo en cualquier editor. Puedes diferenciar dos versiones en cualquier herramienta de revisión de código. Puedes validarlo contra un esquema. Puedes versionarlo en git. Puedes revisarlo en un PR. Puedes recargarlo en caliente. Puedes escribir una experiencia a mano si quieres.

El formato de archivo no es glamoroso. Es estructural.

Cómo se ve un archivo .raku real

Aquí hay una definición de juego real, recortada para el post:

{
  "schema_version": "1.0",
  "game": {
    "title": "My Space Shooter",
    "genre": "space_shooter",
    "template": "space_shooter",
    "mode": "prototype",
    "max_players": 1
  },
  "ai": {
    "dda_enabled": true,
    "target_flow_state": 0.7,
    "profiler_mode": "active",
    "emotional_tracking": true,
    "adaptive_music": true
  },
  "entities": [
    {
      "type": "player_ship",
      "health": 100,
      "shield": 80,
      "speed": 22.0,
      "fire_rate": 0.09
    },
    {
      "type": "enemy_wave",
      "count": 8,
      "health": 15,
      "ai_behavior": "strafe",
      "properties": { "enemy_id": "interceptor" }
    },
    {
      "type": "boss",
      "health": 500,
      "ai_behavior": "boss_pattern"
    }
  ]
}

Eso es la mayor parte de una experiencia. Un encabezado versionado por esquema. Un bloque game con los metadatos de superficie. Un bloque ai con la configuración de la IA de runtime. Un array entities que describe qué hay en el mundo y cómo se comporta cada entidad.

Hay varias cosas que vale la pena señalar.

El bloque ai es el contrato de runtime

Mira otra vez esta parte:

"ai": {
  "dda_enabled": true,
  "target_flow_state": 0.7,
  "profiler_mode": "active",
  "emotional_tracking": true,
  "adaptive_music": true
}

Aquí es donde el archivo dice “el sistema nervioso de IA está activado.” No “pídele a GPT que me escriba un nivel.” Activado. En la capa de runtime, en cada frame, mientras el jugador está jugando.

dda_enabled activa el ajuste dinámico de dificultad. El runtime perfila lo que el jugador está haciendo y remodela los encuentros sobre la marcha. target_flow_state: 0.7 es la banda de dificultad que el runtime persigue. profiler_mode: "active" indica que la IA está leyendo el comportamiento del jugador, no solo muestreándolo. emotional_tracking y adaptive_music son la misma idea aplicada a otros subsistemas.

Un motor de patrón de fábrica no podría tener estos controles a nivel de archivo. No hay una IA de runtime a la que el archivo pueda dirigirse. En nuestro motor, estos controles son la forma en que un autor le dice al sistema nervioso qué tipo de experiencia debe ser.

Puedes revisar este bloque en un PR. Puedes hacer pruebas A/B con dos valores en CI. Un productor que nunca ha visto un editor puede leer esto y tener una conversación con ingeniería sobre qué significa el estado de flujo objetivo. El formato de archivo hace visible la decisión de diseño.

El comportamiento de IA por entidad es una cadena, no una integración

Cada entidad en el archivo puede llevar un campo ai_behavior:

{
  "type": "enemy_wave",
  "count": 8,
  "ai_behavior": "strafe"
}

"strafe" no es una invocación de modelo. Es un comportamiento registrado en el runtime que la capa de sistema nervioso conduce. La misma entidad puede ser "patrol" o "boss_pattern" o cualquier otra cosa que el runtime sepa hacer. El archivo no importa un modelo. Se dirige a una capacidad.

Así es como se desacopla el formato de archivo de un modelo específico. El autor escribe la intención. El runtime decide qué modelo, qué pesos, qué respaldo determinista usar para cumplir esa intención. Cambia el modelo el próximo trimestre y los archivos .raku no cambian.

Esa separación importa más de lo que parece. Cada equipo con el que he hablado que atornilló un LLM específico dentro de un motor ha tenido que rehacer la integración cuando el proveedor del modelo cambió. Nosotros no.

Por qué JSON

Esta es la pregunta que más me hacen cuando muestro el formato de archivo. ¿Por qué JSON y no un DSL personalizado con una sintaxis más agradable para expresiones matemáticas, scripting en línea y bindings reactivos?

Tres razones.

Uno: todas las herramientas ya hablan JSON. Revisión de código. Herramientas de diff. Control de versiones. Linters. Validadores de esquema. Pipelines de CI. Análisis estático. Cada editor en cada plataforma. No tuvimos que construir nada de eso. Lo obtuvimos gratis.

Dos: los humanos leen JSON razonablemente bien. El archivo de arriba no es bonito, pero un diseñador senior puede leerlo sin capacitación. Compara eso con un DSL que toma una semana aprender antes de que alguien pueda revisar un PR.

Tres: los asistentes de IA leen JSON extremadamente bien. Esto importa más en 2026 de lo que importaba hace tres años. Cuando un diseñador le pide a un asistente de IA que “ajuste al jefe para que se sienta más aterrador,” el asistente puede leer el archivo, proponer un diff, y el humano puede aceptar o rechazar el diff. Un DSL personalizado requeriría enseñarle a cada asistente una gramática nueva.

El costo es real. JSON es verboso. No tiene matemática en línea, comentarios ni abreviaturas. Renunciamos a expresividad a cambio de omnipresencia de herramientas. Hasta ahora, el intercambio se ha pagado a sí mismo muchas veces.

Qué habilita esto

Varias cosas cambian una vez que tu experiencia es texto.

Revisión de PR para diseño de juego. Un diseñador cambia target_flow_state de 0.7 a 0.5. El cambio aparece como un diff de una línea en un pull request. Ingeniería y diseño revisan el cambio juntos. La conversación en el PR es un registro de por qué la experiencia se juega como se juega. Seis meses después, cuando alguien pregunta por qué la curva de dificultad se siente como se siente, la respuesta está en el registro de commits.

CI para experiencias. Un archivo .raku falla la validación de esquema. El build falla antes de que el cambio se distribuya. El mismo CI que ejecuta tus pruebas unitarias ejecuta tus definiciones de experiencia.

Recarga en caliente. El archivo cambia en disco. El runtime lo nota. El mundo se actualiza sin reiniciar. El ciclo de desarrollo se reduce a segundos.

Reversión. Un cambio rompió la pelea contra el jefe. Revierte el commit. La experiencia se revierte. Sin editor, sin reconstrucción de assets, sin ida y vuelta de una semana.

Autoría por IA. Un miembro del equipo describe lo que quiere en lenguaje natural. Un asistente de IA escribe el diff .raku. Un revisor humano lo aprueba. El diff es auditable, versionable y cae bajo la misma disciplina de revisión que cualquier otro cambio de código.

Estas no son capacidades exóticas. Son lo que todo equipo de software moderno da por sentado para el resto de su base de código. Nosotros las extendimos al diseño de juego.

Lo que es difícil

Los costos honestos.

JSON no tiene comentarios. Compensamos con archivos .md complementarios para la intención de diseño y con nombres de campo descriptivos, pero es una fricción real.

El esquema tiene que evolucionar con cuidado. Pasamos de schema_version: 1.0 a 2.0 una vez, cuando la generación de mundos superó la forma original. Cada archivo existente en producción necesitó una ruta de migración. Ese trabajo es parte del oficio, y no es gratis.

Hay una tentación de seguir añadiendo campos. Nos resistimos con más fuerza de la que parece. Cada campo añadido es un contrato que el runtime debe honrar a perpetuidad. La inclinación es mantener el archivo pequeño y poner la complejidad en el runtime, no en el archivo.

Y finalmente: las definiciones de experiencia basadas en texto solo importan si el runtime realmente hace algo interesante con ellas. El formato de archivo es corriente abajo de la decisión arquitectónica subyacente. Si el motor trata a la IA como una fábrica de contenido, el archivo es solo un manifiesto. Si el motor trata a la IA como un primitivo de runtime, el archivo es la partitura.

Si quieres leer el formato de principio a fin, el esquema vive en la documentación pública y los archivos de ejemplo se distribuyen en el repositorio. Abre uno. Léelo como código, porque eso es lo que es.

Dos días de trabajo de formato de archivo en el banco. De vuelta al motor el próximo fin de semana.