Phaser 射箭系统：蓄力、风偏、弹道预览和命中反馈

为什么这个玩法不能只写成演示

玩家站在山谷边参加射箭挑战。拉弓时间越长，箭速越快；横风会把箭吹偏；远处靶子有内圈、外圈和移动遮挡。玩家需要感觉自己在瞄准，而不是掷骰子。

射箭系统要平衡可控和变化。蓄力、重力、风、目标移动和辅助瞄准都影响命中。若只画一条直线预览，真实弹道会让玩家困惑；若预览过于准确，挑战又会消失。 本文按一个可上线的小系统拆解，重点不是罗列 Phaser API，而是把输入、规则、表现、调试和内容配置的边界说明白。只要这些边界清楚，后续加关卡、加活动、加存档或加移动端适配，都不会反复推倒。

核心架构

flowchart TD
  N1["AimInput"] --> N2["ChargeCurve"]
  N2["ChargeCurve"] --> N3["TrajectorySampler"]
  N4["WindField"] --> N3["TrajectorySampler"]
  N3["TrajectorySampler"] --> N5["HitResolver"]
  N6["AssistTuning"] --> N1["AimInput"]
  N5["HitResolver"] --> N7["FeedbackDirector"]
  N7["FeedbackDirector"] --> N8["HUD"]

这套结构的关键是让 AimInput、ChargeCurve、WindField、TrajectorySampler、HitResolver、AssistTuning、FeedbackDirector 各司其职。输入层提交意图，规则层产出确定结果，Phaser 层负责把结果演出来。不要让 Tween 完成回调、Sprite 是否可见或某个音效是否播放成为规则事实。规则事实必须能被序列化、测试和回放。

蓄力曲线要有手感

ChargeCurve 把按住时间映射为箭速和稳定度。前半秒增长快，让短按也有反馈；后段趋缓，避免长按必然最优。超过最佳窗口可以轻微抖动，鼓励玩家掌握节奏。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

风偏要可读

WindField 不应只是隐藏数值。旗帜、树叶、粒子或 UI 箭头都可以表达风向。风对弹道的影响要和提示一致，不能 UI 显示微风，实际偏移很大。关卡中可用阵风制造变化，但要提前预告。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

弹道预览要适度

TrajectorySampler 可以采样未来若干点，画出短虚线。新手模式显示更长，高手模式只显示起始方向。预览应考虑当前风和蓄力，但可以隐藏最后一段，让玩家仍需判断。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

命中区域分层

HitResolver 根据箭与靶子的交点计算内圈、外圈、边缘擦过和未命中。移动靶要使用命中时刻的位置，而不是发射时位置。命中结果带上距离、速度和角度，便于评分和反馈。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

辅助瞄准要轻

AssistTuning 可以在手柄或移动端提供轻微吸附，让准星靠近靶心时变慢。辅助不能直接修正箭的物理，否则玩家会觉得结果不真实。吸附强度要按难度和输入设备配置。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

反馈要讲原因

未命中时显示箭落点、风偏方向和蓄力状态。命中时用慢动作、靶面震动和分数弹窗强化结果。若玩家总是偏左，系统可以在训练模式提示风向，而不是直接提高命中率。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

调试要画真实弹道

开发模式显示采样点、风力向量、命中检测圈和最终碰撞点。射箭系统最怕预览和真实飞行不一致，调试线能马上暴露采样和实际物理之间的差异。

实现时建议先用调试图形把这部分规则跑通，再接正式美术。比如先画命中范围、路径、候选区域、分数来源或状态机阶段，确认数据没有问题后，再加入粒子、音效、镜头和 UI 动效。这样做看似慢，实际会减少大量返工。

TypeScript 实现骨架

interface Wind { x: number; y: number }
function chargePower(heldMs: number) {
  const t = Phaser.Math.Clamp(heldMs / 1200, 0, 1);
  return 260 + Math.sin(t * Math.PI / 2) * 520;
}
function sampleTrajectory(origin: Phaser.Math.Vector2, velocity: Phaser.Math.Vector2, wind: Wind, steps = 24) {
  const points: Phaser.Math.Vector2[] = [];
  let pos = origin.clone();
  let vel = velocity.clone();
  for (let i = 0; i < steps; i++) {
    vel.x += wind.x * 0.016;
    vel.y += (420 + wind.y) * 0.016;
    pos = pos.clone().add(vel.clone().scale(0.016));
    points.push(pos);
  }
  return points;
}
function ringScore(distance: number) { return distance < 12 ? 10 : distance < 28 ? 7 : distance < 48 ? 3 : 0; }

这段代码只展示核心边界。真实项目里还需要配置加载、错误码、事件总线、对象池、存档字段和测试夹具。原则是核心系统不依赖 Scene，Scene 只把玩家输入和系统结果连接到 Phaser 的显示对象。

落地步骤

1. 第一步，先把 AimInput 和 ChargeCurve 写成纯数据模型，准备两三个最小样例。
2. 第二步，给 WindField 增加调试可视化，确保中间状态能被看见。
3. 第三步，把 Phaser 动画接到规则结果上，而不是让动画反过来提交规则。
4. 第四步，补齐失败原因、暂停恢复、重复点击保护和读档恢复。
5. 第五步，用正常流程、边界流程、错误配置三类夹具做校验。

常见坑

• 把画面当作状态来源。显示对象可能被对象池回收、被镜头隐藏或被动画临时改值，不能作为规则真相。
• 只为第一关写逻辑。第一关对象少、节奏慢，很多问题不会暴露；内容扩张后，重复触发和配置错误会一起出现。
• 失败反馈太笼统。玩家需要知道是条件不满足、资源不足、路径不可达、输入太晚，还是系统正在等待确认。
• 调试面板缺失。复杂玩法没有中间状态可视化，后期只能靠录屏和猜测定位。

运行时观测

记录命中分布、平均蓄力时长、风偏导致的落点偏差和辅助瞄准触发次数。若大多数玩家满蓄力，说明曲线缺少选择；若风偏投诉多，说明提示不足。 这些指标不一定都要上报到线上，但至少应该在开发版能导出。玩法系统越依赖手感和解释，越需要用数据区分规则问题、表现问题和关卡配置问题。

边界测试与移动端验证

射箭系统 在桌面浏览器里跑通，只能说明主流程成立，还不能说明它适合发布。建议为它准备一组专门的边界测试：蓄力超过最佳窗口、阵风在放箭瞬间变化、移动靶跨越命中线、辅助瞄准开启后仍未命中、训练模式和正式模式预览长度不同。这些测试不用都做成复杂自动化，至少要有可重复的调试入口，让开发、策划和 QA 能在同一状态下观察同一个问题。每次测试都要记录 chargeMs、windVector、TrajectorySampler 和 HitResolver，否则失败只会变成“刚才好像不对”。如果玩法会出现在移动端，还要额外检查触控误差、浏览器切后台、低电量降频、横竖屏切换和音频恢复。很多 Phaser 小游戏不是输在核心规则，而是输在这些边界恢复上。

移动端验证还要关注触摸反馈和文字密度。按钮按下后要有立即响应，即使规则结果需要等待；长文本提示要能在窄屏换行；关键数值不能只靠颜色表达。若系统在低端机关闭粒子、阴影或轨迹后仍能保持同样的规则结果，就说明表现层和规则层边界清楚。发布前把这些用例整理成清单，后续每次改配置、换美术或加活动，都可以快速回归。

发布前检查

发布前至少确认四件事：第一，所有配置引用的 id 都存在；第二，核心状态能存档并恢复；第三，快速输入和跳过动画不会重复结算；第四，低端机可以关闭高成本表现但不改变规则。若系统涉及奖励、货币或排行榜，还要确认事件 id 幂等，避免重复发放或重复扣除。

训练模式的反馈

射箭系统适合做训练回放。每次射击后显示瞄准点、真实落点、风偏贡献、蓄力时间和命中环。玩家能看到自己偏差来自手抖、风还是蓄力不足，就会愿意继续练。训练模式可以比正式挑战显示更多辅助线，但要明确这是练习反馈，不要让玩家进入正式关卡后突然失去所有信息。

目标材质和箭的反馈

箭命中木靶、金属盾、布帘和怪物护甲应该有不同声音和停留状态。命中木靶可以插入，命中金属可能弹开，命中布帘可能穿透后减速。HitResolver 返回命中材质，FeedbackDirector 再选择动画和音效。这个层次能让射箭从单纯算分变成更可信的物理反馈。

射箭关卡还要让目标距离可感知。远靶和近靶如果只是在屏幕上大小不同，玩家很难判断需要多少抬高角。可以用地面刻度、旗帜间距或旁边参照物提示距离，让弹道判断更像技能而不是猜测。

验收标准

这个系统的第一版不需要覆盖所有商业化变化，但至少要能回答三类问题：玩家为什么成功，玩家为什么失败，内容配置为什么非法。验收时可以让一名没有参与开发的人按测试清单操作，如果他能从画面反馈和调试面板里解释当前状态，就说明系统边界基本成立。若每次都需要开发者口头说明，说明 UI、日志或规则命名还不够清楚。

射箭验收还要固定风向、蓄力和角度，对比预览采样点与真实飞行轨迹。两者可以有表现层误差，但不能使用两套互相矛盾的公式。

训练关卡也要保存最近几箭，方便玩家复盘。

如果开启辅助瞄准，复盘里要标明辅助强度，避免玩家误判自己的真实水平。

这个标记也方便平衡测试。

结语

射箭系统：蓄力、风偏、弹道预览和命中反馈 的价值在于可解释。Phaser 可以把反馈做得很快，但真正决定项目能不能持续扩展的，是规则层是否稳定、表现层是否服从结果、调试层是否能讲清楚每一次失败。把这些边界立住，玩法才能从一个好看的 Demo 变成可维护的系统。