总篇

本篇将会统一讲述各个设计方案的基础理念，适用场景以及举例。后续将会结合实际例子来详细讲解的设计方案

————

前言：

网络同步是一个复杂的工程问题，一般来说根据需求，我们需要研究以下问题

1:我们需要同步什么东西

2:我们的同步是部分同步还是完全同步

3:同步更注重于连续还是注重于结果

4:我们的同步的是参数还是结果

5:同步逻辑是群发的还是单发的

6:同步逻辑是否需要双向通信

7:同步是否需要适配持久化保存

有一些东西是……原则上必须实现的：

1:迟到者同步：为新加入的玩家重新同步

2:性能考虑：你必须考虑到网络同步的性能问题

3:防呆设计：你必须保证无论什么情况下你的同步过程中都不会导致崩溃

4：主副机相等：发出同步的人必须和接受信息的人最后的结果一致。

基于上述问题和原则，根据常用的场景，我个人常用以下几种设计原型

————

单文件同步设计

理念：将业务代码和网络同步放入同一个脚本内，同步只需要将重点变量同步即可。同步方式根据需求自由选择。

适用性：这种网络同步模式是最基础的模式。也是大部分复杂度不高，同步要求也不高的插件的通用方案。

其有着设计简单，逻辑清晰的优点，而且易于debug。

其缺点也很明显，网络部分和业务代码高度耦合，后期维护性较差。

适合场景：简单插件

 ————

网络同步分离设计：

将网络同步部分代码和业务代码分离，互相之间通过通过函数进行通信。常用于同步参数需要被多个插件引用，但是同步本身不参与逻辑的情况。同步方式主要以手动同步为主，常见搭配playerobject使每一个人都有独立的同步组件。常用于网络同步部分参数除了本体需要以外，还可能被参数多个插件需要的情况。例如UdonChips-Udon钱包。

同步方式主要以手动同步和自动同步为主，常见搭配PlayerObject使每一个人都有独立的对象。

优点：易于维护开发结构相对简单，开发难度较低，后续继续开发。

缺点：性能较差，因其它脚本无法主动得知更新时间，通常需要多次无意义的重复获取数值来保证数据最新，这带来了十分严重的性能浪费。

（tips：可以弥补的，纯某UdonChips懒导致的性能问题）

一对多网络同步模式：简单来说就是控制面板所在的控制台不参与同步，在收集完信息后，利用另一个只负责同步的脚本进行同步。

优点：可拓展性强，根据设计可以适配多种不同的场景，非常好用的大型网络同步方案

多对一网络同步模式：这个同步模式主要用于解决持久化相关问题。这个模式主要是利用PlayerObject的特性，将数据存储在个人对应的PlayerObject中，控制面板根据需要从Loaclplayer中获取同步脚本。或者利用playerdatabase来进行同步。

优点：可以实现持久化