Kbengine游戏引擎介绍

关注

转载最新推荐文章于 2026-06-25 12:05:30 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

kbengine引擎架构分析服务端组成 |----------| | client | x N |----------| ------------------------|-----|------------------------------- |----------| |----------| |----------| | loginsr 阅读详情

Kbengine游戏引擎

前景
游戏引擎的底层介绍
github地址：
Kbengine框架的优缺点：
结构介绍：
组件介绍：

前景

	这里介绍呢，我是在kbengine原代码上有做修改，原基础上只支持webscoket通信，现在添加了http通信和Async实现异步分布式web框架

 
 1

游戏引擎的底层介绍

kbengine底层架构很庞大功能很完善。底层采用c++，而写逻辑只需要使用python，大家都知道python是一种开发效率非常高的语言，所以你只要写python代码就不用考虑底层如何实现。kbengine底层架构被设计为多进程分布式动态负载均衡方案，理论上只需要不断扩展硬件就能够不断增加承载上限，单台机器的承载上限取决于游戏逻辑本身的复杂度。网络层被底层封装的很好，在写逻辑的时候几乎可以忘记rpg等细节过程，远程访问非常方便，但是目前官网和论坛已经无法访问，具体原因不是很清楚。

github地址：

https://github.com/kbengine/kbengine

Kbengine框架的优缺点：

框架结构非常专业，但是同时非常厚重。编译时间很长，服务器启动时间也很长（10~20秒），部署也非常麻烦（在linux上面要安装openssl，编译python，设置环境变量）部署方面只是环境编辑时间上有点蛋疼，操作步骤没有几下
分布式并不仅仅体现在多个逻辑服务器上面，而体现在多个逻辑服务器（场景服务器）数据可互通。这个也是KBEngine非常强大的地方。
python作为脚本语言，我如果仅仅是实现简单的逻辑还没什么问题。但是一旦我所有的服务器逻辑都是python来实现了，那么性能就会成为问题，甚至可能还不如Node.js性能高。脚本语言比c++、java这样的静态编译的语言开发效率要高，但是实际操作起来却发现很多不顺手的地方，很多静态语言编译期就能检查出来的低级错误，现在必须运行时才发现某个变量名写错了。在我看来服务器其实对热更新并没有那么高的需求，而且要做成安全可靠的热更新是非常困难的，客户端影响比较小还可以考虑，服务器一旦出错就成百上千倍的放大。能把配置做成热加载的，能不关服务器的情况下开启和关闭某个系统就足够了。脚本语言除了开发效率高就是热更新方便，然而现在看来热更新需求不大，开发效率也不如使用c#+vs高效。
RPC的通信方式很棒，可以让客户端和服务器以函数调用的方式来调用远程函数，而不需要考虑通信细节。然而我非常不习惯这种方式，当需要传的数据复杂了，维护起来反而麻烦。而且传输效率上来讲肯定不如protobuf高。如果是protobuf来维护的话，只要proto定好了，客户端和服务器共同使用，有类型修改的时候只要关注proto就可以了。然而KBEngine中的rpc定义参数修改了需要改三处地方，并且还不是静态检查，只有运行时才能发现哪个参数定义的不一致。另外，如果客户端和服务器都是使用python的话，应该还是比较方便的，但是客户端是c#而服务器是python，rpc反而造成了维护的不方便。
数据库管理没有使用之前的原理，自己封装一套，包含有防sql注入等问题