13年畢業後，做了一年半web開發，因為受不了在客戶現場工作的氛圍，憤然辭職。轉行做了一名手遊服務端開發。

在廣州，據我所知，選擇java作為服務端開發語言的大廠大概有37玩，百田，銀漢，易娛等等。其實遊戲服務端開發語言可說是百花齊放，c++、java、python、elang，不一而足。

記得剛入坑的時候，我連策劃資料和玩家資料都傻傻分不清，服務程序還天真地認為是tomcat啟動的。被策劃與測試聯手虐待了近3年後，我終於成為一名有經驗的“業務狗” （=。 =）

下面說一下手遊開發中碰到的一些名詞。這些概念都是自己理解的。剛入坑的朋友可以草率看一看，瞧一瞧。資深遊戲開發請留下聯絡方法，方便請教問題。(^-^)

架構是簡單的伺服器架構，也就是說，大部分業務處理都是在同一個程序。沒有分散式服務的概念。

996

提起遊戲公司，比較受眾人認可的便是它高強度的工作時間。從剛開始的996制度（每天上午9點上班，晚上9點下班，中間休息2個小時，每週6個工作日），到後來的9106，甚至9116，簡直是殘暴剝削從業者的剩餘價值啊。不過，不加班的遊戲公司估計也沒多少人敢去上班，工資能不能按時發都是未知數了。也許有些人會說，遊戲行業工資高，獎金多。說點心裡說，雖然遊戲行業普遍工資是比較高，但綜合工作時間考慮，價效比奇低。近幾年來，手遊行業發展迅速，每年都有非常多的手遊工作室成立，當然，也有很多手遊公司倒閉。總體來說，手遊這塊大蛋糕已被市場瓜分所剩無幾，特別是騰訊和網易兩個大廠就拿了七成左右。利潤減少，人力成本增大，導致很多手遊專案的獎金已悄悄地被砍掉了，大部分專案成員最多就是年底拿個雙薪。(=。=)

策劃資料與玩家資料

簡單說來，策劃資料就是遊戲的規則，是由策劃配置的。玩家資料就是玩家在遊戲過程中產生的用於持久化狀態的資料，需要儲存在資料庫裡。關於策劃資料，有一點需要說明的是，策劃資料是不能被程式碼修改的。一般說來，當服務程序一啟動的時候，所有策劃相關資料都會被load進記憶體。一些新手在開始做業務功能的時候，經常發生程式碼不小心修改到策劃資料，導致遊戲規則被無意修改了。這種情況對遊戲的影響非常嚴重，一旦出現，必定會被老大狂屌。當然，策劃職位也有可能填錯資料。曾經有專案因為策劃不小心把投放XX個銀幣填成XX個鑽石，短時間就發生了嚴重後果，據說後來資料是採用“回檔”殘暴解決。

pve與pvp

簡單來說，pve(player vs environment)，就是玩家與電腦ai對戰，包括各種關卡、副本等；pvp(player vs player)，就是玩家與玩家之間真槍實火地對戰。一個遊戲，如果只有純pve，是不能長期吸引玩家的，畢竟打電腦打多了就會沒意思。pvp一般都是一個遊戲的核心玩法，也是最不好設計的，要綜合平衡網路延遲及戰鬥表現。時下很流行的一款休閒遊戲“貪吃蛇大作戰”倒是挺有意思的，明明是一款單機遊戲，居然能作出類似聯網對戰的效果。一開始，我還在驚訝於它的及時同步如此之屌，玩家的一個扭頭能夠及時同步

Socket服

遊戲主程序，遊戲的所有業務邏輯都在這裡執行。維持著所有線上使用者的socket連結。一般是採用多執行緒來處理使用者的請求。

閘道器

閘道器就是用於服務端與客戶端進行通訊。跟socket服在同一個程序。使用者請求從客戶端發出之後，來到服務端，服務端經過業務邏輯處理，把資料返回給客戶端。閘道器做的事情就是處理髮包，解包，以及各種粘包情況。閘道器程式碼一般都非常複雜，一旦穩定就不會輕易修改。業務程式碼一般不需要跟閘道器打交道。

登入服

現在大部分遊戲都是分成很多個小區，以便在單程序的環境裡容納更多的玩家同時線上。客戶端手機通過渠道sdk驗證後，就需要在登入服中根據平臺與角色id找到玩家所在的服務分割槽。登入服一般是web專案，客戶端通過http請求，查詢玩家所在服務區的ip地址以及埠資訊。有了socket地址後，客戶端就可以直連socket服，完成登入邏輯。

gm工具

gm工具對於一款上線產品來說，具有不可或缺的重要性。既可以實現諸如開服關服之類的運維命令，又可實現提供給客服人員的查詢玩家資訊的介面，也可以輔助管理遊戲程序，實現動態修改遊戲邏輯的黑科技(熱更新)。總體來說，GM工具類似於遊戲的金手指，可以提供各種“作弊操作”和遊戲管理操作。

熱更新

對於一個上線產品專案來說，熱更新為維持專案的穩定健康提供了堅強的保障。小到策劃資料的修改，程式碼bug的修改，大到動態擴充套件遊戲業務功能。試想一下，沒有熱更新機制，如果需要修改程式的一個小bug，都不得不踢人停服維護。這樣的事情來多一發，恐怕老玩家都被攆走了。比較有意思的是，我先前的一個專案，每次更新當日，一定少不了程式碼熱更或者資料熱更，兩年裡的每一個星期都是如此，從無例外。可見熱更新的重要性了。關於熱更新的機制及方法，我的部落格裡有兩篇文章可以參考。

防掛

做遊戲後臺與做web後臺，關於防掛的防禦思想是一致的。不管客戶端發什麼請求上來，即使是客戶端已通過自己的驗證，服務端都需要對請求引數進行有效性驗證。總不能說，客戶端說可以兌換100個物品，服務端什麼驗證都不用，就給角色加了100個物品。一定要有這樣的思想，客戶端完全可以通過修改包資料（加密只能提高破解難度不能杜絕）來自定義請求引數，服務端直接處理來自客戶端請求的介面方法一定要有完善的引數驗證機制。寫的方法能否防得住掛，是區分一個初級業務狗和資深業務狗的重要標誌。

使用者資料持久化

玩家的資料需要儲存到資料庫，如果一下線資料就被重置，那麼玩家每天練級還有什麼意義。比較主流的資料持久方式有兩種，一種是針對每一個功能模組都建一張表，只要有一個userId作為外健能關聯到User主表即可；另外一種是不區別邏輯分表，對User類的所有依賴實體（包括實體及其遞迴依賴），全部對映成字串或者二進位制。兩種做法都有優缺點。邏輯分表的優點是模組分層定位清晰、可讀性強、容易通過sql修正玩家資料等；缺點是新建模組必須手動建表，實體欄位必須增加表屬性才能完成持久化。實體對映的優點是，只需一張表即可完成全部資料的持久化、新建屬性實體或欄位不需要額外修改表結構；缺點是可讀性差，如果存為二進位制的話更無可讀性可言，而且修復玩家資料只能通過修改程式記憶體而不能直接執行sql語句。

另外一方面，由於資料庫連線的資源非常可貴，不可能玩家每一個請求都需要load使用者表。一般都是玩家登入的時候就將玩家相關的使用者表全部load進記憶體。服務端有一個定時器檢測，當玩家在一段時間內沒有發請求上來，認為該玩家已經下線，相應的資料再回寫到資料庫。這樣實現的話，對資料庫的壓力就變小了很多，而且在很短的時候內頻繁上線下線也不會觸發多次讀取資料庫。

遊戲更新與維護

手遊的更新節奏是比較頻繁的，每週一更，每兩週一更，最長的週期應該是每個月一更了。很多遊戲喜歡把更新時間設在深夜或者凌晨，目的是想避開高峰時期，爭取更長的開放時間，這可苦了我們這些做遊戲的人了。無數次晚上加班到兩三點或者早上6點就得趕往公司，往事不堪回首。遊戲的伺服器一般都是部署在Linux系統，所以常見的Linux命令都會熟悉。

最後，寫給即將走進遊戲服務端大坑的朋友們的心裡話。遊戲開發這個職位雖然外表華麗，箇中的辛苦與苦逼只有局中人才能理解。如果兩年後發現自己還在辛勤寫著活動業務邏輯，從未碰過大型功能玩法（例如跨服賽事，戰鬥同步等），那你應該好好思考一下，自己是否適合繼續從事遊戲開發，或者這家公司值不值得你繼續留下來。如果有志往資深遊戲開發的路走下去，建議研究一下分散式遊戲開發。畢竟，這年頭，分散式還是很前沿，逼格很高的玩意。