6-网络框架选择

早期的我年幼无知，一心只想要所有工作自己做。

可是随着游戏开发的推进，自己造的轮子终究没有被人经过几年开发的框架更加结实。

看到下面这句话我深有感触：

我们把梦想建立在一个抛弃了我们的黑匣子上，而我们却无能为力。

也许就是担心这种事情发生吧。

但是现在，我已经具备观看大型项目源码的能力了，尝试开源框架也未尝不可。

Mirror

总体看下来，Mirror感觉是不太适合我目前的需求。主要有下面担忧：

性能限制：Mirror框架的性能可能无法满足支持30人同时对战的需求。在大规模的多人对战游戏中，需要处理大量的玩家输入和同步数据，这对网络同步的性能和带宽要求都是一个挑战。Mirror框架可能无法有效地处理这样的大规模玩家连接和同步需求，导致游戏性能下降或者网络延迟增加。
分布式服务器支持限制：Mirror框架在设计上可能没有ET框架那样专注于支持分布式服务器架构。在大规模多人对战游戏中，采用分布式服务器架构可以更好地分担服务器负载和优化网络连接。Mirror框架可能缺乏一些必要的特性或工具来有效地支持这种分布式架构。
复杂网络同步逻辑：制作复杂的格斗游戏需要高度精细的网络同步逻辑，包括实时碰撞检测、动作同步、状态同步等等。Mirror框架可能没有ET框架那样灵活的组件化设计，无法轻松地构建和扩展复杂的网络同步逻辑。

但是我们可以只让Mirror同步消息，而不使用Mirror的组件开发。但是这样的话，我感觉自己写的也差不多。

这是一个Unity编辑器模式下的同步器，可以克隆一个正在开发的Unity工程，并且持续同步修改，这样就可以避免频繁的打包调试，在编辑器模式下也可以多窗口同时调试，缺点是需要增加成倍数的内存。

这仅仅是一个UDP高级API库，他对UDP的有序性、可靠性进行了处理。

总的来看，目前自定义性最强，学习成本最低的是LiteNetLib，我们选用LiteNetLib作为开发本游戏的框架。