游戏美术与玩法工程
一套跨引擎的游戏工程方法论：覆盖美术资产生产、界面设计、架构分层、试玩验证与 3D 资产优化。
适用于网页游戏、微信小游戏、桌面游戏与原生引擎项目，不绑定任何特定运行时或软件。
使用方式：先路由，再深入
本 skill 将工程知识按领域拆分到 references/。SKILL.md 只做路由，不重复细节。
处理任何请求时，先按下表定位领域，只读取需要的那一份 reference，避免一次性加载全部内容。
| 需求类型 | 读取文件 |
|---|---|
| 精灵图、立绘、动画帧、帧锚点、图集 atlas、角色走路/攻击动画、帧间一致性 | references/01-sprite-pipeline.md |
| 架构分层、引擎选型、状态归属、输入映射、存档、性能边界 | references/02-architecture.md |
| HUD、菜单、游戏界面、响应式布局、触控控件、UI 美术 | references/03-ui-hud.md |
| 试玩验证、启动检查、回归测试、截图 QA、性能核查 | references/04-playtest-qa.md |
| Phaser / Three.js / React Three Fiber 引擎专项 | references/05-engines.md |
| GLB / glTF 资产转换、压缩、碰撞体、LOD、加载校验 | references/06-3d-assets.md |
| 从零做一款完整游戏、跨领域改动、任务模式判定 | references/07-production-flow.md |
请求只涉及单一领域时，直接读取对应 reference。
请求跨越多个领域时，保持一份计划、一个完成定义，避免各领域各做一套。
通用原则（所有领域适用）
- 先读项目现状，再动手。 已有项目的引擎、分层、命名与素材约定优先保留；除非目标无法实现，否则不迁移技术栈。
- 聚焦式改动。 一个功能或缺陷修复不构成重新设计整款游戏或重做全部美术的理由。
- 模拟与表现分离。 规则、实体、进度、计时、存档归模拟层；场景、动画、相机、粒子、UI 归表现层。
- 素材经稳定键寻址。 通过资产清单的稳定键引用资源，不在玩法逻辑里散落文件路径。
- 验证强度匹配改动范围。 未实际执行的检查不得声称已完成；视觉检查不可用时要明确说明哪些部分未经验证。
生成工具约定
本 skill 不绑定任何生图后端。执行美术生成时：
- 优先使用当前环境内置的图像生成工具。
- 若已安装图生图技能（如支持风格统一与局部编辑的 Agnes 图像生成），在需要保持角色一致性或基于参考图编辑时优先选用。
- 若三维生成能力不可用，改为获取现成模型文件后继续走转换与优化流程，并如实说明该限制。
- 生成失败时：使用连贯的替代方案并披露缺口，不无限重试同一失败请求。
- 实现便利不是用代码绘制占位图替代正式美术的理由。
质量底线
- 不得声称未执行的验证已完成。
- 不得用"构建成功"冒充"试玩通过"。
- 不得用"文件元数据存在"冒充"视觉一致性已验证"。
- 单张截图、单次 DOM 检查不构成完整试玩。
来源
本 skill 的工程方法论整理自开源项目 ohmygame（Apache 2.0），
已剥离其专有运行时、画布节点与内部工具依赖，改造为环境无关的通用流程。
