Gameplay dirigido por datos y comportamientos declarativos¶

Una espada de hierro y una espada envenenada deberían diferenciarse principalmente por definiciones de contenido, no por una nueva subclase en el código. Un NPC puede seleccionar políticas ya implementadas mediante datos. El nombre general de este enfoque es Data-Driven Gameplay.

YAML es un formato cómodo para escribir esas definiciones, pero no es un lenguaje de programación ni impone arquitectura. La semántica de los campos depende de los sistemas que los interpretan.

Una estrategia elegida desde YAML¶

id: npc.goblin_king
health: 250
ai:
  type: king_and_minions
  config:
    minion_type: npc.goblin_guard
    max_minions: 8
    summon_cooldown_ticks: 300

Un registro enlaza king_and_minions con una implementación de código. Esa implementación puede orquestar subordinados, dar órdenes y solicitar curaciones. El YAML configura qué estrategia se usa y con qué valores, sin incluir código de pathfinding ni lógica de combate.

Este diseño combina Strategy, Type Object y una factoría o registro de implementaciones.

Composición de políticas¶

Una evolución posible es sustituir una estrategia rígida por un conjunto de módulos de comportamiento:

id: ai.goblin_king_hostile
pipeline:
  - id: perception
    use: perception.standard
    output: candidates

  - id: targeting
    use: targeting.nearest_hostile
    input: candidates
    output: target

  - id: planning
    use: tactics.king_and_minions
    input: target
    output: proposed_actions

  - id: submit
    use: actions.submit_authoritatively
    input: proposed_actions

Un rey pacífico podría seleccionar targeting.lowest_health_ally y una política de asistencia. Sin embargo, cambiar solo targeting no basta si el planificador únicamente sabe atacar: los contratos entre nodos deben establecer qué tipos de objetivos y acciones aceptan.

La percepción de entidades invisibles corresponde a una capacidad de percepción; elegir a qué enemigo atacar es responsabilidad del targeting. Esta distinción evita construir múltiples variantes casi idénticas de la misma IA.

De pipeline a grafo¶

Una pipeline lineal alcanza para ciertos pasos. Las decisiones con bifurcaciones, interrupciones, prioridad o tareas largas se expresan mejor como Behavior Graph, Behavior Tree, State Machine o modelos de Utility AI. YAML puede serializar la estructura de esos grafos, sin contener el algoritmo de cada nodo.

No hay un único estándar universal llamado Declarative Behavior Composition: es una propuesta de síntesis que combina patrones establecidos como Strategy, Composite, Type Object y comportamiento dirigido por datos.

Cuatro piezas de infraestructura¶

Registry: resuelve IDs estables de operaciones. Definitions: representaciones declarativas, versionadas y validadas. Compiler/Loader: resuelve referencias, tipos, condiciones y compatibilidades antes de ejecutar. Runtime: mantiene estado por instancia y ejecuta algoritmos precargados, sin parsear YAML durante cada tick.

flowchart TD
  Y["YAML fuente"] --> C["Validación y compilación"]
  C --> R["Definiciones compartidas"]
  R --> I["Instancias con estado propio"]
  I --> A["Behavior runtime"]
  A --> Q["Intenciones"]
  Q --> S["Simulación autoritativa"]

Un grafo de IA puede compartir una definición inmutable entre miles de NPC, mientras cada NPC conserva target, blackboard, cooldowns y tareas activas propios.

Reglas para evitar un DSL incontrolable¶

Los IDs y los esquemas deben ser estables y versionados.
El archivo no puede invocar arbitrariamente funciones del sistema operativo ni cargar código no permitido.
El loader debe rechazar referencias inexistentes, incompatibilidad de entradas/salidas y ciclos ilegales.
El servidor autoritativo ejecuta y valida efectos reales; el cliente no debe imponerlos.
La recarga en caliente debe especificar qué sucede con las instancias ya existentes.
El contenido que afecte reglas de un mundo multijugador necesita política de compatibilidad y distribución.

También sirve para armas y objetos¶

id: weapon.iron_sword
attack:
  strategy: melee
  cooldown_ticks: 30
  effects:
    - type: deal_damage
      amount: 20
      damage_type: slashing
    - type: apply_status
      status: bleeding
      chance: 0.15

En objetos utilizables, el mismo esquema puede combinar validar recursos, consumir una unidad y aplicar salud. En armas puede seleccionar disparos, trayectorias y efectos. Cada algoritmo vive en código; el contenido aporta identidad, parámetros y composición.

Qué no resuelve¶

Un archivo declarativo no garantiza rendimiento, determinismo ni seguridad. Tampoco reemplaza las reglas de propiedad del estado. La composición libre puede producir definiciones imposibles; hace falta validación y un catálogo de contratos.

La guía profunda de IA composicional, el diseño de blackboards tipados, los sistemas de interrupción, las prioridades y la vida de los nodos se desarrollarán después; consultar Hoja de ruta de la documentación.

Relacionado: Composición, entidades y ECS, Estado del mundo, definiciones e identidad, Autoridad: quién puede cambiar el mundo, Agregar una mecánica sin acoplar todo el juego y Módulos de gameplay y contratos.

Fuentes: Type Object, Component, Unreal Gameplay Ability System, Godot Resources.