正如其他答案提到的，ds出发点是解决fps同步，对同步精度和延迟的追求是很高的。核心特性包括：客户端预测，服务器校验，客户端状态回退，延迟补偿，replay等等。乍看之下mmo不用这么高端的特性，再加上原生ds承载量低，有的小可爱看着ds这一大坨代码，很容易产生自己撸一个更简单的勇气。

　　下面简要讲下，如果放弃ds你损失的是什么：

　　优化的网络传输。ue4在udp上做了一层网络协议，专门用于ds通信。这是根据游戏特点专门优化的，能根据频率/重要度/数据格式等条件选择最优的传输方式(可靠/非可靠)，以及数据压缩，拆合包等。网络传输的技术迭代很慢的，这块可说是epic数十年沉淀，一般人很难比他写的更好。

　　2. actor的属性同步和rpc。也就是编辑器里跟同步有关的功能都只能看不能用。实际上手撸服务器最大的隐含代价就是：你服务器的游戏对象跟客户端的actor一定是异构的，意味着你必须放弃基于actor的整个gameplay framework，以及相关的大量功能，导致蓝图基本不可用，导致你要实现自己的脚本方案，导致……此处太多不展开了。

　　3. replicationgraph，也就是aoi，这个简单，小可爱撸一撸问题不大。

　　4. 动画和物理同步。主要是rootmotion和碰撞同步(武器命中)，以及环境动画，破碎这些策划喜欢的东西。

　　5. ai行为树。嗯，ue4的行为树依赖character，character同步又依赖ds。抛弃ds意味着，你将损失一颗能断点单步可视化调试的行为树。

　　如果你mmo标准很低，上述内容都不需要……那么有一说一，你这个mmo很难活下去啊。

　　所以ds设计上的特点(游戏对象同构，和引擎全层次耦合)导致了，完全抛弃ds相当于把引擎阉割成渲染器。如果你不能接受ds的高消耗/低承载缺点，理智的做法还是去了解它，改进它，根据真实的数据和需求一步步迭代，银弹是不存在的。这里提供几个思路：

　　首先是工程层面，减少不必要的component同步，用好骨骼lod，replicationgraph配置足够的fallback层级和粒度等基操。

　　简化原生的fps同步方案，降低cpu消耗。比如ds不计算位置校验(对应的客户端也不需要状态回退了)，更激进的比如ds跳过大部分物理模拟，关闭动画更新等。

　　ds对线程的使用是谨慎的(相对于客户端)，因此物理机多开ds进程可能带来提升，实例之间也可以实现某种程度的负载均衡。

　　考虑到每个ds进程都会独立加载游戏资源，造成内存浪费，可以实现某种单进程多位面，降低内存占用和包广播量。

　　动态负载均衡，动态aoi之类的高端玩法，可参见spatialos的ue4插件。

　　最后，关于客户端服务器分工也说两句。以前很多客户端和服务器都搞异构游戏对象，导致两边游戏对象的生存环境完全不同，分工是为了降低心智负担，其实挺扭曲的。ds设计上是同构的，你调的rpc你自己实现啊，这时候执着于分工是一种退步。

　　弘成it教育致力于互联网it人才的培养，精心打造并推出零基础入门、高手进阶、推荐就业为一体的课程体系，全面提升学员的个人素质能力和团队协作能力。欢迎咨询!