浏览器恐龙游戏达到指定分数所需时长的服务端计算方法

核心规则前提 #

原版Chrome Dino（包括绝大多数未深度魔改的网页移植版）的分数、速度逻辑是完全硬编码的线性规则，没有随机加成、没有操作减速，是这套校验方案能成立的基础：

• 分数和游戏世界滚动距离严格绑定：世界每向前滚动固定像素数，对应加1分，和玩家跳、蹲等操作无关
• 滚动速度随分数提升线性增长，达到速度上限后保持匀速，全程没有随机变速
• 玩家的跳、蹲操作不会改变水平滚动速度，只要不触发碰撞死亡，分数增长速度只和当前滚动速度有关

理论最短耗时计算方法 #

不用做复杂的游戏逻辑复现，两种方法都能算出玩家达到指定分数的理论最短耗时（也就是全程零失误、无任何干扰、游戏满帧运行下的最快通关时间）：

方法1：公式计算 #

先从你部署的游戏源码里扒到固定常量（直接搜JS里的speed、score相关变量就能找到，别直接套网上的参数，不同魔改版本值不一样）：

• 初始滚动速度v0（单位：像素/帧，原版为6px/帧）
• 每100分的速度增量deltaV（原版为0.35px/帧每100分）
• 最大滚动速度vMax（原版为13px/帧，约在2000分左右触顶）
• 每1分对应的滚动像素pxPerScore（原版为100像素/分）
• 游戏固定帧率fps（原版为60帧/秒）

计算分两个阶段：

1. 提速阶段（分数s ≤ 触顶分数sMax = ((vMax - v0)/deltaV)*100）：速度随分数线性增长，用等差数列求和算总帧数，再除以帧率得到耗时
2. 匀速阶段（分数s > sMax）：超过触顶分数的部分，按最大速度算耗时，即额外耗时 = (s - sMax)*pxPerScore / vMax / fps

方法2：帧模拟计算（推荐，不容易出错） #

直接在服务端写个简单的循环模拟帧推进，不用推导公式，改对常量就能用，哪怕算到几万分数也只需要几毫秒，示例代码：

function calcMinTime(targetScore) {
  // 以下常量替换成你自己部署版本的实际值
  const INIT_SPEED = 6;
  const SPEED_STEP = 0.35;
  const MAX_SPEED = 13;
  const PX_PER_SCORE = 100;
  const FPS = 60;

  let currentScore = 0;
  let currentSpeed = INIT_SPEED;
  let totalFrames = 0;
  let scrolledPx = 0;

  while (currentScore < targetScore) {
    totalFrames++;
    scrolledPx += currentSpeed;
    currentScore = Math.floor(scrolledPx / PX_PER_SCORE);
    // 更新当前速度
    if (currentSpeed < MAX_SPEED) {
      currentSpeed = INIT_SPEED + Math.floor(currentScore / 100) * SPEED_STEP;
      currentSpeed = Math.min(currentSpeed, MAX_SPEED);
    }
  }
  return totalFrames / FPS; // 返回理论最短耗时，单位秒
}

服务端校验规则设计 #

算出来的最短耗时是理想状态下的极限值，实际玩家耗时会受浏览器掉帧、设备性能、启动缓冲等因素影响，需要设置合理的判定区间：

• 首先要求客户端上报的是游戏有效运行时长，不是打开页面的挂墙总时长：要扣除游戏暂停、切后台、死亡动画的时间，只统计游戏处于运行状态的累计时间
• 基础判定阈值：
  • 上传耗时 < 计算出的最短耗时 * 0.9：直接判定作弊，正常情况不可能比理论极限速度还快，留10%的余量是为了兼容客户端计时的微小误差
  • 上传耗时在「最短耗时0.9」到「最短耗时2」区间：判定为合法，正常玩家哪怕有轻微掉帧、操作停顿，耗时也不会超过最短耗时的2倍
  • 上传耗时 > 最短耗时*2：标记为可疑，可结合其他规则二次判定，不直接拦截
• 补充校验规则（防绕过）：
  • 要求客户端每累计100分就上报一次当前分数和对应分段耗时，服务端对每个分段单独做耗时校验，避免玩家开变速齿轮冲一段、停一段，把总耗时卡到合法区间
  • 100分以下的新手阶段不做严格校验，这个阶段游戏刚启动，速度爬升阶段误差大
  • 不要只靠这一个维度校验，客户端可以加基础的篡改检测（比如检测速度全局变量有没有被修改、开发者工具是否打开），服务端还可以校验分数上报的频率是否符合速度曲线

常见避坑点 #

• 一定要对齐自己部署版本的常量，不要直接抄原版的参数，很多魔改版本有加速道具、不同的速度曲线，参数不对会导致大量正常玩家被误判
• 容差下限不能松，上限可以根据实际测试调整，比如上线前先收集几十份正常玩家的游玩数据，看正常耗时的分布再调阈值
• 不要信任客户端上报的任何计算结果，所有常量、计算逻辑都要在服务端存一份，客户端只负责上报原始的分数、时间戳数据

内容的提问来源于stack exchange，提问作者Habs Andfs