kbengine笔记,kbengine教程

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

　　下面是前景介绍。我对kbengine的原代码做了一些修改，在原有基础上只支持webscoket通信。现在，我增加了http通信和Async，实现了异步分布式web框架游戏引擎的底层引入。

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

　　Github地址：https://github.com/kbengine/kbengine

　　KB框架的优缺点：框架结构很专业，但同时也很沉重。编译时间长，服务器启动时间也很长(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)

　　-服务器(通常放置与服务器相关的配置文件)

　　-脚本(所有游戏逻辑，Python文件)

　　-base(Python base逻辑)

　　-单元格(单元格的Python逻辑)

　　-客户端(客户端的Python逻辑)

　　-机器人(机器人的Python逻辑，压力测试)

　　-公共(逻辑公共文件夹)

　　-数据(游戏逻辑中使用的数据资源)

　　- db (dbmgr扩展脚本)

　　- entity_defs(实体定义和声明)

　　-接口(实体的接口声明)

　　- server_common(服务器端逻辑公共)

　　-用户类型(自定义用户类型目录)

　　- kbe(引擎目录)

　　-工具(引擎工具)

　　-服务器(引擎服务器工具)

　　- guiconsole(可视控制台工具)

　　-安装(发动机安装工具)

　　- pycluster(跨平台集群控制Python脚本工具)

　　- xlsx2py(游戏数据表导出工具)

　　- src(知识库引擎源代码)

　　- build (makefile通用脚本)

　　-客户端(客户端插件和示例的目录)

　　- kbengine_dll (Windows应用程序插件源代码)

　　-通用(公共目录)

　　- lib(各种模块的源代码)

　　- client_lib(客户端的底层公共框架)

　　- cstdkbe(知识库引擎标准库)

　　- db_mysql (Mysql访问实现)

　　- dbmgr_lib(数据访问公共接口)

　　-依赖项(依赖库)

　　- entitydef(实体定义解析模块)

　　- helper(一些通用辅助模块)

　　-数学(与数学相关)

　　-导航(2D/3D导航模块)

　　-网络(网络模块)

　　- pyscript(脚本插件)

　　- python (python源代码)

　　- resmgr(资源管理员)

　　-服务器(服务器端公共模块)

　　-线程(多线程模块)

　　- xmlplus (xml解析库)

　　- libs(编译*。lib，*。一个文件)

　　-服务器(服务器应用程序源代码)

　　- baseapp (baseapp源代码)

　　- baseappmgr (baseappmgr源代码)

　　- cellapp (cellapp源代码)

　　- cellappmgr (cellappmgr源代码)

　　- dbmgr (dbmgr源代码)

　　- loginapp (loginapp源代码)

　　-机器(机器源代码)

　　- resourcemgr (resourcemgr源代码)

　　-工具(服务器助手工具)

　　-接口(支持第三方计费、第三方账户和其他接口)

　　-机器人(压力测试、虚拟客户端、源代码)

　　- guiconsole(可视化控制台工具源代码)

　　- message_log(服务器端日志收集工具的源代码)

　　- res(引擎资源目录)

　　-密钥(RSA密钥)

　　-脚本(Python脚本库)

　　-服务器(服务器引擎配置)

　　-log 4 XXX _ properties(log 4 XXX配置)

　　- doc(指南文档源代码)

　　-霸气饭(编译后的可执行文件存放目录)

　　- client(存储已编译的客户端exe可执行文件的目录)

　　-服务器(编译后的服务器可执行文件存储目录)

　　-日志(服务器运行日志)

　　-教程(指导文件)

　　组件介绍：必要组件的描述

　　loginapp:

　　认证、注册、接入端口。可以在多台机器上部署多个loginapp进程进行加载。

　　dbmgr:

　　高性能多线程数据访问。使用Mysql作为默认数据库。

　　baseapp:

　　客户端和服务器的交互只能通过loginapp分配的baseapp来完成。定期将实体数据写入数据库，备份baseapp数据，灾难恢复。可以在多台机器上部署多个baseapp进程来平衡负载。脚本层通常选择实现社交系统、广播聊天、排名、游戏厅等逻辑系统。在baseapp上。

　　baseappmgr:

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

　　手机应用程序：

　　处理游戏中与空间和位置相关的逻辑，如：AOI、导航、AI、战斗等。可以在多台机器上部署多个cellapp进程来动态平衡负载。

　　cellappmgr:

　　协调所有cellapp工作，包括负载平衡。

　　机器：

　　抽象一个服务器硬件节点(一个硬件服务器中只能存在一个这样的进程)。主要用途是接收远程指令处理本机组件的启动和关闭，提供本机运行组件的访问端口，收集当前机器的一些信息，如CPU、内存等。这些信息将被提供给一些感兴趣的组件。

　　客户：

　　客户端会提供基本框架，不包括渲染部分和I/O部分的具体实现。我们将提供一个lib文件和一组API接口。开发者可以选择使用自己的图形渲染引擎和I/O控制部分。Unity3D，HTML5，Cocos2d等技术，我们提供相关插件，可以快速连接服务器。

　　工具组件描述

　　接口：

　　支持快速访问第三方计费、第三方账户和第三方数据，快速与操作系统耦合。

　　记录器：

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

　　其他组件描述

　　机器人：

　　机器人通常用于压力测试。

　　GUI控制台：

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

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。