概念页
专用服务器
Dedicated Server
UE 多人游戏采用客户端-服务器模型。监听服务器 (listen server) 由某个玩家的客户端兼任服务器;专用服务器 (dedicated server) 无头运行,不渲染画面,也没有本地玩家。专用服务器体积更小、房主没有不公平优势、能专注于玩法逻辑,适合大规模或竞技游戏。构建专用服务器需要源码版引擎和支持客户端-服务器的 C++ 项目,并要有
监听服务器 vs 专用服务器
| 监听服务器 | 专用服务器 | |
|---|---|---|
| 谁当服务器 | 某个玩家的客户端 | 独立进程,无头运行 |
| 渲染 | 有(房主在玩) | 不渲染任何画面,没有本地玩家 |
| 公平性 | 房主有优势 | 房主没有不公平优势 |
| 适用 | 休闲多人、合作 | 大规模或竞技游戏 |
(Setting Up Dedicated Servers in Unreal Engine)专用服务器的其他优势:体积更小,专注于玩法逻辑和对客户端信息的仲裁。服务器的权威地位与复制规则见 网络复制与 RPC。
构建流程(官方教程以 Lyra 为例)
flowchart LR A["源码版引擎<br/>+ C++ 客户端-服务器项目"] --> B["添加 项目名Server.Target.cs<br/>(参考 LyraServer.Target.cs)"] B --> C["VS 中选 Development Server 配置编译"] C --> D["Binaries/Win64/项目名Server.exe"] D --> E["烘焙服务器内容、启动服务器<br/>客户端连接测试"]
图中依次是:准备源码引擎和项目、添加服务器 Target、编译、得到服务器可执行文件、烘焙并联机测试。
- 必须使用源码版引擎,以及支持客户端-服务器多人玩法的 C++ 项目。(Setting Up Dedicated Servers in Unreal Engine)服务器 Target 文件属于构建系统,见 模块、插件与构建系统;烘焙与打包见 烘焙、打包与 Zen 加载器(Cook 的平台列表里有 WindowsServer 和 LinuxServer)。
- 教程中先把 Server Default Map 设为 L_Expanse,让客户端直接进地图而不是 Lyra 主菜单。(Setting Up Dedicated Servers in Unreal Engine)
实践
- 服务器 CPU 是大规模多人游戏的主要瓶颈之一,Actor 数量很多时考虑 复制图。
- 移动纠正、预测都是在服务器权威的前提下设计的,见 角色移动组件与 Mover。
出处
相关页面
游戏开发UDP 与游戏协议设计UDP & Game Protocol Design动作游戏的时间关键数据(输入、位姿、物理)只关心最新状态。TCP 的可靠有序流会在丢包时把头阻塞住;正确做法是游戏协议只走 UDP,自己做虚拟连接、按需可靠性与拥塞退避,并按数据类型选择「冗余重发」还是「直接丢弃旧包」。游戏开发延迟补偿Lag Compensation服务器在执行玩家开火等用户命令前,把其他玩家(及必要状态)回拨到「该命令在客户端生成时」所对应的世界时刻——扣除包延迟与客户端视图插值——再做命中判定,然后恢复。这样玩家可以对着自己屏幕上看到的目标直接开火,而不必凭感觉提前量;代价是可能出现「拐角后仍被击中」等时间悖论。游戏开发多人网络游戏模型Multiplayer Networking Models多人游戏并不是共享同一份物理现实,而是每位玩家各自看到的近似。历史上主要两条路:对等锁步 (Peer-to-Peer Lockstep)(RTS 仍常用)与权威客户端/服务器 (Authoritative Client/Server)(动作/FPS 主流);后者再叠加客户端预测、插值与延迟补偿,把延迟藏进体验里。游戏开发 · UE5网络复制与 RPCNetwork Replication & RPCUE 采用服务器权威 (Server-Authoritative) 的客户端-服务器模型:游戏真正在服务器上进行,服务器把状态复制 (Replication) 给客户端,客户端通过远程过程调用 (Remote Procedure Call, RPC) 向服务器请求操作。开发者需要显式声明哪些 Actor、属性、函数要走网络,并借助所有权、网络角色、相关性、优先级控制“发给谁、发多少”。UE 5.8 提供通用复制系统、Replication Graph 和实验性的 Iris 三套复制系统。游戏开发 · UE5复制图Replication Graph复制图 (Replication Graph) 插件解决的是服务器 CPU 瓶颈:标准做法是让每个复制 Actor 对每个连接各自判断是否需要发送,玩家和 Actor 一多(Fortnite 大逃杀开局有 100 名玩家、约 5 万个复制 Actor)就撑不住。复制图由持久存在的节点组成,按空间网格、休眠、常驻相关等规则预先分组,并缓存可跨帧、跨连接共享的复制列表。游戏开发 · UE5烘焙、打包与 Zen 加载器Cooking, Packaging & Zen Loader打包是一组构建操作:编译 (Build) → 烘焙 (Cook,把资产转成目标平台格式) → 暂存 (Stage) → 打包 (Package) → 可选的部署 (Deploy)。UE5 的运行时加载器 Zen Loader 会在暂存阶段离线算好包与对象的依赖图,并把数据装进 .utoc/.ucas 容器(IoStore),由 I/O 分发器以很低的 CPU 开销定位数据块;.pak 只用于不常访问的零散文件。游戏开发 · UE5模块、插件与构建系统Modules, Plugins & Build SystemUE 的代码由模块 (Module) 组成:每个模块是一个独立编译单元,用 [模块名].Build.cs 声明依赖。插件 (Plugin) 是可按项目启用/禁用的代码与内容集合,用 .uplugin 描述,可包含多个模块。虚幻构建工具 (UnrealBuildTool, UBT) 根据 .Target.cs 和 .Build.cs(而不是 IDE 的 .sln)编译,默认把模块编成 DLL 由一个可执行文件加载,也可整体链接成单体 (Monolithic) 可执行文件。游戏开发 · UE5角色移动组件与 MoverCharacter Movement Component & Mover角色移动组件 (CMC) 用「客户端预测 + 服务器校验 + 纠正后重放」实现联网移动:自主代理先在本地移动并把操作存起来,用 ServerMove RPC 发给服务器重演,位置不符时服务器用 ClientAdjustPosition 纠正,客户端再按保存的操作重放;模拟代理只应用复制下来的移动并做平滑。实验性插件 Mover 计划接替 CMC,改用共享时间线、回滚与重模拟的模型,并且更模块化。游戏开发 · UE5在线子系统与 EOSOnline Subsystem & EOSOnline Subsystem (OSS) 是 UE 访问 Steam、Xbox Live、Epic 等在线服务的统一抽象:按功能分成身份 (Identity)、会话 (Session)、好友、成就等接口,所有远程操作都是异步的,用委托回调。UE 5.1 起新增了 Online Services 插件(5.8 中仍为 Beta),返回 TOnlineAsyncOpHandle 句柄。Epic Online Services 通过 OSS EOS 插件接入;在 Steam 等其他平台发行时,可以再叠加 EOS Plus 插件。