網路線上遊戲開發心得(伺服器端)(一)

Bromon原創 請尊重著作權

　　一個多人線上的棋牌類網路遊戲的項目臨近尾聲，我參與了該項目的整個設計流程，並且完成了90%的核心代碼。關於這個項目，有很多地方值得聊一聊。本系列不打算把這個項目將得多麼詳細規範，那是設計文檔應該描述的，我打算只說說一些值得注意的地方。

 

　　這個項目的一個特別之處是，用戶端是手機，使用者通過移動網路與伺服器通訊。和PC相比，手機的處理能力極弱，而且網路流量費用昂貴。因為除了要考慮普通網路遊戲的一些問題之外，這兩點也需要在設計中充分考慮。

 

　　首先是開發語言的選擇，由於伺服器是Linux的環境，MS的技術直接排除，至於MONO嘛，我實在不放心。可供選擇的是C++和Java，Java勝在網路能力強大，開發週期短，有眾多架構和開源庫的支援，要寫出爛得不可接受的代碼也不容易；C++則勝在速度快。綜合各方面因素，C++更容易把這個項目變成一堆代碼噩夢，我們選擇了Java。

 

一、網路

　　網路遊戲，首先面臨的問題當然是如何進行網路通訊。首先考慮的是HTTP協議，因為所有的J2ME手機都支援這個，我們當然想儘可能的相容使用者。而且HTTP協議封裝程度已經非常高了，不用去考慮線程、同步、狀態管理、串連池，不過HTTP協議有兩個不爽的地方：

　　◇    協議無狀態，這個問題已經困擾過很多人很多次了。我曾考慮過的解決辦法是改造HTTP協議，在資料轉送完成之後不關閉socket，但是這樣做工作量非常大，在項目周期中，基本上就是Mission impossible，不予考慮。那麼客戶也就只能通過輪詢的方式向伺服器請求資料。

　　◇    網路流量過大。就這個項目來說，網路間傳遞的只是指令，但是每次傳遞都要加上一堆毫無用處的HTTP Head，再加上用戶端需要做輪詢，這個流量對於手機來說簡直恐怖，經簡單測試，按照0.03元/K的GPRS網路費用計算，一局牌居然要消耗1元多的費用（每秒輪詢），實在不可接受。也許我們可以採用流量費包月的資費方式，不過這個話題與技術無關。

 

　　以上問題導致我們選擇了Socket，這意味著我們將沒有一個web環境，很多東西都要靠自己去實現：線程管理、客戶狀態監控、對象池、控制台……….

 

　　網路部分打算採用Java NIO來實現，這是一種新的網路監聽方式，基於事件的非同步通訊，可以提高效能。每個用戶端串連之後，會有一個獨立的SocketChannel與它通訊，這個SocketChannel會在使用者的整個生存周期中存在。使用者如果中斷連線，伺服器會得到-1，並且會拋出Connection reset異常，通過捕獲這兩個特徵，可以在使用者意外中斷連線後清理相關的資源。由於NIO是非同步通訊的，所以沒有複雜的線程管理。

下一篇：關於通訊協定