JavaScript协程实战：用生成器简化游戏逻辑与状态机管理

图 0：JavaScript 生成器协程在游戏主循环中的运转机制概览

一、为什么传统每帧状态机在复杂时序中变得脆弱

在标准的逐帧游戏引擎循环中，游戏实体每秒都会执行几十次 update(dt)。当我们需要实现一个包含先后依赖的动作序列时，传统有限状态机面临着结构性困境：

图 1：传统 Update 轮询状态机与生成器协程在控制流上的关键差异

1. 关键差异：状态外露与碎片化

为了解释两种方案的关键差异，我们以一段典型的敌人受击后反击逻辑为例：在一致的前提下（都需要在游戏时间被暂停或缩放时正常响应），传统状态机必须将所有瞬时数据提升为实例属性：

• 传统每帧轮询：需要显式定义 state = 'PRE_CAST'、castTimer = 0.8、hasTriggeredHit = false、recoveryTimer = 1.2。在每一帧的 update 中，开发者需要编写庞大的 switch-case 分支，手动递减计数器并在多个分支间倒腾状态。一旦策划调整时序（如增加0.3秒前摇），所有关联的状态枚举和清理逻辑都需要修改。
• 生成器协程：函数本身就是一个状态机。函数的局部变量天然受到闭包保护，代码按照自然时间线自上而下书写，遇到需要等待外部条件的地方使用 yield 交出执行权，等待满足条件后再无缝恢复。

二、核心机制：用 Generator 实现轻量级协程调度器

生成器函数（function*）在执行时并不会立即跑完全部逻辑，而是返回一个迭代器对象。每次调用 next()，函数会执行到下一个 yield 表达式处暂停，并向调用方返回产出值。

利用这个特性，我们可以编写一个只有几十行代码的轻量级 CoroutineRunner。生成器内部产出“等待指令（Yield Instruction）”，调度器在游戏主循环的 update(dt) 中评估这些指令，当且仅当条件满足时调用 next() 唤醒函数。

图 2：CoroutineRunner 协程调度器帧循环处理与指令判定步骤

1. 等待指令设计（Yield Instructions）

为了让协程具有丰富的时序表达能力，我们设计三种基础等待指令：

1. waitForSeconds(seconds)：等待指定的逻辑秒数（支持暂停与变速）。
2. waitUntil(predicate)：每帧检测回调函数，直到返回 true。
3. waitForCoroutine(childRoutine)：等待另一个子协程全部执行完毕（支持嵌套组合）。

// 基础指令封装
export const Coroutine = {
  waitForSeconds: (seconds) => ({ type: 'WAIT_TIME', remaining: seconds }),
  waitUntil: (predicate) => ({ type: 'WAIT_UNTIL', predicate }),
  waitForCoroutine: (routine) => ({ type: 'WAIT_ROUTINE', routine }),
  nextFrame: () => ({ type: 'NEXT_FRAME' })
};

2. 协程调度器完整实现

以下是用于游戏环境的完整调度器实现。它直接支持添加、每帧轮询、异常捕获与提前打断：

export class CoroutineRunner {
  constructor() {
    this.tasks = [];
  }

  /**
   * 启动一个协程
   * @param {Generator} generatorInstance 
   * @returns {Object} 控制句柄（支持 stop）
   */
  start(generatorInstance) {
    const task = {
      gen: generatorInstance,
      currentInstruction: null,
      isDone: false
    };

    // 首次步进，执行至第一个 yield
    this._stepTask(task, 0);
    if (!task.isDone) {
      this.tasks.push(task);
    }

    return {
      stop: () => {
        if (!task.isDone) {
          task.isDone = true;
          // 触发 finally 清理块
          if (typeof task.gen.return === 'function') {
            task.gen.return();
          }
        }
      }
    };
  }

  /**
   * 在游戏主循环每帧调用
   * @param {number} dt 增量时间（秒）
   */
  update(dt) {
    for (let i = this.tasks.length - 1; i >= 0; i--) {
      const task = this.tasks[i];
      if (task.isDone) {
        this.tasks.splice(i, 1);
        continue;
      }

      const ins = task.currentInstruction;
      let readyToStep = false;

      if (!ins || ins.type === 'NEXT_FRAME') {
        readyToStep = true;
      } else if (ins.type === 'WAIT_TIME') {
        ins.remaining -= dt;
        if (ins.remaining <= 0) readyToStep = true;
      } else if (ins.type === 'WAIT_UNTIL') {
        if (ins.predicate()) readyToStep = true;
      } else if (ins.type === 'WAIT_ROUTINE') {
        if (ins.routineHandle.isDone) readyToStep = true;
      }

      if (readyToStep) {
        this._stepTask(task, dt);
        if (task.isDone) {
          this.tasks.splice(i, 1);
        }
      }
    }
  }

  _stepTask(task, dt) {
    try {
      const res = task.gen.next(dt);
      if (res.done) {
        task.isDone = true;
      } else {
        const val = res.value;
        if (val && val.type === 'WAIT_ROUTINE') {
          // 处理子协程嵌套
          val.routineHandle = this.start(val.routine);
        }
        task.currentInstruction = val;
      }
    } catch (err) {
      console.error('[CoroutineRunner] 协程执行异常:', err);
      task.isDone = true;
    }
  }
}

三、实战案例：NPC 战斗与巡逻时序编排

为了验证协程在实际游戏中的优势，我们来看一个包含“巡逻 -> 发现警觉 -> 冲锋 -> 蓄力攻击 -> 疲惫后摇”的完整敌人 AI 流程。

图 3：NPC 多阶段行为在单一生成器协程中的平滑时态流动

1. 编写内聚的行为序列函数

采用协程后，这段复杂的跨帧逻辑只需要写成一个直白的 function*：

function* enemyAiBehavior(enemy, player, runner) {
  while (!enemy.isDead) {
    // 阶段 1：巡逻，直到玩家进入 200 像素警戒范围
    enemy.playAnimation('walk');
    yield Coroutine.waitUntil(() => {
      enemy.patrolAlongWaypoints();
      return enemy.distanceTo(player) < 200;
    });

    // 阶段 2：发现警觉，原地定格硬直 0.5 秒
    enemy.showExclamationMark();
    enemy.stopMovement();
    yield Coroutine.waitForSeconds(0.5);
    enemy.hideExclamationMark();

    // 阶段 3：加速冲锋，直到接近到近战攻击距离（40 像素）
    enemy.playAnimation('run');
    yield Coroutine.waitUntil(() => {
      enemy.moveTowards(player.x, player.y, 150);
      return enemy.distanceTo(player) <= 40;
    });

    // 阶段 4：蓄力攻击动作与命中判定
    try {
      enemy.playAnimation('slash_prepare');
      yield Coroutine.waitForSeconds(0.4); // 前摇

      // 判定伤害
      if (enemy.distanceTo(player) <= 50) {
        player.takeDamage(enemy.attackPower);
      }

      // 阶段 5：攻击后摇（硬直 1.2 秒），期间可被玩家打断
      enemy.playAnimation('slash_recover');
      yield Coroutine.waitForSeconds(1.2);
    } finally {
      // 若中途被玩家冰冻/眩晕打断，确保速度与状态正确重置
      enemy.resetModifiers();
    }
  }
}

四、状态机改造：用协程管理复合分层状态

在实际项目架构中，协程并非用来完全替代状态机，而是作为状态机内部状态的“长任务执行引擎”。

1. 分层结合的最佳形态

顶级状态（如：IdleState、CombatState、DeadState）依然由有限状态机负责调度；而在某一个具体状态（如 CombatState）的 enter() 钩子中，我们启动一个专职协程。当状态机发生顶级切换调用 exit() 时，直接终止该协程句柄：

class CombatState {
  enter(owner, runner) {
    this.routineHandle = runner.start(combatSequence(owner));
  }

  exit(owner) {
    // 离开战斗状态时，立即打断内部协程
    if (this.routineHandle) {
      this.routineHandle.stop();
    }
  }
}

2. 中断与 finally 清理保证

JavaScript 迭代器的 return() 方法规范规定：当外部主动调用迭代器的 return() 时，正在挂起的生成器内部会立即跳转到当前的 finally 块中执行清理代码，然后再结束函数。这为游戏中的突发打断（例如击飞、死亡、施法打断）提供了语言级别的安全防护，杜绝特效残留或速度计算未复位的 Bug。

五、技术选型与性能权衡

在 JavaScript 生态中，提到异步很多开发者第一反应是 async/await。然而在严格的游戏主循环中，async/await 存在根本性的机制缺陷：

图 4：Generator 协程、Promise 微任务与传统 FSM 的技术决策路线

1. 为什么游戏逻辑不能使用 async/await？

async/await 基于 ECMAScript 的微任务（Microtask）与 Promise。微任务的执行是由 JavaScript 引擎事件循环自动排队的，外界无法随心所欲地控制微任务的步进时间。

• 时间步脱节：游戏需要支持慢动作（0.5倍速）、快进（2倍速）或单帧暂停（用于调试）。Promise 依赖真实系统时钟（setTimeout），完全脱离了游戏逻辑时钟 dt。
• 不可取消性：原生 Promise 无法从外部安全、同步且立即地终止。若一个实体在等待 3 秒后被删除，3 秒后 Promise resolve 仍然会触发回调，极易引发访问已销毁实体的空指针报错。
• 帧同步控制：生成器由调度器主动调用 gen.next(dt)，调度器说前进一帧才前进一帧，完全受控于主循环。

2. 垃圾回收（GC）与对象池考量

六、实践总结

通过 ES6 生成器实现游戏协程，我们获得了如下确定性的开发收益：

1. 线性顺序代码：将原本散落在不同帧轮询中的碎片化代码归并至单一上下文，大幅降低逻辑推演和后期维护的心智负担。
2. 精准的帧时间步掌控：与游戏主循环无缝集成，天然支持暂停、变速、倒放与帧调试。
3. 健壮的生命周期闭环：依托 try...finally 语言特性与外部 return() 打断，杜绝状态残留与悬挂计时器。

在实际工程中，建议将“宏观离散状态”交由有限状态机（FSM）或行为树管理，而将“微观持续性动作序列与时序编排”交由 Generator 协程处理。两者优势互补，能够兼顾架构的清晰度与极端场景的鲁棒性。