Análisis Exhaustivo sobre Árboles de Comportamiento (Behavior Trees) y Máquinas de Estados Finitos (FSM)

Los mecanismos de toma de decisiones que forman la base de los agentes autónomos, los personajes complejos de videojuegos y los sistemas de robótica industrial constituyen uno de los campos más críticos y debatidos de la ingeniería de software moderna y la investigación en inteligencia artificial. La forma en que un agente reacciona ante estímulos ambientales en constante cambio, cuáles de los innumerables objetivos disponibles prioriza y en qué orden ejecuta tareas específicas depende enteramente de la solidez y flexibilidad de su arquitectura de toma de decisiones subyacente. Al examinar su proceso de desarrollo histórico, se puede observar que este campo estuvo dominado durante muchos años por las Máquinas de Estados Finitos (Finite State Machines - FSM). Sin embargo, la creciente complejidad de los mundos digitales y las tareas robóticas físicas ha llevado a los desarrolladores e investigadores a buscar estructuras más escalables, reactivas y modulares, una búsqueda que propició el nacimiento de estructuras jerárquicas revolucionarias como los Árboles de Comportamiento (Behavior Trees - BT).

Este informe examina en profundidad estas dos arquitecturas fundamentales, consideradas hoy en día como el estándar de la industria para la toma de decisiones y el modelado de comportamiento en sistemas autónomos, en el contexto de todos sus detalles técnicos, fundamentos matemáticos, evolución histórica, casos de uso industrial y las ventajas y desventajas estructurales entre ambas. Además, los enfoques híbridos más recientes en los motores de juegos modernos (por ejemplo, Unreal Engine) y las soluciones de nueva generación como los Árboles de Estados (State Trees) también se evalúan como una parte integral de este análisis.

Máquinas de Estados Finitos (FSM): Infraestructura Teórica y Fundamentos Matemáticos

Una Máquina de Estados Finitos (FSM) es un modelo de máquina abstracta en el que un sistema puede encontrarse en un solo estado predefinido a la vez y realiza una transición entre estados en respuesta a entradas ambientales específicas o eventos internos (inputs/events). Como uno de los bloques de construcción más fundamentales de la teoría de la computación, este modelo se utiliza en una amplia gama de campos en las ciencias de la computación, desde el diseño de algoritmos hasta la construcción de circuitos electrónicos digitales.

Las FSM pueden diseñarse dividiéndose teóricamente en dos categorías principales: deterministas o no deterministas. Sin embargo, uno de los teoremas fundamentales de la teoría de la computación demuestra que para cualquier máquina de estados finitos no determinista, siempre se puede construir una máquina de estados finitos determinista equivalente que reconozca exactamente el mismo lenguaje y produzca las mismas salidas de comportamiento. Este teorema permite a los ingenieros de software reducir escenarios complejos a estructuras deterministas más predecibles.

Representación Lógica y Dinámica de Transición de Estados

Las Máquinas de Estados Finitos se visualizan y expresan esencialmente como un grafo dirigido o diagrama de estados (state diagram). En este grafo dirigido, los nodos (nodes) representan los estados internos de la máquina abstracta, mientras que las flechas dirigidas (edges) que conectan estos nodos entre sí representan las transiciones de estado. El estado actual del sistema en cualquier momento "t" se calcula siempre como una función determinista del estado anterior y de las entradas actuales que ingresan al sistema en ese momento.

En un contexto matemático, esta función de transición de estados se expresa de la siguiente manera:

En esta formulación, representa el siguiente estado del sistema, el estado anterior (actual) de la máquina, el valor de entrada (input) actual y la función de transición de estados (state transition function). Esta relación se muestra frecuentemente en la literatura como la operación de mapear el producto cartesiano del conjunto de estados (S) y el conjunto de entradas (I) nuevamente al conjunto de estados, es decir, . Las máquinas de estados también se dividen en dos subclases arquitectónicas principales según la naturaleza de las salidas (output) que producen: en el modelo de la Máquina de Moore, la función de salida depende únicamente del estado actual del sistema (), mientras que en el modelo de la Máquina de Mealy, la función de salida depende simultáneamente tanto del estado actual como de la entrada instantánea ().

En el diseño de sistemas, los estados y las entradas se representan típicamente con un alfabeto binario o enumeraciones predefinidas (enum), y las funciones y se codifican generalmente en forma de tabla de búsqueda (look-up table) o tabla de transición de estados (state transition table). En la arquitectura de software, la ocurrencia de las transiciones no solo depende de la presencia de entradas, sino también del cumplimiento de condiciones adicionales (guards). En un diagrama de estado UML típico o en implementaciones de motores modernos, la notación de una transición se expresa generalmente con la sintaxis disparador[condición]/efecto (trigger[guard]/effect). Aquí, el disparador (trigger) puede ser una señal, una llamada, una temporización o un evento de cambio. La condición (guard) es una prueba lógica adicional que debe verificarse para que ocurra la transición. El efecto (effect), por otro lado, es la operación específica que se ejecuta durante la transición.

Sin embargo, el poder de la arquitectura FSM radica no solo en las transiciones entre estados, sino también en las acciones que se pueden ejecutar al entrar en ciertos estados, al permanecer dentro de esos estados y al salir de ellos. Al entrar en un estado FSM (entry action), periódicamente mientras se está dentro del estado (during action) y al salir del estado (exit action), se pueden ejecutar bloques de código especiales. Por ejemplo, en un sistema de radio, presionar el botón "Adelante" cuando el dispositivo está en el estado "Radio" proporciona una transición a la siguiente estación de radio, mientras que presionar el mismo botón "Adelante" cuando el dispositivo está en el estado "CD" activa una transición a la siguiente pista de canción; por lo tanto, exactamente el mismo estimulador ambiental produce acciones completamente diferentes según el estado contextual en el que se encuentra la máquina.

El Lugar de las FSM en los Estándares de la Industria y sus Ventajas Prácticas

Las Máquinas de Estados Finitos han mantenido su presencia como estándar de la industria en un amplio trasfondo histórico que abarca desde el diseño de circuitos digitales hasta la industria de los videojuegos. Sus ventajas más obvias son que son conceptualmente extremadamente fáciles de entender, su simplicidad arquitectónica y sus enormes velocidades de ejecución a nivel de hardware y software. Para un diseñador, visualizar lo que un personaje o sistema puede hacer y a qué estados puede pasar a través de un diagrama de cajas y flechas ("box and arrow" diagram) hace que las FSM sean una estructura extremadamente intuitiva y fácil de depurar (debugging) durante el proceso de codificación.

Las FSM son insuperables, especialmente en áreas donde es crítico determinar el modo instantáneo del sistema, la fase de animación o el estado físico del personaje con límites precisos e impermeables. Los contextos específicos donde las FSM operan sin problemas son los siguientes:

En primer lugar, los juegos de lucha (fighting games) son uno de los campos de aplicación más brillantes de la arquitectura FSM. En un juego de lucha, los estados de un personaje como "Ataque", "Salto", "Aturdido" (Stunned), "Agacharse" o "Defensa" deben separarse entre sí mediante líneas lógicas precisas. Por ejemplo, cuando un personaje recibe un golpe fuerte de su oponente y entra en el estado "Aturdido", el personaje no puede saltar incluso si el jugador presiona el botón de salto. Si no se utiliza la arquitectura FSM, en cada intento de acción del personaje sería necesario escribir expresiones condicionales (conditional) anidadas e interminables e imposibles de mantener del tipo "si el personaje no está aturdido y si no está en el aire y si no está bloqueado en la animación de ataque...". Las FSM procesan perfectamente la lógica de "si el personaje está en el estado A, solo puede pasar al estado B o C", evitando este enorme desorden de espagueti en los bloques de código.

En segundo lugar, los controladores de animación de personajes se basan en gran medida en FSM. En los motores de juegos modernos como el líder de la industria Unreal Engine, las animaciones de los personajes se controlan mediante interfaces llamadas "Animation Blueprints" (Esquemas de Animación) que ejecutan una máquina de estados en segundo plano. Cuándo y cómo un personaje pasará de la animación "Inactividad" (Idle) a la animación "Caminar" (Walk) y de allí a la animación "Correr" (Run) es la función principal de las FSM gestionadas con esta interfaz de caja y flecha.

En tercer lugar, en los sistemas arcade y juegos que requieren una lógica de decisión simple, las FSM son ideales para operar con el principio "KISS" (Keep It Simple, Stupid - Mantenlo Simple, Estúpido). En muchos juegos de estilo arcade, los enemigos tienen estados muy limitados y específicos como "Patrullar", "Perseguir", "Atacar" o "Huir". Una FSM implementada en un entorno C++ nativo ofrece un rendimiento único al ejecutarse a nivel de nanosegundos en los procesadores modernos. Los desarrolladores de software pueden definir estados utilizando enumeraciones sin nombre (unnamed enums) y conectar estos estados a identificadores de eventos (event IDs) mediante una estructura de "un gran switch" (one big switch) o técnicas de enmascaramiento de bits. La arquitectura de código ordenada aportada por esta estructura permite la recompilación en tiempo de ejecución (hot-recompiling) de la FSM, al tiempo que garantiza una ejecución segura y sin interrupciones (execution safety) al devolver identificadores de estado distintos de cero desde los manejadores de eventos (event handlers) en lugar de subrutinas como SetState(). Este flujo de ejecución lineal hace posible alcanzar altas tasas de fotogramas (framerate) al evitar cualquier tartamudeo (stutter) en el ciclo del juego.

Punto de Crisis Arquitectónica: El Problema de la Explosión de Estados (State Explosion)

Aunque las FSM son perfectas y eficientes para modelos de comportamiento determinista con un número limitado de estados, tienden a colapsar estructuralmente a medida que aumenta la complejidad del sistema autónomo, el número de variables ambientales y el repertorio de comportamiento que se espera que tenga la inteligencia artificial. Esta vulnerabilidad crónica se denomina en la literatura "Explosión de Estados" (State Explosion).

La restricción fundamental de la arquitectura FSM es que la máquina solo puede estar en un único estado a la vez. Si un personaje va a poder correr y disparar al mismo tiempo, en la arquitectura FSM el personaje no puede estar en los estados "Correr" y "Disparar" simultáneamente; en su lugar, se debe crear un estado híbrido completamente nuevo llamado "Disparar Corriendo". Cada nueva variable agregada al sistema requiere la producción de tantos estados nuevos como sus combinaciones posibles con todos los estados existentes. El número de estados que el modelo debe representar alcanza dimensiones masivas como el producto cartesiano de los conjuntos de variables.

Un problema aún más crítico es la complejidad de transición (transition) creada por el aumento en el número de estados. Agregar un estado en una FSM no significa solo crear ese estado; requiere codificar uno por uno, con reglas específicas, cómo se realizará la transición a este estado recién agregado desde todos los demás estados relevantes en el sistema y a qué estados se puede regresar desde este estado. En la jerga de las ciencias de la computación, la velocidad de crecimiento de la complejidad de transición con el aumento del número de estados se expresa como proporcional al cuadrado. Esta tasa de crecimiento geométrico crea una carga de complejidad acumulativa similar a la Ley de Metcalfe, que sostiene que el valor de una red de telecomunicaciones es proporcional al cuadrado del número de usuarios en la economía de red.

Cuando una FSM alcanza aproximadamente 10 estados, su gestión se vuelve difícil; cuando el número de estados llega a 40 (por ejemplo, en la inteligencia artificial de un combate contra jefes avanzado al estilo de Sekiro o Dark Souls), el archivo de código se llena con cientos de

líneas de lógica de transición y se convierte literalmente en un "código espagueti" (Spaghettification). 13 En esta etapa, realizar el mantenimiento (maintenance) del código o depurar los errores (debugging) evoluciona hacia una pesadilla. Porque la causa raíz de cualquier error lógico (bug) que surja puede ser un disparador defectuoso en una de las docenas de diferentes transiciones de estado, un orden de prioridad mal construido o una flecha de transición olvidada. 23

Para mitigar esta explosión de estados y evitar en cierta medida la formación de código espagueti, se han desarrollado las "Máquinas de Estados Finitos Jerárquicas" (Hierarchical Finite State Machines - HFSM). En el modelo HFSM, los estados se diseñan de manera que pueden anidarse; un "estado principal" (parent state) alberga subestados (substates) que operan de forma independiente dentro de él. Por ejemplo, un estado principal llamado "Combate" puede tener una submáquina que ejecuta los subestados "Tomar Cover", "Auntar" y "Disparar" en su interior. Si el jugador se aleja mientras el sistema está en el estado principal "Combate", una sola "Transición de Grupo" (Group Transition) realizada desde el estado principal al estado "Patrullar", independientemente de en cuál de los subestados se encuentre, elimina la necesidad de escribir código de escape o cancelación uno por uno para cada uno de los subestados internos. 8 Gracias a los puntos de transición (transition points) y las prioridades de activación de eventos (event triggering precedence), las HFSM llevan la capacidad de las FSM un poco más arriba. 24 Sin embargo, cuando la complejidad del sistema supera un cierto umbral (por ejemplo, en un planificador de tareas complejo que contiene docenas de estados y cientos de transiciones), incluso las HFSM sucumben a la complejidad visual y se vuelven frágiles estructuralmente. 8

Árboles de Comportamiento (Behavior Trees): Evolución, Estructura y Lógica de Ejecución

La barrera de escalabilidad geométrica impuesta por las FSM y las HFSM hizo obligatorio el nacimiento de un nuevo paradigma arquitectónico en los procesos de toma de decisiones de personajes y agentes autónomos. Los Árboles de Comportamiento (Behavior Trees - BT) son estructuras de toma de decisiones modulares y jerárquicas desarrolladas precisamente para superar este estancamiento, ofreciendo a la inteligencia artificial una hoja de ruta visual y clara sin perderse en los rígidos laberintos de transición del tipo "si pasa esto, haz aquello". 2

Orígenes Históricos y Proceso de Adopción Industrial

Aunque las narrativas académicas e industriales sobre exactamente cuándo y dónde surgieron los árboles de comportamiento muestran ligeras diferencias, existe un amplio consenso en que estas estructuras nacieron en las trincheras de los propios estudios de desarrollo de juegos en lugar de en sofisticados laboratorios de investigación. 2 Uno de los primeros usos documentados se remonta al juego SimCopter de 1996, desarrollado por Maxis. Según las explicaciones de Don Hopkins, ex empleado de Maxis, se utilizó un lenguaje visual llamado "SimAntics" para controlar a los NPC dentro del juego, el cual aparecía como "árboles de reacción" (reaction trees) en el archivo people.df del código del juego. Los comentarios de este archivo contienen definiciones que recuerdan a la mecánica moderna de los árboles de comportamiento, como "un árbol de reacción puede ser llamado por otro árbol de reacción pero no puede ser interrumpido en ese momento". 25

Sin embargo, la formulación de la arquitectura de los Árboles de Comportamiento en un sentido moderno, su transformación en un estándar industrial y la adquisición de una sólida base académica ocurrieron en gran medida con la icónica charla de Damian Isla en la Conferencia de Desarrolladores de Juegos (GDC) de 2005 ("Handling Complexity in the Halo 2 AI"), donde presentó la revolucionaria arquitectura de IA del juego Halo 2. 3 Durante el proceso de desarrollo de Halo 2, el equipo de Bungie se encontró con dos grandes callejones sin salida provocados por las FSM: la pérdida de escalabilidad del sistema ante una variedad de comportamientos en rápido crecimiento y la inestabilidad derivada de que la IA oscilara rápidamente entre decisiones, es decir, el problema del "dithering". 3

Queriendo resolver esta sobrecarga mental (mental bandwidth) provocada por las FSM, el equipo estructuró los comportamientos de los personajes en una jerarquía llamada "DAG de comportamiento" (Directed Acyclic Graphs - Grafos Acíclicos Dirigidos). 3 Este sistema contenía aproximadamente 50 comportamientos principales diferentes.

En la estructura descrita por Isla, los nodos en las partes superiores del árbol eran responsables de los algoritmos de toma de decisiones, mientras que los nodos hoja en los extremos se encargaban de ejecutar las acciones. Este enfoque aseguró que la IA no solo supiera qué hacer, sino que también actuara con sentido común (common sense). Además, los personajes tenían sus propias "listas de objetivos" (target lists) internas y conciencia espacial (firing positions) para percibir los objetivos. 3 Esta estructura modular era tan flexible, tolerante a fallos y legible que el concepto pronto saltó al campo de la robótica y la academia. Hoy en día, los Árboles de Comportamiento se han convertido en el estándar de facto (de facto standard) en una amplia gama que va desde los vehículos aéreos no tripulados hasta los robots colaborativos industriales (collaborative robots) y los sistemas de conducción autónoma. 1

Arquitectura Estructural de los BT y Jerarquía de Nodos (Nodes)

Los árboles de comportamiento son una estructura de datos de árbol jerárquico que conecta acciones y decisiones como bloques de LEGO digitales. 2 A diferencia de los Árboles de Decisión (Decision Trees) clásicos, los BT no solo siguen un camino hasta llegar a un resultado; gestionan el control lógico de los nodos, los procesos de ejecución asíncrona (execution flows) y las interrupciones mediante señales regulares enviadas desde la raíz (root) del sistema hacia las hojas (leaves) (generalmente llamadas "tick"). 1

El concepto más vital y distintivo en el funcionamiento de esta arquitectura es que cada nodo devuelve necesariamente un estado lógico (status) a su nodo superior (parent node) como resultado de una operación "tick" que recibe. Estos estados de retorno constan de tres variedades universales:

1. Success (Éxito): El nodo ha completado su tarea completa y sin problemas, o la condición probada es verdadera.

2. Failure (Fallo): El nodo no ha podido realizar su tarea, se ha encontrado con un obstáculo o la condición probada es falsa.

3. Running (En ejecución): La operación aún no ha terminado; se requieren múltiples ciclos de tiempo (tick/frame) para que la acción se complete. 8

Precisamente la existencia de este estado "Running" es un salto tecnológico que diferencia a los Árboles de Comportamiento de todas las demás estructuras de árboles clásicas. 27 No se puede esperar que un robot físico termine la orden de "Caminar hacia el objetivo" en una décima de segundo, ni que el personaje de un juego complete instantáneamente la animación de "Abrir cofre". El estado Running permite que esa rama específica del árbol continúe la acción de forma asíncrona en segundo plano, evitando al mismo tiempo que el sistema se bloquee y se congele (blocking the execution thread). 27

Estructuralmente, los árboles de comportamiento constan de tres categorías principales de nodos: Composiciones, Decoradores y Hojas. 28

1. Nodos Compuestos (Composite Nodes)

Los nodos compuestos son los puntos de ramificación del árbol. Son los bloques de construcción que tienen múltiples subnodos (hijos) y deciden en qué orden, bajo qué condición o de forma simultánea se ejecutarán estos subnodos conectados a ellos. 28

• Selectores (Selector / Fallback Nodes): Es un reflejo del operador OR (O) en la lógica de programación básica. Ejecuta los subnodos conectados a él en orden de izquierda a derecha. Si uno de los subnodos devuelve Success o Running, el nodo Selector deja de probar instantáneamente a los demás hijos y transmite este estado a su nodo superior. La única forma de que un nodo Selector devuelva Failure (Fallo) es que todos los subnodos conectados a él fallen. Esta estructura es perfecta para determinar las prioridades de supervivencia de un agente o planes alternativos (fallback): el sistema intenta primero la opción "Curarse", si falla pasa a la opción "Buscar cobertura", y si eso tampoco funciona, intenta "Huir". Tan pronto como uno tiene éxito, la cadena de acción se satisface. 8

• Secuencias (Sequence Nodes): Es el equivalente del operador AND (Y) de la programación básica en un árbol de comportamiento. Prueba los subnodos de izquierda a derecha. Sin embargo, a diferencia de los Selectores, las Secuencias interrumpen la operación instantáneamente si uno de los subnodos devuelve Failure y devuelven Failure al nodo superior. Para que una Secuencia devuelva Success, es obligatorio que todos los subnodos que contiene tengan éxito sin excepción. Este nodo se utiliza para establecer la cadena de pasos lógicos de una tarea: la cadena necesaria para que un NPC cruce una puerta se estructura como "Caminar hacia la puerta", luego "Desbloquear", luego "Bajar la manija", y luego "Entrar". Si la puerta está cerrada con llave y el personaje no puede desbloquearla (Failure), no tiene sentido pasar a los siguientes pasos; la secuencia falla y el personaje abandona el plan de cruzar la puerta. 8

• Nodos Paralelos (Parallel Nodes): Es uno de los miembros más complejos de la familia de compuestos. Ejecuta sus subnodos no en orden de izquierda a derecha, sino al mismo tiempo (simultáneamente). Devuelve un resultado al árbol basado en una política específica de éxito o fallo (por ejemplo, "terminar la operación cuando cualquiera de los subnodos tenga éxito" o "esperar hasta que todos tengan éxito"). Se utiliza para controlar tareas simultáneas, como que un personaje "mueva las manos mientras habla" o que un vehículo robótico "avance hacia el objetivo mientras realiza un escaneo de radar". 30

2. Nodos Decoradores (Decorator Nodes)

Al igual que el patrón Decorator en los patrones de diseño, son nodos que solo pueden tener un único subnodo y modifican el resultado devuelto por ese subnodo según diversas políticas o condicionan su ejecución. 8

• Inversor (Inverter): Es el operador NOT de la programación clásica. Convierte el resultado Success del subnodo en Failure, y el resultado Failure en Success.

• Limitador (Limiter): Permite que el subnodo funcione solo un número determinado de veces en un segundo determinado o durante todo su ciclo de vida; devuelve un fallo en los casos que superen esta cuota.

• Temporizador (Timer): Retrasa la acción del subnodo durante un cierto período de tiempo en lugar de ejecutarla inmediatamente. 8

3. Nodos Hoja (Leaf Nodes)

Son nodos de ejecución ubicados en el nivel más alto y final del árbol y que, por su naturaleza, no pueden tener ningún subnodo. 29 Las hojas son los puntos finales donde el sistema interactúa directamente con el mundo virtual del juego o con los sensores reales del robot, generando efectos tangibles. 22

• Acciones (Actions/Tasks): Son los bloques de código reales que crean un cambio físico o lógico en el mundo, reproducen animaciones, emiten sonidos o envían energía a los motores ("Disparar", "Caminar al objetivo", "Detener motores").

• Condiciones (Conditions/Queries): Son comprobaciones instantáneas de lógica y consultas de sensores que generalmente devuelven Success o Failure y no realizan ninguna acción ("¿Está el enemigo en el rango de visión?", "¿Me quedan municiones?", "¿Está el nivel de batería por debajo del 20%?"). 8

Árboles de Comportamiento Dirigidos por Eventos (Event-Driven) y Observadores (Observers)

Los BT clásicos de los primeros tiempos funcionaban con una lógica de sondeo (polling) que reevaluaba continuamente el árbol hacia abajo desde la raíz en cada operación "tick" (generalmente en cada fotograma visual). 19 Aunque esto era impecable en términos de reactividad, creaba una sobrecarga de procesador (CPU) masiva en el cálculo de cada fotograma. A medida que un árbol se volvía muy profundo, el coste de probar repetidamente todas las condiciones desde la parte superior hasta la inferior en cada fotograma dejaba de ser sostenible. 9

Los motores de juegos modernos como Unreal Engine y los estándares de la industria han evolucionado la arquitectura al modelo de "Árboles de Comportamiento Dirigidos por Eventos" (Event-Driven Behavior Trees) para superar este cuello de botella de hardware. 32 En esta estructura innovadora, en lugar de comprobar las condiciones de principio a fin como un policía en cada "tick", el sistema utiliza decoradores reactivos llamados "Anulaciones del Observador" (Observer Aborts). Por ejemplo, si una IA de gato persigue a un ratón, un nodo paralelo clásico pregunta cada segundo si el ratón ha entrado en el agujero. En la estructura dirigida por eventos, la condición "¿Se puede observar al ratón?" se coloca en el árbol como un Observer.

Tan pronto como el ratón escapa al agujero (event), este evento se activa y el Observador anula (abort) instantáneamente la secuencia actual de "Correr" y "Saltar" del gato. De esta manera, la inteligencia artificial solo recalcula cuando su estado realmente cambia, se logra un gran ahorro de potencia de procesamiento, se minimizan las rutas de ejecución simultánea en árboles complejos y la optimización del sistema se vuelve increíblemente fácil. Además, en el sistema de Unreal Engine, se pueden agregar nodos especiales llamados "Servicios" (Services) a los nodos Compuestos. Los servicios funcionan a ciertos períodos (por ejemplo, cada 2 segundos) siempre que el subárbol esté activo, reemplazando las acciones periódicas "during" de las FSM y actualizando continuamente datos como el seguimiento de enemigos.

El Problema de la Memoria y el Mecanismo de Pizarra (Blackboard)

La inmensa modularidad de los Árboles de Comportamiento tiene un precio: los nodos de los BT están, por diseño, completamente aislados y no tienen estado (stateless). Es decir, un nodo de acción "Caminar hacia el objetivo" desconoce qué encontró el nodo de condición "Encontrar enemigo" situado inmediatamente a su izquierda o qué se decidió en ciclos anteriores. A diferencia de las FSM, los BT no guardan decisiones pasadas o datos de sensores instantáneos en sus propias estructuras internas.

Para llenar este vacío de comunicación vital y dotar al árbol de una especie de "memoria a corto plazo", se utiliza el patrón de diseño Blackboard (Pizarra). La pizarra es un grupo de datos externo y compartido (configurado generalmente como un diccionario, mapa hash o estructura de datos Variant en los lenguajes de programación) que todos los nodos del árbol pueden leer y escribir durante la ejecución.

El funcionamiento es el siguiente: cuando un árbol llega al nodo de condición "Ver enemigo", este nodo detecta las coordenadas del enemigo pero no guarda esta información por sí mismo; la escribe directamente en el Blackboard como TargetPosition = . Cuando el flujo del árbol llega al siguiente paso, el nodo de acción "Ir allí", el nodo de acción se conecta al Blackboard, lee los datos de TargetPosition y traza su ruta.

La arquitectura de Pizarra construye un puente de datos increíblemente potente, flexible y rápido entre nodos y ramas, sin poner en peligro la modularidad pura y el aislamiento de nodos de los Árboles de Comportamiento.

Análisis Comparativo: El Enfrentamiento entre Máquinas de Estados Finitos y Árboles de Comportamiento

Para los arquitectos que se disponen a sentar las bases de un sistema de inteligencia artificial desde cero, la elección entre las Máquinas de Estados Finitos (FSM) y los Árboles de Comportamiento (BT) no es una mera preferencia de sintaxis o de motor, sino una decisión arquitectónica vital que afectará profundamente a todo el ciclo de vida del proyecto. Las actas de la Conferencia de Desarrolladores de Juegos (GDC), los estudios de casos industriales y las simulaciones académicas de robótica publicadas en los últimos años comparan exhaustivamente el rendimiento estructural de estos dos sistemas en términos de Toma de Decisiones, Modularidad, Reactividad, Legibilidad y Escalabilidad.

1. Toma de Decisiones frente a Control de Estados

El consenso más sólido en la industria del software es que los árboles de comportamiento se especializan en los procesos de «toma de decisiones», mientras que las FSM lo hacen en los procesos de «control de estados».

Los árboles de comportamiento están optimizados específicamente para tomar decisiones cognitivas («¿Qué debe hacer ahora el agente?») que son dinámicas, responden a condiciones ambientales en constante cambio, contienen numerosas ramificaciones lógicas y requieren priorización. Por otro lado, las FSM son perfectas para el modo en que se aplica una decisión ya tomada, la gestión de modos físicos coherentes y aislados del sistema, y el control con límites precisos de los flujos secuenciales («¿Cómo y mediante qué etapas debe ejecutar esta acción el agente?»).

La siguiente tabla resume sistemáticamente estas diferencias filosóficas fundamentales:

2. Modularidad y Crisis de Dependencia

Los árboles de comportamiento son arquitecturas de «baja dependencia» (low-dependency), como se reconoce en la industria. Un nodo hoja de un BT (por ejemplo, la acción «Correr Hacia el Objetivo») es un objeto autónomo y encapsulado, totalmente independiente de dónde se encuentre en el árbol. Este nodo puede ser copiado y arrastrado a una rama completamente diferente llamada «Modo de Defensa con Ametralladora Pesada» y funcionará sin problemas sin modificar ningún código fuente.

Por el contrario, en las FSM, un «estado» debe definir en sí mismo o en su gestor qué estados específicos se pueden transicionar después de él y con qué condiciones se realizará dicha transición. Este enfoque de «acoplamiento fuerte» (tight coupling) hace que sea casi imposible copiar un bloque de código escrito del proyecto y transferirlo a otra inteligencia artificial. Cada pequeño cambio realizado en una FSM o la adición de un nuevo estado requiere recalibrar una a una todas las flechas de entrada y salida (transiciones) conectadas a ese estado. Se ha demostrado estadísticamente que añadir nuevos comportamientos de tolerancia a fallos (por ejemplo, volver a la carga autónoma cuando la batería se agota) a los sistemas basados en FSM es exponencialmente más difícil que en los sistemas basados en BT.

3. Conflicto entre Fuerza de Expresión y Reactividad

Las comparaciones de laboratorio realizadas en arquitecturas de control robótico revelan la diferencia filosófica inherente de estas dos arquitecturas con métricas sumamente llamativas.

Fuerza de Expresión (Expressiveness): Al contrario de lo esperado, los estudios académicos han demostrado que las FSM son más «expresivas» que los BT. El estado activo en el que se encuentra una FSM es una acumulación física concreta de decisiones tomadas en el pasado. Si una FSM emite la señal «Actualmente estoy en Estado de Alarma», esta información contiene intrínsecamente (inherently) el hecho de que en el pasado se percibió una amenaza, el sistema validó esta amenaza e inició una secuencia de acciones. Los árboles de comportamiento, por el contrario, son totalmente olvidadizos. En cada nuevo ciclo de «tick», el árbol comienza a escanear desde el nodo raíz como si el mundo hubiera sido creado de nuevo. Depende completamente de los datos externos en el Pizarron (Blackboard) para recordar acciones o modos pasados.

Reactividad: Como precio de la modularidad, la reactividad es débil en las FSM. Si el diseñador de la FSM no dibujó una flecha de transición del tipo «Si el robot escucha una alarma de incendio repentinamente mientras transporta un objeto, pasa a este estado», el robot nunca soltará la caja que tiene en la mano y huirá. Los árboles de comportamiento, por su parte, son infinitamente más reactivos que las FSM. Dado que el mundo se verifica desde el principio en cada ciclo o se utilizan Observadores, el más mínimo cambio ambiental permite que el árbol se dirija instantáneamente a la rama de mayor prioridad (por ejemplo, «Huida de Emergencia») y anule (preempt) la acción de transporte de objetos que se encuentra en estado «Running» en ese momento.

4. Coste de Instalación, Depuración (Debugging) y Mantenimiento

En los sistemas de toma de decisiones, el coste de mantenimiento es el área donde los desarrolladores dedican más tiempo. Las FSM se pueden construir desde cero en cuestión de minutos en la fase inicial con un coste extremadamente bajo, mediante unos simples enumeradores y expresiones switch-case. Sin embargo, a medida que el sistema crece con el tiempo, esta ventaja se evapora y la depuración se convierte en un caos total.

Los árboles de comportamiento, por otro lado, comienzan el trabajo con una pesada carga de «boilerplate» (código repetitivo) desde el principio. Entre los mecanismos de raíz, los sistemas de Tick y la integración del Pizarron, simplemente poner en marcha el sistema ya es una inversión arquitectónica seria. Sin embargo, una vez pagado este precio, sus capacidades de depuración visual en tiempo real son extraordinarias. En sistemas como las herramientas de BT integradas en Unreal Engine o el complemento Beehave desarrollado para Godot, el desarrollador puede monitorear los flujos de datos en la parte superior del árbol (estados verdes o rojos encendidos) en tiempo real mientras se ejecuta el juego o la simulación, y detectar en segundos por qué falló un nodo de acción determinado. En las «telas de araña» basadas en FSM, encontrar visualmente la fuente del error suele llevar horas.

Aplicaciones de Arquitectura Híbrida Avanzada y Sistemas Orientados a Objetivos

Aferrarse a un único patrón arquitectónico a menudo conduce al fracaso en proyectos de sistemas autónomos. Mientras que un enfoque de FSM pura choca con el muro de la escalabilidad, intentar diseñar incluso el ciclo de movimiento más pequeño o un algoritmo de salto utilizando BT crea un recuento innecesario de condiciones al aumentar el número de "observadores" y un coste de CPU masivo. Por esta razón, el "Estándar de Oro" en los juegos AAA modernos y en las soluciones de robótica industrial son los diseños híbridos donde estas dos arquitectura se integran ingeniosamente para cubrir las debilidades de la otra.

Fusión de Árboles de Comportamiento y Máquinas de Estados (Layered AI)

En los diseños híbridos más eficientes y aceptados por la industria, el sistema de inteligencia artificial se divide en capas (layers). Las decisiones cognitivas de alto nivel sobre lo que debe hacer el personaje son tomadas por el Árbol de Comportamiento, que por su naturaleza es jerárquico y propenso a ramificaciones, mientras que la tarea de ejecutar esta decisión seleccionada física y algorítmicamente en el campo se delega a la FSM o HFSM subyacente.

Por ejemplo, en una inteligencia artificial de enemigos avanzada o en un agente de vigilancia autónomo, el sistema funciona de la siguiente

manera:

1. Capa de Decisiones (BT - Cerebro Estratégico): Lee el número de amenazas alrededor del personaje, sus propios valores de salud y munición a través del Blackboard. Como resultado de la evaluación selectiva realizada, se toma la decisión de "Retirada Táctica".35

2. Capa de Ejecución (FSM - Habilidades Motoras): El comando de "Retirada Táctica" se transmite como un disparador (trigger) a una máquina de estados integrada en el sistema esquelético del personaje. La FSM saca inmediatamente al personaje del estado actual de "Animación de Ataque" al estado de "Correr a Serie", y de ahí pasa suavemente al estado de animación de "Agacharse" detrás de la cobertura.

Gracias a este enfoque por capas, el BT no se atasca innecesariamente en cada fotograma (frame) con detalles de ejecución como "¿está el pie izquierdo o el derecho del personaje al frente?"; y la FSM no tiene que preguntar por decisiones macroestratégicas como "¿dónde está el enemigo?".22

En el campo de la robótica, la situación muestra un paralelismo similar. Los cambios de modo de nivel superior (Control Manual Humano, Modo de Misión Autónoma, Modo de Error de Hardware/Emergencia) de un vehículo de guía automatizada (AGV) que trabaja en un almacén logístico son coordinados por una HFSM macro para garantizar la comprensibilidad.27 Sin embargo, cuando el robot entra en el "Modo de Misión Autónoma", operaciones como evitar obstáculos dinámicos en la ruta hacia el objetivo, la manipulación precisa de objetos y las retroalimentaciones sensoriales instantáneas se confían a la reactividad jerárquica única de los BT.27 En la literatura, utilizando planificadores de encadenamiento hacia atrás (backward-chaining), también se han aplicado con éxito soluciones avanzadas en las que los árboles de comportamiento autónomos se generan dinámicamente desde cero ordenando las condiciones hacia atrás desde un objetivo.27

Otras Dimensiones de la Toma de Decisiones Autónoma: El Contexto GOAP

Para comprender plenamente la complejidad de las arquitecturas, también es importante mencionar el concepto de "Planificación de Acciones Orientada a Objetivos" (Goal-Oriented Action Planning - GOAP), que va más allá de los sistemas FSM y BT en la industria. Basado en la teoría de planificación STRIPS de 1971 y popularizado por Jeff Orkin, arquitecto de la legendaria IA enemiga en el juego F.E.A.R., GOAP ha aportado una dimensión completamente diferente a los procesos de toma de decisiones.13

En el sistema GOAP, las acciones no se combinan de antemano en un árbol rígido. Al sistema se le proporciona únicamente una lista de "Acciones" (Actions - Ej: Abrir puerta), "Precondiciones" (Preconditions - Ej: Estar al lado de la puerta) y "Efectos" (Effects - Ej: La puerta ahora está abierta). El sistema (generalmente utilizando un algoritmo de búsqueda A*) combina estas acciones en tiempo de ejecución (runtime) para alcanzar el estado "Objetivo" deseado y crea automáticamente el plan más ideal. La genialidad de F.E.A.R. es que para ejecutar los planes producidos por este enorme motor de planificación autónoma en segundo plano, en realidad utiliza una FSM muy simple y minimalista con solo 3 estados (GoTo, Animate, Use Smart Object).13 Al igual que en los híbridos de BT modernos, mientras que el cerebro es un algoritmo complejo, los músculos siempre consisten en una FSM robusta.

Ecosistemas de Motores de Juegos de Nueva Generación: La Visión de "State Trees" (Árboles de Estados) en Unreal Engine

Epic Games, pionero global en tecnologías de motores de juegos y simulaciones de sistemas autónomos, ha presentado a la industria una herramienta visionaria con la estructura revolucionaria de Unreal Engine 5 (especialmente tal como se visibiliza en la actualización 5.5) que pretende poner fin a la disputa de décadas entre los Árboles de Comportamiento y las Máquinas de Estados: "State Trees" (Árboles de Estados).36

La naturaleza "stateless" (sin estado) de los Árboles de Comportamiento (BT) tradicionales, que tiende a volverse voluminosa después de una cierta escala, y los límites rígidos de las FSM, carentes de flexibilidad y propensas a producir código espagueti, se han mezclado ingeniosamente en el concepto de Árboles de Estados.36 Epic Games elimina las vulnerabilidades estructurales que tenían los BT de estilo antiguo con la arquitectura State Tree y dota a la potencia lineal de las FSM de un mecanismo de decisión moderno.

Las características destacadas de la arquitectura State Tree son las siguientes:

● Como flujo operativo básico, en lugar de la estructura enemiga del procesador de los BT que realiza ticks continuos y "comprueba las condiciones sin parar", se basa en el rendimiento del control de estados optimizado (state flow) que ofrecen las FSM.36 ● Al definir transiciones entre estados, en lugar de utilizar "complejas flechas de transición estrechamente acopladas entre sí", que es el punto más débil de las FSM, aprovecha la flexibilidad de los nodos selectivos (Fallback) utilizados por los Árboles de Comportamiento. ● Llevando esto un paso más allá, integra algoritmos de Utilidad (puntuación de beneficio/peso) directamente en la selección de estados.38 En lugar de dibujar flechas de transición estáticas y frágiles para las acciones de "Luchar" o "Huir" hacia un objetivo, el desarrollador puede definir parámetros de ponderación matemática (weight) y distribuciones de probabilidad para cada estado. A medida que la salud del personaje disminuye, la puntuación de utilidad de la función que calcula el estado de "Huir" supera la puntuación del estado de "Luchar".38 De este modo, el árbol realiza una transición orgánica de un estado a otro, casi con la elegancia de un árbol de decisiones, sin necesidad de innumerables flechas de transición.38

Este nuevo movimiento tecnológico generacional es un paso que cambiará las reglas del juego en el campo de la toma de decisiones autónoma. El hecho de que los ingenieros de Epic Games se centren directamente en la arquitectura State Tree en las nuevas construcciones de hardware y sistemas dibuja una clara proyección de que los Árboles de Comportamiento clásicos serán abandonados gradualmente en el futuro para dejar su lugar a "Árboles de Estados" híbridos equipados con el rendimiento de las FSM y enriquecidos con funciones de utilidad.36

Conclusión

A la hora de diseñar la columna vertebral de la toma de decisiones de personajes autónomos, brazos robóticos, vehículos autónomos y agentes de inteligencia artificial avanzados en los videojuegos, no existe una única respuesta teórica absoluta a la pregunta "¿Qué arquitectura es superior?". Cada decisión arquitectónica tomada en las ciencias de la computación y la ingeniería de software trae consigo un cálculo profundo de compromisos (trade-offs).

Las Máquinas de Estados Finitos (FSM) seguirán siendo una piedra angular indispensable, especialmente en controles de juegos de bajo nivel, juegos de lucha, mecánicas de arcade y sistemas de animación complejos, gracias al alto rendimiento de velocidad que proporcionan en las transiciones de estado deterministas, la facilidad de comprensión lógica que ofrecen desde la perspectiva del desarrollador y su naturaleza equipada con límites de hardware precisos. Sin embargo, en escenarios cognitivos donde aumenta el número de variables representadas y las condiciones ambientales cambian instantáneamente, la "Explosión de Estados" causada por la FSM se transforma en una peligrosa crisis estructural que condena rápidamente al proyecto a un código espagueti imposible de mantener.

Por otro lado, los Árboles de Comportamiento (Behavior Trees) han dado un verdadero salto evolutivo a la inteligencia artificial de los juegos y a la autonomía robótica al introducir en la industria paradigmas de flexibilidad, modularidad extrema, reutilización basada en componentes y alta reactividad. La existencia del concepto "Running", que puede ejecutar asíncronamente acciones que abarcan el tiempo, y dar forma a los códigos como piezas de Lego independientes que se pueden agregar a otros agentes sin volver a tocarlos jamás, han convertido a los BT en el cerebro indiscutible de las simulaciones masivas de mundo abierto. Sin embargo, la falta de estado (statelessness), que es el precio de esta flexibilidad, obliga a los diseñadores de sistemas a construir puentes de memoria externa como el Blackboard y hace imperativo implementar diseños pesados orientados a eventos (event-driven) para garantizar las optimizaciones de rendimiento.

En última instancia, el diseño de un sistema autónomo moderno exitoso depende del nivel de abstracción en el que el arquitecto prefiera gestionar el proyecto. Las prácticas industriales prácticas demuestran un hecho indiscutible: las arquitecturas híbridas jerárquicas donde se establecen los objetivos de los sistemas autónomos y las decisiones reactivas sobre qué acción elegir se toman con Árboles de Comportamiento; y la coordinación física, los pasos de animación y las transiciones de modo de esta acción seleccionada se gestionan con FSM, representan el punto más elegante y sofisticado alcanzado por el software actual. Los mecanismos de toma de decisiones del futuro seguirán presenciando evoluciones de sistemas de nueva generación donde los límites se difuminan aún más y las arquitecturas fusionan FSM y BT en un solo cuerpo (como en el ejemplo de Unreal Engine State Trees).

*Nota: Las imágenes fueron generadas por Google Gemini.