game-dev-combat-skill-polish

游戏开发：战斗技能打磨

技能由施放动作（施法者的身体）、效果（它投掷、升起或撕裂出来的东西）和结果（目标的反应，以及留下的痕迹）组成。把这三部分都打磨好，并由未参与制作的人根据实际录制的画面评判。

有两项评分标准。先弄清楚用户指的是哪一项：

标准	关注的问题	评分细则	典型目标
可读性	看起来像它本身吗？打击到来时，结果是否在恰当的时间和地点显现？姿势是否独具特色？	references/rubric-readability.md（辨识度、时机、身体、效果、反应）	每项技能 6+
美术表现	细节与质感、光照、动作与轨迹、冲击感、美术方向，以及与指定参照的对比	references/rubric-art.md（用文字描述的《暗黑破坏神 IV》圣骑士技能）	每项技能 7+

一项技能的可读性可以得 7 分，美术表现却只有 3 分。引用分数时，务必注明所用的评分细则。

1. 明确任务

• 要评估哪些技能：全部技能（全面评估），还是指定技能（重做）。同时有多个技能在进行时，每个讨论串只处理一项技能。
• 确定评分标准和参照。如果用户提供了参照图片，将其保存到项目中，方便评审查看；否则就在评分细则中用文字描述。
• 设计前先阅读项目参照文件（如果存在 references/<project>.md）：了解每项技能的代码位置、测试环境设置、目前的评分卡，以及其他讨论串已经得出的结论。
• 开始前运行 git fetch，检查其他讨论串正在修改的内容；多个技能讨论串可能会编辑相同的效果和动画文件。

2. 拍摄实际效果

• 在主分支之外，使用自己的 Git 工作树进行开发。在空闲端口上运行它；再用第二个端口运行干净的主工作树，作为“修改前”的对照。
• 使用停止并逐步推进的时钟进行无头拍摄：冻结游戏时钟，每帧推进 0.05 s，等待画面渲染完成后再截图。这样即使机器负载较高，帧间距也能保持均匀。（使用 scripts/film.mjs；每项技能的场景配置放在类似 scripts/scenarios.example.mjs 的场景文件中。）游戏需要为此提供仅供评审使用的钩子：设置场景状态、发出命令、调整摄像机、冻结并推进时钟（接口约定见 film.mjs 顶部；HOOK、PAGE、READY、SETTINGS_KEY 和 CHROME 通过环境变量设置）。
• 布置每次施放场景时，确保施法者、目标、主体对象和落点都在取景范围内，并避开 HUD（frame、span、points）。被面板挡住的东西会被评为“一个小点”。
• 每次施放都制作一条接触表（scripts/strips.py，设置 N=16、TAIL=3 以保留后续画面），并制作关键帧的特写图（scripts/close.py）。评审两者都需要：接触表展示时机，特写图展示美术表现。
• 尽可能量化：敌人开始移动的帧与打击命中的帧（每帧操作和时间见 meta.json）、施放期间的绘制调用次数与三角形数量（scripts/perf.mjs），以及下载大小。
• 拍摄过程中绝不要编辑正在提供服务的源文件；开发服务器可能会在拍摄中途重新加载。

3. 两人一组，盲评

• 每轮安排两名全新、通用型子 Agent。提供评分细则、清单文件和图片路径，并要求他们不要打开其他文件：不要看代码、先前评分或密钥。scripts/judge-set.py 会用中性 ID 为接触表匿名编号，并生成清单和密钥；两份提示词见 templates/judge-prompt.md。
• 要求以 JSON 格式给出各项分数、总分、最大问题，以及最能提高评分的一项改动。将每条回复保存到 judges/ 下。
• 采用两者中较低的分数。绝不向上取整。绝不要给自己拍摄的画面打分。
• 评审评分差异通常约为 ±0.5 到 1。要确认 7 分可靠，先让评审重新评看同一组图片，或在集合中加入一条旧版本的校准接触表。单次侥幸得分不算通过。
• 评审提出的“下一步”就是工作清单。两人意见一致时，优先处理他们共同指出的问题。

4. 一轮一轮地提升

修复失分最多的评判项。以下做法曾让分数提升：

时机与可读性

• 结果必须在节拍到来时生效：目标要在打击、投射物或波到达时才做出反应、被推开或获得状态，绝不能在点击时发生。检查每帧都按规则位置绘制单位的场景层；它会毫不犹豫地在打击发生前显示推开效果（这是本技能所针对的项目中最先修复、也是影响最大的一个问题）。
• 借用其他技能的时间表（持续时间和接触时刻）的技能，不能有自己的动作主体。为它设置自己的时间表和关键动作：先跪下再起身、先蓄力再投掷、先鞠躬再迎接。然后更新所有依据旧时间表名称进行分支处理的地方。
• 波和投射物的飞行时间：命中要等到抵达时才发生。
• 沿弧线的多次命中要按照测量出的刀刃路径依次错开，而不是同时触发。
• 目标的反应：后仰、弯折、眩晕或击退占了一半的视觉表现。只有状态标签，得分会很低。

美术

• 核心物体的建模水平决定上限。 脚本生成的基本几何体和手工制作的网格，得分会停在 5.5 到 6.5（“普通棱柱”“玩具”）。将绘制的概念图（gpt_image_2_5）通过图像转 3D（Higgsfield image_to_3d、Meshy、带纹理 + PBR，约 12k 个三角形）制成带纹理的模型后，有两个技能的分数超过了 7。没有任何核心元素的技能，分数往往会停在 6 左右（一个没有任何建模元素的风系技能，经过 20 轮后仍停在 6）。
• 核心物体是小型场景道具时，要让道具清晰可辨，并在其周围绘制飘散的效果（建模的“力量之手”在战术镜头下始终看不清）。
• 绘制的纹理应用于黑底以进行加色混合（陨坑、新月、飘带、冲击波环、漩涡），效果胜过程序生成的圆环和条纹。发布前，将它们映射为技能的调色板（熔岩红紧挨着红色目标标记会显得不协调）。
• 飘带和拖尾：面向摄像机并横跨路径，宽度随绘制路径逐渐增加，横向边缘柔和，沿运动轨迹本身回溯采样（不是逐帧采样）。细而均匀的线条看起来像“激光”或“调试线”；宽阔的单条色带看起来像“一张扁平卡片”。
• 金属需要有反射对象。 战术场景通常没有环境贴图；为模型提供专属的小型等距天空盒和收紧的菲涅耳边缘光。过宽的边缘光或偏暖的色调，会让金色变成奶油色，或让铜色泛白。
• 光照：放在物体上，或放在靠施法者一侧、距离主体约一米处。光源放在主体内部照不亮任何东西；投射物下方的光池看起来像“脱离主体的圆盘”；光线太亮会冲淡目标。
• 冲击效果：一个小而炽热的核心、飞散后落下的碎片、贴近地面的暗色尘土、地面上逐渐冷却或淡去的痕迹，以及强烈的后仰反应。遮住目标的大块白色圆盘总会扣分。

评审总会扣分的内容：照搬其他技能的视觉效果（圆环、闪光或姿势）；扁平的奶油色或白色占位闪光；均匀的放射状条纹；目标上方的光柱或光矛；把地面照成奶油色的加色混合尘土环；拉长的白色火花（“白色短划线”）；长时间不消失的拖尾（“激光”“闪电”）；看起来像电流的裂纹贴花；以及 HUD 下方的任何内容。

提升时也要守住限制：帧预算、首场景下载预算（只有在开始一场可能用到新资源的战斗时，才加载这些资源）、可读性评分、测试，以及其他技能的视觉效果。每轮都在本地提交 WIP；这样即使重启也不会有损失。

5. 停止、锁定并发布

• 当较低评分者的门槛已达标（且重新评审结果一致）时停止；如果某项技能连续几轮都没有提升，也停止。然后直截了当地说明还需要什么（通常是一个建模的主视觉元素）。
• 发布评审者打过分的版本，而不是未经评审就改动过的版本。
• 添加一项测试，锁定该技能自身的日程安排、模型或方案。
• 编写评分表：逐轮列出变更、两位评审者的评分及是否保留，并说明哪些因素带来了变化、还遗留哪些问题、成本，以及前后对比表（scripts/beforeafter.py）。
• 按照项目的发布流程（workflow-ship-change），将其作为独立版本发布，并附上三张图片（开始、关键时刻、结果），同时标注测量尺寸。
• 更新项目记忆，记录哪些因素提升了评分以及新增的陷阱，让下一项技能有更好的起点。

报告

先按各项技能对应的评分标准报告结果：“Summon Hammer 4 → 7（艺术表现，两位盲评者，取较低分）”。然后给出逐轮表格、评审方式和所用录像、评审者指出的不足之处、成本，以及以内嵌形式提供的前后对比图片。将截图标注为无头浏览器截图，而非设备测试。