Si la gramática por defecto de la IA de juego contemporánea sigue siendo «colgar nodos en un Behavior Tree, escribir booleanos en un blackboard y, con una cadena de ifs dentro de `Update()`, pegar la intención de alto nivel del NPC como atmósfera», entonces **htn_planner**, publicado por Jose Antonio Escribano (GitHub: urosidoki) a finales de septiembre de 2026, casi clava en público otro linaje al suelo de la ingeniería: las Hierarchical Task Networks (HTN) no tienen por qué ser un dialecto de script interpretado en runtime; pueden ser un pipeline de compilación **DSL de dominio → AST → IR → C generado**, donde el runtime ejecuta directamente el planificador generado y no parsea el código fuente del dominio durante el gameplay.
Esa frase puede sonar a eslogan de compilador. Lo que pesa de verdad es el límite que el propio autor fija en declaraciones públicas: se trata de una **implementación independiente** inspirada en el diseño y la experiencia de producción del planificador HTN que Guerrilla usó en *Horizon Zero Dawn* y *Horizon Forbidden West*. **No** es el planificador de Guerrilla ni una publicación de su código fuente. El linaje puede citarse; el copyright y la sangre deben permanecer separados.
La imagen que atraviesa este texto es el **backtracking** mismo. No es la búsqueda abstracta de un paper de IA, sino el árbol de decisión que un depurador expandirá en el suelo de producción: cómo retroceder cuando falla una precondición, cómo las ramas de método reasignan bindings, cómo la descomposición diferida se vuelve a expandir contra un world state actualizado—y cómo todo eso aterriza en un ABI C versionado, no en el booleano temporal del siguiente frame.
1. Lógica por defecto: las decisiones de alto nivel equivalen a Behavior Trees, scripts de blackboard, intérpretes en runtime
La lógica por defecto de la industria es limpia—y por eso perezosa.
En cuanto un NPC necesita intención a escala de segundos—«patrullar, luego alertar, luego pedir apoyo tras detectar un objetivo»—, los equipos suelen abrir un menú familiar: colgar un Behavior Tree, meter `enemyVisible` / `lowHealth` en un blackboard, codificar prioridades como UI de árbol con decoradores y selectores y, cuando hace falta parecer «un poco más listo», enchufar GOAP o una máquina de estados casera. Jugadores y desarrolladores aprenden a leer NPCs con el mismo vocabulario—«el árbol está afinado», «el blackboard está limpio», «este frame parece que piensa». Ese pacto convierte «decisión de alto nivel = interpretar un grafo en runtime» en gramática industrial perdonable.
El problema no son los Behavior Trees en sí. Los árboles destacan al ordenar reacciones ejecutables en flujo de control visualizable. Donde se tensan es cuando las decisiones deben buscar combinatoriamente **predicados de world state**, retroceder de forma sistemática ante precondiciones fallidas y separar «un plan local honesto ahora» de «tareas posteriores que solo deberían expandirse después»—exactamente el trabajo que el linaje HTN lleva tiempo reclamando.
El motor Decima de Guerrilla llevó ese linaje al escenario público AAA. El 25 de noviembre de 2024, el Principal AI Programmer Tim Johan Verweij, en *HTN Planning in Decima* (Goldsmiths / AI and Games Conference), enunció el interior con dureza: backtracking al estilo Prolog sobre precondiciones; visualización de ese flujo; cómo se realiza en **C++ generado**; y el depurado in-game de descomposiciones HTN. En otras palabras, el HTN en un suelo AAA nunca fue el romance de «otro intérprete de scripts más», sino la institución productiva de «código generado + descomposición depurable».
htn_planner se sitúa en el lado público del mismo linaje. Lo que rechaza no son los Behavior Trees, sino un default más callado: la creencia de que la intención de alto nivel del NPC puede sostenerse para siempre con parseo en runtime y atmósfera de blackboard, sin escribirse como sistema que compile, haga hot-reload y compruebe versiones de ABI.
2. Romper el guion: de «interpretar el dominio» a «generar un planificador nativo»
En la publicación pública de LinkedIn de Jose (hacia 2026-09-27), el relevo en r/gamedev (u/Thhaki, 2026-09-30) y la cobertura de GameFromScratch (2026-09-30), la tesis de ingeniería es directa: los dominios de comportamiento se escriben en un DSL al estilo Lisp y se compilan **Domain source → AST → IR → generated C**; la ruta de ejecución generada es independiente del intérprete; un ABI C versionado conecta dominios generados al runtime anfitrión, con helpers opcionales de integración C++.
El README del repositorio descompone el mismo pipeline en pasos verificables: lexer y rangos de fuente → AST propiedad del compilador → validación y linking (declaraciones, includes, overrides, referencias) → IR → `HTNCCodeGenerator` emite fuente C y metadatos estáticos → el cliente compila ese C en el juego o en un módulo de dominio. AST e IR son representaciones de build-time; la ejecución runtime generada **ni las retiene ni depende de ellas**. No es «AOT» como eslogan, sino un pipeline que se puede recorrer con `HTNTranslator --check` y el comando de generación.
¿Cómo se ve un dominio? Un DSL declarativo de S-expresiones, no un Lisp de propósito general. Un método mínimo de NPC guardia puede decir: cuando `guard_on_duty` se cumple, encolar tareas primitivas como `!move_to` y `!scan_area` en el plan; el motor asigna significado a esas tareas y decide cuándo empiezan, terminan o fallan. Las ramas de método se prueban en orden de fuente; los cuerpos de condición combinan consultas de hechos y axiomas con `and` / `or` / `alt` / `not`; `!` marca primitivas que entran al plan de inmediato, las tareas compuestas desnudas se descomponen ahora, y `&` emite **descomposición diferida**—ejecutar primero las acciones anteriores y expandir el método posterior solo después de que el world state se haya actualizado.
La descomposición diferida es el corte más afilado y más orientado a producción de la tesis. Admite que un plan completo no tiene por qué mentir sobre el futuro en t0. Puedes hacer `!move_to` primero y dejar `&after_arrival` hasta después de llegar, redescomponiendo contra un objetivo que «entonces» sigue visible—o ya se perdió. El host posee la planificación temporal, la cancelación y la petición posterior de descomposición; `&` no es un temporizador ni abre hilos en silencio. El planificador separa lo que puede prometerse con honestidad ahora de lo que solo es honesto al diferirse—mucho más duro, y más limpio, que fingir dentro de `Update()` que ya se planeó todo el trayecto con booleanos temporales.
3. Los mecanismos aplastan la retórica: backtracking anidado, ABI C, hot reload, 209 tests y ocho variantes de SDK
Sin lista de mecanismos, la narrativa de compilación se desliza hacia el vacío. El material público clava clavos contrastables con el repo.
**Backtracking anidado.** El backtracking jerárquico entre métodos y axiomas cubre llamadas anidadas y bindings alternativos; `alt` retiene alternativas, mientras `or` descarta el resto tras el primer éxito—no es una diferencia de redacción, sino institucional: si el fallo puede retroceder y reasignar. La charla Decima enfatiza el backtracking de precondiciones al estilo Prolog; htn_planner escribe la misma clase de problema como política explícita en la ruta de ejecución generada, con opciones del traductor para capacidad de backtracking y selección de modo en runtime.
**ABI C versionado.** Los dominios generados se enganchan al host vía ABI C; los módulos de dominio cargados dinámicamente llevan comprobaciones de compatibilidad. Las actualizaciones suelen exigir regenerar dominios y reconstruir host y puente de runtime **juntos**—el README advierte una y otra vez que la API pública, el lenguaje de dominio y el ABI del código generado siguen evolucionando. Suena a molestia; es honestidad: en cuanto un planificador entra en el carril de «código generado», el ABI es tu contrato de variantes de shader, no una cadena de script que puedas fingir eterna.
**Depurador visual.** Builds instrumentados pueden capturar la ejecución generada sin cambiar la lógica del planificador: métodos, ramas, condiciones, axiomas, tareas, resultados, rangos de fuente y bindings con ámbito. El modelo de datos es independiente de ImGui; un motor puede renderizar nodos capturados en su propio editor. HTNDemo ofrece Domain Runner, un depurador de eventos generados y una pequeña simulación de NPC—el demo carga datos de world state; las definiciones de dominio ya están compiladas en planificadores nativos generados. Es casi un eco open source de la promesa pública de Verweij sobre depurar descomposiciones in-game.
**Hot reload.** En la integración de referencia de módulos de dominio dinámicos, la **aplicación host** controla la compilación, la carga y la orquestación del reload. Iterar el dominio se vuelve un bucle de producción parecido al hot-reload de shaders: editar predicados y alternativas de método → traducir/generar → el host recarga → ver de inmediato el nuevo árbol de descomposición. Jose afirma haber integrado el SDK en su propio motor y haber probado allí planificación y reload de dominio.
**Números de validación.** En el nodo de publicación pública, el autor reporta que **v2.0.2 pasó 209 tests**, más validación de consumidores externos en ocho variantes del SDK Windows (incluidas comprobaciones de que las DLL de dominio generadas resuelven los exports de runtime requeridos). El repo siguió después: el CHANGELOG muestra que 2.1–2.3 añadieron tutorial de lenguaje de dominio, Linux x64 (Ubuntu 24.04 / GCC 14 / Clang 18), literales numéricos negativos, etc.; al escribir esto, VERSION en main apunta a un 2.4.0 en preparación. Este artículo clava «209 + ocho variantes» en ese nodo anunciado, sin inventar nuevos eslóganes numéricos para commits posteriores que no reiteraron el mismo conteo en el mismo post.
La licencia es MIT. Las notas de contribuidores son claras: el planificador generado, el pipeline del compilador y la publicación pública los lidera y mantiene Jose Antonio Escribano; la **base compartida de 2023** retenida en núcleo, parsing, world state e integración fue coautoría con Sandra Alvarez (Sandruski)—cuyo repositorio `Sandruski/htn-planner` es un trabajo previo relacionado en la vía interpretativa. El linaje puede mencionarse; los repos no deben confundirse.
4. Reflujo: lo que los indies deben robar no es el «halo Horizon», sino «planificar como sistema compilado»
El final más útil de la historia open source no es otra palabra clave AAA, sino el reflujo de ética de producción.
Para indies y equipos pequeños, lo que duele de htn_planner no es que deban tirar mañana los Behavior Trees, sino que traduce una tesis larga tiempo encerrada en lecturas internas de estudio a objetos de ingeniería clonables: **los predicados de world state y las alternativas de método son ciudadanos de primera**; el fallo es backtracking buscable, no un flag temporal sobrescrito al siguiente frame; la descomposición diferida obliga a admitir que el tiempo reescribe precondiciones; el hot reload obliga a que los cambios de dominio sean tan verificables como los de shaders; las comprobaciones de versión de ABI obligan a tratar los «artefactos generados» como contratos, no como exportaciones de un solo uso.
No hace falta adoptar este SDK. Aun así puede extraerse una institución más pequeña de la misma ética: escribir «enemigo visible / munición baja / cobertura alcanzable» como tabla explícita de predicados, no como booleanos dispersos en seis componentes; escribir «acercarse / pedir ayuda / retirarse» como ramas de método reemplazables, no como un megárbol inmóvil; hacer de «decidir tras llegar» una segunda etapa explícita de planificación, no una coroutine dormida que finge que el plan sigue vivo. Planificar como sistema compilado no exige que cada estudio invente un IR; exige dejar de sustituir atmósfera de `Update()` por estructura de decisión auditable.
Cierre: independencia e IA, redefinidas dentro del backtracking generable
Sitúa esta publicación de nuevo en el suelo de producción de 2026 y lo que realmente golpea no es la reputación de los Behavior Trees, sino una inercia de IA más callada—la creencia de que la intención de alto nivel puede vivir para siempre en intérpretes y temporales de blackboard, de que depurar por qué un NPC «hizo eso» solo puede ser suerte de spam de logs, de que indies y AAA están separados por experiencia de caja negra intraducible.
El contraejemplo de Jose es torpe y profundamente de ingeniería: DSL con sabor Lisp, AST/IR, C generado, ABI versionado, backtracking anidado, descomposición diferida, depuración visual, hot reload controlado por el host y—en el nodo de publicación—tests más una matriz de consumidores del SDK; más la declaración repetida de que está informado por la experiencia Guerrilla pero no es código Guerrilla. Torpe, porque obliga a escribir el comportamiento como dominio traducible; caro, porque gasta diseño de sistema real, no solo otro frame de ifs.
Así «indie» e «IA de juego» pueden redefinirse aquí. Indie no tiene por qué equivaler a Behavior Trees escritos a mano para siempre; puede equivaler a seguir preguntando, con recursos más estrechos, qué decisiones mueren en el instante en que solo pueden sostenerse por atmósfera. La IA de juego no tiene por qué equivaler a apilar nodos de feature; puede equivaler a estar dispuesto a preparar, para ese conjunto mínimo de decisiones, un camino que compile, depure y haga hot-reload—aunque ese camino haga parecer que los NPC son un pequeño lenguaje.
La lista ejecutable es corta y duramente honesta:
- Escribe primero tu lista de «predicados de world state»: qué diez hechos, una vez vagos, hacen inexplicable la intención de alto nivel del NPC; tienen veto al optimizar o añadir features.
- Codifica al menos un conjunto de intenciones mutuamente excluyentes como alternativas de método (rama + condición + lista de tareas), no como booleanos de blackboard que se pisan; ante el fallo deberías poder decir qué capa retrocedió.
- Encuentra un lugar que «debe esperar a que el mundo cambie antes de decidir» y constrúyelo como segunda etapa explícita de planificación (descomposición diferida o replan activo equivalente); prohíbe frames dormidos que se hagan pasar por plan.
- Si introduces hot reload de dominio/script, que el **host** posea la orquestación de compile y load, y haz un ensayo deliberado de ABI/versión incompatible—si el hot reload no puede fallar limpio, aún no es un sistema.
- Al leer *HTN Planning in Decima* de Verweij y la guía de lenguaje de dominio de htn_planner, compara contra «generación + descomposición depurable», no contra el halo artístico de Horizon.
Los posts y coberturas de finales de septiembre ya fijaron el estándar de auditoría: no «¿parece listo en un demo?», sino «¿pueden las decisiones de alto nivel compilarse, hacer backtracking y expandirse de nuevo contra un mundo actualizado?». Después solo queda una pregunta más fría en el suelo indie—¿tus NPC están planificando, o interpretando planificación durante un frame temporal?
Fuentes y lectura adicional
Jose Antonio Escribano, nota pública en LinkedIn (hacia 2026-09-27): I’ve released HTN Planner…
GameFromScratch (2026-09-30): htn_planner – AAA Inspired Game AI Framework
Repositorio y README: urosidoki/htn_planner
Guía del lenguaje de dominio (incluye `&` diferido): docs/DOMAIN_LANGUAGE.md
Trabajo previo relacionado (vía interpretativa; no confundir): Sandruski/htn-planner
Más: Exploring HTN Planners through Example; The AI of Horizon Zero Dawn