craft-game-floors

打磨游戏各方面

一个功能完整、但看起来和玩起来都像程序员美术作品的游戏，在提出需求的人看来就是失败。本技能提供打磨层：各方面——每款游戏都必须达到最低标准、且不能接受引擎默认设置的领域；每个领域都附有下方的参考资料，其中包含明确的取舍、可供模仿的完整示例，以及验证步骤。这些方面是 铺平路径的核心（Unity 为 Agent 构建的游戏提供的默认脚手架：预先声明假设，并且一句话即可撤销）；在本技能中，“铺平”仅表示默认启用这些方面，除非用户选择不启用。

开始任何方面的处理或诊断之前，请打开并阅读下方匹配的参考资料及其链接的 Unity 文档页面——你对引擎的了解可能已经过时、有误，或适用于其他版本。请在报告中列出你阅读过的文件和页面。只做要求的事情。不要修改无关的资源或文件。避免冗长解释。

有两种入口，处理的方面相同：

• 创建项目时——new-unity-project 技能会加载本技能，并按下方顺序在构建过程中应用这些方面。
• 项目进行中，提出任何打磨需求时（“改进画面”“添加音效”“感觉很平”“制作标题画面”“评估一下”）——完成下方的中途流程检查后，直接跳转到匹配的参考资料。

按需求确定范围：授权修改的请求（“修复”“添加”“润色”）会应用相应方面；仅要求评估的请求（“评估一下”“我应该修复什么？”）则提供评分结果和建议，在用户同意之前不修改项目。

中途介入

参考资料假设项目已有一份美术圣经（风格说明 + 固定调色板），以及在音频与 UI 交互时所需的混音器握手（公开参数 MusicVol/SFXVol）。对于现有项目，请在处理所请求的方面之前，按顺序完成以下步骤：

1. 还原点——在进行任何更改之前，确认存在可回滚的干净提交，或先创建一个。
2. 渲染管线——读取 GraphicsSettings.currentRenderPipeline：画面相关方面的验证步骤是为 URP 编写的；如果使用 Built-in 或 HDRP，则应用相关建议，说明管线差异，并跳过针对 URP 的检查。
3. 美术圣经——查找 Palette 类型或美术圣经说明（CLAUDE.md、docs）；如果不存在，先根据游戏当前画面编写三行美术圣经——事后再改成复古风格，代价更高。
4. 身份（仅实时方面）——通过实时探测验证玩家身份（服务已初始化且存在 PlayerId），绝不能假设更早的设置步骤已运行。
5. 确定完成门槛的范围，使其对应你触及的部分：标题画面会话评估外壳和画面这两项，而不是整个评分表。

**某个方面用于补足引擎默认设置，绝不用于取代开发者的选择。**如果项目已有自己的控制器、摄像机、着色器、调色板或风格，请予以保留，只应用与其不冲突的相关建议，并在报告中说明差异。美术圣经只能根据开发者已做出的选择编写；在项目进行中添加美术圣经前，请先征得同意。

各楼层——按构建顺序编号，在对应阶段阅读

1. art-direction — 添加第一个材质、灯光或 UI 元素之前
2. scene-lighting — 确立视觉基线时（3D）
3. toon-shading — 美术规范选定赛璐璐／卡通风格时（3D）
4. camera-rigs — 首个游戏摄像机（含 2D 章节）
5. placeholder-assets — 首次遇到缺失资源时
6. character-motion — 首个角色开始移动时（偏向 3D）
7. (可玩循环在此阶段完成——先做循环，再做内容，每轮专注一个系统)
8. game-feel — 循环完成后的手感调整阶段
9. vfx — 手感调整阶段（含 2D 章节）
10. game-audio — 完成之前
11. game-shell — 完成之前（2D 背景差异）。首次使用 TextMeshPro 文本之前，导入 TMP Essentials（参见参考文档中的故障表）。
12. live-floor — 与外壳阶段同步（先实现服务，再编写游戏代码）
13. visual-scorecard — 完成门槛，始终最后执行；可玩循环完成后运行。 创建项目期间，在采集基础灯光效果时停止，并跳过此门槛。

项目中途提出的需求从对应编号开始；只有中途检查需要时，才回看更早的楼层 （美术规范、管线、身份探测）。

解析参考文档链接中的 <VERSION>——优先使用 WebFetch 获取确切页面，而不是使用 WebSearch：对于 docs.unity.com/en-us/engine/<VERSION> 的手册和脚本参考页面，使用 ProjectSettings/ProjectVersion.txt 中项目所用的 Editor 发行流（例如 6000.3），并为其余 docs.unity3d.com/<VERSION>/Documentation 页面使用相同发行流；对于 docs.unity3d.com/Packages/<package>@<VERSION> 页面，使用 Packages/manifest.json 或 Library/PackageCache 文件夹名称中已安装软件包的主版本号和次版本号； docs.unity.com/en-us/<service>.md 服务页面不区分版本。

路由方式应符合游戏的 2D／3D 特性；目前尚未覆盖 2D 外观楼层（精灵美术指导、2D 灯光、 精灵占位资源）——对于 2D 游戏，在相应阶段说明这一点，而不要套用 3D 指南。评分卡的 2D 锚点集仍然适用。

职责边界（本技能不负责什么）

本技能负责有明确主张的创作与各楼层——采用哪些值、顺序如何、达到什么标准。 目录中的相关技能负责在现有设置上实现机制：音量／后期处理机制 → urp-postprocessing · 将音源路由到现有混音器组 → audio-setup-mixers · 音频 导入／内存 → optimize-audio · UI 框架选择与构建 → ui · 字体资源 → optimize-text-mesh-pro · 后端服务 → build-live-game · 像素级精准的 2D → 2d-pixel-perfect。如果需求纯粹是机制实现，就转到对应技能；如果需求是“把它做好”， 则由本技能负责，并由本技能再委派机制实现。如果要扩展此索引，应新增一个由提示词路由的 目录技能，而不是再加一个楼层——楼层必须适用于每一款游戏。

完成门槛

创作环节以 visual-scorecard 的评分板作为结束标志—— 评估画面帧，而不是看编译是否通过。按以下顺序执行：

1. 评分——按照评分卡评估全部六个维度。六项都达到 3 分或以上才算达标。
2. 修复阶段——低于 3 分的项目必须在完成前修复（仅评估的需求：提供评分和 建议，不做修复）。如果修复无效，请重新阅读相关参考文档及其链接的文档，再尝试其他方案。
3. 控制台——确认控制台错误为零。
4. 运行检查——进入 Play 模式，并使用为此添加的 Debug.Log 语句检查已修改的行为。 如果修复阶段或此检查未通过，请重新阅读相关参考文档及其链接的文档，再尝试其他方案。

最终报告

状态：说明运行了哪些层级、查阅了哪些参考资料 · 修复前后的整体规范（或限定范围的维度） · 所有附带影响——已安装的软件包、编辑过的文件或设置、导入的素材——以及用户需要采取的后续操作 · 跳过的层级或明确指出的缺口（2D 外观层级、用户拒绝安装、缺少相邻技能），让用户了解跳过了哪些更深入的指导。

常见错误

• 没有规范就开始润色——没有调色板作依据就修整某个对象的外观；即使项目已进行到一半，也要先写出三行规范。
• 用层级方案取代开发者的选择——已有的自定义控制器、摄像机、着色器或调色板应予以保留；修复过程绝不应将它换成层级的默认方案。
• 把层级当成功能——层级是默认设置；用户可以用一句话拒绝某项设置，并在报告中记录，不要争辩。
• 凭记忆执行机制操作，而相邻技能才负责这些操作——应转交并委派。
• 因改动很小而跳过完成检查——应缩小检查范围，而不是跳过。
• 对 2D 游戏应用 3D 外观指导——应明确指出这一缺口。