Evilom
9.9 KiB
GfgYwRD7Yiyac0kVWOtc9WFjn2c
Source: https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c
一、主要进展
- 今天的重点是继续围绕已确定的目标竞品，梳理并锁定项目的局外主循环方向。当前项目方向已经从前几天的底层架构搭建，逐步进入到“可看、可跑、可演示”的玩法闭环阶段。
- 目前局外循环按参考合了个合，确认为：资源/武器获取 -> 二合升级 -> 战斗推进 -> 金币与奖励结算 -> 再次投入成长
二、视频抽帧特征提取工具
今天借鉴了前几天看到的极逸SOON AI, 功能是输入一个视频, 输出一个小游戏
按着这个思路, 完成了一个感觉会很有用的AI研发工具节点：视频抽帧特征提取工具
这个工具的作用是把参考游戏的视频转换成可输入多模态AI的带注释的图，并且可以由ai自身调用。后续在拆竞品、做玩法复刻、生成 HTML 原型、整理程序交接文档时，都可以先通过这个工具把视频处理成关键帧、时间线和分析报告，再交给 AI 进一步理解和产出。
执行效果▼
程序本体, README文档与Skill▼
这个工具重点解决了普通平均抽帧的一个关键问题：固定间隔抽帧会丢失高动态过程, 无信息帧又浪费token。
例如战斗清屏、金币雨、弹窗切换、角色下落、奖励飞散等过程，如果只按固定时间截图，AI 可能只看到前后两个状态，从而误判为“瞬移”或“状态突然变化”。这会直接影响后续对玩法节奏、动画反馈和功能逻辑的复刻判断。
本次工具采用了更适合游戏视频的处理方式：
- 低信息密度片段少抽帧，例如长时间静态 UI。
- 高信息密度片段密集抽帧，例如战斗爆发、金币雨、弹窗切换、奖励结算。
- 自动生成 contact sheet，方便 AI 和人工快速浏览完整流程。
- 自动生成 timeline.json，将视频中的关键时间点和画面变化结构化。
- 自动生成 analysis_report.md，记录视频信息、关键帧数量、运动事件和模型读取预算。
如图，工具将竞品视频整理为多页关键帧总览，便于快速复盘玩法流程▼
本次使用目标游戏视频完成测试。测试视频为竖屏，分辨率 1080x2400，时长约 134 秒。工具成功抽取关键帧 158 张，识别运动/场景变化事件 39 个，并将 contact sheet 拆分为 7 页，避免单张图过长导致 AI 视觉读取效率下降。
如图，工具识别并连续保留战斗与金币雨高动态过程，避免普通抽帧造成动作断裂▼
通过这次工具辅助分析，已经可以比较清楚地确认目标竞品的核心循环： - 上方武器棋盘二合
- 下方人海战斗阵列验证数值
- 金币购买武器
- 广告激励弹窗
- 小游戏导流弹窗 AI直接读取视频，然后得到游戏玩法的信息，并且逆向输出策划文档供进一步审阅。 这说明工具已经能初步支撑“输入竞品视频 -> 提取富信息材料 -> AI 理解玩法 -> 输出原型/文档”的工作流。
三、视频解析工具具体技术
过去拆竞品通常依赖人工看视频或者玩游戏、截图、写笔记，再把观察结果交给 AI 或程序。这种方式很容易遗漏高动态细节，也很难稳定复用。 现在有希望简化成： 竞品视频 -> 工具提取关键帧与时间线 -> AI 阅读结构化材料 -> 输出玩法拆解/HTML 原型/程序交接文档 这对尤其对快速开发有价值。因为 IAA 小游戏的很多关键设计并不只在静态 UI 上，而是在短时间反馈里，例如广告奖励触发、金币飞行动画、战斗清屏、弹窗层级、自动合成节奏、小游戏导流包装等。 如果这些内容都靠人工输入给AI，效率会比较低。通过工具先做信息提炼，再让 AI 进行理解和复刻，可以明显降低前期拆解成本，也更适合后续快速测试多个小游戏方向。
基础处理流程
工具目前采用 Python + OpenCV 实现，整体流程如下： 也就是说，AI 实际看到的不是原始视频，而是经过工具压缩后的高信息量的视觉摘要。
高信息密度多抽、低信息密度少抽
普通平均抽帧的问题是：每隔固定时间取一张图，不管这段画面有没有发生变化。这会导致两个问题：
- 静态 UI 会产生大量重复帧，浪费视觉 token。
- 战斗、金币雨、弹窗切换等高动态过程反而可能被漏掉。 本工具通过 motion_score 解决这个问题。它会将当前帧缩放到较小尺寸，转为灰度图，并与上一帧做像素差分。差分越大，说明这段时间画面变化越剧烈。 当前选择策略大致为：
- 第一帧保留，作为起点。
- 超过固定时间间隔的帧保留，作为常规时间线锚点。
- motion_score 超过阈值的帧保留，作为高动态关键帧。
- scene_score 超过阈值的帧保留，作为大幅画面变化或弹窗切换节点。 这样可以做到： 静态界面少抽，动态过程密集抽。 例如在本次测试视频中，战斗与金币雨发生在约 115.94s - 119.78s 之间，工具连续保留了多个高动态帧，而不是只留下前后两个状态。这一点可以避免 AI 把“连续战斗结算”误读成“画面瞬间跳变”。
用 contact sheet 降低多模态读取成本
多模态模型读取图片是有成本的。如果直接把 158 张关键帧逐张交给 AI，会造成较高的视觉 token 消耗，也不利于先建立整体理解。 所以工具会把关键帧按时间顺序拼接成 contact sheet。每页包含一组关键帧，并在每张小图下方标注时间点和抽取原因，例如：
- regular
- motion
- scene
- start 这样 AI 可以先用低细节模式阅读 contact sheet，快速理解完整视频流程；只有在某些片段存在歧义时，再单独打开高动态关键帧做高细节阅读。
timeline.json 让视频信息结构化
除了图片外，工具还会生成 timeline.json。这个文件记录了每个采样点的：
- 视频帧号
- 时间戳
- motion_score
- scene_score
- 抽取原因
- 对应图片路径 这一步把视频中的视觉变化转成了可被程序和 AI 共同读取的结构化数据。 后续 AI 不需要只靠“看图猜时间关系”，而是可以结合时间线判断：
- 哪些片段是稳定 UI。
- 哪些片段是战斗高动态。
- 哪些片段是弹窗或场景变化。
- 哪些帧应该作为复刻玩法时的重点参考。
模型读取预算估算
工具还会在 summary.json 和 analysis_report.md 中生成视觉 token 预算估算。 目前采用的是工程上的粗略规划值：
- contact sheet 适合低细节读取。
- 高动态单帧适合高细节读取。
- 默认只建议挑选一部分关键帧进行高细节分析。 这让整个流程从一开始就考虑“AI 读取成本”，而不是把所有图片无差别喂给模型。
当前版本与后续扩展
当前版本已经完成第一阶段能力：
- 视频元信息读取
- 自适应抽帧
- 高动态片段识别
- contact sheet 生成
- timeline.json 结构化输出
- 分析报告生成
- 独立 CLI 调用 后续可以继续扩展为更强的视频理解工具：
- 引入 OCR，识别 UI 文本、按钮、等级、金币数。
- 引入光流，区分镜头移动和物体移动。
- 引入目标追踪，跟踪角色、武器、金币、弹窗等对象。
- 引入事件聚类，自动标记“战斗开始”“奖励弹窗”“金币结算”“广告触发”等片段。
- 引入 ffmpeg 后端，提高视频格式兼容性。
- 输出更接近游戏复刻需求的 mechanics.md，直接总结玩法规则和程序实现建议。
四、今日实际完成内容
- 完成视频抽帧特征提取工具第一版, 并且实际使用在参考游戏上, 得出对应的富信息原型
- 梳理当前项目局外主循环。
- 开始接入并调试战斗系统基础流程。
五、项目进度评估
当前项目整体进度尚可，个人暂定目标预估完整玩法闭环预计5月29日前后完成
前两天主要完成的是底层能力建设，包括二合架构、配置表、资源系统、存档和基础测试能力。今天在目标竞品方向明确后，开始把这些底层能力向完整系统闭环和视觉表现上推进。
从当前节奏判断，完整玩法开发预计在5月末6月前形成闭环，也就是约23周左右。
基础框架与核心循环（已经完成2-3天）： 底层状态机、存档、资源加载机制已完成。
核心战斗/合成逻辑拓展（估计6天）： 二合玩法的多阶生成逻辑、战斗系统, 网格判定、手感调优, 动画和粒子效果。
商业化与外围系统（预计4天）： IAA 游戏的核心是“看广告机制”。这部分需要接入虚拟的激励视频系统节点，并完成双倍奖励、加速、商店等强商业化逻辑
平台上架相关（预计47天）：这块需要研究, 小游戏平台上架、广告 SDK、审核规范、包体要求、数据埋点等流程，目前还没有完整走过。虽然当前开发节奏中已经预留了一部分时间，仍需要后续推进到对应任务时进一步确认时间。
六、明日计划
- 继续调试战斗系统接入，确保基础战斗流程稳定
- 补齐金币掉落与结算反馈。
- 补改游戏的新UI
七、总结
当前项目方向已经明确，重点是把局外循环和战斗流程快速做成可演示版本，并围绕目标时间前完成完整玩法闭环这个目标持续推进。