Unity手游实战：从0开始SLG——ECS战斗（四）实战ECS架构和优化

设计思想和插件介绍完了，那么就需要看看实际项目怎么去使用它。

根据策划和服务器大佬的评估，正常情况下每秒发生的战斗约2000场，我们的服务器预估为8核，如果每个核起一个战斗线程，就可以同时并发8场战斗。如果每场战斗花费50ms，那么一台服务器一秒只能计算160场，那么就需要13台服务器，呃~有点贵。。。如果每场战斗花费20ms，那么一台服务器一秒能计算400场，就只需要5台服务器即可，似乎能接受了。

所以我们的目标就是让服务器（逻辑）每场战斗的耗时保证在20ms左右（非常困难），想看看大家有没有跟我们类似的项目，服务器的异常战斗结算是多少。。。

客户端编程与服务器编程

虽然都是码代码，但服务器的编程思想和客户端还是有一些差异的，服务器更多是无“我”概念（和客户端帧同步的处理有些相似），而客户端则以“我”为核心。比如一个联盟的功能系统，有人晋升了，它给所有的联盟成员推送的协议都是一样的，但是在客户端你需要跟自己的id进行比对，如果是别人晋升了那我只要改变一下别人的显示头衔，如果是自己晋升了，那不仅要改变显示头衔，还需要处理自己的各种权限按钮，甚至是一些特殊权限才能查阅的功能界面。

服务器的大部分更新和逻辑都是由驱动完成的，而客户端在线时期，往往都是即时计算和展示的。这些驱动可能来自某个玩家的操作请求，某些定时器（这个功能不太常用）的触发。比如一个联盟如果100天都没有人上线，那么它就会被自动解散。你可能会认为，这些100天没有上线的联盟一到100天就会被服务器清除，但其实并不是。大部分时候，它们会静静的躺在数据库里，直到这个僵尸联