Phaser 银河城能力门：地图标记、回访路径和进度状态

为什么这个系统值得单独设计

银河城游戏最迷人的时刻，是玩家拿到二段跳后突然想起两个小时前看过的高台。返回旧区域，越过原本过不去的缺口，发现新路线和隐藏 Boss。这个体验依赖能力门系统，而不是靠策划在地图上随手摆障碍。

能力门要同时服务关卡设计、玩家记忆、地图 UI、存档和进度统计。门不是一扇门，它可能是一段高墙、一片水域、一种机关、一种敌人护盾或一条黑暗通道。系统需要用统一的数据描述进入条件和反馈方式。 本文按实际项目会遇到的问题来拆，不停留在“能跑”的 Demo 层。重点会放在数据边界、状态流、玩家反馈、调试方式和后续维护成本上。Phaser 很适合快速做出手感，但越是能快速表现，越需要把规则层写清楚。

核心架构

flowchart TD
  N1["AbilityInventory"] --> N2["GateDefinition"]
  N2["GateDefinition"] --> N3["RegionGraph"]
  N3["RegionGraph"] --> N4["可达区域计算"]
  N4["可达区域计算"] --> N5["MapMarker"]
  N6["ProgressState"] --> N5["MapMarker"]
  N4["可达区域计算"] --> N7["HintResolver"]
  N7["HintResolver"] --> N8["Phaser UI"]

这套结构的原则是单向流动：输入或场景事件进入 AbilityInventory，核心模型完成计算，再由 Phaser 表现层消费结果。GateDefinition、RegionGraph、MapMarker、ProgressState、HintResolver 都应尽量保持可序列化、可测试、可回放。不要让某个 Tween 完成回调、某个 Sprite 是否可见、某个按钮是否高亮成为玩法事实。

能力门要用条件表达

不要把某扇门写成 if hasDoubleJump。GateDefinition 应支持条件组合：需要二段跳、冲刺或红色钥匙；需要击败某 Boss；需要水下呼吸等级至少 2。这样地图工具可以计算可达性，UI 可以显示缺少什么，测试也能覆盖不同进度。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

区域图帮助检查断路

把地图拆成 region，能力门连接 region。玩家获得新能力后，系统重新计算可达区域。开发工具可以立刻发现：某个关键区域永远不可达，某个高阶区域过早可达，或某条回访路线太绕。银河城关卡越大，RegionGraph 越重要。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

地图标记要区分看见和理解

玩家看到一堵高墙时，未必知道需要二段跳。地图可以先记录 unknownObstacle，获得二段跳后再把相关标记升级为 reachableWithNewAbility。这样系统既尊重探索，也能在后期给玩家合理提示。标记状态应进存档，而不是每次进房间重算。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

反馈要告诉玩家方向

能力不足时，门的反馈要具体但不剧透。水流把玩家推回、护盾弹开攻击、黑暗区域让视野缩小，这些都比简单显示不能进入更好。若玩家已经获得对应能力，反馈应消失或改变，避免旧提示误导。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

回访提示不能太吵

拿到新能力后，如果地图上所有相关点都闪烁，玩家会被信息淹没。HintResolver 可以按距离、奖励价值、主线相关度和玩家最近访问时间排序，只提示最值得回访的几个点。其余点保留在地图筛选里。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

存档记录能力和门状态

能力库存、已访问房间、已识别障碍、已打开永久门、临时机关状态都要分开保存。永久门一旦打开，不应因为玩家卸下能力或读取旧房间而关闭。临时机关则按区域重置或按存档恢复，规则要明确。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

调试工具要模拟进度

开发模式应能勾选任意能力，立即查看地图可达区域变化。关卡设计师可以用这个工具检查拿到冲刺前后路线是否合理。没有模拟工具，银河城项目很容易只凭记忆调关卡，后期会出现大量顺序破坏。

落地时可以先用最朴素的调试图形验证规则，再替换成正式美术。这个顺序很重要：如果规则层还没稳定就开始堆特效，后面每一次调参都会同时牵动动画、音效和 UI，问题会变得难以判断。

TypeScript 实现骨架

type Ability = "doubleJump" | "dash" | "swim" | "redKey";
interface Gate { id: string; from: string; to: string; requires: Ability[]; permanent?: boolean }
function canPass(gate: Gate, abilities: Set<Ability>) {
  return gate.requires.every(a => abilities.has(a));
}
function reachableRegions(start: string, gates: Gate[], abilities: Set<Ability>) {
  const reached = new Set<string>([start]);
  let changed = true;
  while (changed) {
    changed = false;
    for (const gate of gates) {
      if (reached.has(gate.from) && canPass(gate, abilities) && !reached.has(gate.to)) {
        reached.add(gate.to);
        changed = true;
      }
    }
  }
  return reached;
}
function newlyReachable(before: Set<string>, after: Set<string>) {
  return [...after].filter(region => !before.has(region));
}

这段代码不是完整框架，而是把关键边界先立出来。实际项目里应继续补上配置加载、错误码、事件派发、性能统计和单元测试。只要骨架保持清楚，后续接入 Phaser 的 Graphics、Sprite、Matter、Tilemap 或 Sound 都不会污染规则层。

具体落地步骤

1. 第一步，把 AbilityInventory 和 GateDefinition 从 Scene 中拆出来，写成可以直接用 TypeScript 调用的模型。这个模型只接收普通对象，不接收 Sprite、Camera 或 Tween。只要这一步做到，后面的测试、调试、存档和工具预览都会简单很多。
2. 第二步，在 Phaser Scene 里建立很薄的适配层。输入事件、物理回调、计时器和资源加载都可以在适配层发生，但它们只提交意图，不直接改核心状态。核心系统产出快照后，适配层再更新显示对象、音效、粒子和 HUD。
3. 第三步，给每个关键状态准备调试可视化。不要等 QA 报问题才补日志。开发模式下至少能看到当前状态、最近输入、失败原因、候选列表、耗时和重要阈值。对复杂玩法来说，能看见中间状态比多写一层封装更重要。
4. 第四步，用三类样例保护系统：正常流程、边界流程、错误配置。正常流程证明体验能跑通，边界流程证明快速输入、暂停、切场景和重复触发不会破坏状态，错误配置证明系统会给出明确报告，而不是静默失败。

项目检查清单

• 确认 AbilityInventory 的输入输出能被 JSON 记录，便于复现玩家操作。
• 确认 GateDefinition 的配置有默认值、版本号和校验错误信息。
• 确认快速点击、暂停、切后台、重开场景和读档不会重复提交关键状态。
• 确认失败反馈比成功反馈更具体，玩家能理解自己为什么没有成功。
• 确认低端机或高负载场景有降级策略，而不是等帧率下降后再猜瓶颈。
• 确认调试面板能在不改代码的情况下打开，并能导出最近关键事件。

常见误区

第一类误区，是把 Phaser 的显示对象当成状态来源。显示对象适合表达结果，却不适合保存规则事实。它可能被对象池回收、被摄像机隐藏、被动画临时修改，也可能因为画质档变化而不存在。核心状态必须独立存在。

第二类误区，是只为当前关卡写逻辑。当前关卡对象少、节奏慢、输入简单，临时判断看起来没有问题。等到内容增加、节奏加快、平台变多，临时逻辑会互相覆盖。每个系统至少要提前考虑配置错误、重复触发和性能上限。

第三类误区，是没有把失败当成流程设计。复杂系统一定会失败：条件不满足、资源缺失、网络超时、玩家中断、配置非法。失败不应该只是 console 里的一行错误，而应该是玩家、QA 和内容团队都能理解的状态。

能力获得时的叙事节奏

能力门系统还要考虑玩家刚获得能力的前五分钟。最理想的节奏通常是：立刻给一个安全教学场景，让玩家确认新能力的输入；随后给一个轻微压力场景，让玩家在移动中使用；最后把旧区域里曾经见过的门重新放进玩家视野。这个顺序能把能力从按钮变成记忆。Phaser 里可以在能力获得后记录 recentlyUnlockedAbility，地图提示、环境闪光和 NPC 台词都从这个状态读取。这样提示不是硬编码在某个房间里，而是围绕玩家进度自然出现。

地图完成度要分层统计

银河城玩家很在意完成度，但完成度不能只按房间数量算。一个房间可能包含主路径、隐藏道具、能力门、捷径和挑战入口。建议把完成度拆成 explored、collected、unlocked、shortcutOpened 等字段。地图 UI 可以显示总完成度，也能在区域详情里展示缺少哪类目标。这样玩家后期查漏时不会被一个 97% 的数字折磨，却不知道到底漏了宝箱、门还是隐藏房间。

关卡调试时，还可以给每个能力门加最近访问时间。若很多玩家反复来到同一个门前却长期没有获得对应能力，说明提示、地图动线或能力投放位置可能不清楚。

结语

银河城能力门：地图标记、回访路径和进度状态 的难点不在某个 API，而在边界。把数据、规则、表现和调试分开后，Phaser 的优势会更明显：你可以很快做出反馈，也可以放心迭代规则。反过来，如果所有逻辑都散落在 Scene 的回调里，第一版越快，后续越难维护。

额外实践建议

• 能力门最好从第一张地图开始数据化，不要等地图大了再回头补。
• 每个门都要有玩家反馈配置：声音、动画、提示、地图标记，避免能力不足时看起来像 bug。
• 回访提示要给玩家选择权，地图筛选比强制导航更适合探索类游戏。