我在 Unity Code MCP Server 中构建了一个 Search -> Execute -> Verify 循环,以测试游戏玩法的变化。
这是一个开源项目,允许 AI 代理进入 Play Mode,通过在 Unity 编辑器中执行 C# 脚本来检查实时运行状态,并通过 Unity Input System 动作模拟玩家输入。
核心工作流程是:
搜索实时状态 -> 执行更改 -> 验证结果 -> 重复
相比于仅仅读取源文件,代理可以进入 Play Mode 并在 Unity 编辑器中使用 C# 执行来检查实时运行状态:
- 场景对象
- 组件字段
- 物理值
- UI 层次结构
- 分数和计时器
- 输入配置
- 项目特定的玩法状态
然后代理可以使用 play_unity_game 来模拟玩家输入通过 Unity Input System 动作。它可以按住右键,点击跳跃,驾驶汽车,按 UI 按钮,提交对话,或者驱动菜单流程。这适用于游戏玩法和 UI 测试,只要行为可以通过游戏的输入路径来访问。
重要的是循环。代理不仅仅是盲目地按下按钮。它可以检查游戏,决定要做什么,运行游戏的控制时间,检查什么改变,并适应下一个动作。
我在一个简单的 Pong 项目上测试了这个。
代理的任务是:
玩 Pong。
用拍板 5 次将球弹起来。
使用进入 Play Mode 一次,然后使用 play_unity_game 进行玩法。
每次行动后都重新感知。
从不直接移动变换。
它读取球的位置和速度,预测球将在拍板线上何时交叉,计算精确的移动时间,并按住拍板输入动作的该时间。
示例决策输出:
SENSE: 球=(1.84,0.71) 速度=(4.2,-2.1) 拍板Y=0.10
COMPUTE: targetY=-0.43 action=Player1Down moveMs=132 safeIdleMs=0 delta=-0.53
然后它调用:
play_unity_game:
持续时间:132
输入:
- 动作:"Player1Down"
类型:持有
工具返回后,它读取日志并重新检查实时状态。如果球弹起来,它重新计算。如果游戏重置,它重新发现状态,而不是继续从陈旧的假设中。
为什么我认为这很有用
这很适合于重复的游戏检查:
- 这个输入动作还能用吗?
- 玩家是否仍然移动了吗?控制器重构后?
- UI 流程是否仍然响应提交/取消?
- 投射物是否仍然碰撞并得分?
- 场景是否在 Play Mode 中几秒钟后抛出运行时错误?
- 是否可以重复一个小场景而不必每次都手动打开游戏?
代理可以自动运行所有这些检查。
链接
完整的文章附有更多示例:
https://www.signal-loop.com/blog/playtest-unity-games-with-unity-code-mcp-server/
GitHub 仓库:
评论 (0)