正如其他答案提到的,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人才的培养,精心打造并推出零基础入门、高手进阶、推荐就业为一体的课程体系,全面提升学员的个人素质能力和团队协作能力。欢迎咨询!