skynet和kbengine的比较

skynet和kbengine的比较

技术背景

skynet和kbengine都是国内知名的分布式游戏服务器引擎。

在游戏服务器架构转向分布式技术过程中都吸引了大量的游戏公司和程序员。

这两个引擎的特点是都是分布式结构。所不同的是skynet支持线程模式而kbengine只支持多进程模式。

游戏服务器最初大部分都是C或C++开发的。因为游戏服务器对性能要求非常的高。属于CPU密集型服务器。

但C或C++最大的问题就是软件崩溃。随着功能的增加,软件的膨胀。导致崩溃的问题越来越难解决。所以崩溃问题严重限制了服务端软件的规模。

与互联网软件要求不同的是,因为游戏服务器对性能的极高要求。导致了互联网软件可以牺牲部分性能使用java来解决崩溃问题。因为解决了崩溃问题互联网服务器规模得以进一步的增加。这部分性能的损失互联网服务器又通过分布式的方法进行了弥补

游戏服务器虽然有强烈意愿转向分布式以获得更多功能,但大部分公司无力承担分布式架构的高技术成本。因为传统的java分布式架构的代价极高。需要大量开发人员进行维护。

分布式的技术发展路线可以总结如下。由C语言转向脚本语言以避免崩溃问题。没有了崩溃问题就可以引入更多的开发人员。而更多的开发人员和分布式结构抵消了脚本语言带来的性能下降,并带来了更多的功能。更多的功能给公司带来了很好的收益。

但游戏公司和互联网公司完全不同。游戏属于功能密集型的软件。游戏公司养不起哪么多的开发人员来维护哪么多的分布式功能。互联网公司的一个功能可以好几个开发人员来维护。而游戏公司的一个程序要维护好几个游戏功能。这种差异导致了分布式技术在游戏公司推广困难。

在这样的背景下诞生了skynet和kbengine两个比较成功的服务器引擎。

为什么来比较这两个引擎?

因为这两个引擎在技术上非常有特点。是两条完全相反的技术路线。

skynet是走得极简路线,只提供最核心的分布式组件。并且在技术上主张使用多线程。认为在多线程结构下的崩溃能使软件完全停止服务。避免导致数据错误。

kbengine则完全相反,提供了完整的3DMMO游戏的示例。并按最复杂的3Dmmo游戏设计了整个框架。其主张每个进程只有一个逻辑服务,这样任何进程的崩溃只会导致部分玩家的部分功能不能使用。但因为kbengine的底层结构太过复杂。如果开发的不是3DMMO,而是一个3DFPS需要帧同步。哪么对底层的修改和扩展就会比较痛苦。同样的道理开发一个2D的横板战斗游戏也要修改底层的坐标系统。

虽然修改kbengine的底层比较痛苦,但是游戏的模式毕竟有限,使用坐标的方式无外乎就是FPS的帧同步,2D格子,2D横板,2D自由移动,3D空间自由,3D无缝大地图等等几种。可以期待如果kbengine未来能够支撑这些坐标系统哪么将会是不错的商用服务器引擎。

这两种游戏引擎对技术要求都比单线程服务器高!

在分布式系统开始普及的今天,换皮游戏公司和技术型游戏公司的区别正在凸现。最近的《三国志策略版》和《万国崛起》都把千人同地图战斗作为了卖点。而且都取得了很好的游戏效果。

传统的游戏服务器基本就是客户端-〉网络协议-〉游戏逻辑-〉数据库的过程。

而分布式的游戏服务器是网络协议到多个服务到多个服务到多个服务的过程再到多个逻辑再到多个数据库的过程。从游戏逻辑来看与原来没有任何区别。但从软件架构角度来讲这中间的环节出现问题,解决起来也是非常麻烦的。

总的来说kbengine更像商用的游戏服务引擎,如果能够再提供更丰富的游戏脚本模块和功能模块就更好了。但目前只针对大型mmo做了商业优化。而有能力开发大型mmo的公司对这些优化并不十分在意。因为底层功能复杂自行扩展也比较的困难。

kbe独创的空间管理系统技术非常的高效。整体性能好于基于map的九宫格系统。估计性能提升在20%以上。

而skynet更贴近库开发模式,对开发游戏的限制更少,扩展非常容易。但功能比kbengine更少更缺乏。

整体来说分布式架构代传统单线程游戏服务器的道路依旧漫长。

编辑于 10-01

文章被以下专栏收录