之前探索的内容：

demo git地址：chenhao/Mirror2KCC: Mirror2KCC 同步Demo - Mirror2KCC - Gitea: Git with a cup of tea (minish-cap.com)

效果 ->：试封装的Mirror角色同步基类（包含快照） - Chen Hao - Confluence (cyboak.com)

如下是正式视角讨论的同步方案：

接入的一些前提 （先读我)：

• 接入网络对各类业务系统的影响，必要改动和不确定因素

• 前期的各类系统网络快照大致定义的讨论草案 

接下来，是...

同步时序总览：（若采用ＣＭＤ不广播，仅同步后续结果的模式）

• 基本前提：

个人理解，

在本游戏中是动作主导，则角色相关的任何外围系统，都必须以动作的同步修正的当前帧（TAE运行时总帧）作为依据。

例如，当前动作处于10帧，现由于滞后需要修正到15帧的位置，

那么 动作修正到15帧的快照状态的同时，数值属性等其他系统应该修正到15帧的快照的状态。

• 快照大结构：

基于基本前提，那么可考虑的结构为，以依据帧（如TAE）为主，其他各系统 必要和可选快照，在同一结构体中。

如下：

注：玩家对象会包含ＣＭＤ数据

依据帧：TAE运行时。

关键帧标记：bool值，实则是为了加速修正过程中可抛弃的非关键帧数的标识。也许来自于策略。

transform类快照：包含Position，Rotation，KCC向量等

动作状态快照：TAE状态相关

属性类快照：采集来自数值计算Redux的当前结果值相关

其他可选快照插槽：其他有快照需求，但不需要频繁，有时需要快照携带同步的内容。

• 快照管理模式：

• 关于采集的部分描述

在整体图的采集上报部分设计思路，

设计描述的是一个逻辑帧内的流程。

参照上面的快照结构设计，分为可选快照和必要快照，构建一个发送前的快照Cache。

然后借助引擎对于不同功能块的执行：

1，各类系统，按需将可选的快照插入到发送前缓存中 

2，在引擎逻辑帧的末尾，快照按需采集必要的快照。组装成一个单个快照数据。

3，最后发送，并清除缓存的可选部分