網絡游戲中棋牌類游戲的設計與實現(xiàn)

網絡游戲中棋牌類游戲的設計與實現(xiàn)

下棋游戲是許多玩家喜歡的游戲，但在商業(yè)網絡游戲系統(tǒng)中，游戲的類型和規(guī)則相對固定。由于棋牌類游戲畫面簡單、實時性要求低、游戲邏輯簡單,所以實現(xiàn)復雜度相對較低,我們完全可以自主構建各種特色棋牌網游系統(tǒng),為此本文提出了對一種通用的基于Windows系統(tǒng)的棋牌網游系統(tǒng)方案,該方案已經成功地應用于一個棋類游戲網游戲系統(tǒng),讀者可以在此方案的基礎上根據(jù)具體情況進行各種細化和完善。由于大家均比較熟悉棋牌類網游的功能,所以接下來直接從系統(tǒng)總體架構開始介紹。1全球框架網游系統(tǒng)由客戶端和服務器端組成。1.1客戶端主程序支持1.1.1為確保游戲規(guī)則的靈活性和服務器的精簡,本方案將游戲邏輯放在客戶端實現(xiàn),服務器端不對游戲數(shù)據(jù)進行處理,這樣開發(fā)人員可以自由修改游戲規(guī)則(通過修改客戶端程序或配置)。即使在增加新游戲種類時,在服務器端也不需修改程序,只需修改配置即可。1.1.2為了提高客戶端開發(fā)的重用性,把具體的游戲畫面繪制、游戲邏輯功能封裝到游戲子模塊中(用動態(tài)鏈接庫(DLL)的形式實現(xiàn)),每種游戲用一個DLL實現(xiàn)。把各游戲通用的功能,如用戶登錄、游戲室操作、網絡通信、用戶輸入操作等功能,放在客戶端主程序來實現(xiàn)。1.1.3為降低復雜性,限定一種游戲只有一個游戲室,每個玩家同一時刻只能進入一個游戲室(可以直接從一個游戲室進入另一個游戲室),只能玩一種游戲,不支持旁觀功能,進入游戲后不顯示游戲室畫面,退出游戲后重新顯示游戲室畫面。允許在一臺計算機上同時運行多個客戶端系統(tǒng)。1.1.4在服務器端為了實現(xiàn)對多客戶的并發(fā)支持,采用了多路利用I/O技術和線程池技術。雖然Winsock中的完成端口技術也可以實現(xiàn)類似功能,但考慮到通用性的因素,方案中沒有使用該技術。1.1.5由于系統(tǒng)提供了游戲室、游戲桌機制,在服務器端提供了專門的游戲室模塊進行管理,對此類數(shù)據(jù)(如玩家進入游戲室、坐下、站起等)要進行的處理。1.1.6由于注冊玩家可能數(shù)量眾多,而在線玩家數(shù)量相對較少,在服務器端提供了在線玩家管理器,針對在線玩家進行狀態(tài)管理,但不實現(xiàn)游戲積分功能。1.1.7為了降低服務器端的實現(xiàn)難度,采用本地數(shù)據(jù)庫(如ACCESS)存儲相關數(shù)據(jù),避免使用網絡數(shù)據(jù)庫引進的額外復雜度。在用戶數(shù)量級為一千以內時,在性能上完全可以滿足要求。1.1.8方案包含一個用于面向玩家提供注冊用戶、游戲程序(DLL文件)下載等功能,面向管理員提供游戲配置等功能的網站系統(tǒng)。由于該網站功能簡單、技術復雜度不高(主要為數(shù)據(jù)庫的讀寫操作),所以對其設計和實現(xiàn)不作介紹。服務器在啟動時一次性讀取數(shù)據(jù)庫中的游戲配置信息,所以如果通過網站修改了游戲配置,需要重啟服務器才能生效,但新注冊的用戶可以實時生效。1.2消息的組成和方向客戶端與服務器端之間通過TCP協(xié)議通信,應用層數(shù)據(jù)為自定義的消息。每個消息由消息名和若干參數(shù)組成,各種消息的具體情況見表1,表1中未給出詳細的消息和參數(shù)格式,可自行設計,最好全部采用可顯示字符。表1中“方向”列中C->S表示消息傳送方向為從客戶端到服務器端,S->C表示消息傳送方向為從服務器端到客戶端。所有C->S方向消息的第1個參數(shù)均為消息發(fā)送者的玩家ID。1.3根據(jù)游戲情況響應消息的處理有一定的順序要求,如客戶端只在進入游戲室后才可以發(fā)送sitdown請求,只在游戲過程中才可以發(fā)送gameend消息,等等。以下假設消息都按正確的順序出現(xiàn),忽略了消息順序錯誤的處理。此外,對于消息參數(shù)格式錯誤或內容錯誤(如請求坐在一個不存在的座位上),服務器端直接忽略,不發(fā)送任何響應。1.3.1服務器收到login消息后,若登錄成功用gamelist消息響應,登錄失敗用error消息響應,錯誤類型為登錄失敗(或細分為ID錯、密碼錯等)。1.3.2服務器收到entergameroom消息后,用該游戲室的gameroominfo消息響應。發(fā)送原因為“數(shù)據(jù)刷新”。1.3.3服務器在某游戲室狀態(tài)變動時(有玩家坐下或站起),向所有已經進入該游戲室的玩家發(fā)送gameroominfo消息,發(fā)送原因為“數(shù)據(jù)刷新”。這一點體現(xiàn)在以下消息的處理過程中。1.3.4服務器收到sitdown消息后,若坐下成功,用gameroominfo消息響應,并按1.3.3廣播該消息。若坐下失敗(如指定座位非空),用error消息響應,錯誤類型為坐下失敗。若收到sitdown消息后,該游戲桌己經達到游戲開始的條件,則向該游戲桌的所有玩家(包括sitdown消息的發(fā)送者)發(fā)送gamestart消息。1.3.5服務器收到standup消息后,若站起成功,處理方法同sitdown消息。若站起失敗(如玩家尚未坐下),用error消息響應,錯誤類型為站起失敗。1.3.6服務器收到gamemessage消息后,不作任何處理,透明轉發(fā)給所有其他同桌玩家,沒有響應。1.3.7一盤游戲正常結束后,每個參與玩家均向服務器發(fā)送gameend消息,服務器無響應。一盤游戲結束后,若玩家選擇繼續(xù)游戲,向服務器發(fā)送resumegame消息,服務器無響應。若服務器收到所有參與玩家的resumegame消息后,向所有參與玩家發(fā)送gamestart消息(玩家的順序可不變,也可按一定規(guī)則變化)。1.3.8一盤游戲結束后,若玩家選擇不繼續(xù)游戲,或在選擇了繼續(xù)游戲后等待其他玩家確認繼續(xù)游戲的過程中選擇退出,則向服務器發(fā)送quitgame消息。若玩家在游戲進行過程中逃跑,則向服務器發(fā)送escapegame消息。1.3.9服務器收到quitgame或escapegame消息后,強制該玩家從原座位站起,并各所有其他同桌玩家發(fā)送gameroominfo消息,發(fā)送原因為“某玩家退出”或“某玩家逃跑”。并按1.3.3廣播該消息。1.3.10客戶端在游戲過程中,或在兩盤游戲的間隙時間,收到發(fā)送原因為“對方逃跑”或“對方退出”的gameroominfo消息,說明對方己退出或逃跑,退出到游戲室畫面(根據(jù)剛才收到的gameroominfo消息中的數(shù)據(jù)進行繪制)。如果收到發(fā)送原因為“數(shù)據(jù)刷新”的gameroominfo消息,將其忽略。1.3.11客戶端只在未進入游戲之前才能直接退出程序,退出前發(fā)送logout消息給服務器,服務器收到后進行判斷是否需要按1.3.3廣播gameroominfo消息。1.3.12若服務器在非游戲過程中檢測到某玩家出現(xiàn)網絡故障等異常情況,可等價于收到該玩家的logout消息。若服務器在游戲過程檢測到某玩家出現(xiàn)異常情況,可等價于連續(xù)收到該玩家的quitgame(或escapegame)消息和logout消息。客戶端在檢測到異常情況時直接退出程序即可。1.4安全系統(tǒng)網游系統(tǒng)必須考慮到安全問題,由于本系統(tǒng)為非電子商務類應用,只要求一般的安全性即可。1.4.1有效的密鑰為避免客戶端與服務器之間在網絡上傳送的信息被監(jiān)聽,可采用加密算法,如DES。DES的密鑰可固定為一常數(shù),或由客戶端在網站上注冊用戶時(見1.1.9)由服務器分配一證書,客戶端采用該證書中的密鑰進行加密通信。考慮到對安全性要求不是特別高,沒有必要采用比較復雜的非對稱密鑰算法。1.4.2消息的評估與被監(jiān)聽相比,消息被篡改是一種更嚴重的安全威脅,可采用MD5摘要算法來對消息真實性進行鑒定,摘要可作為消息的一部分發(fā)送。1.4.3外來人口的接收在1.3中提到,客戶端與服務器在處理消息時都有一定的順序要求,在某種狀態(tài)下收到此狀態(tài)不可能產生的消息類型,即將之拋棄,此外,服務器可限定在一個網絡連接(TCP連接)上只能接收由同一個玩家ID產生的消息,否則將之拋棄,通過這些方法保證了游戲邏輯的安全性。1.5如上所述，客戶和服務器的總體結構可以包括圖1和圖22游戲plc實現(xiàn)2.1狀態(tài)管理向其它模塊提供玩家當前狀態(tài)的讀寫服務,玩家狀態(tài)有下列幾種:未登錄、已登錄、未進入游戲室、已進入游戲室(未坐下)、已坐下、正在站起、正在游戲、游戲暫停、等待確認。初始狀態(tài)為未登錄。此外還有一P標記,表示正在完成一個動作。如P標記值為TRUE,且狀態(tài)為“已登錄”,且表示“正在登錄”(從“未登錄”到“已登錄”的切換過程),登錄完成后,P恢復為FALSE。穩(wěn)定狀態(tài)下P標記為FALSE。采用P標記可以減少狀態(tài)個數(shù)?！罢谡酒稹睜顟B(tài)是從“已坐下”到“已進入游戲室(未坐下)”的切換狀態(tài),由于“已經進入游戲室”狀態(tài)和P為TRUE的組合表示“正在進入游戲室”,故單設一個“正在站起”狀態(tài)?！罢谧隆睜顟B(tài)由“已坐下”狀態(tài)和P為TRUE組合表示?！坝螒驎和！北硎疽槐P游戲結束后的狀態(tài),此時客戶端系統(tǒng)提示玩家是否繼續(xù)游戲,若玩家選擇否,則回到“已進入游戲室(未坐下)”狀態(tài)。若玩家選擇是,則進入“等待確認”狀態(tài),等待其他玩家的確認。若所有其他同桌玩家都同意繼續(xù)游戲,則開始下一盤游戲,進入“正在游戲”狀態(tài),若至少一位同桌玩家不愿繼續(xù)游戲,則退回到“已坐下”狀態(tài)?！坝螒驎和！焙汀暗却_認”兩種狀態(tài)不需要和P標記搭配。2.2數(shù)據(jù)接收、發(fā)送線程:在程序初始化時啟動,使用流式socket技術。發(fā)送線程首先連接服務器,然后等待主窗口的通知(用event觸發(fā)技術),通知到達后取出全局數(shù)據(jù)區(qū)中的數(shù)據(jù)發(fā)送給服務器,然后繼續(xù)等待通知,不斷循環(huán)。接收線程等待接收服務器的數(shù)據(jù),數(shù)據(jù)到達后用windows消息通知主窗口,然后繼續(xù)等待接收數(shù)據(jù),不斷循環(huán)。注意,在不同狀態(tài)下windows消息的目標窗口也不同(登錄窗口、游戲室窗口等)。2.3登錄管理:玩家要求登錄后,收集必要的參數(shù)組裝login消息,提交給數(shù)據(jù)發(fā)送線程進行發(fā)送,并切換狀態(tài)到“正在登錄”(由“已登錄”和P標記為TRUE表示,下同)。當收到接收線程接收的數(shù)據(jù)后,若為gamelist,則登錄成功,切換到“已登錄”狀態(tài),并顯示游戲列表供玩家選擇。若收到error消息,恢復到“未登錄”狀態(tài),提示登錄失敗。2.4游戲室管理:玩家選擇游戲后,按gamelist指定的該游戲的DLL名在指定目錄中裝載該DLL(事先從服務網站下載),若不存在則報錯。裝載成功后(最好檢查DLL接口是否完整,詳見2.6),組裝發(fā)送entergameroom消息,以后的處理步驟(如“坐下”、“站起”等)請按1.3的交互邏輯和并參考2.3的內容自行設計,不再贅述,要注意玩家狀態(tài)的檢測和更新,如果接收到與當前狀態(tài)不匹配的服務器消息(如還未坐下就收到gamestart消息),忽略。2.5游戲DLL接口模塊:對DLL進行初始化,啟動新游戲,將用戶輸入傳遞到DLL(通過windows的鼠標、鍵盤消息來檢測用戶輸入),將數(shù)據(jù)接收線程接收的gamemessage消息中的游戲數(shù)據(jù)傳遞到DLL,根據(jù)DLL的返回值決定是否發(fā)送數(shù)據(jù),根據(jù)DLL的返回值判斷游戲是否結束等,并在需要重畫窗口時(收到windows窗口刷新消息)通知DLL重畫窗口。同樣要注意玩家狀態(tài)的檢測和更新。2.6游戲DLL接口(請自行設計詳細參數(shù)、返回值。所有游戲邏輯,包括畫面繪制、游戲規(guī)則等功能都由游戲DLL完成。游戲DLL文件名由服務器在gamelist中指定,客戶端必須事先下載好這些DLL存放在指定目錄中。):2.6.1Init:初始化DLL,傳遞一些必要參數(shù),如用于繪圖的DC等。調用一次即可。2.6.2NewGame:啟動新游戲,傳遞參與玩家ID、本玩家順序號等參數(shù)。2.6.3UserInput:處理用戶輸入數(shù)據(jù)(如鍵盤按鍵、鼠標動作、位置等)。2.6.4NetworkData:處理網絡上接收到的數(shù)據(jù)(即其他同桌玩家產生的數(shù)據(jù))2.6.5Redraw:重畫游戲畫面。2.6.6說明:UserInput、NetworkData兩個操作可能導致需要發(fā)送游戲數(shù)據(jù)或游戲結束,所以接口的返回值中包含是否需要發(fā)送數(shù)據(jù)的標記,游戲是否結束的標記,相應地還應返回需要發(fā)送的數(shù)據(jù)、游戲戰(zhàn)績。(如:象棋游戲,A玩家點擊鼠標移動了“炮”,則需要把該數(shù)據(jù)發(fā)送給其他玩家。如果其他玩家吃了A玩家的“將”,則A玩家接收到該數(shù)據(jù)后游戲結束,戰(zhàn)績?yōu)椤皵　?。2.6.7提示:游戲DLL內部適合采用狀態(tài)轉移方式來實現(xiàn)游戲邏輯。如象棋游戲,當玩家單擊鼠標時,如果處于等待其他玩家走棋的狀態(tài),則忽略此操作。否則判斷玩家是否己選定棋子,如未選定則該操作為選定棋子,如己選定則該操作為走子、吃子或重新選定棋子,對前兩種情況根據(jù)象棋規(guī)則實現(xiàn)合法性判斷。對成功選子、走子、吃子等動作,通過返回值通知DLL接口模塊需要發(fā)送數(shù)據(jù)給其他玩家。2.7其它:通過全局數(shù)據(jù)區(qū)與數(shù)據(jù)接收、發(fā)送線程交互時,要注意數(shù)據(jù)訪問的同步問題,要注意解決TCP粘包問題(可妥善設計消息格式使之易于劃分邊界)。3其他數(shù)據(jù)處理3.1組件介紹CAT:連接接收線程;DRT:數(shù)據(jù)接收線程;DRTPM:數(shù)據(jù)接收線程池管理器;WorkingChannel:工作通道;WCM:工作通道管理器;GRM:游戲室管理器;OPM:在線玩家管理器;DB:本地數(shù)據(jù)庫。每個WorkingChannel(以下簡稱為WC)包括:TQ:任務隊列;GT:游戲線程;SQ:發(fā)送隊列;DST:數(shù)據(jù)發(fā)送線程:3.2工作流程3.2.1系統(tǒng)初始化時,命WCM先創(chuàng)建若干個WC,每個WC建立自己的隊列、啟動自己的線程。WC的個數(shù)可固定,也可由WCM根據(jù)系統(tǒng)負載動態(tài)調整。3.2.2連接接收和數(shù)據(jù)接收由單個CAT線程負責接收所有客戶端的TCP連接請求,連接成功后將該客戶端的socket提交給DRTPM處理。DRTPM根據(jù)一定的策略來管理一定數(shù)量的DRT線程(生成、撤銷),并將客戶端的socket均勻分配給這些DRT來處理,每個DRT可同時接收多個客戶端的數(shù)據(jù)。關于DRTPM與DRT的管理接口與方法此處省略。每個DRT通過多路復用I/O技術(可通過select、poll或Unix中性能更高的epoll等函數(shù)實現(xiàn))同時監(jiān)測接收多個客戶端的數(shù)據(jù)(由DRTPM分配的任務),而且DRT還應定時檢測DRTPM是否給自己分配了新任務,所以在調用select等函數(shù)時,要設置timeout時間,如1秒,超時后檢測DRTPM是否分配了新任務,是則將新的socket加入監(jiān)測集合,再調用select等函數(shù),不斷循環(huán)。每個DRT在創(chuàng)建時由WCM提供一個關聯(lián)WC(WCM根據(jù)一定的策略,如負載均衡,來分配),并且在DRT生存期間不改變其關聯(lián)WC,一個WC可與多個DRT關聯(lián)。DRT接收到數(shù)據(jù)后,通過WCM的接口將其提交給關聯(lián)WC(DRT處理粘包問題,每次向WC提交一條完整的消息)。3.2.3數(shù)據(jù)處理WC將數(shù)據(jù)放進TQ,并通知GT進行處理,GT從TQ逐條提取并處理游戲消息。詳見3.4。3.2.4數(shù)據(jù)發(fā)送GT處理完一條游戲消息后,如果需要發(fā)送響應消息(一條或多條),則將要發(fā)送的消息和接收者(可以為一個或多個)放到SQ中,并通知DST發(fā)送,DST從SQ中逐條取并發(fā)送給指定的客戶端。在空閑情況下,GT和DST都在等待通知(用event觸發(fā)技術)。3.3GRM、OPM的功能GRM管理游戲室信息,在系統(tǒng)啟動時一次性從數(shù)據(jù)庫讀入由管理員事先通過網站配置好的游戲室信息,包括每種游戲的名字、ID、DLL文件名、桌子數(shù)、座位數(shù)、要求游戲人數(shù)(如象棋為2人)等。GRM還要維護每個游戲室的每個座位的狀態(tài)(空或坐在上面的玩家ID),記錄進入每個游戲室的玩家ID清單(包括坐下和未坐下的玩家),用于1.3.3描述的功能。OPM管理在線玩家及其狀態(tài),初始狀態(tài)為空(無在線玩家)。玩家有六種狀態(tài):“已登錄”“已選擇游戲”“己坐下”“游戲己開始”“游戲暫停”“等待下一盤游戲”。其含義參