网络游戏中棋牌类游戏的设计与实现

网络游戏中棋牌类游戏的设计与实现

下棋游戏是许多玩家喜欢的游戏，但在商业网络游戏系统中，游戏的类型和规则相对固定。由于棋牌类游戏画面简单、实时性要求低、游戏逻辑简单,所以实现复杂度相对较低,我们完全可以自主构建各种特色棋牌网游系统,为此本文提出了对一种通用的基于Windows系统的棋牌网游系统方案,该方案已经成功地应用于一个棋类游戏网游戏系统,读者可以在此方案的基础上根据具体情况进行各种细化和完善。由于大家均比较熟悉棋牌类网游的功能,所以接下来直接从系统总体架构开始介绍。1全球框架网游系统由客户端和服务器端组成。1.1客户端主程序支持1.1.1为确保游戏规则的灵活性和服务器的精简,本方案将游戏逻辑放在客户端实现,服务器端不对游戏数据进行处理,这样开发人员可以自由修改游戏规则(通过修改客户端程序或配置)。即使在增加新游戏种类时,在服务器端也不需修改程序,只需修改配置即可。1.1.2为了提高客户端开发的重用性,把具体的游戏画面绘制、游戏逻辑功能封装到游戏子模块中(用动态链接库(DLL)的形式实现),每种游戏用一个DLL实现。把各游戏通用的功能,如用户登录、游戏室操作、网络通信、用户输入操作等功能,放在客户端主程序来实现。1.1.3为降低复杂性,限定一种游戏只有一个游戏室,每个玩家同一时刻只能进入一个游戏室(可以直接从一个游戏室进入另一个游戏室),只能玩一种游戏,不支持旁观功能,进入游戏后不显示游戏室画面,退出游戏后重新显示游戏室画面。允许在一台计算机上同时运行多个客户端系统。1.1.4在服务器端为了实现对多客户的并发支持,采用了多路利用I/O技术和线程池技术。虽然Winsock中的完成端口技术也可以实现类似功能,但考虑到通用性的因素,方案中没有使用该技术。1.1.5由于系统提供了游戏室、游戏桌机制,在服务器端提供了专门的游戏室模块进行管理,对此类数据(如玩家进入游戏室、坐下、站起等)要进行的处理。1.1.6由于注册玩家可能数量众多,而在线玩家数量相对较少,在服务器端提供了在线玩家管理器,针对在线玩家进行状态管理,但不实现游戏积分功能。1.1.7为了降低服务器端的实现难度,采用本地数据库(如ACCESS)存储相关数据,避免使用网络数据库引进的额外复杂度。在用户数量级为一千以内时,在性能上完全可以满足要求。1.1.8方案包含一个用于面向玩家提供注册用户、游戏程序(DLL文件)下载等功能,面向管理员提供游戏配置等功能的网站系统。由于该网站功能简单、技术复杂度不高(主要为数据库的读写操作),所以对其设计和实现不作介绍。服务器在启动时一次性读取数据库中的游戏配置信息,所以如果通过网站修改了游戏配置,需要重启服务器才能生效,但新注册的用户可以实时生效。1.2消息的组成和方向客户端与服务器端之间通过TCP协议通信,应用层数据为自定义的消息。每个消息由消息名和若干参数组成,各种消息的具体情况见表1,表1中未给出详细的消息和参数格式,可自行设计,最好全部采用可显示字符。表1中“方向”列中C->S表示消息传送方向为从客户端到服务器端,S->C表示消息传送方向为从服务器端到客户端。所有C->S方向消息的第1个参数均为消息发送者的玩家ID。1.3根据游戏情况响应消息的处理有一定的顺序要求,如客户端只在进入游戏室后才可以发送sitdown请求,只在游戏过程中才可以发送gameend消息,等等。以下假设消息都按正确的顺序出现,忽略了消息顺序错误的处理。此外,对于消息参数格式错误或内容错误(如请求坐在一个不存在的座位上),服务器端直接忽略,不发送任何响应。1.3.1服务器收到login消息后,若登录成功用gamelist消息响应,登录失败用error消息响应,错误类型为登录失败(或细分为ID错、密码错等)。1.3.2服务器收到entergameroom消息后,用该游戏室的gameroominfo消息响应。发送原因为“数据刷新”。1.3.3服务器在某游戏室状态变动时(有玩家坐下或站起),向所有已经进入该游戏室的玩家发送gameroominfo消息,发送原因为“数据刷新”。这一点体现在以下消息的处理过程中。1.3.4服务器收到sitdown消息后,若坐下成功,用gameroominfo消息响应,并按1.3.3广播该消息。若坐下失败(如指定座位非空),用error消息响应,错误类型为坐下失败。若收到sitdown消息后,该游戏桌己经达到游戏开始的条件,则向该游戏桌的所有玩家(包括sitdown消息的发送者)发送gamestart消息。1.3.5服务器收到standup消息后,若站起成功,处理方法同sitdown消息。若站起失败(如玩家尚未坐下),用error消息响应,错误类型为站起失败。1.3.6服务器收到gamemessage消息后,不作任何处理,透明转发给所有其他同桌玩家,没有响应。1.3.7一盘游戏正常结束后,每个参与玩家均向服务器发送gameend消息,服务器无响应。一盘游戏结束后,若玩家选择继续游戏,向服务器发送resumegame消息,服务器无响应。若服务器收到所有参与玩家的resumegame消息后,向所有参与玩家发送gamestart消息(玩家的顺序可不变,也可按一定规则变化)。1.3.8一盘游戏结束后,若玩家选择不继续游戏,或在选择了继续游戏后等待其他玩家确认继续游戏的过程中选择退出,则向服务器发送quitgame消息。若玩家在游戏进行过程中逃跑,则向服务器发送escapegame消息。1.3.9服务器收到quitgame或escapegame消息后,强制该玩家从原座位站起,并各所有其他同桌玩家发送gameroominfo消息,发送原因为“某玩家退出”或“某玩家逃跑”。并按1.3.3广播该消息。1.3.10客户端在游戏过程中,或在两盘游戏的间隙时间,收到发送原因为“对方逃跑”或“对方退出”的gameroominfo消息,说明对方己退出或逃跑,退出到游戏室画面(根据刚才收到的gameroominfo消息中的数据进行绘制)。如果收到发送原因为“数据刷新”的gameroominfo消息,将其忽略。1.3.11客户端只在未进入游戏之前才能直接退出程序,退出前发送logout消息给服务器,服务器收到后进行判断是否需要按1.3.3广播gameroominfo消息。1.3.12若服务器在非游戏过程中检测到某玩家出现网络故障等异常情况,可等价于收到该玩家的logout消息。若服务器在游戏过程检测到某玩家出现异常情况,可等价于连续收到该玩家的quitgame(或escapegame)消息和logout消息。客户端在检测到异常情况时直接退出程序即可。1.4安全系统网游系统必须考虑到安全问题,由于本系统为非电子商务类应用,只要求一般的安全性即可。1.4.1有效的密钥为避免客户端与服务器之间在网络上传送的信息被监听,可采用加密算法,如DES。DES的密钥可固定为一常数,或由客户端在网站上注册用户时(见1.1.9)由服务器分配一证书,客户端采用该证书中的密钥进行加密通信。考虑到对安全性要求不是特别高,没有必要采用比较复杂的非对称密钥算法。1.4.2消息的评估与被监听相比,消息被篡改是一种更严重的安全威胁,可采用MD5摘要算法来对消息真实性进行鉴定,摘要可作为消息的一部分发送。1.4.3外来人口的接收在1.3中提到,客户端与服务器在处理消息时都有一定的顺序要求,在某种状态下收到此状态不可能产生的消息类型,即将之抛弃,此外,服务器可限定在一个网络连接(TCP连接)上只能接收由同一个玩家ID产生的消息,否则将之抛弃,通过这些方法保证了游戏逻辑的安全性。1.5如上所述，客户和服务器的总体结构可以包括图1和图22游戏plc实现2.1状态管理向其它模块提供玩家当前状态的读写服务,玩家状态有下列几种:未登录、已登录、未进入游戏室、已进入游戏室(未坐下)、已坐下、正在站起、正在游戏、游戏暂停、等待确认。初始状态为未登录。此外还有一P标记,表示正在完成一个动作。如P标记值为TRUE,且状态为“已登录”,且表示“正在登录”(从“未登录”到“已登录”的切换过程),登录完成后,P恢复为FALSE。稳定状态下P标记为FALSE。采用P标记可以减少状态个数。“正在站起”状态是从“已坐下”到“已进入游戏室(未坐下)”的切换状态,由于“已经进入游戏室”状态和P为TRUE的组合表示“正在进入游戏室”,故单设一个“正在站起”状态。“正在坐下”状态由“已坐下”状态和P为TRUE组合表示。“游戏暂停”表示一盘游戏结束后的状态,此时客户端系统提示玩家是否继续游戏,若玩家选择否,则回到“已进入游戏室(未坐下)”状态。若玩家选择是,则进入“等待确认”状态,等待其他玩家的确认。若所有其他同桌玩家都同意继续游戏,则开始下一盘游戏,进入“正在游戏”状态,若至少一位同桌玩家不愿继续游戏,则退回到“已坐下”状态。“游戏暂停”和“等待确认”两种状态不需要和P标记搭配。2.2数据接收、发送线程:在程序初始化时启动,使用流式socket技术。发送线程首先连接服务器,然后等待主窗口的通知(用event触发技术),通知到达后取出全局数据区中的数据发送给服务器,然后继续等待通知,不断循环。接收线程等待接收服务器的数据,数据到达后用windows消息通知主窗口,然后继续等待接收数据,不断循环。注意,在不同状态下windows消息的目标窗口也不同(登录窗口、游戏室窗口等)。2.3登录管理:玩家要求登录后,收集必要的参数组装login消息,提交给数据发送线程进行发送,并切换状态到“正在登录”(由“已登录”和P标记为TRUE表示,下同)。当收到接收线程接收的数据后,若为gamelist,则登录成功,切换到“已登录”状态,并显示游戏列表供玩家选择。若收到error消息,恢复到“未登录”状态,提示登录失败。2.4游戏室管理:玩家选择游戏后,按gamelist指定的该游戏的DLL名在指定目录中装载该DLL(事先从服务网站下载),若不存在则报错。装载成功后(最好检查DLL接口是否完整,详见2.6),组装发送entergameroom消息,以后的处理步骤(如“坐下”、“站起”等)请按1.3的交互逻辑和并参考2.3的内容自行设计,不再赘述,要注意玩家状态的检测和更新,如果接收到与当前状态不匹配的服务器消息(如还未坐下就收到gamestart消息),忽略。2.5游戏DLL接口模块:对DLL进行初始化,启动新游戏,将用户输入传递到DLL(通过windows的鼠标、键盘消息来检测用户输入),将数据接收线程接收的gamemessage消息中的游戏数据传递到DLL,根据DLL的返回值决定是否发送数据,根据DLL的返回值判断游戏是否结束等,并在需要重画窗口时(收到windows窗口刷新消息)通知DLL重画窗口。同样要注意玩家状态的检测和更新。2.6游戏DLL接口(请自行设计详细参数、返回值。所有游戏逻辑,包括画面绘制、游戏规则等功能都由游戏DLL完成。游戏DLL文件名由服务器在gamelist中指定,客户端必须事先下载好这些DLL存放在指定目录中。):2.6.1Init:初始化DLL,传递一些必要参数,如用于绘图的DC等。调用一次即可。2.6.2NewGame:启动新游戏,传递参与玩家ID、本玩家顺序号等参数。2.6.3UserInput:处理用户输入数据(如键盘按键、鼠标动作、位置等)。2.6.4NetworkData:处理网络上接收到的数据(即其他同桌玩家产生的数据)2.6.5Redraw:重画游戏画面。2.6.6说明:UserInput、NetworkData两个操作可能导致需要发送游戏数据或游戏结束,所以接口的返回值中包含是否需要发送数据的标记,游戏是否结束的标记,相应地还应返回需要发送的数据、游戏战绩。(如:象棋游戏,A玩家点击鼠标移动了“炮”,则需要把该数据发送给其他玩家。如果其他玩家吃了A玩家的“将”,则A玩家接收到该数据后游戏结束,战绩为“败”)。2.6.7提示:游戏DLL内部适合采用状态转移方式来实现游戏逻辑。如象棋游戏,当玩家单击鼠标时,如果处于等待其他玩家走棋的状态,则忽略此操作。否则判断玩家是否己选定棋子,如未选定则该操作为选定棋子,如己选定则该操作为走子、吃子或重新选定棋子,对前两种情况根据象棋规则实现合法性判断。对成功选子、走子、吃子等动作,通过返回值通知DLL接口模块需要发送数据给其他玩家。2.7其它:通过全局数据区与数据接收、发送线程交互时,要注意数据访问的同步问题,要注意解决TCP粘包问题(可妥善设计消息格式使之易于划分边界)。3其他数据处理3.1组件介绍CAT:连接接收线程;DRT:数据接收线程;DRTPM:数据接收线程池管理器;WorkingChannel:工作通道;WCM:工作通道管理器;GRM:游戏室管理器;OPM:在线玩家管理器;DB:本地数据库。每个WorkingChannel(以下简称为WC)包括:TQ:任务队列;GT:游戏线程;SQ:发送队列;DST:数据发送线程:3.2工作流程3.2.1系统初始化时,命WCM先创建若干个WC,每个WC建立自己的队列、启动自己的线程。WC的个数可固定,也可由WCM根据系统负载动态调整。3.2.2连接接收和数据接收由单个CAT线程负责接收所有客户端的TCP连接请求,连接成功后将该客户端的socket提交给DRTPM处理。DRTPM根据一定的策略来管理一定数量的DRT线程(生成、撤销),并将客户端的socket均匀分配给这些DRT来处理,每个DRT可同时接收多个客户端的数据。关于DRTPM与DRT的管理接口与方法此处省略。每个DRT通过多路复用I/O技术(可通过select、poll或Unix中性能更高的epoll等函数实现)同时监测接收多个客户端的数据(由DRTPM分配的任务),而且DRT还应定时检测DRTPM是否给自己分配了新任务,所以在调用select等函数时,要设置timeout时间,如1秒,超时后检测DRTPM是否分配了新任务,是则将新的socket加入监测集合,再调用select等函数,不断循环。每个DRT在创建时由WCM提供一个关联WC(WCM根据一定的策略,如负载均衡,来分配),并且在DRT生存期间不改变其关联WC,一个WC可与多个DRT关联。DRT接收到数据后,通过WCM的接口将其提交给关联WC(DRT处理粘包问题,每次向WC提交一条完整的消息)。3.2.3数据处理WC将数据放进TQ,并通知GT进行处理,GT从TQ逐条提取并处理游戏消息。详见3.4。3.2.4数据发送GT处理完一条游戏消息后,如果需要发送响应消息(一条或多条),则将要发送的消息和接收者(可以为一个或多个)放到SQ中,并通知DST发送,DST从SQ中逐条取并发送给指定的客户端。在空闲情况下,GT和DST都在等待通知(用event触发技术)。3.3GRM、OPM的功能GRM管理游戏室信息,在系统启动时一次性从数据库读入由管理员事先通过网站配置好的游戏室信息,包括每种游戏的名字、ID、DLL文件名、桌子数、座位数、要求游戏人数(如象棋为2人)等。GRM还要维护每个游戏室的每个座位的状态(空或坐在上面的玩家ID),记录进入每个游戏室的玩家ID清单(包括坐下和未坐下的玩家),用于1.3.3描述的功能。OPM管理在线玩家及其状态,初始状态为空(无在线玩家)。玩家有六种状态:“已登录”“已选择游戏”“己坐下”“游戏己开始”“游戏暂停”“等待下一盘游戏”。其含义参