这是熊猫的第472篇原创
大家好，我是熊猫。
之前我做了一个把角色图片变成游戏帧动画的 Skill，作为我的第一个开源项目，有人在github点star和folk了。
我开源了一个Codex Skill｜把角色图片变成游戏帧动画
这次又开源了一个新的 Codex Skill：video-to-ios-game。
它想解决的问题是：如果我手里只有一段游戏录屏，能不能让 Codex 帮我把它还原成一个可以运行的 iOS 游戏？
这里的还原不是把视频简单放进 App 里播放，而是让 Codex 先理解视频里的玩法，再生成 SwiftUI 游戏代码、关卡配置，最后完成构建和测试。
一段视频，怎么变成一个游戏
这个 Skill 的完整流程是：
游戏玩法视频
↓
分析玩法和关卡
↓
生成需求文档
↓
用户确认
↓
实现 SwiftUI 游戏
↓
构建、测试和模拟器检查
第一步不是马上写代码，而是先分析视频。
Skill 要求录屏里至少有 3 个真正可以玩的关卡。它会观察游戏的目标、点击或滑动方式、关卡状态、成功反馈、重置逻辑，以及不同关卡之间发生了什么变化。
这些内容会被整理成一份需求文档，并且区分哪些是视频里直接观察到的，哪些是根据画面推断出来的。
只有需求文档确认之后，才会进入实现阶段，这样才能保证质量。
为什么要加这一步？
因为我试过直接让 AI 看完视频就写代码，很容易得到一个看起来像的界面，但玩法规则、关卡数据和交互细节可能完全不对。
然后就需要反反复复来改。
先把视频变成一份可确认的产品说明，后面实现时就有了明确依据。
从视频复刻成配置化游戏
这个项目不希望每次都生成一个只能运行一次的 Demo。
所以我把游戏内容和游戏逻辑分开了。
以仓库里的 Word Spin 示例为例，关卡里包含图片线索、答案、棋盘行列、字母初始布局、难度和提示次数。
新增普通关卡时，只需要增加一份配置和经过授权的图片，不需要重新修改 SwiftUI 页面或移动规则。
示例展示了原版游戏录屏、需求文档、配置化 SwiftUI 游戏和模拟器录屏之间的对应关系，还提供了 Level 10、Level 11 和 Level 12 的原版与生成结果对比图。
复刻版本的游戏，图片都是codex 从视频抽帧生成的。
Level 10 STAR 原版与生成结果对比
Level 11 SNEAKER 原版与生成结果对比
Level 12 APPLE 原版与生成结果对比
这也是我觉得这个 Skill 比一次性代码生成更有价值的地方：视频负责提供玩法证据，配置负责承载关卡内容，代码负责实现可以重复使用的游戏规则。
Codex 还要负责验证
实现游戏只是中间过程，后面还需要构建、单元测试、UI 测试和模拟器视觉检查。
比如要验证滑动一行或一列之后，字母是否按照规则移动；答案完成后，成功状态和下一关是否正常；重新打开 App 时，关卡进度是否能够保留。这些验证也被写进了 Skill 的工作流程里。
我还增加了一个admob的接入建议
如果后面要接入 AdMob，放在核心游戏完成之后。
默认可以接入底部 Banner、从第 5 个有序关卡开始的自动插屏广告，以及用户主动点击道具时触发的激励视频，但广告不可用时，游戏本身仍然应该可以正常运行。
我把这个项目开源，是因为我觉得看视频做游戏框架可能会成为一种新的原型方式，做简单游戏生成app的门槛已经非常低了。
以前的流程通常是：先拆玩法，再画界面，再写规则，再手动补关卡。
现在也可以先从一段录屏开始，让 Codex 帮忙完成分析、需求整理、实现和验证，最后再用结构化的数据去替换关卡。
当然，它不是一个完全自动化的万能按钮。视频质量、玩法复杂度、素材版权和 Xcode 工程状态，都会影响最后结果，但至少这条链路已经被整理成了一个可以复用的 Skill。
项目地址：
github.com/youxichuhai/video-to-ios-game如果你经常需要根据竞品录屏做玩法原型，或者想把一个已有玩法快速改造成自己的 iOS 游戏，然后上架到app store去赚广告费，可以试试这个项目。
最后，再补充下这个skill的边界，这个skill 用swiftui 复刻出来的游戏，大概能打到59分。
动效太复杂的，还是需要手动去调整；
尺寸的细节，复刻还是会有差异，要自己去调整；
关卡的数据，每一关的图片，题库，题目的初始状态，还是需要自己去配置；
不同操作的手感，以及震动反馈，也需要去手动调整；
好处是框架已经搭好了，你只需要去填空和打磨。
让codex拼接了一个对比视频，可以看看：
视频内容暂未收录。
开源相关阅读
我开源了一个Codex Skill｜把角色图片变成游戏帧动画
看到这了，点点关注👇