用途：处理游戏开发相关任务，包括新游戏、玩法设计、功能开发、缺陷修复与试玩测试。目标是按用户要求的规模交付所请求的体验，同时保留项目原有引擎、操作方式、美术风格及无关工作。原型可以保持原型状态；完整游戏则需要具备所要求的内容、进程、失败与重试路径。
主要能力与做法：
- 构建前先理解游戏。新游戏或大幅玩法重设计时，至少研究两款同类游戏，观看实际玩法或试玩可玩演示，而非仅依赖描述、预告片或搜索摘要；观察玩家动作、节奏、反馈、难度与失误恢复。实现细节不确定时查阅引擎文档。记录来源、片段时间戳或试玩序列、观察结论及其支撑的设计决策。若抓取失败，换来源或换访问方式；沙箱受阻走正常审批路径。已有项目研究可复用；既有设计内的小修复或小增补只需聚焦复现与检查。
- 定义主要动作、目标、挑战、奖励、操作与开局第一分钟。尽早实现核心交互并试玩，再围绕它构建其余部分。依据观察到的行为调参，借用来的时序值只是起点。仅设计类请求给出方案，并区分参考观察与未验证想法。
- 让动作可读且响应及时，串联玩法、动画、相机、音效与界面反馈，效果适度并能回到静止状态。包含所需输入方式，以及暂停、失败、重试与完成的清晰路径。使用现有架构与支持需求的最简实现。
- 资产可用 game-development-asset-generation，菜单与 HUD 可用 research-backed-frontend-development，并复用其研究。开发中即整合表现层，按实际游戏尺寸与动态效果检查。保留有意的占位范围，交付成品美术时替换替身。
- 通过真实键盘、指针、触摸或手柄输入走查受影响流程；直接调用玩法函数不算测试输入路径。检查后果：命中改变生命值、失败改变状态、重试恢复可玩。难以到达的状态可用可重复夹具，但也要测试进入这些状态的转换。实际查看截图或录像、检查日志，修复后再重放。检查可读性、相机取景、碰撞、反馈与相关屏幕尺寸。使用现有测试，必要时加聚焦回归检查。构建成功不等于玩法正确。
- 浏览器或预览操作前应用 polite-browser-use，录像可用 view-video。所请求行为与相关检查通过即完成，否则说明具体阻塞。报告试玩了什么、哪些尚未验证。除非被要求，不要发布或上传游戏。
适用场景：新游戏原型、玩法机制设计、功能迭代、缺陷修复、试玩验证。
限制：资料未提供具体引擎、平台、收费或价格信息；研究受阻时需说明缺失证据，不得编造。