跳到主要内容

关卡与配置：规则相同，数据不同

第一关 30 秒拿 200 分，第二关 25 秒拿 250 分。玩法相同，变化的是参数。把参数抽成数据，通常比复制一整个场景更容易维护。

关卡从准备进入游玩，再结算；重玩先重置数据
关卡从准备进入游玩，再结算；重玩先重置数据（概念演示，非引擎录屏）

先做最小配置​

type LevelConfig = {
  id: number;
  durationSeconds: number;
  goalScore: number;
};

const levels: readonly LevelConfig[] = [
  { id: 1, durationSeconds: 30, goalScore: 200 },
  { id: 2, durationSeconds: 25, goalScore: 250 },
];

这个规则片段可以放到独立 LevelConfig.ts。闭环脚本目前使用检查器参数，便于先验证。扩展时增加“开始指定关卡”的入口，从配置读取参数并统一重置，不需要为每关写一套计时逻辑。

配置读取之后还要校验​

外部 JSON 不是因为加上 TypeScript 类型就自动可信。检查 id 唯一、时间为正、积分目标有效、资源引用存在。无效配置应阻止开始，并显示可定位的错误，而不是运行到一半才失败。

下一关不一定需要切场景​

如果只是目标分数和背景变化，在同一场景里重置可能最简单。如果加载完全不同的地图与相机结构，切场景可能更清楚。不要按“有多少关就建多少场景”机械组织。

切场景时，director.loadScene 不是一个表示加载完成的 Promise。应检查启动返回值并在完成回调里处理错误；场景也要纳入构建配置。预加载不等于已经切换。

需要明确的边界​

最后一关通过后怎样显示？失败会不会消耗体力？重开是否同一随机种子？资源加载中能否返回菜单？这些决定会改变状态与数据，不是最后补个按钮就能解决。

给 AI：“保留一套玩法脚本，用配置描述时间和目标。先验证配置，加载失败不进入游玩。提供第一关、最后一关、缺失配置、连点下一关四类验收步骤。”

依据：场景管理、资源加载。