Evilom
122 lines
9.9 KiB
Markdown
122 lines
9.9 KiB
Markdown
# 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月前形成闭环，也就是约2~3周左右。
|
|
基础框架与核心循环（已经完成2-3天）： 底层状态机、存档、资源加载机制已完成。
|
|
核心战斗/合成逻辑拓展（估计6天）： 二合玩法的多阶生成逻辑、战斗系统, 网格判定、手感调优, 动画和粒子效果。
|
|
商业化与外围系统（预计4天）： IAA 游戏的核心是“看广告机制”。这部分需要接入虚拟的激励视频系统节点，并完成双倍奖励、加速、商店等强商业化逻辑
|
|
平台上架相关（预计4~7天）：这块需要研究, 小游戏平台上架、广告 SDK、审核规范、包体要求、数据埋点等流程，目前还没有完整走过。虽然当前开发节奏中已经预留了一部分时间，仍需要后续推进到对应任务时进一步确认时间。
|
|
## 六、明日计划
|
|
- 继续调试战斗系统接入，确保基础战斗流程稳定
|
|
- 补齐金币掉落与结算反馈。
|
|
- 补改游戏的新UI
|
|
## 七、总结
|
|
当前项目方向已经明确，重点是把局外循环和战斗流程快速做成可演示版本，并围绕目标时间前完成完整玩法闭环这个目标持续推进。 |