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只有一個列表，到能旋轉的星空，再到位置散列的星球。無論最后結果如何，我都感謝有過這段經歷。
游戲成不成功不是我決定的，我能做的只有把代碼寫好，希望技術更好。能夠理解更深的技術。
最近看到了余華的《活着》。生活本來就是個玩笑，怎么可能都如意順心呢。
成年人的生活沒有容易。但行好事莫問前程。