棋牌类游戏客户端结构分析

在这里所讨论的棋牌类游戏并不是所有的平台类型,而是通常的表现形式即游戏广场-游戏大厅-游戏房间的类型,这些结构的产品有QQGAME, OURGAME,CHINAGAMES,GAMEABC,GAMETEA…以及还有我们的产品.其他的异型结构如黄金岛(基地城市)等其实也是大同小异.

解释:游戏广场-用户通过登陆验证连接进入以后所看到的那个部分即通常都是左边游戏和服务器列表右边是网页的形式,简单的描述就是游戏目录,游戏大厅的集合;

游戏大厅-具体的游戏的大厅,也就是用户进入某个游戏后所看到的一排又一排的桌子以及一个用户列表的形式,简单的描述就是游戏房间的集合;

游戏房间-具体的游戏的区域,也就是用户点了某个桌子所出现的具体的游戏的界面.

虽然上面的产品用户操作表现形式方面基本一致,但是产品形式方面还是有很大差异的.以下主要分析的是游戏客户端和游戏大厅客户端的关系方面:

第一种是游戏是DLL表现形式,游戏大厅EXE将采用loadlibary方式加载到堆栈当中,整个系统采用一个进程来处理所有的事情,即使用户同时进入了几个游戏也是一样,这样的处理方式的优缺点如下:
优点:
1.由于是一个进程,同在一段内容地址当中,最大的好处就是开发的难度降低,函数或者变量的调用非常的简单,只要设计好基本的结构剩下的开发就相当的简单了;

2.由于是在一个进程当中,连接也自然就共用了,soket可以在任何地方调用,无论游戏大厅中,游戏房间中都可以方便的使用同一个连接,这样在服务器端就只要维护一个连接就可以了节约了资源;

3.部署方面,由于目前某些防火墙比较的严格,对于EXE的改动会再次让用户确认是否允许访问网络,而DLL就不会,因为防火墙只针对主进程.

说完了优点,该说缺点了:

1.同样由于所有的应用都是使用的一段内存,也就成为了最大的缺点,比如用户同时在斗地主和麻将里面,如果由于麻将某些质量不高的代码引起了内存操 作错误,那么其结果就是整个游戏大厅进程崩溃,斗地主也就要遭殃了. 同理如果使用一个堆栈的坏处还有: 一个进程所占用的内存过高,每个游戏的效率都受影响,同时频繁的操作导致了更多的内存随片,危险系数大大增加.

2.游戏大厅和游戏房间在一个DLL中,或者使用抽象的库,具体的游戏是继承公共的类库来实现,高耦合度的系统向来是能避免则避免,前面提高的稳定 性不说,dll hell这个讨厌的事情也是经常发生的事情,由于业务逻辑改动公共库改动是经常的事情,如果一不小心改动了类函数结构或者增加了变量那么就需要把每个游戏 都重新编译并发布,新产品上线的时间以及实施的成本就大大的增加了.

另外一种形式就是EXE的形式了,游戏广场和游戏大厅都在一个主进程中处理,游戏房间采用另外一个进程来处理,优点就不用说了看了上面的缺点就应该 明白这个形式的优点在哪里了,关键是缺点,如果使用分进程的模式所面临的就是2个主要问题,进程间的通讯和连接的维护,以下分析使用此模式的各个产品这方 面的具体的方法,大部分为猜测:)

QQGAME:QQGAME的游戏大厅和游戏EXE应该是使用了COM进行双向的过程调用,因为看到它的目录下面有个COMToolKit.dll 文件,估计这个就是处理COM的或者类COM的方式来处理进程间的通讯,对于连接方面,用户进入游戏大厅后和具体的游戏服务器只有一个网络连接.所以很容 易的推断游戏大厅起到了网络消息转发的作用,游戏房间中的网络消息通过游戏大厅转发.

SOHU:SOHU游戏中心的游戏大厅和游戏EXE之间的进程通讯使用了SOKET通讯的方式,采用UDP协议,同样和具体游戏服务器之间使用一个TCP连接,游戏大厅进行网络消息的转发,不过UDP协议虽然高效,但是时序和丢包率方面也是缺陷,不知道它是如何保证的.

另外还有的方式也有内存共享传递数据,IPC等方式这里就不一一表述了.以上2个类型有一个共同点就是游戏大厅充当了消息的转发功能,所以对于游戏 大厅进程的稳定性方面就有比较高的要求了,否则用户的大厅主进程EXE挂掉了即使每个游戏的EXE还活着也没什么用了.所以就有了另外一个模式,双 SOKET模式,即游戏房间EXE使用独立的SOKET,用户玩一个游戏需要同时维护2个连接,大厅挂了游戏继续玩,可用性方面有了保证,但是性能方面降 低了50%以上,网络消息的有些要重复的发送,此类的代表就是GAMEABC了,运营平台成本方面就比其他的高了.