一個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隻有一個清單，到能旋轉的星空，再到位置散列的星球。無論最後結果如何，我都感謝有過這段經曆。

遊戲成不成功不是我決定的，我能做的隻有把代碼寫好，希望技術更好。能夠了解更深的技術。

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

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

轉載于:https://www.cnblogs.com/yao2yaoblog/p/6723621.html