Phaser 水下关卡系统：氧气、暗流、浮力和溺水反馈要一起设计

为什么值得单独做成系统

一个横版冒险关卡里，玩家潜入沉船寻找电池。舱室里有气泡口，破损管道制造横向暗流，角色在水中转向变慢，氧气条逐渐下降。玩家既要感到水下的阻力，也要清楚知道自己为什么被推走、为什么开始溺水。

水下玩法如果只是在进入水区后给角色加一个慢速状态，很快就会变得单薄。真正可信的水下系统需要把区域、物理、氧气、恢复、视听反馈和失败保护放进同一套规则里。 本文会按一个可上线的小系统来拆，不追求炫技，而是把数据结构、状态流、玩家反馈、调试工具和发布检查说清楚。Phaser 的优势是让画面和交互快速成型，但越是快速，越需要把规则层和表现层分开。

核心架构

flowchart TD
  N1["WaterVolume"] --> N2["OxygenModel"]
  N1["WaterVolume"] --> N3["BuoyancyMotor"]
  N4["CurrentField"] --> N3["BuoyancyMotor"]
  N2["OxygenModel"] --> N5["DrowningState"]
  N6["BubbleSource"] --> N2["OxygenModel"]
  N5["DrowningState"] --> N7["HUDFeedback"]
  N3["BuoyancyMotor"] --> N8["Phaser Physics"]

这张图的重点是单向流动。WaterVolume、OxygenModel、CurrentField、BuoyancyMotor、DrowningState、BubbleSource、HUDFeedback 不应该互相随意读写。输入或场景事件进入模型，模型输出快照或事件，Phaser 表现层再根据结果更新 Sprite、Graphics、Sound 和 UI。只要这条边界稳定，后续加内容、加难度、加存档或加多人同步，都不会把系统推倒重写。

水域要有边界和属性

水下区域不只是一个矩形 trigger。每个 WaterVolume 应记录深度、浑浊度、基础阻力、是否消耗氧气、是否允许上浮、是否屏蔽火焰类技能。这样浅水、深海、毒液池和安全蓄水舱都能共用同一套状态流。Phaser 中可以用 Zone 或 Tiled object layer 做触发，但进入区域后应该把区域 id 交给规则层，而不是让碰撞回调直接改角色速度。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

氧气消耗要能解释

氧气条下降速度应由区域、角色状态和装备共同决定。冲刺、受伤、携带重物会增加消耗；潜水服、气泡源、氧气瓶会降低或恢复。调试面板要显示当前每秒变化量和来源贡献，否则策划调参时只会感觉太快或太慢。玩家层面也需要明确反馈，比如氧气条颜色、呼吸音和边缘暗角逐步变化。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

暗流不是推力贴图

暗流区域需要方向、强度、噪声和边界衰减。直接给角色每帧加固定 velocity 会很生硬，尤其在边界处会突然跳。更好的方式是 CurrentField 根据角色位置采样力，再由 BuoyancyMotor 合成到移动控制里。强暗流可以压制玩家输入，弱暗流只影响漂移。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

浮力手感要保留控制

水下角色通常应该有惯性，但不能完全失控。可以降低水平加速度、提高阻尼、限制下落速度，并给上浮键一个持续力。若项目使用 Arcade Physics，重点是自己控制速度曲线；若使用 Matter，重点是限制力和速度上限。不要直接套真实物理，游戏需要的是可预测的水感。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

溺水状态要有缓冲

氧气归零后不一定立刻死亡。可以进入 drowning 状态，开始扣生命、播放急促气泡和画面收缩。若玩家在短时间内到达气泡口，状态恢复；若继续停留，进入失败。这个缓冲能制造紧张，也给玩家最后一次理解和纠正的机会。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

恢复点要防刷也要公平

气泡源、空气口和氧气瓶都能恢复，但规则不同。气泡源可以持续恢复但有冷却，空气口快速回满，氧气瓶一次性使用。恢复时应停止溺水扣血，并给足够清楚的声音反馈。若气泡源和暗流重叠，优先保证玩家能停留，不要让恢复点被暗流推得无法使用。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

镜头和音频服务方向感

水下关卡容易让玩家迷路。可以用气泡方向、低频水流声和镜头轻微偏移提示出口。音频不应只做氛围，也可以承载信息：越接近气泡源，呼吸声越稳定；越靠近强暗流，水流声越尖锐。这样的反馈比屏幕上堆文字更自然。

实现时建议先用最简单的调试图形验证规则，再接正式美术。比如先画出区域、方向、时间轴、占用格或检测范围，确认数据正确后再添加粒子、镜头、音效和过渡动画。这样做不花哨，但能避免很多“看起来对，规则其实错”的问题。

TypeScript 实现骨架

interface WaterVolume { id: string; drag: number; oxygenDrain: number; murky: number }
interface CurrentZone { x: number; y: number; radius: number; force: Phaser.Math.Vector2 }
class OxygenModel {
  value = 1;
  drowning = false;
  update(dt: number, drainPerSec: number, refillPerSec: number) {
    this.value = Phaser.Math.Clamp(this.value + (refillPerSec - drainPerSec) * dt / 1000, 0, 1);
    this.drowning = this.value <= 0;
  }
}
function sampleCurrent(pos: Phaser.Math.Vector2, zones: CurrentZone[]) {
  const out = new Phaser.Math.Vector2();
  for (const zone of zones) {
    const d = Phaser.Math.Distance.Between(pos.x, pos.y, zone.x, zone.y);
    if (d > zone.radius) continue;
    out.add(zone.force.clone().scale(1 - d / zone.radius));
  }
  return out;
}
function underwaterVelocity(input: Phaser.Math.Vector2, current: Phaser.Math.Vector2, maxSpeed: number) {
  return input.clone().scale(maxSpeed * 0.58).add(current).limit(maxSpeed);
}

这段代码只展示核心边界，不是完整项目代码。真实项目里还需要补配置加载、错误码、事件派发、对象池、性能采样和测试。关键是让核心规则能独立运行，Phaser 层只是把规则结果变成玩家能感知的反馈。

落地步骤

1. 第一，先把 WaterVolume 和 OxygenModel 写成普通 TypeScript 模型。不要让它们依赖 Phaser Scene、Sprite 或 Camera。核心模型越普通，越容易写测试、做编辑器预览和复现玩家问题。
2. 第二，Phaser 层只做适配：接收输入、播放动画、更新图形、触发音效。它可以很薄，但必须清楚。只要某段规则开始读取 Sprite 的 visible、alpha 或动画状态，就说明边界正在变脏。
3. 第三，给 CurrentField 或同等复杂的中间结果做调试显示。开发模式里能看到状态、阈值、候选对象、失败原因和耗时，后续调参才不会靠猜。
4. 第四，准备三组测试夹具：正常流程、边界流程、错误配置。正常流程验证体验，边界流程验证稳定性，错误配置验证系统会报出人能看懂的问题。

检查清单

• 确认 WaterVolume 的状态可以序列化，能写入存档或调试日志。
• 确认 OxygenModel 的配置有默认值、版本号和校验错误。
• 确认快速点击、暂停、切后台、读档和切场景不会重复提交关键事件。
• 确认失败反馈足够具体，玩家能知道是条件不足、输入中断、资源不够还是规则禁止。
• 确认低端机有降级策略，尤其是粒子、音效、动态对象和调试图层。
• 确认开发模式可以导出最近关键事件，方便复现玩家反馈。

常见误区

第一类误区，是把表现当成事实。动画播完、按钮亮着、Sprite 存在，都只能说明表现层当前长什么样，不能说明规则已经完成。规则事实应该存在于模型和事件里。

第二类误区，是只为了第一个关卡写逻辑。第一个关卡对象少、输入慢、节奏简单，临时判断很难暴露问题。等内容增加，重复触发、配置错误和性能峰值会一起出现，早期的边界会决定后期成本。

第三类误区，是没有设计失败路径。复杂系统一定会遇到失败，好的失败路径会告诉玩家和开发者发生了什么；坏的失败路径只会留下一句操作失败，甚至什么都不显示。

发布前验证

发布前至少跑一次规则级测试和一次运行时冒烟。规则级测试不需要启动浏览器，直接喂数据，断言状态和事件。运行时冒烟则在 Phaser 场景里验证输入、反馈、暂停、重开和边界情况。若系统涉及经济、存档或排行榜，还要记录 requestId 或事件 id，保证重复提交不会造成重复奖励或重复扣费。

额外实践建议

• 先用纯色水域和箭头调规则，不要一开始就上复杂水纹。
• 氧气变化要能导出日志，玩家死亡时能看到最后十秒状态。
• 水下关卡要准备无障碍选项，减少强暗角和低频压迫。

运行时观测与调参

水下系统上线前，建议记录几项非常朴素的数据：玩家每次进入水域的停留时间、氧气低于 20% 的次数、溺水前最后一个恢复点距离、暗流造成的位移比例、以及玩家是否在同一片水域连续死亡。只看通关率不够，因为玩家可能勉强通关但体验很差。若大量玩家在气泡源附近死亡，问题可能不是难度，而是气泡源位置、暗流方向或视觉提示不清楚。调参时也不要只改氧气总量，先判断失败来自消耗太快、恢复太少、移动失控还是路线误导。把这些指标写进调试日志，水下关卡会从凭感觉调整变成有证据地迭代。

结语

水下关卡系统：氧气、暗流、浮力和溺水反馈要一起设计 的关键不是某个 API，而是把可解释的规则交给模型，把可感知的反馈交给 Phaser。只要这条线清楚，项目就能持续扩展；如果所有逻辑都塞进 Scene 回调，第一版越快，后面的维护压力越大。