La posesión de un vehículo es una transferencia de estado

845. Identidad de la lección

Módulo

2.12 — Navegación, mapas y vehículos

Lección

La posesión de un vehículo es una transferencia de estado

Tipo académico

Construcción guiada

Tipo de esquema

práctica

Orden

2

Tiempo estimado

35–45 minutos

Esta lección modela la entrada a un vehículo, la salida y el control sin crear dos autoridades de movimiento que compitan entre sí.

846. Objetivo de aprendizaje

Al terminar esta lección, podrás producir y trazar un diagrama de posesión de cinco estados que identifique las transiciones legales, quién recibe las señales de control de movimiento, cómo se resuelven las interrupciones, cuándo se usa el estado no disponible y cómo se evitan estados inválidos para un jugador y un vehículo.

847. Por qué importa

La posesión de un vehículo cambia qué entidad interpreta las señales de control de movimiento. Si el personaje y el vehículo procesan esas señales al mismo tiempo, pueden producirse movimientos duplicados, controles bloqueados o una salida con resultado indefinido. Un contrato explícito de transición permite revisar la autoridad, el rechazo, las interrupciones y la recuperación antes de implementar el sistema.

848. Conocimientos previos

Debes poder distinguir una representación del mapa del estado actual del mundo, como se explicó en 2.12 L1 — Un mapa no es el estado del mundo. También debes saber describir un comportamiento mediante estados y transiciones, sin tratar la presentación como fuente de autoridad. No necesitas una implementación completa del vehículo.

849. Concepto central

La posesión de un vehículo es una transferencia de autoridad representada mediante cinco estados explícitos:

1. JugadorControlado: el personaje recibe las señales de control de movimiento.
2. Entrando: está en curso una transferencia aceptada de entrada al vehículo. Un único coordinador decide el resultado y el movimiento permanece bloqueado.
3. VehículoControlado: el vehículo recibe las señales de control de movimiento.
4. Saliendo: está en curso una transferencia aceptada de salida del vehículo. Un único coordinador decide el resultado y el movimiento permanece bloqueado.
5. NoDisponible: ninguno de los estados estables habituales es, por el momento, un destino de recuperación seguro. Ninguna entidad recibe señales de control hasta que el coordinador restablece un estado estable verificado.

La invariante central es no tener nunca dos autoridades de movimiento a la vez. JugadorControlado y VehículoControlado tienen exactamente un receptor de las señales de movimiento. Entrando y Saliendo tienen una sola autoridad que decide la transferencia, pero ninguna entidad recibe control de movimiento activo. NoDisponible es excepcional: se usa únicamente cuando el sistema no puede restablecer con seguridad ninguno de los dos estados estables, por ejemplo, porque falta una entidad necesaria o el contexto de posesión es incoherente.

No uses NoDisponible para rechazos normales:

• una solicitud de entrada al vehículo rechazada antes de iniciar la transferencia permanece en JugadorControlado;
• una entrada interrumpida vuelve a JugadorControlado si el jugador sigue siendo un destino de recuperación válido;
• una solicitud de salida con un destino inválido permanece en VehículoControlado;
• una salida interrumpida vuelve a VehículoControlado si el contexto de posesión sigue siendo válido;
• solo se entra en NoDisponible cuando ninguna de las dos recuperaciones habituales puede considerarse segura.

Mantén separadas estas cuestiones:

• Estado de posesión: cuál de los cinco estados se aplica.
• Estado del mundo: si el jugador, el vehículo, la ocupación y el destino son válidos.
• Estado de presentación: animación, cámara, visibilidad, avisos y efectos.
• Enrutamiento del control: qué entidad recibe las señales de movimiento o si quedan bloqueadas.

La presentación refleja el estado autoritativo de posesión; no lo determina.

850. Contrato determinista de transición

Cada flecha debe indicar cinco campos: solicitud o evento, precondición, autoridad que decide, regla de control de movimiento y ruta de fallo o recuperación.

JugadorControlado --[solicitud de entrada al vehículo
  | jugador válido; vehículo existente, disponible y libre; jugador dentro del alcance
  | coordinador acepta
  | bloquear movimiento
  | solicitud rechazada -> JugadorControlado]--> Entrando

Entrando --[confirmación de entrada
  | jugador, vehículo, acoplamiento y contexto de posesión siguen siendo válidos
  | coordinador transfiere la autoridad al vehículo
  | mantener bloqueo hasta confirmar; después, el vehículo recibe las señales de movimiento
  | interrupción con jugador seguro -> JugadorControlado;
    ninguna recuperación estable segura -> NoDisponible]--> VehículoControlado

VehículoControlado --[solicitud de salida
  | la posesión del vehículo sigue siendo válida; el destino de salida es válido
  | coordinador acepta
  | bloquear movimiento
  | destino inválido o solicitud rechazada -> VehículoControlado]--> Saliendo

Saliendo --[confirmación de salida
  | jugador, vehículo, separación y destino siguen siendo válidos
  | coordinador transfiere la autoridad al jugador
  | mantener bloqueo hasta confirmar; después, el jugador recibe las señales de movimiento
  | interrupción con posesión del vehículo segura -> VehículoControlado;
    ninguna recuperación estable segura -> NoDisponible]--> JugadorControlado

NoDisponible --[recuperar control del jugador
  | el jugador existe en un estado controlable y seguro verificado,
    y no hay autoridad de movimiento activa en el vehículo
  | coordinador restablece la autoridad del jugador
  | mantener bloqueo hasta confirmar la recuperación
  | validación fallida -> NoDisponible]--> JugadorControlado

NoDisponible --[recuperar control del vehículo
  | el vehículo y el contexto de posesión están verificados,
    el jugador sigue poseyendo válidamente el vehículo
    y no hay autoridad de movimiento activa en el jugador
  | coordinador restablece la autoridad del vehículo
  | mantener bloqueo hasta confirmar la recuperación
  | validación fallida -> NoDisponible]--> VehículoControlado

Una nueva solicitud de entrada o salida no salta directamente desde NoDisponible. Primero, la recuperación establece JugadorControlado o VehículoControlado; después puede comenzar la transición normal correspondiente. Así se evita que un reintento eluda silenciosamente las invariantes de los estados estables.

851. Cómo clasificar los fallos

Elige el resultado según el destino de recuperación que siga siendo seguro, no según la acción que haya fallado.

852. Ejemplo concreto

El jugador está junto a un vehículo disponible y libre. El sistema de posesión valida la proximidad, la disponibilidad y la ocupación antes de aceptar la solicitud de entrada. Al aceptarla, pasa a Entrando y el coordinador bloquea el movimiento. Si el acoplamiento y el contexto de posesión siguen siendo válidos, confirma VehículoControlado; solo entonces el vehículo recibe las señales de control de movimiento.

Si el vehículo pasa a estar ocupado durante la transferencia, pero el jugador sigue siendo válido fuera de él, el coordinador cancela la operación y restablece JugadorControlado. No es un caso de NoDisponible, porque el estado de origen sigue siendo seguro.

Mientras el vehículo está controlado, el jugador solicita salir. Si el destino está bloqueado, la solicitud se rechaza y el modelo permanece en VehículoControlado. Si el destino supera la validación, el modelo entra en Saliendo. Una separación correcta confirma JugadorControlado. Si el destino deja de ser válido durante la transición, pero la posesión del vehículo sigue intacta, la recuperación vuelve a VehículoControlado.

Usa NoDisponible únicamente cuando una interrupción impida verificar cualquiera de las dos recuperaciones estables. En ese estado, el movimiento permanece bloqueado hasta que una transición de recuperación etiquetada explícitamente valide y confirme una sola autoridad estable.

853. Errores comunes

Usar un solo booleano

Un booleano como isInVehicle no puede representar una entrada aceptada pero incompleta, una salida aceptada pero incompleta ni una recuperación excepcional. Distintos sistemas pueden interpretarlo en momentos diferentes y activar por accidente los dos controladores de movimiento.

Tratar la animación como autoridad

Un evento de animación puede servir como evidencia de que terminó un paso visual, pero no debe decidir por sí solo la posesión. El coordinador confirma el estado autoritativo únicamente después de comprobar que siguen cumpliéndose las condiciones necesarias.

Enviar todos los fallos a NoDisponible

Un rechazo normal debe conservar o restablecer su estado de origen seguro. Usar NoDisponible en exceso oculta si el control del jugador o del vehículo podía recuperarse de inmediato.

Dar a un reintento un destino arbitrario

Un reintento desde NoDisponible no debe conceder automáticamente el control al jugador ni iniciar una entrada al vehículo. Primero debe validar un destino de recuperación concreto y confirmar ese estado estable.

854. Práctica guiada

Crea un diagrama de estados de posesión y una tabla de decisiones para un jugador y un vehículo. Puedes usar papel, un editor de texto o una herramienta de diagramación; no necesitas escribir código.

Paso 1: Define los cinco estados

Incluye JugadorControlado, Entrando, VehículoControlado, Saliendo y NoDisponible. Para cada estado, indica:

• quién decide una transición;
• quién recibe las señales de control de movimiento;
• si el movimiento está bloqueado;
• qué invariante debe cumplirse.

Paso 2: Dibuja las transferencias normales

Representa la entrada como JugadorControlado -> Entrando -> VehículoControlado y la salida como VehículoControlado -> Saliendo -> JugadorControlado. Etiqueta cada flecha con la solicitud o evento, la precondición, la autoridad, la regla de control de movimiento y la ruta de fallo o recuperación.

Paso 3: Añade rutas deterministas de rechazo e interrupción

Muestra que:

• una entrada rechazada permanece o vuelve a JugadorControlado si el control del jugador sigue siendo seguro;
• un destino de salida inválido conserva VehículoControlado si la posesión sigue siendo segura;
• solo se llega a NoDisponible cuando no puede verificarse ninguna recuperación estable;
• NoDisponible tiene flechas de recuperación separadas y validadas hacia JugadorControlado y VehículoControlado.

Añade al menos tres interrupciones, incluida una durante la entrada y otra durante la salida.

Paso 4: Marca estados inválidos

Identifica al menos cinco combinaciones inválidas y asocia cada una con una invariante preventiva. Incluye:

• el jugador y el vehículo reciben señales de movimiento a la vez;
• ninguna entidad recibe señales después de confirmar una transición estable;
• la presentación contradice el estado autoritativo de posesión;
• la salida se confirma sin un destino válido;
• NoDisponible concede autoridad de movimiento;
• una recuperación concede autoridad antes de completar la validación.

Paso 5: Completa dos trazas o más

Como mínimo, traza:

1. una entrada correcta seguida de una salida correcta;
2. una salida fallida por un destino bloqueado.

Para una cobertura más sólida, traza también una entrada interrumpida que vuelva a JugadorControlado y una interrupción excepcional que pase por NoDisponible antes de recuperar un estado estable verificado.

En cada traza, registra el estado inicial, el evento, el resultado de la precondición, la autoridad que decide, la regla de control de movimiento, el estado de destino y la invariante relevante.

855. Validación y evidencia

856. Ideas clave

• La posesión es una transferencia de autoridad, no solo un efecto visual.
• Los estados estables tienen exactamente una autoridad sobre el movimiento.
• Los estados transitorios y NoDisponible bloquean el movimiento bajo un único coordinador.
• Un fallo normal restablece o conserva su estado de origen seguro.
• NoDisponible se reserva para casos en los que no puede verificarse ninguna recuperación estable habitual.
• La recuperación desde NoDisponible debe validar y confirmar explícitamente un estado estable antes de comenzar otra solicitud.

857. Siguiente lección

Continúa con 2.12 L3 — Llegar es un contrato, no una estimación de distancia.

858. Comprobación