Back to Details

craft-game-floors

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Craft Game Floors

打造游戏打磨底线

A functional game that looks and feels like programmer art reads as a failure to the person who asked for it. This skill is the craft layer: floors — disciplines where every game needs a minimum and the engine's defaults are unacceptable — each carried by a reference below with opinionated values, worked examples to imitate, and a verify step. The floors are the heart of the paved path (Unity's default scaffolding for agent-built games: assumptions declared up front, reversible on a word); in this skill, "paved" simply means these floors are always on unless the user declines one.
Before starting any floor or diagnosis, open and read the matching reference below and the Unity docs pages it links — your engine knowledge may be out of date, wrong, or for a different version. Name the files and pages you read in your report. Do only what's asked. Don't change unrelated assets or files. Avoid long explanations.
Two ways in, same floors:
  • During project creation — the 
    new-unity-project
    skill loads this one and carries the floors through the build in the order below.
  • Mid-project, on any craft ask ("fix the look", "add sound", "it feels flat", "make a title screen", "score it") — jump straight to the matching reference, after the mid-flow check below.
Scope by the ask: a request that authorizes changes ("fix", "add", "polish") gets the floor applied; an assessment-only ask ("score it", "what should I fix?") gets the scored board and recommendations, with no project modifications until the user says go.
一个在功能上可用、但视觉和体验仍像程序员美术制作的游戏，在委托者眼中会被视为失败。本 skill 是打磨层：底线——每款游戏都必须达到最低标准、且引擎默认效果不可接受的各个领域——每个底线都由下方相应的参考文档承载，其中提供有明确取向的设定值、可供模仿的实作示例以及验证步骤。底线是铺装路径（paved）的核心（paved 是 Unity 面向 Agent 构建游戏时默认采用的脚手架：预先声明假设，并可凭用户一句话撤销）；在本 skill 中，paved 只是表示这些底线始终启用，除非用户明确拒绝其中一项。
在开始任何底线或诊断工作前，打开并阅读下方匹配的参考文档及其链接的 Unity 文档页面——你的引擎知识可能已经过时、有误，或对应的是其他版本。在报告中写明你读过的文件和页面。只做被要求的事。不要改动无关的资产或文件。避免冗长解释。
进入方式有两种，适用同一组底线：
  • 在项目创建期间——
    new-unity-project
    skill 会加载本 skill，并按以下顺序在构建过程中落实这些底线。
  • 在项目中途，针对任何打磨请求（“修复观感”“添加音效”“感觉平淡”“制作标题画面”“进行评分”）——完成下面的中途流程检查后，直接进入匹配的参考文档。
按请求确定范围：授权进行更改的请求（“修复”“添加”“打磨”）会应用对应底线；仅要求评估的请求（“进行评分”“我应该修复什么？”）则只返回评分板和建议，在用户同意开始前不修改项目。

Entering mid-flow

进入中途流程

The references assume an art bible (style statement + fixed palette) and, where audio meets UI, the mixer handshake (exposed params 
MusicVol
/
SFXVol
). On an existing project, run these in order before the asked-for floor:
  1. Restore point — confirm a clean commit to roll back to, or create one, before any change.
  2. Render pipeline — read 
    GraphicsSettings.currentRenderPipeline
    : the look floors' verifies are written for URP; on Built-in or HDRP, apply the opinions, name the pipeline gap, and skip the URP-typed checks.
  3. Art bible — look for a 
    Palette
    type or an art-bible note (CLAUDE.md, docs); if none exists, write the three-line bible from the game's current look first — retro-tinting later is the expensive order.
  4. Identity (live floor only) — verify player identity with a live probe (services initialized and a PlayerId present), never by assuming an earlier setup step ran.
  5. Scope the done gate to the surface you touched: a title-screen session scores the shell and look axes, not the whole board.
A floor fills an engine default, never a developer's choice. If the project already has its own controller, camera, shader, palette or style, keep it, apply only the floor's opinions that don't conflict, and name the difference in the report. Write an art bible only from choices the developer has made, and ask before adding one mid-project.
这些参考文档假定项目已有美术圣经（art bible：风格声明 + 固定调色板），并且在音频与 UI 相交的场景中已有 mixer 握手（暴露参数 
MusicVol
/
SFXVol
）。在现有项目中，在处理所请求的底线之前，按以下顺序执行这些步骤：
  1. 恢复点——在任何更改之前，确认存在可用于回滚的 clean commit；若没有，则创建一个。
  2. 渲染管线——读取 
    GraphicsSettings.currentRenderPipeline
    ：视觉相关底线的验证均按 URP 编写；如果使用 Built-in 或 HDRP，则应用其中的设计取向，在报告中指出管线差异，并跳过针对 URP 的检查。
  3. 美术圣经——查找 
    Palette
    类型或美术圣经说明（
    CLAUDE.md
    、docs）；如果不存在，先根据游戏当前风格编写三行美术圣经——之后再进行复古色调（retro tint）处理会导致昂贵的返工。
  4. 身份（仅 live floor）——通过 live probe 验证玩家身份（服务已初始化且存在 
    PlayerId
    ），绝不能假定之前的设置步骤已经执行。
  5. 限定完成门禁的范围——仅针对你接触过的界面进行评分：标题画面会话应评分外壳和视觉轴，而不是整张评分板。
底线用于补齐引擎默认项，绝不替代开发者的选择。 如果项目已有自己的控制器、相机、shader、调色板或风格，应予以保留，只应用与其不冲突的底线设计取向，并在报告中说明差异。美术圣经只能依据开发者已经做出的选择来编写；在项目中途添加美术圣经前，必须先询问用户。

The floors — numbered in build order, read each at its moment

各项底线——按构建顺序编号，到达相应阶段时再阅读

  1. art-direction — before the first material, light, or UI element
  2. scene-lighting — with the visual baseline (3D)
  3. toon-shading — when the art bible picks a cel/toon style (3D)
  4. camera-rigs — first gameplay camera (has a 2D section)
  5. placeholder-assets — first missing asset
  6. character-motion — first moving character (3D-leaning)
  7. (the playable loop lands here — loop before content, one system per pass)
  8. game-feel — the feel pass, after the loop
  9. vfx — with the feel pass (has a 2D section)
  10. game-audio — before done
  11. game-shell — before done (2D backdrop delta). Before the first TextMeshPro text, import TMP Essentials (see the reference's failure table).
  12. live-floor — with the shell (services before gameplay code)
  13. visual-scorecard — the done gate, always last; run it once a playable loop exists. During project creation, stop at the lit-baseline capture and skip the gate.
Mid-project asks enter at the matching number and pull earlier floors only as the mid-flow check requires (the bible, the pipeline, the identity probe).
Resolving 
<VERSION>
in the references' doc links — prefer WebFetch of the exact page over WebSearch: for 
docs.unity.com/en-us/engine/<VERSION>
manual and script-reference pages, use the project's Editor stream (e.g. 
6000.3
) from 
ProjectSettings/ProjectVersion.txt
, and the same stream for the remaining 
docs.unity3d.com/<VERSION>/Documentation
pages; for 
docs.unity3d.com/Packages/<package>@<VERSION>
pages, use the installed package's major.minor from 
Packages/manifest.json
or the 
Library/PackageCache
folder name; the 
docs.unity.com/en-us/<service>.md
services pages are unversioned.
Routing follows the game's 2D/3D nature; the 2D look floor (sprite art direction, 2D lights, sprite placeholders) is not yet covered — on a 2D game, say so at those beats rather than applying 3D instructions. The scorecard's 2D anchor set still applies.
  1. art-direction——在第一个材质、灯光或 UI 元素之前
  2. scene-lighting——与视觉基线一同进行（3D）
  3. toon-shading——当美术圣经选择 cel/toon 风格时（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 backdrop 差异）。在首次使用 TextMeshPro 文本之前，导入 TMP Essentials（参见该参考文档的故障表）。
  12. live-floor——与游戏外壳一同进行（服务先于 gameplay 代码）
  13. visual-scorecard——**完成门禁，始终最后执行；可玩循环存在后运行一次。**在项目创建期间，停在 lit-baseline 截图阶段并跳过门禁。
项目中途的请求从匹配的编号进入，并且只在 midway check 要求时拉入更早的底线（美术圣经、管线、身份探测）。
解析参考文档链接中的 
<VERSION>
——优先对确切页面使用 WebFetch，而不是 WebSearch：对于 
docs.unity.com/en-us/engine/<VERSION>
手册和脚本参考页面，使用项目的 Editor stream（例如 
6000.3
），其值来自 
ProjectSettings/ProjectVersion.txt
；其余 
docs.unity3d.com/<VERSION>/Documentation
页面也使用同一 stream；对于 
docs.unity3d.com/Packages/<package>@<VERSION>
页面，使用已安装 package 的 major.minor 版本，可从 
Packages/manifest.json
或 
Library/PackageCache
文件夹名称获取；
docs.unity.com/en-us/<service>.md
服务页面不区分版本。
路由根据游戏的 2D/3D 属性而定；2D 视觉底线（sprite 美术指导、2D 灯光、sprite 占位资产）尚未覆盖——在 2D 游戏对应节点应明确说明这一点，而不是套用 3D 指南。评分卡的 2D 锚点集仍然适用。

The boundary (what this skill is not)

边界（本 skill 不负责的内容）

This skill owns opinionated creation and floors — which values, in what order, to what bar. Catalog neighbours own mechanics on existing setups: volume/post mechanics → 
urp-postprocessing
· routing sources into existing mixer groups → 
audio-setup-mixers
· audio import/memory → 
optimize-audio
· UI framework choice and construction → 
ui
· font assets → 
optimize-text-mesh-pro
· backend services → 
build-live-game
· pixel-perfect 2D → 
2d-pixel-perfect
. When an ask is purely mechanical, route there; when it's "make it good," it's this skill, which then delegates the mechanics. If this index wants to grow, the new thing is a catalog skill routed by the prompt, not another floor — a floor must apply to every game.
本 skill 负责有明确取向的创作与底线——采用哪些设定值、按什么顺序执行，以及达到什么标准。目录中的邻近 skill 负责基于现有设置实现机制：音量/后处理机制 → 
urp-postprocessing
· 将音源路由到现有 mixer 组 → 
audio-setup-mixers
· 音频导入/内存 → 
optimize-audio
· UI 框架选择与构建 → 
ui
· 字体资产 → 
optimize-text-mesh-pro
· 后端服务 → 
build-live-game
· 2D 像素级精确显示 → 
2d-pixel-perfect
。当请求纯粹是机械性工作时，应路由到对应 skill；当请求是“把它做好”时，则使用本 skill，再由它委派具体机制。如果此索引需要扩展，新内容应是根据提示进行路由的目录 skill，而不是另一条底线——底线必须适用于每款游戏。

The done gate

完成门禁

A craft session ends with visual-scorecard's board — scored frames, not a green compile. In order:
  1. Score all six axes per the scorecard. All six at 3 or better is the floor.
  2. Fix pass — anything below 3 gets its fix before done (assessment-only asks: scores and recommendations, no fixes). If a fix doesn't work, reread the relevant reference and its linked documentation before trying variations.
  3. Console — confirm zero console errors.
  4. Play check — enter Play mode and check the touched behavior with 
    Debug.Log
    lines you added for the purpose. If the fix pass or this check fails, reread the relevant reference and its linked documentation before trying variations.
一次打磨会话应以 visual-scorecard 的评分板结束——评分依据是渲染帧，而不是编译变绿。顺序如下：
  1. 评分——按照评分卡对全部六个维度评分。所有维度达到 3 分或以上即达到底线。
  2. 修复环节——完成前修复所有低于 3 分的维度（仅评估的请求：只给出评分和建议，不做修复）。如果某项修复无效，应重新阅读相关参考文档及其链接文档，再尝试其他方案。
  3. 控制台——确认控制台中没有错误。
  4. 游玩检查——进入 Play mode，并使用为此目的添加的 
    Debug.Log
    行检查所触及的行为。如果修复环节或此检查失败，应重新阅读相关参考文档及其链接文档，再尝试其他方案。

Final report

最终报告

State: which floors ran and which references were read · the board (or the scoped axes) before and after the fix pass · every incidental side effect — packages installed, files or settings edited, assets imported — and any follow-up the user needs · any floor skipped or gap named (the 2D look floor, a declined install, a missing neighbour skill), so the user knows what deeper guidance was skipped.
说明：运行了哪些底线、阅读了哪些参考文档 · 修复环节前后的评分板（或限定维度的评分）· 所有附带副作用——已安装的 package、已编辑的文件或设置、已导入的资产——以及用户需要跟进的事项 · 任何被跳过的底线或已指出的缺口（2D 视觉底线、拒绝安装、缺少邻近 skill），让用户知道跳过了哪些更深入的指导。

Common mistakes

常见错误

  • Polishing without a bible — fixing one object's look against no palette; write the three-line bible first, even mid-project.
  • Replacing a developer's choice with a floor recipe — an existing custom controller, camera, shader or palette stays; the fix pass never swaps it for the floor's default.
  • Treating a floor as a feature — floors are defaults; the user declines one with a word, and the decline is recorded in the report, never argued.
  • Running the mechanics from memory when a neighbour skill owns them — route and delegate.
  • Skipping the done gate because the change was small — scope it down instead.
  • Applying 3D look instructions to a 2D game — name the gap instead.
  • 没有美术圣经就直接打磨——在缺少调色板的情况下修复单个对象的外观；即使在项目中途，也要先编写三行美术圣经。
  • 用底线配方替换开发者的选择——已有的自定义控制器、相机、shader 或调色板应保留；修复环节绝不把它们换成底线的默认实现。
  • 把底线当成功能——底线是默认标准；用户可以用一句话拒绝某项底线，且应在报告中记录该拒绝，绝不与之争辩。
  • 当邻近 skill 负责机制时，仍凭记忆实现机制——应进行路由并委派。
  • 因为改动很小就跳过完成门禁——应相应缩小评分范围，而不是跳过。
  • 把 3D 视觉指南应用到 2D 游戏——应明确指出相应缺口。