我所理解的網絡遊戲<一>：網遊的頂層設計

網遊的基本結構

各大模塊的基本功能以下

· 服務器端

登錄服：處理新建玩家、登錄邏輯。

場景服：處理場景服中的邏輯。

中心服：處理跨服的邏輯，實現不一樣場景服進程的數據調度，以及向數據庫查詢數據。

數據庫前端：定時將這裏緩存的數據存入數據庫。

 

服務器管理服：經過配置xml管理多個服務器的啓動關閉，做爲守護程序按期與全部服務器相連，當不能接受到某個服務器的按期鏈接時認爲該服務器宕機，作相應處理並重啓服務器。

運營對接服務器：鏈接多個服務器，作GM管理，處理來自運營平臺的登錄、充值、身份驗證。

日誌服務器：記錄玩家的數據（包括玩家登入登出記錄；升級、經驗、道具的得到途徑、遊戲時間；玩家消費的傾向等）供運營作數據挖掘及服務器意外宕機後的賠付依據。

 

 

· 客戶端

接收玩家輸入，處理遊戲邏輯，顯示遊戲。

 

接着討論一下上述五個大模塊具體該實現那些功能，可以拆分紅那些小的模塊，分爲那些層次。這裏只討論大模塊所能拆分出那些小模塊，以及這些模塊要負責的功能，至於這些模塊如何設計，將在後續討論。

 

場景服的結構

首先就場景服進行討論

 

· 可公共的網絡與數據庫底層

場景服最底層的是「數據庫存儲過程調用」、「網絡消息接收」和「網絡消息發送」，這些功能通過抽象能夠供其餘服務器模塊（中心服、登錄服）共用。

 

數據庫存儲過程調用用於與數據庫前端進行交換。其中一種作法是經過存儲過程id區分存儲過程，以數據流的方式填充存儲過程的輸入參數，以數據流的方式返回存儲過程輸出結果。

 

網絡消息接收和網絡消息發送經過對socket的進一步封裝，使得消息可以很方便的被解析和發送，它們一般要實現的功能包括網絡鏈接創建、套接字的解析、數據加密與解密、數據包的組包與拆包、數據流的寫入與讀取。

遊戲業務邏輯執行完畢後再調用底層的網絡消息發送，向中心服、或客戶端發送消息。消息發送既能夠直接對流進行寫入，能夠填充一個結構體，在將結構體寫入流。後一種方法的好處在於可以確保進入流之中的消息的格式，不會出現直接進行流寫入時會出現漏掉消息的某個數據致使消息格式出錯的問題。

還有就是網絡通訊消息的大小對於受流量限制的手機遊戲相當重要，老邱提出可使用Google開源項目的 Protocol buffers，對消息進行壓縮。（ 相關介紹）

 

· 可公共的事件觸發層

往上一層是「事件監聽」、「日誌管理」以及「消息派發」。這些功能中，事件監聽是能夠供其餘服務器模塊共用。

事件監聽包括數據庫回調獲得監聽、客戶端網絡消息監聽、場景服不一樣模塊的消息監聽、中心服數據返回的監聽。經過監聽事件的消息碼，消息會觸發相應事件監聽的消息回調。

 

消息派發與事件監聽相相似，主要能夠分爲網絡消息派發、響應消息派發、否決消息派發。網絡消息派發是接收到客戶端或中心服消息後進行派發。響應消息派發是場景服中某個業務邏輯模塊在處理本身的邏輯業務時須要通知其餘邏輯業務模塊進行相應更新。否決消息派發是場景服中某個業務邏輯模塊在處理本身的邏輯業務時須要獲得其餘模塊的驗證。

消息的派發還要作一個必定時間內接收同一客戶端消息的限制，當消息接收頻率超過必定數值，能夠判斷客戶端至少使用了按鍵精靈或者加速器，甚至客戶端已經被破解了，這樣的話能夠考慮將該客戶端踢下線。

 

日誌能夠分爲錯誤/警告日誌和玩家記錄日誌。錯誤/警告日誌用於記錄遊戲執行中發生的異常，編寫業務邏輯模塊的程序員應該考慮一些異常狀況，在發現這種異常狀況時調用錯誤/警告日誌進行記錄，這樣能爲程序的bug調試提供線索；

玩家記錄日誌用於記錄玩家的重要數據，如玩家等級、經驗、物品等，以防遊戲發送崩潰、回檔等狀況時檢查錯誤，並做爲營運期發生意外異常時賠償給玩家的根據。這種日誌將發送到日誌服務器存儲到數據空中。關於玩家記錄的日誌，因爲數據量會十分龐大，具體工做應該獨立出來成爲另外一個服務器，即日誌服務器。這層僅用於向日志服務器發送數據。

 

· 數據層

往上一層是數據層，這裏包括玩家、寵物、坐騎、物品、容器的數據。這些數據類的接口須要定義好，方便擴展，例如能夠將全部數據獲取都集中定義到一個函數，經過傳入的枚舉區分所要獲取的數據，設置數據也是使用一樣的方法。經過這樣的接口定義，有助於擴展，更有助於邏輯腳本的調用，是的上面一層的遊戲業務邏輯層更爲靈活。

數據層還要考慮兩種狀況，在線玩家的完整在線數據，和因跨服業務邏輯致使的離線玩家部分數據請求。這些請求由跨服業務邏輯發出，程序查詢數據庫或得到。得到得結果能夠緩存在中心服中，並同步到發起查詢的場景服中，供下一次請求使用。離線玩家再次上線時，與之相關的離線部分數據應從緩存中清理掉。

 

· 邏輯層

最上層的是遊戲業務邏輯層，這裏主要能夠分爲場景服業務邏輯，和跨服業務邏輯。場景服業務邏輯是指該業務邏輯須要的數據都在同一個場景服進程中；而跨服業務邏輯是指該業務邏輯須要的數據不必定在同一個場景服進程中，有可能須要中心服進行跨服的數據查找。這裏能夠產生不一樣的設計，例如數據只存在場景服進程中，中心服只是作一個調度數據的功能；或者數據即存在場景服，中心服有全部的數據。我並無實現過跨服業務邏輯的功能，因此暫時並不知道那種設計更好，以及應該考慮的因素。

不一樣的設計按照策劃的需求，場景服業務邏輯派生出養成模塊、戰鬥模塊、玩家活動響應、玩家數據管理模塊、小遊戲模塊；跨服業務邏輯派生出副本模塊、跨服PVP模塊、好友模塊、聊天模塊、幫派模塊、交易模塊。

養成模塊包括玩家眷性提高（科技）、技能升級、坐騎的升級、寵物的升級

戰鬥模塊

玩家活動響應，包括玩家行爲的廣播、任務模塊

玩家數據管理模塊

小遊戲模塊

 

配置數據和腳本邏輯都是對遊戲業務邏輯層的支援。配置數據是提供給策劃填寫遊戲內容。而邏輯腳本是用於描述遊戲業務邏輯的。腳本可使用Lua、Python等。爲什麼要使用腳本？使用腳本的好處是靈活，針對多變的策劃需求，腳本編寫的業務邏輯能夠不經從新編譯就能應對小規模的修改。如何提升腳本代碼的執行效率？腳本應只調用封裝好的C++函數組織成業務邏輯，而不進行數據運算。這樣效率接近C++編譯的原生代碼。

 

中心服的結構

中心服的結構與場景服的結構基本相同，不一樣之處在於其主要處理的是跨場景服的遊戲業務邏輯。而邏輯層的具體設計能夠採起dll插件式的設計，主要是因應跨服邏輯可能出現的增減，同時也是的插件專門針對一個模塊能比較獨立。

登錄服的結構

登錄服主要起到的功能包括：

1. 建立新玩家

2. （ 登錄服、中心服、場景服之間的關係是怎樣的？用戶登錄的流程應該是先到哪一個服，怎樣走？）

 

數據庫前端

數據庫前端主要起一個緩存數據提供效率，統一管理數據庫操做的做用，結構以下：

（數據庫前端擔負一些什麼功能？）

 

服務器管理服的結構

（所擔負的功能；多線程結構）

 

運營對接服的結構

（所擔負的功能——用例圖；可以選用的技術；對接的模式）

 

日誌服的結構

（所擔負功能；大量數據應如何處理，內存不足，佔用太高，緩存的使用）

 

客戶端的結構

客戶端的功能包括遊戲資源的版本驗證與下載、與服務器網絡通訊、遊戲場景構建、模型繪製、動畫和特效的播放、UI界面和玩家輸入的響應。

具體結構大體以下

整體來講能夠劃分爲三條主線：UI、網絡、以及資源與數據。按照MVC的分層模式，能夠分爲：

表現層，主要包括UI事件響應的表現，當前攝像機的設置，以及動態/靜態（場景）物體的表現，這一層與客戶端的圖形引擎顯示相關的接口緊密結合；

業務邏輯層，主要包括UI界面上的遊戲邏輯，不一樣攝像機根據需求的切換，以及動態/靜態（場景）物體管理、動態物體的業務邏輯還有動態物體的生成、變化與銷燬。這一層是遊戲主要玩法的所在，大量投入邏輯程序員開發的地方；同時也是會因應策劃需求，容易發生變化的地方。這一層會與客戶端的UI接口，物理引擎，AI引擎緊密相連；

數據層，可分爲元數據層、數據加載層、數據管理層，主要負責數據的讀取、解析和管理。這些數據能夠分爲來自網絡的網絡通訊消息、UI資源、配置和本地記錄數據、由模型特性聲效組成的美術資源。因此這一層會跟客戶端圖形引擎的資源解析，客戶端目標系統的文件系統、網絡系統緊密相關。這一層要考慮到數據加載的不一樣步問題，具體而言就是微端要求玩家可以下載儘量小的客戶端快速進入並開始遊戲，致使這些資源，特別是美術資源，在遊戲運行時可能正在下載。要保證在沒有資源的狀況下游戲可以運行，同時當資源下載好後馬上顯示出來。

 

輔助工具

網絡遊戲的開發除了以上的最終發佈的製成品外，還須要不少的輔助工具。如下僅做列舉和簡單說明，具體討論留在後面。

名稱	做用	描述
機器人系統	對服務器進行模擬的壓力測試	主要經過模擬多人同時與服務器進行通訊，對服務器進行壓力測試 經過測試，能夠看到服務器的性能；甚至在能夠反映出服務器是否出現內存泄露等狀況
配置表編輯工具	供策劃填寫配置表	經過對編輯工具的限制，可以有效避免策劃填錯數據的問題
擺怪編輯器	供策劃設計關卡、佈置場景和怪物	與場景編輯器，甚至是遊戲引擎緊密結合，最終產生一張物件id和位置等相關信息的配置表
粒子編輯器	供美術將粒子系統編輯成爲特效	與遊戲引擎相結合，美術附上着色器、貼圖、模型可以看到特效的效果
場景阻擋數據的導出工具	供美術標記場景中玩家可行走的區域	阻擋數據也會應用到自動尋路和npc行走等功能中，同時也是服務器驗證玩家位置的依據之一
動畫組合編輯器	供美術將動畫和特效組合到一塊兒	具體的例子是技能編輯器，將不一樣的技能動畫和特效按美術所設想的順序、間隔播放
攝像機編輯器	供美術設置不一樣的攝像機	與遊戲引擎相結合，美術在一個測試場景調整不一樣攝像機的參數，以及攝像機拉近推遠的參數
場景動畫編輯器	供美術在場景中編輯模型、攝像機、特效組合成場景動畫	可考慮與上面的美術工具相結合

這些工具或是與客戶端引擎緊密相連，或是與通訊消息相關，或是利用到一些工具，能夠製做爲獨立的小程序，或者遊戲引擎、美術工具的插件。

 

 

後續內容：

已完成：

進行中：客戶端的主體設計

 

計劃中：

服務器相關：服務器的主體設計（場景服與中心服）、網絡通訊設計、數據緩存與數據庫通訊設計、數據層設計、邏輯層設計與dll劃分、戰鬥模塊設計、機器人壓力測試工具設計、服務器管理工具設計、運營對接服務器設計、攻擊服務器方式及對策。

客戶端相關：資源動態加載與管理、場景管理、戰鬥模塊設計、特效實現方式、UI相關（原理與美術製做規範）、動畫相關（原理與美術製做規範）、美術工具設計、破解客戶端方法與對策。

公共部分：性能優化與代碼檢測、測試遊戲的方法、遊戲開發團隊的組建、改善遊戲體驗的要素。