架构 Architecture

本页用四张交互式图呈现 MassBattle 的整体结构:① 处理器管线——每帧模拟从网格更新到渲染的完整执行顺序;② 渲染管线——fragment 数据到 GPU 材质参数的单一路径;③ 网络锁步——双端哈希校验与快照恢复;④ 模块依赖——插件的七个模块分层。图中节点可点击跳转到对应 API 文档页,悬停可高亮关联连线。

This page presents MassBattle's overall structure with four interactive diagrams: ① Processor pipeline — the full per-frame execution order from grid update to render; ② Rendering pipeline — the single path from fragment data to GPU material parameters; ③ Network lockstep — cross-peer hash validation and snapshot restore; ④ Module dependencies — the plugin's seven modules in layers. Nodes are clickable (jump to API pages) and hovering highlights connected edges.

处理器不自动注册(每个构造函数 bAutoRegisterWithProcessingPhases=false),由 UMassBattleSubsystem 持有实例并在 Tick 中经 RunProcessorsView 手动派发,数组追加顺序是唯一排序依据。模拟分 6 个 SimStage,每阶段以生成边界收尾(阶段间 ResolvePendingSpawns 使前一阶段生成的实体对下一阶段同帧可见)。Move 放在最后使击退收集(Behavior/Projectile)在同一逻辑 tick 内被消费施加(子帧内闭环),快照无需在途击退特判。UMassBattleNetworkProcessor 不在 SimStages 中——它在 post-sim 队列变异(子系统 ExecuteTick / 事件队列 / 回收 / FlushCommandBuffer)之后派发,使哈希与快照反映真正的帧末状态。

Processors are NOT auto-registered (bAutoRegisterWithProcessingPhases=false in each constructor). UMassBattleSubsystem owns the instances and dispatches them manually from Tick via RunProcessorsView; the array append order is the only ordering authority. Simulation runs in 6 SimStages, each ending at a spawn boundary (ResolvePendingSpawns between stages makes one stage's spawns visible to the next same-frame). Move is LAST so knockback (Behavior/Projectile) is collected and applied within the same logical tick (subtick-close loop) — the snapshot needs no in-flight launch special-casing. UMassBattleNetworkProcessor is not in SimStages — it dispatches after the post-sim queue mutations (subsystem ExecuteTick / event queues / recycle / FlushCommandBuffer) so hash + snapshot reflect the true end-of-frame state.

MassBattle 的渲染走单一路径:fragment → RenderProcessor(渲染子帧,并行 chunk walk)→ slot 索引批量数组(每个实体唯一 InstanceId → 无锁元素写入)→ SetNiagaraArray* 整批推送 → GPU emitter CustomHLSL 预测节点(插值/外推 + 身份令牌 snap + 位打包 DP0)→ Mesh Renderer 动态材质参数 → 材质 DynamicParameter 节点 + 位解码 Custom 节点。不使用 ISMC、不做逐实例 SetTransform、不用 ENQUEUE_RENDER_COMMAND。每数组 bUse*Array 反射探针在批次创建时门控向后兼容;一次性事件走 NDC 开关。

MassBattle renders everything through one path: fragment → RenderProcessor (render sub-frame, parallel chunk walk) → slot-indexed batch arrays (per-entity unique InstanceId → lock-free element writes) → SetNiagaraArray* whole-batch push → GPU emitter CustomHLSL prediction node (interp/extrapolation + identity-token snap + bit-packed DP0) → Mesh Renderer dynamic material parameters → material DynamicParameter node + bit-decode Custom nodes. No ISMC, no per-instance SetTransform, no ENQUEUE_RENDER_COMMAND. Per-array bUse*Array reflection probes gate backward compatibility at batch creation; one-shot events go through NDC toggles.

MassBattle 采用确定性锁步:双端各自运行同一套确定性模拟,每帧用注册表驱动的哈希折叠(MassBattleHashRegistry)计算模拟状态摘要并交换校验;哈希失步触发 resync,对端用快照(MassBattleSnapshotRegistry + 骨架模板)恢复状态。通道判据:hash = 模拟状态,snapshot = 网络状态,两者皆无 = 纯本地视觉层(UID=-1 哨兵,永不进哈希/快照/池)。快照经 TCP 传输(带端口冲突自愈),恢复端以注册表行为准——新增 fragment 字段必须进快照注册表,否则恢复端拿到模板默认值,resync 后必失步。

MassBattle uses deterministic lockstep: both peers run the same deterministic simulation; each frame a registry-driven hash fold (MassBattleHashRegistry) summarizes simulation state for cross-peer validation. A hash mismatch triggers resync, where the peer restores state from a snapshot (MassBattleSnapshotRegistry + skeleton templates). Channel criteria: hash = simulation state, snapshot = network state, neither = peer-local visual layer (UID=-1 sentinel, never in hash/snapshot/pools). Snapshots travel over TCP (with port-conflict self-healing). Restore is driven by registry lines — a new fragment field missing from the snapshot registry restores as the template default and guarantees post-resync desync.

插件由七个模块组成(依据 MassBattle.uplugin 与各 Build.cs):三个 Runtime 模块(MassBattle 核心、MassAPI Mass 实体管理 API、FlowFieldCanvas 流场寻路)、两个 UncookedOnly 模块(MassAPIUncooked / MagnusUncooked,蓝图节点定义,编辑器专用)、Magnus(Runtime,自定义属性与节点框架)与 MassBattleEditor(Editor)。依赖方向:Editor/Uncooked → Runtime;MassBattle 依赖 MassAPI 与 FlowFieldCanvas。

The plugin has seven modules (per MassBattle.uplugin and each Build.cs): three Runtime modules (MassBattle core, MassAPI Mass entity-management API, FlowFieldCanvas flow-field pathfinding), two UncookedOnly modules (MassAPIUncooked / MagnusUncooked — Blueprint node definitions, editor-only), Magnus (Runtime, custom-property & node framework), and MassBattleEditor (Editor). Dependencies: Editor/Uncooked → Runtime; MassBattle depends on MassAPI and FlowFieldCanvas.