一個SLG遊戲

2015年11月到2017年4月，我在公司的一個SLG遊戲項目組工做。SLG應該是指策略遊戲（Simulation Game）。

說的更具體一點，這幾年手機遊戲行業出現了兩個標誌性的SLG遊戲。部落衝突（COC）和海島奇兵（Boom Beach）。

加上後來Supercell另一個遊戲，皇室戰爭。遊戲立項的時候，大概是2015年11月，目標是模仿這些主流SLG，

美術風格是星際風格的SLG遊戲。遊戲最終沒有上線。由於封測的數據比較差，市場和老闆以爲沒有必要進行推廣。

內心面有不少想說的，寫在這裏吧。雖然失敗了，可是從技術上講，反而比以前的ARPG換皮學到的多。

千頭萬緒從何提及，我是寫邏輯代碼的，先從技術開始，說到哪算哪。

項目組總共有11個程序。

我主要負責戰鬥模塊開發，PVP，PVE系統開發，地理位置管理。包括客戶端，服務端。其餘小夥伴

一我的負責戰鬥尋路，戰鬥客戶端系能優化，錄像系統。

兩我的負責建築系統和一個特殊玩法聯盟戰。

一我的負責客戶端場景和2d對象的表現效果，引擎上的支持。

一我的負責攝像頭，客戶端整體優化，引擎上的支持。

一我的負責兵營系統，聯盟系統，及新手指引。（加一個最後一個月纔來的新人）

一我的負責郵件系統，AI，和部分PVE副本玩法。

一我的負責SDK相關。

最後主程，統籌全部人的工做。一些框架上的改動。

跟我作的部分相關，技術上有幾個大的難點： 

1.服務端ARPG框架改成SLG框架。

公司的其餘遊戲所有是ARPG，沒有其餘代碼能夠借鑑。ARPG有大量的場景管理，副本管理，場景對象管理。

這些大塊在SLG裏只有一小部分。

SLG裏只有兩個主要場景，主場景和戰鬥場景（參考海島奇兵）。

所以把原先在服務端的場景管理，副本管理，場景對象管理刪掉。這些改到客戶端管理。

之前ARPG專門有一個進程Gameworld管理場景，副本，場景對象，尋路，以及角色系統（我的的遊戲邏輯）的進程。

有一個Global管理全服的活動，全服的邏輯的進程。

SLG框架去掉了Gameworld，把Gameworld裏的角色管理部分移到了Global裏面。

 

2.客戶端cocos2d轉Unity3d。

2015年之前只作過cocos2d的一個ARPG。此次須要變到Unity3d。剛開始是被Unity虐的，3d比2d多了不少東西。

不過好在Unity的編輯器比較專業，不像cocos2d的編輯器（公司本身的）有點簡單。

第一次接觸Unity，發現一個和cocos2d徹底不一樣的概念。cocos2d裏面的控件是總體性的，Unity裏面控件是由Component組成的。

好比cocos2d裏一個button就是button控件，它不能是label，不能是sprite。

可是unity裏面控件，經過Component能夠成爲組合，一個button能夠有label，也能夠有sprite，能夠有tween，能夠有boxclider。

這其實只是概念上的差異。

雖然是換成unity客戶端，可是腳本邏輯依然使用lua，因此實際編程而言區別不大。

遊戲採用3d的場景（兩個場景，主場景和戰鬥場景），2d對象。2d對象用的tk2d這個插件。

 

3.全球同服。

如同海島奇兵同樣的全球同服。之前的ARPG都是一個服一個服的，好比排行榜只能在一個服裏面排名。

全球同服是世界的全部玩家都在一個服裏。這在技術上是怎麼實現的呢。

我不知道其餘公司怎麼樣，咱們公司自己有一套跨服框架。

遊戲功能上，好比有一些副本可讓1服2服3服的玩家都進入，這種叫跨服副本玩法。

開啓這種玩法須要多啓動cross的兩個進程。cross，crossmanager。全球同服就是邏輯上只有一個服務器。

經過跨服來實現全部服的玩家在一塊兒玩耍。

 

4.戰鬥驗證。

咱們把戰鬥系統想象成黑盒。假設沒有用戶的操做，輸入數據肯定則輸出結果肯定。這樣就是一個卡牌遊戲的模型。

若是把戰鬥系統寫在服務端，由服務端命令隊列驅動客戶端表現。那麼就不須要戰鬥驗證。

可是由於咱們的框架服務端採用c++開發，寫邏輯很是慢，而戰鬥系統註定改動很是大。

所以戰鬥系統改到客戶端用lua寫。服務端負責下發戰鬥數據，客戶端上報戰鬥結果以後，服務端再下發戰鬥結果。

結果徹底是由客戶端計算的。那玩家做弊怎麼辦。因此必須有戰鬥驗證這一步。

最後採用的是服務端c++跑lua模塊的方式。服務端增長了一個戰鬥驗證進程，單獨處理驗證需求。

在服務器下發戰鬥數據的同時，經過進程間通訊將戰鬥數據傳遞給battleserver，battleserver理論上跑lua速度比客戶端快，

也就是客戶端戰鬥結束前服務端會有一個戰鬥驗證結果出來。將這個驗證結果和客戶端上報的結果作比對。從而實現戰鬥驗證。

 

這套戰鬥驗證有幾個問題。

a.客戶端lua若是改到戰鬥模塊須要重啓服務器。通常客戶端lua都是熱更的。

如今由於戰鬥驗證，假設策劃須要微調一個兵種的數值，也須要重啓服務器。

b.測試階段會有大量數據驗證異常，影響體驗。因爲戰鬥模塊頻繁改動，每一次改動都須要大量測試來保證戰鬥驗證。

每一次修改戰鬥異常的bug後，合併到外網都須要重啓服務器。

c.若是用戶量大，戰鬥驗證的請求多的時候，會不會出現阻塞，致使服務端沒有驗證完，客戶端就已經出結果上報了。這種狀況應該怎麼處理。

 

5.戰鬥系統。

玩法上是這樣，首先玩家在主場景的兵營擺放兵的陣型。3*5個位置。進入戰鬥場景以後，隔15秒出一波兵，此時玩家沒法操做。

實際上是模仿皇室戰爭，可是去掉了手動的操做。玩法好很差我不想討論。商業遊戲是爲了賺錢，遊戲火了才能賺錢。

遊戲火不火和玩法好很差沒有正相關的關係。一樣是SLG遊戲，有些遊戲都沒有戰鬥表現，所有是數值，同樣是流水不錯。

遊戲能不能到達高流水，更大取決於市場和運營的能力和美術風格。玩法上固然是能抄則抄，由於遊戲開發須要巨大的成本。

去抄襲一個玩法，比原創一個玩法的成功率高不少。

 

戰鬥系統是我全程從無到有寫的邏輯。架構上講，在客戶端模擬了一套戰鬥命令隊列。

客戶端戰鬥模塊收到服務端下發的戰鬥數據和戰鬥開始的協議，就開始進行戰鬥。

邏輯層會發命令給表現層（場景，對象）進行展示。邏輯層和表現層是分離的，邏輯層驅動表現層。

 

6.地理位置管理（四叉樹）

能夠參見個人另外一篇 http://www.cnblogs.com/yao2yaoblog/p/5475231.html

 

我從這個遊戲只有一個2d模型尋路，到滿屏的對象，特效。

從pve只有一排排整齊的據點，到有云霧，有副本，各式各樣的據點。

從pvp只有一個列表，到能旋轉的星空，再到位置散列的星球。不管最後結果如何，我都感謝有過這段經歷。

遊戲成不成功不是我決定的，我能作的只有把代碼寫好，但願技術更好。可以理解更深的技術。

 

最近看到了餘華的《活着》。生活原本就是個玩笑，怎麼可能都如意順心呢。

成年人的生活沒有容易。但行好事莫問前程。