Contents
  1. 1. MMServer
  2. 2. KBEngine

其实说是参考梦三端游的服务器,不如说更像是同为手游的光影对决的服务器。当然,两边的源码我都在读。除了架构是一样的外,很多细节也不尽相同,当然业务逻辑是不一样的。有一种一次性在做三个项目的感觉(并没有

MMServer

每天对着这十几个G代码鼓捣来鼓捣去,从开始的盲人摸象到开始摸出这是一个什么东西了,一些超级好用的工具不说,代码本身越看越有意思。昨天对着新加的一张库表进行了DBServer的底层C++封装,一天大概贡献了几百行C++代码,下班了人都是晕的。虽然是依葫芦画瓢,但是我感觉对DBServer这个服务器已经基本理解了。其实分布式架构,真的也就这样了。我感觉过个一年对架构的理解不会比现在高多少,如果这样混日子过个3年,那不就是「3年大型游戏分布式架构经验」,但是就这样的话,想想不会不甘心么?

底层先是DatabaseDef对表进行简单的定义和注册,然后用宏进行初步封装,抽象出基本的CURD,然后是DBServer的DBPlayerMgr对DBPlayer的个人线程进行内存管理,把查询数据放在DBPlayer层中,而MSGProcess里的Process和Send相当于对DBPlayer内存对database的读和写。这里用的trick就是在有些比如一局游戏结算时,把数据发放到个人线程中去处理。

因为DBServer的结构简单,我又看了下入口的main,发现其实每个服务器进程在启动后都有自己的Debug模式,按下F1即可,比如DBserver就可以实时查看各部分内存占用,或者同步所有Player数据从内存到DB,WorldServer可以选择开关商城功能等。(宏是真的好用,明显地大幅度提升代码可读性)

说DBServer结构简单的原因是因为和它通信的除了一个Database,对于服务器就只有WorldServer。而且通信的方法有很简单,就是对接受data的curd。稍稍复杂的方法都放在了DBPlayer中,主要是Login时的进行内存层的DB读取,然后每读取一个模块就set一个flag,之后通过二进制运算来判断来决定是否让用户进入主界面。(我当初3天没有解决的登录问题貌似就是出在这,那时候是一个开发中的模块在入口逻辑中有人忘记注释那一行就提交到SVN,导致我登录返回值是OK但是停留在登录界面。当时整个人都快崩溃了,断点一天后update整个项目还是报错,还没人鸟我)

端游和手游还是有差别的,比如m3端游这边完全找不到历史战绩的模块,甚至HttpServer内容都很少。因为这里客户端基本上是直接和运维通信,就不走服务器这里,拿数据也直接从运维那里拿。而光影这边基本上是一样,但是有很多内容是客户端-服务器-运维这样走。老大这边对手游这部分的架构还保持不确定的态度,我就有点不太想做了-_-||。

KBEngine

我看了几天的这个框架,把这个参考bigworld的国内解决方案拿来做入门服务器运维不知道是祸是福。说是文档友好其实已经过期相当一段时间,按照它的getstart的代码七改八改,然而怎么都跑不起来,只能直接用它附带的源码。用它的原因除了是国内环境以外,还是因为它们公司是电魂投资,对我会存在潜在的资源(并不-_-除了一次宣讲会完全没有)。我觉得kbe想要提高知名度和拿到更多的资源,还是需要一款游戏的成功来证明。就好像崩坏3对于unity,wow对于bigworld,仅仅靠一大堆没听过的页游是不行的。

虽然helloworld跑不起来,但是写的时候好处还是看的到的,至少它很对我的相性(还是说我见识少,说不定用过Photon我就不这么想了)。我刚刚fork了b站有人用它写了一个麻将的游戏,有时间去看看。看来还是看视频这种最low又最直接的方法适合我^^(<-这个人真的菜

之前不是写了一个人物demo嘛,其实我一开始还是想把它写成多人的。很多细节就是考虑到多人联机才设计的复杂一些。但是这几天的工作下来,感觉自己一个人要完成的话会吐血到死。但是我并不指望(一开始就)有人会分摊我的工作,这也是我最近的观点,永远不要指望别人做什么,尽量发挥你的主观能动性吧。

Contents
  1. 1. MMServer
  2. 2. KBEngine