我从 @xikhar 的 AI 游戏工作流中借鉴的检查点：在构建关卡之前先玩原型。

他的帖子描述了这一流程：

1. 生成参考视频，以确立世界观、角色和视觉方向。
2. 使用其中的帧来指导 Blender 资产和 Three.js 场景。生成角色视图，然后将其转换为 3D 模型。
3. 试玩原型，确认其正常运行后再进行扩展。
4. 在既定风格下创建关卡概念，构建场景，然后重复“试玩-报告错误-修复”的循环。

当多个工具正在制作同一款游戏的各个部分时，这种顺序至关重要。参考帧为资产制作提供了具体的目标。可玩的原型让你有机会在这些问题蔓延到更多关卡之前，发现移动或几何结构方面的问题。

该帖子将 Video2Game 列为灵感来源。该项目的仓库使检查过程更加明确：其说明要求在固定检查点进行并排比较，并使用键盘驱动的场景来检查游戏状态。

这些检查回答了不同的问题：

• 场景是否符合预期的外观和摄像机角度？
• 玩家能否执行预期的操作，并产生预期的状态变化？

视觉相似性和可玩行为需要独立的证据。一个看起来不错的场景仍然可能存在损坏的移动、碰撞或进度问题。

24小时极限开发是作者的报告，而非复现的基准测试。他还表示尚未测试不同的浏览器和配置。不应将 Video2Game 的记录检查视为该特定游戏已通过这些检查的证明。

这里的工程价值在于可检查的参考文件和可玩的检查点的序列。它让 AI 辅助原型能够在世界围绕未解决问题扩张之前，通过测试得到改进。

https://x.com/xikhar/status/2117776295534997818
https://github.com/lovisdotio/video-to-game
https://x.com/xikhar/status/2117857276027658469