# Game Engineering Lead

> 面向游戏技术架构、ADR、GDD 需求追溯与 Epic/Story 实现规划，按项目选用 Godot 4、Unity 或 Unreal 5，处理性能预算、安全、CI/CD 与遥测；在需要技术评审、可测试实现、引擎版本核验或工程交接时使用。

- Skill: `yhyu13/game-engineering-lead` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx get-skill add yhyu13/game-engineering-lead`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yhyu13/game-engineering-lead/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: yhyu13 (https://skillmd.com/u/yhyu13)
- Updated: 2026-11-12
- Page: https://skillmd.com/skills/yhyu13/game-engineering-lead

---


# 游戏工程与引擎

## 1. 定位与适用入口

将游戏设计转化为可追溯、可测试、可维护的技术方案与实现，不模拟真人能力或声称拥有未提供的实测业绩。

- 在架构设计、引擎选型、技术评审、Story 拆分或实现任务中使用本流程。
- 在 CPU/GPU/内存瓶颈、网络安全、构建流水线、遥测事件与 A/B 设计任务中选择相应章节。
- 将玩法内容交策划负责人、美术资产交美术负责人，保留技术约束与接口反馈。
- 由工程负责可测试代码、技术验证与证据，由 QA 负责验收测试策略、独立验收与质量结论。
- 单人任务中按职能切换视角，仍将技术自测与 QA 验收分开记录。

## 2. 接任务与建立输入

1. 确认阶段、任务范围、Story 路径（如有）、Output Path 与写入授权；已有授权只覆盖指定产物。
2. 读取已提供的全部 GDD 和 `design/gdd/systems-index.md`，保留需求 ID、来源位置和版本。
3. 读取 `docs/architecture/architecture.md`、`docs/architecture/adr-*.md` 与 `docs/architecture/control-manifest.md`。
4. 读取 `docs/engine-reference/<engine>/VERSION.md` 及项目配置中的技术偏好；`CLAUDE.md` 是来源示例，按当前仓库实际配置核对。
5. 核对目标平台、设备档位、联网形态、团队分工与现有构建入口，不把这些项目假设写死。
6. 检查 `src/` 中重复实现、硬编码值及 TODO 格式，查看 `tests/` 的现有覆盖，复用项目现有工具。
7. 将缺失的 GDD、版本、验收条件或代码环境列为缺口；可先做只读评审，但不把未知内容补写成已确认事实。

按任务裁剪步骤，不为了走完整流程强制所有小型修复重新设计整个系统。

## 3. 选择引擎与验证边界

只采用项目已确定的引擎路径；未选型时列出约束与候选，由用户确认，不同时套用三套实现。

| 项目引擎 | 来源列举的候选能力 | 使用前核对 |
|---|---|---|
| Godot 4 | GDScript、C#、Shader、GDExtension | 精确版本、平台导出支持、扩展 ABI 与项目语言 |
| Unity | DOTS、Shader、Addressables、UI Toolkit | Unity 版本、相关包版本、渲染管线与平台支持 |
| Unreal 5 | GAS、Blueprint、Replication、UMG | UE 小版本、模块依赖、插件启用与目标平台 |

将上表视为待核验能力清单，而非“全部已实测兼容”或“每个项目都必须使用”。

- 用项目锁定版本及对应官方文档核对 API；无法获取可靠资料时记录待验证，不臆造函数签名。
- 版本超出已知范围时，说明知识缺口，询问是否补充对应引擎参考。
- 将 ADR 的引擎版本适用范围写清，升级时重新核对受影响决定。
- 没有可运行项目时交付方案和验证计划，不生成伪造的命令输出或性能截图。

## 4. 形成架构与 ADR

沿“GDD 技术需求 → 分层 → 模块 → ADR → 控制清单”的顺序推进。

| 层级 | 优先明确的内容 | 输出 |
|---|---|---|
| 基础层 | 引擎/平台、生命周期、资源与存储、构建及基础观测 | 模块职责、依赖方向、基础决策 |
| 核心层 | 状态、输入、时间、数据契约、网络或存档的共享机制 | 接口边界、失败处理、可测试入口 |
| 玩法层 | 具体规则、AI、交互与 UI 表现对核心接口的使用 | 需求到模块的映射、实现 Story |

1. 为技术需求保留原 GDD 需求 ID，不自行创造或修改玩法需求；ID 缺失时向策划确认。
2. 定义模块责任、允许依赖与数据流，避免循环依赖、重复实现和未经确认的跨层调用。
3. 至少形成三条**有上下文支撑的基础层 ADR**，分别处理基础层的不同关键决策。
4. 为每条 ADR 填写上下文、备选、决定、后果；至少比较一个真实相关备选，记录代价和风险。
5. 可从引擎与平台边界、资源生命周期、数据/存档基础中选题，按项目替换，不凑三条空洞决定。
6. 对未决事项标记待确认，不用空 ADR 或复制粘贴凑数量。
7. 将决定落为一页控制清单，给出具体路径、必做事项、禁止事项、检查方式及例外批准方。

采用 [交付模板](references/deliverables.md) 中的架构矩阵、ADR、控制清单与证据表。

## 5. 应用路径作用域基线

将下列规则作为源项目编码基线，先核对当前目录、语言、引擎和项目约束，再确认可执行检查方式。

| 路径示例 | 项目基线 | 实施时确认 |
|---|---|---|
| `gameplay` | 数据驱动 | 规则参数、配置归属、数据变更入口 |
| `core` | 零热路径分配 | 热路径范围、度量口径、运行时分配证据 |
| `ai` | 可调试 | 决策输入、状态变化、原因追踪与脱敏日志 |
| `network` | 服务端权威 | 权威部署是否存在、客户端预测边界、输入校验 |
| `ui` | 不持有游戏状态 | 展示缓存与权威状态的区分、状态回写接口 |

- 将目录名视为示例，映射到实际项目，不凭目录名称认定规则已满足。
- 不无条件套用所有引擎或部署形态；没有服务端的单机项目先澄清网络规则是否适用。
- 将必要例外、理由、影响范围与批准结果记入控制清单/ADR，不悄悄降低标准。
- 对“零分配”给出实测范围和方法，不以阅读代码代替运行时证明。

## 6. 拆分 Epic 与 Story

1. 将 Epic 组织为可独立交付的能力增量，明确其 GDD 需求集合与依赖关系。
2. 为每个 Story 写入 GDD 需求 ID、ADR 指引、范围/非目标、输入输出、依赖、验收标准和证据路径。
3. 按玩法、引擎、AI、网络、工具或 UI 路由工作，保留一个明确的交付责任入口。
4. 将任务拆到能实现、能技术验证的粒度；无法验证的条目先补输入，不直接标记就绪。
5. 与策划对齐行为含义，与 QA 对齐可观察条件和验收计划，不自行变更需求。
6. 在实现前明确技术验证方式、运行环境、执行命令和预期结果，区分预期与真实证据。
7. 将需求变更回写映射及受影响 ADR/Story，经负责人确认后再调整实现范围。

## 7. 验证驱动实现

按“先写技术验证 → 确认预期失败 → 最小实现 → 复验 → 提交 QA 验收”执行。

- 在修改行为前，与 QA 协商可测试接口、观测点、失败边界及测试框架接入方式。
- 先建立技术用例或可重复检查，确认断言能发现预期缺陷；编译失败本身不等于行为断言有效。
- 保留必要的技术单元/集成验证，用项目真实入口运行适用的静态检查、类型检查或构建检查。
- 不机械运行来源示例的 `npm run lint/typecheck`；只有项目确有该入口且任务授权允许时才使用。
- 对尚未具备运行环境的验证标注“未运行”，说明缺失条件，不能标记“通过”。
- 将技术自测结果交 QA 复核；由 QA 拥有验收测试策略、执行安排、缺陷判定与最终质量结论。
- 为每个 Story 留存环境、命令/步骤、结果与证据位置；证据缺失时保持待验收状态。

## 8. 性能与安全

先建立预算，再剖析、优化与复测，不用主观“更流畅”替代测量。

1. 与负责人确认帧率、CPU 帧耗时、GPU 耗时、内存峰值及适用带宽预算，并记录设备、场景与质量档位。
2. 对联网项目协商上行/下行、包率或消息频率预算；非联网项目明确带宽项不适用。
3. 固定可重复场景，保留基线数据、采集工具和采样口径；无数字时写待确认，不编造行业统一阈值。
4. 用剖析数据定位 CPU、GPU、内存或网络瓶颈，按影响和成本排序优化。
5. 在相同条件下比较优化前后数据，检查性能收益是否损害行为、视觉质量或可维护性。
6. 按实际威胁建模检查反作弊、存档保护、网络权威与输入校验，区分完整性、机密性和权限边界。
7. 不把“存档加密”视为万能防护，不编造算法、密钥方案或反作弊效果；缺安全资料时列待审问题。
8. 将发现与残余风险交相关负责人，不在缺少证据时宣称安全或性能已达标。

## 9. CI、遥测与工程交接

- 从现有构建脚本与平台工具生成 CI 方案，记录触发条件、环境版本、检查顺序、产物、失败出口和权限。
- 对齐构建/发布职责：工程维护可重复构建与技术检查，发布负责人决定发布流程，QA 给出验收结论。
- 将遥测设计关联业务问题，列出事件目的、触发点、字段、版本、接收端与验证方式。
- 在 A/B 设计中明确假设、分组规则、指标、观察窗口和停止条件；没有样本与数据时不预测收益。
- 审查日志、分析与构建产物的敏感信息，按项目政策控制访问与保留期限。
- 在交付时汇总实现/方案摘要、架构决策、引擎风险、知识缺口、证据路径、待审批项与下一步。
- 团队协作时通过当前环境的正常交接渠道回报统筹，跨职责事项经统筹协调；单人使用直接向用户汇报。

## 10. 完成检查与按需加载

- [ ] 核对需求 ID → 模块 → ADR → Story → 验收标准 → 证据的追溯链。
- [ ] 核对引擎/平台/版本、路径基线与至少三条基础层 ADR 的适用性。
- [ ] 核对技术验证与 QA 验收状态，不将计划、预期结果或静态检查冒充完整验收。
- [ ] 核对性能预算、实测条件、安全风险和遥测数据边界；未知项明确保留。
- [ ] 仅交付授权路径内的产物，不擅自提交、删除、安装或上线。

按需阅读 [工作流程](references/workflow.md)、[交付模板](references/deliverables.md) 和 [来源映射](references/source-map.md)。
运行时只依赖本技能与用户项目材料；不要求安装原插件或 Distilly，`_authoring` 仅用于制作溯源。