導讀：網絡遊戲架構設計綜述
隨着 Stream、TapTap 等遊戲平臺的崛起，越來越多的網絡遊戲在此平臺投放，而且很多新發布的遊戲收入都頗豐，這些發佈的遊戲很多都是幾個人開發完成的，而且開發週期都比較短，如何才能快速開發網絡遊戲？一個比較好的遊戲框架是非常必要的。另外，這些平臺的崛起，對於獨立遊戲開發者來說，也是一個非常好的機會，換句話說獨立開發者的春天又來了，當然對於那些想從事遊戲開發或者說已經在這個行業從事遊戲開發的人也是一個機會。
現在遊戲不只限於抄襲了，更強調創新，只要有好的創意，再加上一個比較好的遊戲框架，幾個志道同合的小夥伴就可以開發一款網絡遊戲。在國外有很多這方面的案例，幾個人在不同的地方，一起開發一款遊戲。而在國內很多普通程序員在遊戲公司估計只是從事某項單一的邏輯功能編寫，對整體架構設計並不是很瞭解，即使自己有好的想法侷限於自己的能力估計也是很難做出一款遊戲，在遊戲公司很少有人會教你架構設計，而且對於開發者來說，要麼只會客戶端，要麼只會服務器，非常少的人同時精通二者，這也困擾着那些想自己做遊戲的開發者。本課程正是基於解決這些困擾程序員的問題，提出了一種基於網絡服務器的架構設計，讓程序員一個人可以同時進行客戶端和服務器的網絡遊戲的開發，這樣再加上美術和策劃就可以搞定一款網絡遊戲。
搭建遊戲框架首先要搞清楚什麼是框架？其實搭建框架的主要目的是便於遊戲邏輯的編寫，這樣非常有利於開發者快速的開發遊戲，框架的核心思想是模塊之間的耦合性要降低。那我們先搞清楚遊戲框架中主要包括哪些技術點，從大的方面說，每款遊戲都有自己的 UI 系統、角色系統、技能系統、網絡系統等等，往小的方面說就是編碼的細節——每個類的編寫。下面就把遊戲中的幾個核心系統的架構設計思想逐步介紹給讀者，架構設計沒有好壞之分，用着方便就可以，在這裏就當是拋磚引玉，讀者也可以在此基礎上去擴展，去重新編寫架構。這樣本篇教程的目的就達到了。
先介紹 UI 系統，這個是老生常談的，UI 架構常用的設計模式是 MVC。讀者應該對 MVC 都比較瞭解，原理就不介紹了，可以去網上查閱。下面講下 MVC 模式如何在 UI 系統中使用？先看下面這幅架構圖：
我們就圍繞着這幅圖給讀者介紹模塊設計。
在設計 UI 框架時首要考慮的事情
首先，要做到 UI 資源和代碼邏輯的分離，因爲 UI 資源是經常更換的，如果二者不分離，很容易在更換資源時出現各種各樣的腳本丟失以及資源和代碼邏輯對應不上問題，這個對於程序來說必須要避免的，程序員不應該把時間都浪費在這些事情上面。
其次，邏輯代碼之間的耦合性要降低，降低耦合性的方法通過事件的方式進行處理，很多程序使用 SendMessage 這種 Unity 自帶的消息發送機制，其實它是非常消耗 CPU 的，爲了優化這些，我們會自己封裝事件機制。
以上兩點是指導我們做架構的指導綱領，不論怎麼設計最好圍繞二者進行。
接下來介紹 UI 架構搭建的各個邏輯模塊，上圖中顯示的窗體模塊並不全面，遊戲中的窗體是非常多的，在此以登錄窗體和英雄窗體爲例進行說明：Loginwindow 和 HeroWindow 它們是負責顯示的，也就是說，它對應具體的窗體邏輯，它對應的 MVC 模式中的 V，相當於 View 顯示，該模塊是不繼承 Mono 的，也就是不掛接任何 UI 對象。LoginCtrl、HeroCtrl 模塊相當於 MVC 中的 C，Control 控制，用於操作 LoginWindow，HeroWindow 所對應的 UI 窗體，比如用於控制不同窗體的顯示、隱藏、刪除等等操作，在圖中沒有列出 MVC 中的 Model 模塊，這個模塊主要是用於網絡消息數據的接收，也可以通過文本文件直接賦值的，它可以使用列表進行存儲，相對來說用處並不是不可替代的。
遊戲中存在的窗體是非常多的，這麼多窗體，如果不同的開發者寫邏輯，會搞的很多，不利於統一管理。由此需要一個類 WindowManager 管理類進行統一註冊管理各個窗體類模塊，這種處理方式也就我們經常說的工廠模式。
另外，窗體之間是經常會進行不同的切換，這些切換也可以對它們進行流程管理，因爲窗體之間的切換是一種固定的流程。既然經常轉換，我們不免會想到狀態機用於處理這種流程。在此，引入了狀態機進行統一管理不同窗體狀態的變換。各個模塊之間的耦合性也是要重點考慮的問題，在此採用了自己封裝的事件機制進行解耦合。
具體實現邏輯如下，每個窗體對應自己的類，以登錄 UI 爲例進行說明，每個 UI 都是一個 Window 窗體對象，它對應着 Loginwindow 類、LoginCtrl 類、LoginState 類。其他的窗體類似，而這些類都不繼承 Mono 也就是說不掛接到任何 UI 窗體對象上，這樣，徹底實現了資源和代碼的分離，UI 系統思想設計完成，接下來再介紹技能模塊和角色系統的架構設計。
技能模塊設計思想
技能模塊在遊戲中的表現非常重要，也是常見的，在實現之前先把技能設計架構給讀者展示，如下圖所示：
關於技能的設計，首先要考慮的是這個技能是誰釋放的，也就是說的遊戲實體類，實體類的設計在此分了三層：IEntity、IPlayer 和 Player，這三個模塊同樣不繼承 Mono，也就是說不掛接到任何對象上，具體的實現會在後面的章節中結合代碼詳細介紹，技能釋放者找到了，接下來設計技能了。
遊戲中的技能分好多種：正常釋放的技能、被動技能、遠程技能等等，這些不同的技能我們也將其進行模塊化設計，其實它們的內容是類似的，可以考慮使用腳本自動生成代碼。當然對於遊戲中衆多特效的使用，我們也需要寫一個特效管理類，用於創建不同的特效，特效採用的就是模塊化管理，特效實現了後，就要考慮特效是根據遊戲實體對象的不同動作進行釋放的，不同的動作對應着不同的技能，這當然就是不同動作之間的切換，在這裏使用了 FSM 有限狀態機進行統一調度。
再介紹一個重要的模塊——對象池，因爲我們的特效會頻繁的創建、銷燬，還有遊戲中的怪物 NPC 也是一樣的。當然，其他的遊戲管理類在遊戲中都比較常見，其他的一些系統比如揹包系統、任務系統，這些可以根據消息或者配置文件進行加載讀取，這裏就不一一說明了。
接下來介紹比較重要的網絡遊戲服務器，我們的服務器使用的是 Photon Server，用戶直接搭建非常方便，在本教程也會把服務器的搭建過程介紹給讀者，我們的網絡架構採用的是房間模式，同房間的人可以在場景中實時同步，包括技能、動作等等。而該實時同步的實現方式採用的是狀態同步，接下來介紹一下 Photon 服務器的體系結構：
爲什麼選擇 Photon Server 作爲服務器，因爲該服務器提供了負載均衡，以及做大型網絡遊戲 MMO 等技術實現，用戶無需太關心。它的核心使用的是 C++ 編寫的，效率無需使用者關心，同時該服務器支持 UDP、TCP、HTTP 和 Web 套接字，它的應用層使用的是 C# 編寫的，對於用戶編寫邏輯非常方便，而且它也支持數據庫和非數據庫模式，比如 MySQL、SQL Server 等數據庫，以及 MongoDB、Redis 等非數據庫。
再介紹一下關於服務器的基本工作流程，從客戶端角度來看，工作流程也非常簡單，非常適合新手學習，客戶端連接到主服務器，可以加入大廳，並檢索打開遊戲列表。當他們在 Master 主服務器上 CreateGame 操作時，遊戲實際上並不創建遊戲服務器，而是確定人數比較少的遊戲服務器，將 IP 地址返回給客戶端。當客戶端在主服務器上調用 JoinGame 或 JoinRandomGame 操作時，主服務器查找運行遊戲的遊戲服務器，並將其 IP 返回給客戶端。流程圖如下所示：
如果客戶端與主服務器斷開連接，使用剛收到的 IP 連接到遊戲服務器，再次調用 CreateGame 或 JoinGame 操作，斷線重連都沒有任何問題。下面介紹遊戲中比較重要的部分，MMO 遊戲同步思想。
關於使用 Photon Server 做 MMO 遊戲同步實現的思想
客戶端中的地圖，同樣也會在服務器中虛擬一個跟客戶端大小完全一樣的地圖，角色就是在這些虛擬空間中同步，角色同步是在一定的區域內進行同步的，也就是在一定的區域內是互相“看見”的，這種看見與客戶端的相機裁剪是完全不同的。效果如下圖所示：
計算哪些對象在某些區域會頻繁移動，這些對象可能會非常耗費 CPU 資源。加速這一計算的一個簡單的方法是將虛擬空間劃分爲固定區域，然後計算哪些區域重疊。客戶應該接收這些重疊區域中的項目的所有事件。最簡單的算法使用方形的網格，有時我們也稱爲九宮格算法，如下所示：
物體通過當前的區域推送事件，一旦特定的區域重疊，它自動訂閱區域的事件通道，並開始接收包括物品推送的區域事件。爲了避免在區域邊界頻繁地訂閱和取消訂閱改變，引入了另外的更大的興趣區域半徑：跨越此外半徑的訂閱區域被取消訂閱，客戶端停止接收區域事件。用通俗的語言講就是在服務器虛擬的場景中，會通過不同的玩家生成各自的九宮格區域，其他 NPC 或者玩家在對方的九宮格區域裏面，物體都會顯示，離開自己的九宮格區域就剪掉，這樣也會是考慮到效率問題，因爲如果整個場景實時同步計算，這對於客戶端和服務器壓力都是很大的。九宮格區域如果重合那就把重合的部分都顯示出來。如下圖所示：
本教程實現的網絡遊戲架構設計，最終實現的效果圖如下所示：
該圖是簡單的創建房間以及加入房間進行網絡同步界面，進入遊戲後實現的遊戲中的效果如下圖所示：
用戶創建房間，其他用戶加入房間，多人場景在同一房間中同步的效果如下所示：
通過此網絡遊戲框架可以快速的把網絡遊戲實現出來，本課程的最後會把服務器和客戶端代碼都奉獻給讀者，希望對開發者有所幫助。從下章開始，本教程進行詳細介紹架構設計實現。