Framework de juego de Unreal: ubicar con criterio las reglas, el estado compartido y la posesión

Decidir la propiedad antes de elegir una clase

Una función multijugador suele fallar porque un valor se guarda en un objeto con un ciclo de vida o una visibilidad inadecuados. Antes de elegir una clase del framework, conviene responder tres preguntas: quién decide el valor, quién necesita observarlo y qué evento debe reiniciarlo. Estas preguntas resultan más útiles que reunir todas las referencias cómodas en el primer Blueprint que pueda alcanzarlas.

Reglas e información compartida

GameMode define las reglas del juego y, en multijugador, existe en el servidor. GameState transmite a los clientes información replicada sobre la partida. [1] Esta separación sirve para distinguir una decisión de su resultado publicado. Una interfaz orientada al cliente debe leer la información que se ha previsto para ella, en lugar de intentar inspeccionar el objeto de reglas del servidor.

Control y cuerpo actual

PlayerController controla un Pawn. En juego en red, el controlador de un jugador existe en el servidor y en el cliente propietario, pero no en los demás clientes. [2] La posesión vincula un controlador con su pawn actual, y Possess se ejecuta con autoridad de red. [3] Conviene tratar el cambio de cuerpo como una transición explícita, con limpieza e inicialización, y no como una simple asignación del objetivo de la cámara.

Ejemplo: una misión de rescate cooperativa

Imagina una misión en la que los jugadores rescatan a trabajadores atrapados y después manejan drones a distancia. Que las reglas de la misión en el servidor decidan si un rescate es válido. El recuento compartido de trabajadores rescatados se publica mediante un estado de partida replicado de forma adecuada. El movimiento a pie y las interacciones físicas se mantienen en el pawn de a pie; el movimiento del dron, en el pawn del dron. Cuando un jugador solicita controlar un dron, se valida la solicitud en el lado con autoridad, se realiza la transición de posesión y se actualizan la entrada y la presentación locales cuando el nuevo cuerpo controlado está disponible. Si el dron es destruido, se elige una vía definida de retorno o reaparición. El recuento de rescates compartido debe sobrevivir a ese reemplazo de cuerpo, porque pertenece a la misión. Esto es un reparto de responsabilidades ilustrativo, no una implementación de red completa.

Límites y verificación

Elegir una clase del framework no replica automáticamente cada propiedad personalizada ni valida cada solicitud de un cliente. Hay que especificar la replicación y las comprobaciones de autoridad para la función concreta. Conviene no asumir que el pawn siempre está presente durante la conexión, la reaparición o los cambios de posesión. Prueba con un servidor dedicado y dos clientes, incluyendo el caso de un jugador que observa la transición al dron del otro. Prueba también una incorporación tardía y una destrucción durante una solicitud de control. Comprueba que la información compartida llega a ambos clientes, que el estado de la interfaz local permanece con el jugador correspondiente y que el estado transitorio del cuerpo se reinicia sin reiniciar el progreso de la misión.

Fuentes

1. Game Mode and Game State — Epic Games.
2. APlayerController — Epic Games.
3. AController::Possess — Epic Games.