摘要
在这款回合制战棋游戏里，玩家把鼠标指向一个敌方单位、准备普通攻击或施放技能/法术时，屏幕上会弹出一个小提示，写着“预计造成多少伤害、预计击杀几个”。这些数字发生在动作之前，是推断双方属性和构筑的宝贵证据，但它们很小、出现时间短，而且与说明文字、战斗日志里“已经造成的伤害”外观相似。
本实验先定义这类“目标预览”的观察格式，再从已有的 3 段战斗录像里整理参考图并做一个可解释的基线：用现成 OCR 在整张截图上找数字，再按几何位置判断哪些数字是预览。结果：50 张审核图中 30 张含预览，全图定位找到 29/30 个完整预览区域，20 张无预览对照图没有产生任何候选；但只有 25/30 个区域同时定位正确且两行文字完全读对。另一个简单的“这块裁图是否含预览”二分类器在按视频留出的数据上 F1 为 86.96%。技能的目标预览一个都没有确认到，所以没有训练“攻击/技能/法术”三分类。
要回答的问题
- 一张截图上怎样记录“释放前预览”，才能和动作已经发生后的实际伤害区分开？
- 不训练新模型，直接用整图 OCR 和数字的几何排布，能找到多少预览？
- 一个很简单的图像分类器能否判断“这里有没有预览”？
数据与来源
- 先对 3 段战斗录像已有的稀疏整图 OCR 缓存（每段 128 条）搜关键词“预计/伤害：/击杀：/反击：”等，命中多是选秀说明或等待时间，没有直接确认预览正例。稀疏缓存不能证明录像里没有预览。
- 又在一段录像的 198 个密集候选里目视 109 张缩略图，主要是单位移动、攻击效果和面板；一处疑似提示回到原图后确认是“完成战斗”对话框。这次搜索没有审计所有原始帧。
- 最终定向整理出 50 张唯一原图（51 条用途记录，其中一张同时有生物面板和预览，合并在同一帧下）：30 张含预览、20 张纯对照。按图计：21 张攻击（14 个保守的决策组）、5 张法术、4 张动作类别未知。
- 31 个预览数字区域中 30 个完整，1 个被面板遮住尾部、标为部分且不计分（不把可见的尾部当完整值）。
- 同图另记 24 组英雄界面数值和 3 个目标区域；目标区域只是关联参考，不是紧致的生物检测框。
- 标注由助手在原图/视频上核对，属于开发参考，不是用户人工审核的金标准。
方法
观察格式。 每个预览记录：场景层级（战场 → 战斗进行中 → 目标伤害预览）、动作类型（攻击/技能/法术/未知）、发起者和目标在同一帧里的实例引用、预览区域的原图坐标、原始文字和 OCR 分数、可读状态（可读/部分/过渡/未知），以及语义角色（目标预览/说明数值/实际结果/未知）。规则是：截图上看不出动作来源或目标，就保留“未知”，不从同屏人物去猜；画面上没有显示的数字，不能用规则模拟器补成 OCR 真值。
基线。 只给整张原图做 OCR，得到文字和位置，再把相邻的数字配成“伤害 / 击杀”对。定位过程不输入场景、动作或参考框。另外单独报告“已知参考框时 OCR 能否读回原文”。
简单分类器。 把 31 个真实预览裁图作为正例；从 20 张确认无预览的整图中，在预览常出现的相似位置采 40 个负例裁图。先试 32×32 RGB 像素 + Extra Trees（一种随机树集成），再试 64×64 灰度 HOG 特征（梯度方向直方图）+ 同样的 Extra Trees。它只回答“这块裁图里有没有预览”，不负责在整图上找位置。
设置
- 20 张原 OCR 缓存缺失的图补跑了 OCR：原图 2560×1440 和 1.5 倍放大图 3840×2160 各一次。
- 分类器按视频隔离：前两段视频的 40 个裁图（18 正/22 负）训练，第三段视频的 31 个裁图（13 正/18 负）完全留出；相邻帧不跨来源。
- 这 50 张是已经查看过的开发样本，不是全视频或独立测试。
结果
| 项目 | 结果 |
|---|---|
| 已知 30 个完整区域时，OCR 读回原文 | 57/60 行 |
| 已知区域时两行都对的区域 | 27/30 |
| 全图定位：完整区域 | 29/30（另 1 个部分区域也定位到） |
| 全图定位且两行文字都精确 | 25/30 |
| 全部候选数 | 32 |
| 20 张纯对照图的候选 | 0 |
| 分类器（留出视频 31 个裁图） | 结果 |
|---|---|
| 32×32 RGB + Extra Trees | 全部判负，F1 = 0 |
| 64×64 HOG + Extra Trees | 10 TP、3 FN、0 FP、18 TN |
| 准确率 / 精确率 / 召回率 / F1 | 90.32% / 100% / 76.92% / 86.96% |
OCR 计时：本地缓存模型启动 8.37 秒；20 张原图平均 0.214 秒、放大图 0.351 秒，两次加读取与放大合计约 0.600 秒。这不是视频端到端速度。
整理后的训练清单共有 80 条稀疏元素标注：31 个目标预览、24 个英雄界面数值、22 个文字或控件、3 个目标锚点；其中 2 条历史辅助文字没有位置，明确保留为未定位，没有编造框。按区域计的动作类别是攻击 21、法术 6、未知 4。
失败与负结果
- 两处高分 OCR 把预览数字和背景里的兵力数量拼在一起：15 与 46 被读成 1546，7 与 38 被读成 738。另有一处漏读数字 9、一处多配了一个 0。这些失败没有通过调参数去掉。
- 纯像素分类器完全失败（F1 为 0）。
- 关键词搜索只证明“有些预览没有关键词就会漏”，并没有在同一完整时段比较“稳定关键帧 / 局部变化 / OCR 先行”三种采样路线的覆盖率。
- 技能（ABILITY）的目标预览没有确认到任何正例。
局限
- 样本小，来自 3 段已曝光录像；所有数字都是开发参考上的结果，不是独立准确率。
- 法术归类依据的是短时上下文（图标停留、书页收起、目标指示连贯），不是看到了真实的输入事件。
- 分类器只证明局部外观方向可行，不能代替整图定位，也没有判断动作类别或目标绑定。
结论与下一步
整图 OCR 加数字几何排布已经能在这批图上找到绝大多数完整预览，且对照图零误报；主要错误是把背景数字拼进预览。首轮交付后停止无限扩搜。下一步请用户先查看这批标注，再补录技能目标预览和更多不同目标的法术预览（建议的录制顺序：看说明 → 选择动作 → 悬停两个目标 → 取消），在缺技能正例时不训练三类动作模型。
Comments