Diferencias

Muestra las diferencias entre dos versiones de la página.

--- public:vj1231:fsm:start [2025/10/08 15:36] – mperez
+++ public:vj1231:fsm:start [2026/10/13 16:42] (actual) – [Componentes de la FSM] mperez
@@ Línea 1: / Línea 1: @@
-====== Máquinas de estado finitos ======
+====== Máquinas de Estados Finitos ======
 Una Máquinas de estado finitos (FSM, por sus siglas en inglés) es un modelo matemático compuesto por:
@@ Línea 7: / Línea 7: @@
   * Eventos o condiciones: Son los disparadores de las transiciones (como la distancia al jugador, recibir daño, perder de vista al objetivo, etc.).
   * Acciones: Lo que el NPC hace mientras está en un estado determinado (animaciones, movimientos, sonidos, etc.).
+====== ¿Cómo se modela? ======
 Las FSM pueden implementarse utilizando simples estructuras condicionales if-then-else (o switch/case) es lo que se conoce como  "FSM implícita". Este tipo de FSM funcionan para casos simples, pero no escala bien y puede volverse difícil de mantener, depurar o extender.
-Existen otras formas más robustas, modulares y limpias de implementar las FSM, uno de los paradigmas más usados es el orientado a objetos donde cada estado es una clase, y las transiciones se manejan dentro de esas clases.
+Los principales inconvenientes que plantea este enfoque son:
+    *   **Spaghetti code:** A partir de 5 o 6 estados, la función se vuelve ilegible.
+    *   **Violación del principio Abierto/Cerrado:** Añadir un estado nuevo o modificar una transición obliga a tocar y recompilar la función central, rompiendo fácilmente el código existente.
+    *   **Falta de reutilización:** No es fácil compartir estados entre diferentes tipos de NPCs.
+Existen otras formas más robustas, modulares y limpias de implementar las FSM, uno de las técnicas más usadas es la que utiliza el **enfoque orientado a objetos** donde cada estado es una clase, y las transiciones se manejan dentro de esas clases.
+Las ventajas de este modelo es que cada estado encapsula su lógica lo que lo hace fácil de extender ya que  añadir un nuevo estado solo requiere una nueva clase y evita grandes bloques de if/else que hacen el código ilegible.
+====== Enfoque orientado a Objetos ======
+===== class State: =====
+Clase base para todos los estados del NPC. Cada estado define una interfaz común que define:
+  * ''enter'': qué hacer al entrar en el estado,
+  * ''execute'' (o  ''update''): qué hacer cuando se está en ese estado
+  * ''exit'': qué hacer al salir del estado.
+  * ''get_next_state_class'': define el estado al que se pasa ante la llegada de un evento.
+  def enter(self, npc):  → Acción al entrar en el estado.
+  def execute(self, npc):  → Acción principal que se ejecuta cada frame.
+  def exit(self, npc):  → Acción al salir del estado.
+  def get_next_state_class(self, event): → Devuelve la clase del estado siguiente según el evento recibido.
+===== class StateMachine =====
+Esta clase implementa la Máquina de estados que gestiona el estado actual de un NPC.
+===== Nuevos estados =====
+Para definir nuevos estados se define una nueva clase que hereda de State:
+<code python>
+class TimidoPatrolState(State):
+    """
+    Estado en el que el NPC tímido patrulla por el borde.
+    """
+...
+</code>
+===== Transiciones entre estados =====
+Las transiciones de un estado a otros se pueden definir en el método ''get_next_state_class(self, event)'' de cada estado.
+Otras implementaciones definen las transiciones entre estados como un diccionario de pares ''"evento":estado''. Por ejemplo se puede definir para cada estado un diccionario denominado ''transitions'' con el evento que provoca una transición y a qué estado se mueve.
+<code python>
+# Definir transiciones para NPCTimido
+TimidoPatrolState.transitions = {"player_seen": TimidoChaseState}
+TimidoChaseState.transitions = {"player_too_close": TimidoFleeState, "player_lost": TimidoPatrolState}
+...
+</code>
+====== Ejemplo ======
+En esta imagen se muestra el comportamiento de tres NPCs distintos modelados usando FSM. Los estados se muestran en azul los eventos que provocan las transiciones entre estados aparecen sobre las flechas.
+### 🟢 NPC Normal
+Es el más simple: solo decide entre perseguir o patrullar según si detecta al jugador.
+{{:public:vj1231:fsm:npc_normal_fsm.svg?600|}}
+### 🟠 NPC Tímido
+Su comportamiento cambia drásticamente dependiendo de si está en "misión de alerta" (buscando al guardia para reportar la posición del jugador):
+   - Si **está en alerta**, prioriza su seguridad (huye hacia un guardia o completa un informe).
+   - Si **no está en alerta**, se comporta de forma más agresiva (inicia la alerta si el jugador está cerca, o lo sigue si está lejos).
+{{:public:vj1231:fsm:npc_timido_fsm.svg?600|}}
+### 🔵 NPC Guardia
+tiene un comportamiento intermedio. Si no ve al jugador, actúa como un "investigador": va a la última posición reportada del jugador si tiene esa información, o vuelve a patrullar si no.
+{{:public:vj1231:fsm:npc_guardia_fsm.svg?600|}}
-Las ventajas de este modelo es que cada estado encapsula su lógica lo que lo hace fácil de extender ya que  añadir un nuevo estado solo requiere una nueva clase. Evita grandes bloques de if/else que hacen el código ilegible.
+Puedes ver y ejecutar el ejemplo en este {{ :public:vj1231:fsm:fsm.v4.py.tgz |script de python}}