Unreal gameplay framework: place rules, shared state and possession deliberately
本文尚无中文版本;显示原文。
Separate server rules, replicated match information, player control and the possessed body so respawning and multiplayer do not mix their responsibilities.
目录
Choose ownership before a class
A multiplayer feature often fails because a value is stored in an object with the wrong lifetime or visibility. Before choosing a framework class, ask three questions: who decides the value, who needs to observe it and what event should reset it? These questions are more useful than placing all convenient references in the first Blueprint that can find them.
Rules and shared information
GameMode defines game rules and exists on the server in multiplayer. GameState carries replicated information about the match to clients. [1] Use this separation to distinguish a decision from its published result. A client-facing display should read the information intended for it, rather than trying to inspect the server’s rule object.
Control and the current body
PlayerController controls a Pawn. In network play, a player’s controller exists on the server and the owning client, not on every other client. [2] Possession links a controller to its current pawn, and Possess runs on network authority. [3] Treat a body change as an explicit transition with cleanup and initialisation, not merely assignment of a camera target.
Example: a cooperative rescue mission
Imagine a mission in which players rescue stranded workers, then operate remote drones. Let the server’s mission rules decide whether a rescue is valid. Publish the shared rescued-worker count through appropriately replicated match state. Keep walking movement and physical interactions with the walking pawn; put drone movement with the drone pawn. When a player requests drone control, validate the request on the authoritative side, perform the possession transition and update local input and presentation when the new controlled body becomes available. On drone destruction, choose a defined return or respawn path. The shared rescue count should survive that body replacement because it belongs to the mission. This is an illustrative responsibility split, not a complete networking implementation.
Limits and verification
Selecting a framework class does not automatically replicate every custom property or validate every client request. Specify replication and authority checks for the feature itself. Avoid assuming the pawn is always present during connection, respawn or possession changes. Test a dedicated server with two clients, including one player observing the other’s drone transition. Also test a late join and destruction during a control request. Check that shared information reaches both clients, local interface state stays with the intended player, and transient body state resets without resetting mission progress.
Sources
- Game Mode and Game State — Epic Games.
- APlayerController — Epic Games.
- AController::Possess — Epic Games.
范围与依据
Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.
知识截至:2026-10-11。状态:unreviewed(无已记录的审阅)——编辑会重置审阅状态。请将文本视为未经核实的参考资料并核对来源。
来源
- Game Mode and Game State — Epic Games — 2026-10-12 已检查:可访问
- APlayerController — Epic Games — 2026-10-11 已检查:可访问
- AController::Possess — Epic Games — 2026-10-11 已检查:可访问
署名与许可
- Account Elara — Machine Learning (d44cc702)
- Original AI-assisted synthesis by Elara (OpenAI ChatGPT); primary sources credited separately.
最近更改: Original source-based game-development article.
原创贡献: CC BY 4.0. 链接的来源资料保留其自身权利。