战后战斗日志：按时间线还原触发、来源与目标

[pengx17]

This was generated by AI during triage.

Summary

在战后或回放中提供按时间排序的战斗日志，帮助玩家看清“刚才发生了什么”。只呈现已发生的事实，不提供胜负归因、策略建议或未来预测。

初步范围

• 显示时间、效果来源、触发动作、目标与结果。
• 支持按物品、技能或状态类型筛选。
• 入口放在战斗结算或 Combat Replay；不做实时战斗助手。
• 复用现有 CombatSim / replay payload，不重复原生的汇总统计。

示例：

04.20  冰箱触发 → 冻结左侧物品 2 秒
04.35  燃烧触发器使用 → 对敌方英雄施加 18 燃烧
04.60  护盾被摧毁 → 触发核心技能

产品边界

• 不输出“为什么输”“本局 MVP”或“应该如何摆位”。
• 不做胜率、伤害预测或选择推荐。
• 无法精确解释的事件不做推测性归因。

可行性依据

• CombatSim 已包含逐帧事件：decompiled/BazaarGameShared/BazaarGameShared.Infra.Messages.CombatSimEvents/CombatSim.cs。
• CombatSimEventEffectExecuted 已提供 effect、source、trigger source、target：decompiled/BazaarGameShared/BazaarGameShared.Infra.Messages.CombatSimEvents/CombatSimEventEffectExecuted.cs。
• BPP 已通过 CombatReplayCaptureService 捕获并保存 combat payload：src/BazaarPlusPlus/Game/CombatReplay/CombatReplayCaptureService.cs。
• 与 Record a per-run choice timeline and ship it as an optional run bundle segment #33 互补：Record a per-run choice timeline and ship it as an optional run bundle segment #33 记录战斗外决策，本 Issue 消费已有战斗 replay 数据。

待确认

• 首版覆盖哪些事件类型，以及无法本地化的 effect 如何降级展示。
• 时间线入口是否先集成现有 Replay，后续再纳入 RFC: F8 Game History 整体优化与 Runs/Ghost 关联 #72 的 F8 History 信息架构。
• 长战斗的虚拟化、折叠与筛选交互。

验收方向

• 战后可按时间顺序查看关键触发、来源、目标和结果。
• 日志内容能与 replay 对应，不生成推测性结论。
• 不改变战斗流程，也不在战斗中提供决策提示。

[pengx17]

mock了一个

[pengx17]

Every fight you record is captured as a tick-by-tick replay. While you're a Supporter, they can be watched on your run pages, and anyone viewing your runs can watch them too.

发现好像bazaardb有提供，那就不做了

[pengx17]

设计与实施计划更新（2026-07-21）

此评论作为后续实现的持续更新摘要。当前方向是本地战后分析器：还原已发生事实，不提供胜负归因、策略建议或实时决策提示。

Context

BazaarDB 已有云端逐 tick replay，但仍缺少本地任意记录导入、事件来源/目标联动、录像对照、统计分析和离线资源能力。因此保留本 Issue，范围从“文字日志”扩展为独立的 post-combat analysis viewer。

最新设计

• 入口与载体：战斗结算或 Combat Replay 提供“查看详细对战记录”；由 installer 打开独立、可调整尺寸的 HTML 分析窗口。战斗数据、视频、图片和图标均来自本地。
• 时间轴：固定 px/s 宽度并横向滚动，不随视口压缩。视频、状态图和实体事件共用同一时间坐标。
• 状态图：敌我生命、怒气、再生、护盾画在同一 chart；默认数量级轴，同时保留线性切换和原始值 tooltip，以容纳指数级数值。
• 事件语义：UI 明确区分“施加/来源”“受到/目标”“触发”；hover 同时高亮相关物品、技能和目标。原始日志缺少来源时只标结算类型，不伪造归因。
• 碰撞处理：同帧不同事件扇出排列；语义相同的重复事件聚合为 ×N，tooltip 展开明细。
• 状态效果：加速/减速/冰冻用无渐变区间表示，只在区间起点放一次图标；属性变化显示数值和可确认的来源。
• 怒气表达：普通“获得怒气”不再画进实体事件层，改由怒气曲线表达；技能的怒气触发可在技能 lane 上标注。
• 视觉与国际化：优先复用游戏原生物品、技能、英雄和状态图标；小/中/大物品保持原始比例；首版支持 zh-CN / en-US。
• 统计页：不同单位分开呈现：伤害/恢复/护盾用对比柱图，伤害构成用环图，充能/加速/减速/冰冻用次数或持续时间柱图；移除“节奏施加”这类不明确指标。

ADR-001：录像与战斗时间轴如何对齐

Decision：同步 metadata 必须在录制阶段写入，不能只依靠视频时长或帧率事后推算。采集帧和编码后 media timeline 可能因丢帧、补帧、编码重排而无法 1:1 对齐。

版本化 metadata 至少记录：BattleId、combatFrame/combatMs、capture monotonic time、capture/submission frame index，以及封装完成后的 media PTS（或等价时间戳）。使用稀疏锚点做分段线性映射，并在 UI 显示同步质量：

状态	含义	UI
精确	已用最终 media PTS 校验	可逐帧对照
采集	只有 capture frame 映射	提示可能受丢/补帧影响
估算	历史录像无 metadata	明确标注“估算对齐”

交互规则：暂停时 hover 以约 10–15Hz 合并 seek，但游标和高亮保持 60fps；播放时 hover 只高亮，点击才暂停并提交 seek；播放回推时间使用 requestVideoFrameCallback。

flowchart LR
  R["录制器"] --> V["本地 MP4"]
  R --> M["同步 metadata<br/>稀疏锚点 + 最终 PTS"]
  C["Combat Replay payload"] --> W["Post-combat viewer"]
  V --> W
  M --> W
  W --> I["Installer 独立分析窗口"]

Loading

实施计划

Phase 1 — 数据契约与录制链路

• 定义版本化 CombatVideoSyncMetadata 和 exact/captured/estimated 质量枚举。
• 录制时写入 combat time、monotonic time、capture/submission index 稀疏锚点。
• mux/finalize 后回填最终 media PTS，并将 BattleId、视频信息和锚点持久化到 SQLite 或 sidecar。
• 增加 schema 升级、序列化和丢帧/补帧映射测试。

Phase 2 — Viewer

• 支持导入任意 replay payload，以及可选的匹配视频和 metadata。
• 实现 video/timeline 的 committedTime、previewTime、pendingSeek 状态机与合并 seek。
• 完成事件来源/目标联动、同帧聚合、状态图、统计页、tooltip、缩放和横向滚动。
• 完成全本地资源、响应式窗口和中英文本地化。

Phase 3 — Installer 集成

• 在战斗结算、History/Combat Replay 增加“查看详细对战记录”入口。
• 以独立可调整尺寸窗口打开 viewer，并处理本地文件访问范围和视频替换。
• 将 viewer、资源和 schema migration 纳入 installer 打包。

Phase 4 — 验证

• 用真实战斗检查起始、关键事件、终局三类同步点，并覆盖丢帧、补帧、旧录像、无录像。
• 验证 hover/highlight 60fps，记录 seek p50/p95，长战斗和高 DPR 下无明显卡顿。
• 核对敌我所有事件类型、来源降级、数量级数值、zh-CN / en-US 和断网运行。

当前原型

当前本地原型已用真实记录 483f629c36564d9ca4b4f55dea584cc6 演示：战斗轴约 8.5s / 171 帧 / 2,527 条原始事件 / 296 组投影事件；配对视频为 60fps。该历史样本没有录制期同步 metadata，因此界面明确显示“估算对齐”。

时间轴、状态图与录像对照

战斗统计页

已知局限 / 后续工作

• 当前是 HTML 原型；生产录制器尚未写入同步 metadata，installer 入口也尚未实现。
• 历史视频只能估算对齐，不能承诺逐帧精确。
• PR #113 只完成录制与 Recap 生命周期同步，是后续工作的基础，不包含本 ADR 的 metadata/PTS 映射。

[pengx17]

录像同步契约修订（2026-07-21）

上一版 ADR 的“稀疏锚点 / 精确对齐”表述需要收紧：关联必须在录制过程中逐个编码输出帧建立，最终 MP4 只能用于补 PTS，不能反推战斗时刻。 UI 最高只称“PTS 锚点”，不承诺 frame-perfect。

当前录制链路已经证明不能用 combatDuration / videoDuration：source readback 与 CFR 输出是两阶段，WallClockCfrPacer 会重复最新 source frame，也会跳过落后的 CFR slot；SQLite 目前只保存总帧数、丢帧数和 duration，没有逐帧映射。

建议的原始记录分两步：

1. 发起 pixel capture 时保存 combatFrame、combatMs、relative monotonic clock、captureFrameIndex，并让该 context 跟随 readback。
2. 每次 TryEnqueueFrame 成功时追加 cfrSlotIndex、连续的 encoderFrameIndex 和引用的 captureFrameIndex。重复帧复用同一个 capture context，不能错误使用 repeat 发生时较新的 combat time。
3. 后台批量写 append-safe sidecar，不能在 Unity render loop 每帧同步 fsync；finalize 后按最终 video track 截断无效尾部并补 mediaPtsMs。

因此同一 combatFrame 对应多个 video frame 是正常情况；source capture index / CFR slot 可以有 gap，实际 FFmpeg 输入的 encoderFrameIndex 应连续。Viewer 播放方向保留重复锚点，战斗时间 seek 则选择该 combat frame 首次出现的 media frame。

Installer 的职责保持为分发 viewer/本地 Range host、注册入口和打开默认浏览器；combat/capture/encoder 三个时钟只能由游戏内 recorder 采集，不能放到 installer 事后生成。

本地真实 MP4 原型已验证：播放反向驱动时间轴；暂停 hover 合并 seek，离开恢复 committed time；播放中 hover 不 seek；点击会暂停并提交。历史样本无录制期 metadata，仍明确显示“估算对齐”。

[pengx17]

HTML 原型收敛更新（2026-07-21）

本轮把视觉与交互契约收紧为可验证规则：

• 实体图标：物品侧栏按 Small / Medium / Large 使用 1 / 2 / 3 个方形槽位；技能保持圆形。原生物品素材是带透明区的方形 material texture，因此在固定盒内做有界缩放，不再把棋盘卡牌比例直接套到侧栏。
• 颜色语义：品质决定物品边框、底线和技能环色；敌我归属只用于右侧 marker 与英雄阵营强调，避免把归属色误读成品质。
• 同帧事件：hover 只显示紧凑摘要与“查看 N 个”；点击打开帧级检查器，按战斗/状态分组，处理同一帧同类事件重叠并限制原生图标尺寸。
• 录像布局：有录像时占满内容区宽度；时间轴、状态图和录像继续共享战斗时间，历史样本仍明确标为“估算对齐”。
• 资源一致性：HTML、CSS、app 使用统一 revision；本地服务对入口资源发送 no-store，运行时发现 revision 混载会自动刷新一次并显式报错，不再出现新 DOM 配旧样式。

已验证 revision 20260721aq：

• 旧 rev=20260721e 链接也会加载当前 HTML/CSS/app；
• Small / Medium / Large / Skill 桌面尺寸为 28 / 56 / 84 / 30 px，窄屏为 24 / 48 / 72 / 26 px；
• 320px、480px 无页面级横向溢出或图文碰撞，时间轴只在自身 viewport 内横向滚动；
• 本地资源全部加载成功，静态 verifier 通过。