傳統 MMORPG 通訊模式實現的一點想法

　　既然 MMORPG 都有千篇一律同質化的趨勢，好歹我們技術人員也應該總結出點東西來，新項目開發可以用現成的模式。

　　一般來說，MMORPG 服務器要解決的問題無非是，同步玩家的位置，狀態，把這些信息廣播出去(細分的話，有非戰斗環境和戰斗環境);需要建立一個聊天服務，供玩家文字交流;有一個信息發布渠道;有任務 NPC 和玩家一對一交流;玩家調整自己的裝備(也可以看成是和一特定 NPC 交流)。

　　以上，我們可以看到幾個基本需求是可以正交分解出來，并有不同的實現方式的。

　　同步玩家的狀態，基本上是由玩家自己不斷提交自己的最新狀態，然后由服務器把這些信息廣播給其他人。

　　聊天服務比較成熟，基本上就是玩家訂閱聊天頻道，并按權限向頻道內發布信息。

　　信息發布可以看成是一個特殊的聊天頻道。

　　任務 NPC 或是整理自己裝備，都類似于向特定節點做請求等待回復。

　　我經歷的幾個 MMO 項目都實現的比較簡單，無論是 server 還是 client ，都是跑一個消息循環，對每個到來的消息包進行處理。通常都是一個 timer 消息源和一個網絡包消息源，共同組成最終的消息源，主程序是標準的消息循環分發結構。

　　但對比前面的需求，可以看到，這些方式略顯簡陋。最后能再此基礎上再做一個層次的封裝工作，讓這些不同的需求可以分開處理。更方便的解決一些有狀態的需求，或是能夠對信息處理進行優先級排序。

　　最近一段時間，我受 zeromq 的設計思想影響較多。對于未來的項目設計方法，我有一些想法需要梳理一下。

　　玩家 Client 和游戲 Server 方面，我還是傾向于采用單一的 TCP 連接。但是希望再其上加一個層次?？梢栽趩我?TCP 連接上模擬多個通訊信道。實現 zeromq 提出的幾個模式(的變形)。

　　在我看來，MMORPG 的服務器端，可以看成是若干服務的集合。那么這些服務無論布置在哪里，我都希望他們是在一個邏輯上的網絡中。玩家通過網關也接入這個網絡，并可以根據授權來使用網絡上的服務。

　　拋開玩家登陸(注冊)流程不談。典型的場景是玩家在虛擬場景中漫步。這可以看成是 Client 向訂閱一個指定場景的環境。訂閱本身會先鑒權，服務器會查閱玩家是否有權限訂閱(玩家是否在這個場景中)。場景會不斷的發布場景中每個玩家，NPC 的動態。訂閱者將不斷的獲得這些信息。由于性能問題，我們可以把不同類別的信息放在不同的訂閱點上。訂閱可以按需進行。

　　玩家會選擇向特定場景 PUSH 自己的狀態數據，按 zeromq 的模式，這應該走另一個信道。

　　每個可對話的 NPC 都可以看成是一個特定服務。玩家向它建立連接，然后以 Request/Reply 模式工作。這樣可以方便完成帶狀態的任務。同樣，建立連接的過程可以引入鑒權(比如說檢查玩家是否在 NPC 附近等)。當然，NPC 同樣需要訂閱場景，當場景中和他交流的玩家跑開后，可以自動切斷信道。

　　戰斗部分的處理可以獨立。以即時戰斗為例，戰斗計算服務訂閱場景中對象的位置和動作。計算他們的動作的后果，得到每次攻擊的傷害值。它自己是一個信息訂閱點，玩家通過訂閱戰斗服務，可以了解場景中每個個體受傷害的情況。

　　同樣，某些增值服務，比如自動尋路，都可以獨立出來實現。

　　只是一些想法，希望整理出來后，可以有更多啟發。對人也對己。

原文轉自：http://blogread.cn/it/article/3802?f=wb