MOBA服務器開發第一階段完成總結

開發歷程

---

 

項目是從8月20日左右開始開發的，到今天一個月不到吧。

除了底層庫和服務器架構外咱們大體開發了5個服務器爲：

　　一 ) . 戰鬥服務器

　　二 ) . 匹配服務器

　　三 ) . 驗證服務器

　　四 ) . 網關服務器

　　五 ) . 遊戲服務器

其中 戰鬥服務器 和 匹配服務器是我負責的 (確實擼的很爽 哈哈哈) : 

在有一套成熟的框架體系下擼代碼的體驗就是快速穩定健全。

 

戰鬥服務器總結

---

戰鬥服務器是集羣節點的配置。

爲了提升服務器的容錯和開發速度。咱們把全部集羣服務器都設置爲單線程模式。容許一臺服務器部署多個服務器。

戰鬥服務器主要處理遊戲戰鬥中事務：

　　建立遊戲房間

　　提供英雄選擇 技能選擇 皮膚選擇

　　提供遊戲過程支持（使用技能 / 請求移動 / 斷線重連 / 遊戲結算 / 遊戲規則 / 戰鬥回放）

 

邏輯幀

　　咱們在設計戰鬥服務器之初就定義好了遊戲有邏輯幀的概念，同時客戶端也遵循該邏輯幀的時間而且客戶端的邏輯幀時間由服務器下發。

　　以此概念就能保證在大多狀況下客戶端和服務器的邏輯幀是相同的，有時候可能會出現指令有1-2幀的偏差，但這並不影響，由於一個邏輯幀也就幾十毫秒，玩家基本感知不到。（網絡延遲不參與此處偏差計算）

　　有了邏輯幀概念後，服務器只須要將收到客戶端的全部請求信息所有壓入隊列。當下一個邏輯幀到達後將全部消息取出，依次處理並下發遊戲消息。而客戶端收到網絡消息就只需作對應的播放就能夠，也就是說客戶端就算不請求服務器可是收到了服務器的下發消息也須要對該消息進行播放處理。

 

戰鬥回訪

　　服務器能夠借邏輯幀的概念將每幀下發的消息都存儲到 redis 而後用於支持戰鬥回訪。

 

技能系統 

　　爲了知足策劃的腦洞大開，技能系統開發了一版並重構了一版後，目前暫且滿意了。

　　剛剛開發技能系統的時候，選擇了快速開發的方式簡單的對技能進行 分類 / 接口抽離 / 解耦 開發了。

　　在Demo版出來後，發現功能的倒是實現了，技能系統架構也還行，但邏輯層的代碼太過於冗餘，也不方便後期的擴展和維護。

　　因而重寫之，大概的從新分析了下技能的一些處理，好比使用技能開始，使用技能下發。

　　根據以上分析和實際的開發中的心路歷程將技能抽象爲狀態機之。寫好了感受也不是最好的方式不過按目前的需求足夠了。

　　之因此選擇狀態機是由於在如今的研發階段好維護 / 好擴展，重構的話成本也不高。

 

Buff系統

　　Buff系統總共就開發了兩個類吧。由於這個比較簡單。一個是 BuffNode 節點類，一個是 BuffManager 管理類。　　

　　每個戰鬥對象會被綁定一個BuffManager管理類。這樣就把每一個對象本身的Buff都剝離開了。而且狀態操做直接操做對象類就能夠了。

 

戰鬥對象

　　全部戰鬥中能夠和其它對象交互的對象都統稱爲戰鬥對象。（能夠爲 英雄 / 彈道技能 / 甚至阻擋）

　　戰鬥對象具備類型。對外提供抽象接口。提供統一的查詢接口。外部操做都經過接口操做。

　　該設計方便了後期的擴展和維護。

 

遊戲規則

　　對外提供規則管理接口，內部規則對管理接口提供內部規則操做接口。實現一接口操做多規則的構架。

　　規則內部以狀態機方式實現，實如今不一樣狀態下的處理剝離。