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

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

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注入等问题 结构介绍：

目录结构：

|- kbengine (KBE_ROOT 根目录)
|- assets (默认的游戏项目资产库，你可以添加新的资产库通过环境变量绑定)
|- res (所有资源文件)
|- spaces (通常存放游戏场景相关的资源，例如Navmesh)
|- server (通常放置服务端相关的配置文件)
|- scripts (所有的游戏逻辑，Python文件)
|- base (Base的Python逻辑)
|- cell (Cell的Python逻辑)
|- client (Client的Python逻辑)
|- bots (机器人的Python逻辑，压力测试)
|- common (逻辑公共文件夹)
|- data (游戏逻辑用到的数据资源)
|- db (dbmgr扩展脚本)
|- entity_defs (实体定义与声明)
|- interfaces (实体的接口声明)
|- server_common (服务端逻辑公共)
|- user_type (自定义用户类型目录)
|- kbe (引擎目录)
|- tools (引擎工具)
|- server (引擎服务端工具)
|- guiconsole (可视化的控制台工具)
|- install (引擎安装工具)
|- pycluster (跨平台的集群控制Python脚本工具)
|- xlsx2py (游戏数据表导出工具)
|- src (KBEngine源代码)
|- build (makefile公共脚本)
|- client (客户端插件和例子目录)
|- kbengine_dll (Windows应用程序插件源代码)
|- common (公共目录)
|- lib (各种模块源代码)
|- client_lib (客户端底层公共框架)
|- cstdkbe (KBEngine标准库)
|- db_mysql (Mysql存取实现)
|- dbmgr_lib (数据存取公共接口)
|- dependencies (依赖库)
|- entitydef (实体定义解析模块)
|- helper (一些通用的协助性模块)
|- math (数学相关)
|- navigation (2D/3D导航模块)
|- network (网络模块)
|- pyscript (脚本插件)
|- python (python源代码)
|- resmgr (资源管理器)
|- server (服务端公共模块)
|- thread (多线程模块)
|- xmlplus (xml解析库)
|- libs (编译后的*.lib, *.a文件)
|- server (服务端app源代码)
|- baseapp (baseapp源代码)
|- baseappmgr (baseappmgr源代码)
|- cellapp (cellapp源代码)
|- cellappmgr (cellappmgr源代码)
|- dbmgr (dbmgr源代码)
|- loginapp (loginapp源代码)
|- machine (machine源代码)
|- resourcemgr (resourcemgr源代码)
|- tools (服务端助手工具)
|- interfaces (支持第三方计费、第三方账号等接口)
|- bots (压力测试， 虚拟客户端, 源码)
|- guiconsole (可视化的控制台工具源码)
|- message_log (服务端log收集工具源码)
|- res (引擎资源目录)
|- key (RSA密钥)
|- scripts (Python脚本库)
|- server (服务端引擎配置)
|- log4cxx_properties (log4cxx配置)
|- doc (指南文档源代码)
|- 霸气的大米 (编译后的可执行文件存放目录)
|- client (编译后的客户端exe可执行文件存放目录)
|- server (编译后的服务端可执行文件存放目录)
|- logs (服务端运行日志)
|- tutorial (指南文档)

组件介绍：

必要组件描述
· loginapp:
登录验证、注册、接入口。可在多台机器部署多个loginapp进程来负载。

· dbmgr:

高性能多线程的数据存取。默认使用Mysql作为数据库。

· baseapp:

客户端与服务端的交互只能通过loginapp分配的baseapp来完成。定时写entity的数据到数据库、baseapp数据相互备份、灾难恢复。可在多台机器部署多个baseapp进程来均衡负载。脚本层通常会选择在baseapp上实现如：社交系统、广播聊天、排行、游戏大厅、等等逻辑系统。

· baseappmgr:

协调所有baseapp的工作，包括baseapp负载均衡处理等。

· cellapp:
处理游戏与空间和位置有关的逻辑，如：AOI、Navigate、AI、战斗等等。可在多台机器部署多个cellapp进程来动态均衡负载。

· cellappmgr:

负责协调所有cellapp的工作，包括负载均衡处理等。

· machine:

抽象出一个服务端硬件节点(一台硬件服务器只能存在一个这样的进程)。主要用途是接收远程指令处理本机上的组件启动与关闭, 提供本机上运行组件的接入口以及收集当前机器上的一些信息， 如：CPU、内存等。 这些信息会提供给一些对此比较感兴趣的组件。

· client:

客户端我们将提供基础框架，这个框架不包括渲染部分和输入输出部分的具体实现, 我们将提供一个lib文件和一套API接口，开发者可以选择使用自己比较适合的图形渲染引擎与输入输出控制部分。Unity3D, HTML5, Cocos2d等技术我们提供了相关插件，能够快速的和服务端对接。

工具组件描述
· interfaces:
支持快速接入第三方计费、第三方账号、第三方数据， 快速与运营系统耦合。

· logger:

收集和备份各个组件的运行日志。

其它组件描述
· bots:
机器人，通常用来做压力测试。

· guiconsole:
可视化控制台，这个图形工具只能在Windows运行。