帧同步的一些思考（五）：战斗结果验证

常见的验证方案

一般有以下 2 种方法：

1. apk 包加壳

   • 好处是，通用方案，不需要考虑具体项目细节
   • 坏处是，专业性太强，加壳是否可行未知（本人）

2. 服务器端验证

   • 1 个玩家，服务器端跑战斗逻辑，做验证
   • 2 个及以上玩家，服务器端比对结果或跑战斗逻辑，做验证

下面针对 服务器端验证 来分析下做法、是否可行

先分析下原理

验证原理 - 1 个玩家

验证原理 - 多个玩家

验证原理 - 时序图分析

以上流程图简化了一些细节，实际情况要稍微复杂一点：

• 至少涉及 2 个服务器：

  • 业务服（名称很多，如大厅服）
  • 验证服

• 最多会涉及到 3 个服务器：

  • 业务服（名称很多，如大厅服）
  • 验证服
  • 房间服

• 实际上会有 3 种情况有特殊处理代码

  • PVE 。走验证原理 - 1 个玩家
  • PVP
    • 玩家数只有 1 个。 匹配返回后，走验证原理 - 1 个玩家
    • 玩家数有多个。匹配，并房间中战斗结束。走的是验证原理 - 多个玩家

具体实现时，需要细化时序图。避免多服务器交互某些时序上的问题！

从上面 2 张时序图中，理论上可以得出，从流程上是可行的。

原因如下：

• 战斗初始数据 服务器只依赖系统、服务器端的数据：
  • 服务器端确定，随机数种子
  • 服务器端确定，场景等信息
  • 服务器端确定，玩家数据、英雄数据
• 战斗指令序列 造假也无所谓
  • 验证原理 - 多个玩家 房间服上有，无法造假
  • PVE 情况，是客户端上传该数据
    • 玩家数据、英雄数据是服务器端的，每个账号都不一样。造假的战斗指令序列是很难预测战斗结果的
    • 即使造假，也是玩家用自己的玩家数据、英雄数据打过的
    • PVE 下通常会做优化，只要某关卡通过一次，就假设该玩家都能通过（可极大减少验证次数）

下面再来考察下，实际情况下，需要注意的问题。

注意事项 - 时延

1. 战斗指令序列 数据量大小（PVE 、 PVP[1 玩家] 情况需要上发该数据）

   • 数据量太大必然上传数据延时会严重
   • 比如具体项目
     • 1 玩家
     • 1 帧 30 字节（空帧）
     • 1 秒 20 帧
     • 则 1 分钟会有 35 K （压缩后应该会更小些）
     • 则 5 分钟会有 175 K （压缩后应该会更小些）
   • 实际情况上传 10 - 200 K 数据会有多少延迟待检验
   • 可以做优化处理， PVE 下，某英雄通过的关卡未通过时，做下验证吧。可极大减少验证次数
   • 可以做优化处理，乐观信任客户端法则。客户端流畅显示本地结果，后台做发送数据给服务端处理

2. 服务器计算战斗逻辑的时间

   • 最好是微妙级别
   • 毫秒级别，则服务器压力会大些
   • 没实际验证，这是 1 个待检验点
   • 应该不会在这里成为不可行点吧，如果是代码质量可能有严重问题

注意事项 - CPU密集度

• 验证服必然会是 CPU 密集型服务
• 实际项目中，验证服必须是微服务
• 实际项目中，验证服必须有压测报告

注意事项 - 制作难易度

与 apk 包加壳比起来，显然每个帧同步项目都需要制作如下内容：

• 客户端独立战斗逻辑，并向服务器提供 .so 文件
• 服务器端需要对 PVE 逻辑上做调整
• 服务器端需要对匹配结果逻辑上做额外处理
• 服务器端需要对PVP结算逻辑上做调整
• 服务器端需要让房间服可以提供战斗指令序列数据

客户端工作量的难点在于，代码是否干净、封装合理；且起带头作用
服务器端工作量主要跑通流程，避免多服务器交互上的时序问题