10 个游戏开发 Agent Skill：从原型到手感，怎么选、怎么组合
用 Codex 做一个能动起来的小游戏，现在已经不算难。真正麻烦的，是后面的事。
角色能移动，但手感很飘；界面在电脑上正常，换到手机就错位；单机版本跑通了，一加多人联机，状态同步、房间管理和作弊校验全来了。这也是游戏开发 Skill 越来越细的原因。
有的负责把原型做出来，有的专门处理引擎和架构，还有的只做一件事：让一次跳跃、碰撞或者攻击真正“有感觉”。
下面这张榜单整理了 10 个热度较高的游戏开发 Agent Skill。
注：排名和安装量采用图片中的“2026 年第五期”快照，仅作热度参考。Agent Skill 更新很快，正式安装前仍要检查仓库说明、最近更新和依赖。
这 10 个 Skill 不能简单理解成“第一名一定比第十名好”。它们解决的根本不是同一个问题。
1. higgsfield-game-generation：从素材到可玩游戏的一整条链路
这个 Skill 覆盖得最完整。
它可以围绕浏览器游戏组织设计、生成精灵图和纹理等素材、编写游戏、验证完整循环，再部署成可访问的版本。除单人游戏外，它也覆盖本地和在线多人场景。
它更像一条完整的游戏生产线，而不是一份普通的编码提示词。
代价也很明确：它依赖 Higgsfield CLI、账号和对应服务。如果只是想在现有仓库里改一个小游戏，没有必要为了“功能最全”先把整条链路接进来。
适合： 希望快速完成浏览器游戏，并且同时需要图片、3D 或音频资产的人。
2. game-engine：网页游戏的工程底座
game-engine 关注 HTML5、Canvas、WebGL 和 JavaScript 游戏开发。
游戏循环、输入、碰撞检测、精灵、音频、2D/3D 渲染，以及 Phaser、Three.js、Babylon.js 等常见技术路线，都在它的覆盖范围里。
它的价值不是替你发明玩法，而是让 Codex 在实现玩法时少走一些工程弯路。
适合： 想从零搭网页游戏，或者希望 Codex 在已有代码里按相对完整的游戏架构工作。
3. multiplayer-game：多人联机不是加一个 WebSocket 就结束了
多人游戏最容易被低估。
除了连接本身，还要处理匹配、房间、状态同步、Tick Loop、兴趣管理、服务端校验和断线恢复。
榜单里的 multiplayer-game 主要面向 RivetKit，提供的是多人游戏的工程模式和检查清单。它不是一套适用于所有技术栈的通用联机魔法。
适合： 已经确定使用 RivetKit，或者希望参考较完整的多人游戏架构。
如果只是做单机小游戏，可以先跳过。
4. game-developer：覆盖面很广的通用游戏开发角色
这个 Skill 更像一名通用型游戏开发顾问。
它通常会从玩法需求、目标平台、引擎架构、图形性能和多人系统几个角度给出实现方案，覆盖 Unity、Unreal、Godot 等常见方向。
优点是覆盖面广，适合做方案讨论和架构检查；缺点也是覆盖面广——如果你的项目已经明确是 Three.js 网页小游戏，专用 Skill 往往更直接。
适合： 项目前期选型、跨引擎讨论，以及需要整体开发视角的项目。
5. game-ui-design：先解决“看起来像不像游戏”
游戏 UI 不是把普通网页按钮换个渐变色。
HUD、菜单、血条、背包和结算页，都要服从游戏类型、信息优先级和玩家注意力。
game-ui-design 更偏视觉设计和体验判断：界面应该呈现什么气质、哪些信息必须被快速看见、不同设备上的阅读距离如何影响设计。
适合： 游戏功能已经有了，但界面仍像后台管理系统或者普通网页。
6. game-design-theory：别急着写代码，先把核心循环想清楚
不是所有问题都能靠多写代码解决。
如果玩家不知道为什么继续玩，或者奖励、难度和反馈没有形成循环，技术实现再完整，也可能只是一个能运行的 Demo。
game-design-theory 主要提供 MDA、核心循环、玩家动机、难度和奖励设计等理论框架。
适合： 定玩法、写游戏设计文档、检查核心循环。
它不负责把想法自动变成一款好游戏，但可以减少“做完才发现不好玩”的概率。
7. game-feel：功能正确之后，再处理“打击感”
角色确实跳起来了，为什么还是觉得轻飘飘？
攻击命中了，为什么没有力量感？
问题通常不在规则，而在反馈。
game-feel 专门处理屏幕震动、Hit Stop、缓动、挤压拉伸、击退、闪烁以及多层反馈组合。它的定位很清楚：给已经存在的机制增加手感，而不是替你实现机制。
适合： 原型已经可以玩，但动作、碰撞和得分反馈显得单薄。
8. game-ui-ux：让 HUD 和菜单在不同设备上真正可用
它和 game-ui-design 看起来很像，实际上关注点不同。
game-ui-design 更偏视觉表达；game-ui-ux 更偏界面架构和可用性，包括响应式布局、分辨率适配、安全区域、手柄焦点、菜单流程，以及 UI 如何和游戏状态通信。
适合： 同时支持手机、桌面、超宽屏或手柄操作的游戏。
这两个 Skill 可以一起用，但职责最好分开，否则很容易产生重复甚至冲突的建议。
9. threejs-game-ui-designer：Three.js 项目的定向强化
如果项目已经确定使用 Three.js，这个 Skill 比通用 UI Skill 更贴近实际实现。
它关注 HUD、菜单、暂停页、胜负页、触控操作、响应式适配，以及游戏 UI 和 3D 世界的视觉一致性，并配套了完成前检查项。
适合： Three.js 游戏或 3D 网页互动项目。
如果项目使用 Unity、Godot 或纯 Canvas，就没必要因为它排在前十而安装。
10. develop-web-game：我更建议网页小游戏先从它开始
develop-web-game 来自 OpenAI Skills 仓库，思路并不复杂：每次只做一小步，然后实际操作游戏、暂停观察结果，再继续调整。
这套流程很像开发里的短反馈循环：
实现 → 操作 → 观察 → 修正。
它不会因为名字排在第十，就比前面的 Skill 弱。对于想用 Codex 做网页小游戏的人，它反而是很合适的默认起点，因为它把“能生成代码”变成了“生成后必须实际验证”。
适合： 网页小游戏、交互原型，以及需要持续试玩和迭代的项目。
这 10 个 Skill，应该怎么组合？
如果只是做一个网页小游戏，我会按项目阶段选择，而不是一次装满。
快速做出第一个可玩版本
develop-web-game + game-engine
前者负责小步实现和试玩验证，后者补充网页游戏的架构、输入、碰撞和渲染知识。
原型能玩，但体验比较粗糙
game-feel + game-ui-ux
一个处理动作反馈，一个处理 HUD、菜单和多设备适配。
确定使用 Three.js
game-engine + threejs-game-ui-designer + game-feel
这个组合更适合 3D 网页小游戏和互动体验。
要做在线多人游戏
在基础组合上加入 multiplayer-game，但前提是技术栈和 RivetKit 匹配。
希望资产、开发、验证和部署一起完成
可以评估 higgsfield-game-generation，同时把第三方账号、服务成本和部署方式算进来。
最后一个建议
安装量只能说明有多少人尝试过，不能证明它适合你的项目。
装 Skill 之前，至少看四件事：
- 它解决的是设计、编码、素材、验证还是发布？
- 是否绑定某个引擎、框架、CLI 或第三方服务？
- 仓库最近是否仍在维护？
- 输出有没有可运行、可试玩、可检查的验证环节？
对个人开发者来说，真正有用的不是“让 Codex 装上最多的 Skill”。
而是用两三个职责清晰的 Skill，把一个小游戏从想法推到真正能玩的版本。