《游戏服务端编程实践》1.1.2 客户端与服务端的职责划分

一、前言：分层协作是现代游戏架构的根基

在网络游戏中，客户端与服务端共同构成了一个“分布式系统”。
两者之间通过协议进行通信，承担不同职责：

• 客户端（Client）：面向玩家，负责交互与表现；
• 服务端（Server）：面向世界，负责逻辑与权威。

这种模式与“浏览器 + 后端 API”的关系类似，但在游戏中更复杂，
因为它不仅要处理数据，还要处理实时同步、状态预测、时序一致性等问题。

游戏客户端与服务端的划分，本质是“性能与安全的平衡艺术”。

二、宏观层面：职责分工的三大原则

这三个原则是所有网络游戏的底层设计指南，无论是 MMO、SLG、MOBA 还是 FPS。

三、层次化职责结构

游戏通常可以被划分为四个逻辑层：

graph TD
A[玩家输入] --> B[客户端表现层]
B --> C[网络通信层（Client→Server）]
C --> D[逻辑层（Server）]
D --> E[数据层（Database）]
E --> F[状态同步回客户端]

四、客户端职责详解

客户端的职责集中在“玩家体验”相关的部分：

4.1 视觉表现与交互反馈

• 负责图形渲染（2D/3D）；
• 播放动画、音效、特效；
• 响应输入事件（键盘、触控、手柄）；
• 展示即时反馈（血量条闪烁、命中音效）。

目标：低延迟响应 + 高沉浸感。

例如：
当玩家点击“攻击”按钮时，客户端立即播放攻击动作、特效；
同时异步发送“攻击请求”到服务器等待确认。

4.2 客户端预测（Client-side Prediction）

客户端为了“看起来更流畅”，会先假设服务器一定会批准操作。
这称为 预测执行。

示例：角色移动预测

// 客户端本地预测
player.position += direction * speed * deltaTime;
sendToServer("move", player.position);

同时，服务器接收到消息后：

// 服务端确认
if (validateMove(player)) {
    player.position = newPos;
    broadcastToOthers(player.id, newPos);
}

如果预测错误（例如服务器判定碰撞或越界），则客户端会被校正（Reconciliation）。

预测 + 校正机制 是 FPS、MOBA、开放世界类游戏的核心技术之一。

4.3 界面逻辑与本地缓存

客户端还负责：

• UI 状态机（登录、匹配、战斗界面切换）；
• 本地缓存（用户配置、资源、离线存档）；
• 异步加载（动态资源 Streaming）；
• 游戏脚本逻辑（如 Lua 控制 UI 动画）。

4.4 离线模式与延迟容忍

优秀的客户端架构往往具备“延迟容忍”能力：

• 当网络延迟高时，仍能本地响应；
• 离线状态下仍能进行部分体验（如剧情模式、练习场）。

实现方式：

• 本地模拟部分服务端逻辑；
• 使用缓存或假数据填充；
• 等网络恢复后同步。

五、服务端职责详解

服务端是“游戏世界的真理中心（Source of Truth）”，它管理一切可以改变游戏状态的逻辑。

5.1 权威逻辑（Authoritative Logic）

服务器的逻辑包括但不限于：

任何会影响全局状态的计算，必须在服务器端完成。

5.2 权限控制与防作弊

服务器必须拒绝来自客户端的“强制命令”：

• “我打死了对方” → ❌ 无效；
• “我获得了 1000 金币” → ❌ 无效；
• “我进入地图 BOSS 房间” → ✅ 验证后允许。

服务端始终以“逻辑验证”为核心：

if (attack.distance > weapon.getRange()) {
    reject("too far");
}

5.3 状态存储与持久化

服务端负责维护游戏状态：

• 玩家基本信息；
• 世界状态；
• 物品与装备；
• 任务进度。

常用数据存储体系：

5.4 广播与同步机制

服务端的另一个关键职责是同步状态：
当某个玩家状态改变时，服务器需要通知相关玩家。

func BroadcastToRoom(roomID string, msg Message) {
    for _, player := range Rooms[roomID].Players {
        player.Conn.WriteJSON(msg)
    }
}

同步设计的关键点：

• 范围限制（只同步必要玩家）；
• 节流（限制同步频率）；
• 压缩与合并（节省带宽）。

5.5 定时与事件系统

服务器负责：

• Buff 持续时间；
• 副本倒计时；
• 世界事件触发；
• 定时刷新任务/怪物。

因为客户端可能掉线或修改时间，
所有“时间逻辑”都必须在服务端驱动。

六、典型分工结构：客户端 vs 服务端职责表

七、分工图示

graph LR
A[Client] -->|输入指令| B[Server]
B -->|逻辑判定| C[Database]
B -->|状态结果| A
A -->|表现与动画| A

客户端负责“看起来像游戏”，
服务端负责“确保它真的在发生”。

八、案例分析

案例一：MOBA（如《王者荣耀》）

• 客户端：即时响应（技能、走位、动画、击中特效）；
• 服务端：技能冷却、命中检测、战斗结算、经济平衡；
• 同步模式：帧同步（Frame Sync） + 状态回滚。

案例二：SLG 策略游戏

• 客户端：界面渲染、指令发送、结果展示；
• 服务端：计算建造、战斗结果、资源产出；
• 通信模式：异步命令队列（Command Queue）。

SLG 的本质是一个异步状态机，客户端只是显示终端。

案例三：MMORPG

• 客户端：表现层（动画、技能释放、UI）；
• 服务端：世界模拟（地图、NPC、任务、交易）；
• 通信模型：分区服 / 区域同步（Region Sync）。

案例四：FPS / 射击类

• 客户端：本地预测（移动、瞄准）；
• 服务端：逻辑仲裁（命中检测、死亡判定）；
• 机制：预测 + 回滚（Prediction & Reconciliation）。

九、Go + Java 混合实践：职责落地示例

在现代大型游戏架构中，常采用多语言分层：

graph TD
C["Client"] --> G["Gateway(Go)"]
G --> J["Logic Service(Java)"]
J --> DB["MySQL"]

这种混合架构可以兼顾：

• Go 的高并发；
• Java 的复杂业务逻辑；
• 客户端的即时响应。

十、设计启示：保持边界清晰

在游戏项目中，最常见的架构灾难就是：

“逻辑分布在前后端之间，没有明确权威边界。”

结果会导致：

• 调试困难；
• 作弊漏洞；
• 状态不一致；
• 开发效率下降。

良好的设计应该是：

十一、总结

游戏的灵魂在玩法，
而玩法的秩序来自“客户端与服务端的边界”。

服务器确保公平、持续、稳定；
客户端确保流畅、沉浸、即时。

两者既相互独立，又彼此依赖。
这种分工协作构成了现代游戏最稳固的基础。