maximizing-game-feel

改善一款已能正常运行的动作游戏的响应感和可读性。考虑每类重要对象，但只采用符合角色定位和事件的效果。

工作流程

1. 确立基线

检查实体、碰撞边界、渲染层级、反馈辅助工具、性能限制和视觉方向。选择技巧前，先指出表现薄弱的环节。

对于大型项目，在 FEEL_TUNING.md 中记录整体风格、薄弱环节、效果预算和验证阈值；对于单文件游戏，则在简短的 README 或源代码头部注释中记录。文档应比实现更精简。

2. 选择表现风格

根据标题、对象、形状、调色板和现有方向推断基调。遵循现有的 directing-game-visuals 产物。

风格	倾向采用	避免
角色化／轻快	明显的挤压变形、眼睛、生动的过冲、粒子	遮挡小角色的效果
抽象／极简	倾斜、拖尾、光效脉冲、克制的粒子	面部表情和卡通式变形
严肃／紧张	厚重的撞击感、克制的变形、短促的镜头震动	弹跳或嘈杂的反馈

不确定时，宁可克制；运动和光效比面部表情／弹跳更普适。

3. 将事件映射到一小组反馈效果

针对玩家、敌人、可移动／固定危险物、投射物和奖励相关的每个重要事件，选择合理的效果，或明确标记为 none。

保持不同类别的效果各自鲜明：

• 危险：锐利的轮廓、警示闪光、火花、短促而强烈的撞击；
• 奖励：闪光、放射状粒子、柔和的弹出效果、明亮的确认反馈；
• 状态变化：局部脉冲、过渡主题、受控的镜头响应；
• 险些错过：令人满意，但明显弱于实际奖励。仅当触发条件确实对应玩家避开了威胁时才添加；如果仅仅从旁经过也会触发，或漏掉真正的脱险情况，那么这种接近判定毫无意义，应当舍弃。
• 失败原因：不同原因导致的失败应呈现不同效果。因规则未达成而失败（未满足配额、计数器满值）时，不应沿用被摧毁的效果，否则会让人觉得玩家像是被无形之物击中。

选择或实现具体技巧时，请阅读 technique-catalog.md；其中包含特定引擎的限制。

4. 实现表现效果，避免破坏游戏机制

• 以游戏逻辑／碰撞为准；尽可能仅对渲染用视觉对象应用变形、旋转、拖尾、闪光和后坐。更改屏幕上的移动方式之前，先查明碰撞和拾取读取的是哪个位置；如果读取的是绘制位置，那么改变运动效果就是改变规则。
• 只要危险物仍能造成伤害，就应确保其绘制尺寸至少与有效碰撞区域一样大。如果碰撞区域已达到完整尺寸，而效果却从小尺寸逐渐放大，就会让玩家在可见距离外被摧毁。
• 对所有变形和镜头位移设定上限，并确保效果能恢复到静止状态。
• 根据速度、蓄力、冲击强度或稀有程度，限制高开销／干扰性效果的触发。
• 命中停顿期间保留缓冲输入，切勿仅为表现后坐而将权威玩家位置移入危险区域。
• 优先使用小型的局部表现辅助工具，而非庞大的强化效果框架。
• 在资源受限的目标平台上限制粒子／拖尾数量，并设定最低可接受帧率。

5. 按效果收益与投入比实施

仅应用有依据的效果，并按以下顺序实施：

1. 事件确认：受击闪光、短促的撞击粒子、落地反馈；
2. 撞击力度：命中停顿或克制的镜头震动；
3. 动作表现：倾斜、挤压／拉伸、缓动和预备动作；
4. 世界一致性：让相关敌人、危险物、投射物和奖励做出适当响应；
5. 高速润色：拖尾和残影；
6. 仅当风格和屏幕尺寸适合时，再添加角色表情效果。

6. 在实际运行中验证

以正常速度对比前后效果，并检查高反馈场景的渲染画面。

• 操作响应依然即时，缓冲输入不会丢失。
• 视觉边界不会错误呈现碰撞边界。
• 存在带种子的模拟玩家时，仅呈现层的处理前后，其结果应完全一致。任何差异都意味着该处理影响了规则；在评估手感前先找出问题。
• 在效果最密集时，玩家、主要危险物和奖励依然清晰可辨。
• 最强烈的反馈应留给最重要的事件。
• 效果会恢复到静止状态，不会累积或泄漏。
• 性能保持在目标预算范围内。

如果润色显著影响危险物的辨识度或实际难度，只需重新运行仍受影响的平衡／机制检查；默认不必全面扫描遥测数据。

参考路由

• technique-catalog.md — 具体效果，以及在 crisp-game-lib/Godot/其他 2D 引擎中的适配方式。
• directing-game-visuals — 重用现有的配色与层级设计决策；不要仅为满足依赖项而调用它。