技術選型

Unity引擎內置了多人聯機的解決方案，涵蓋了從最底層的網絡數據傳輸，到不同玩家之間的消息發送，再到遊戲大廳這樣的高級功能。考慮到Unity官方提供的雲服務（Internet Services）在國內的延遲較高，而且需要付費，我們決定采用Steam與Unity相結合的方式。底層用Steam發送網絡數據包，中間由Unity負責把各個包整合成遊戲邏輯所需要的格式，高層的大廳也使用Steam提供的服務。

說到這裏要贊美一下Unity Networking的模塊設計，它把具體的網絡數據傳輸細節和抽象的消息發送功能分離開來。使得開發者既可以使用傳統的“IP地址+端口”的方式實現玩家之間的連接，也可以相對方便地接入Steam或WeGame，利用這些平臺SDK包含的更高級的功能去收發網絡數據。而且Unity的網絡模塊是開源的，不僅方便查閱，還可以根據自身需求進行修改，然後替換掉引擎自帶的模塊。

服務器

聯網遊戲需要一個服務器，用於協調多個玩家之間的遊戲進程。否則大家的電腦有快有慢，很容易出現遊戲節奏不一致的情況。比如，玩家A的電腦配置高，運行流暢；玩家B的電腦有點卡，會掉幀。那麽，當遊戲需要3個小飛碟從上方飛入屏幕攻擊玩家的時候，可能玩家A那邊的飛碟已經全部就位，開始發射子彈了；但玩家B那邊剛剛創建出第二個飛碟。這樣就導致不同玩家屏幕上顯示的內容完全不同，很難進行正常的遊戲。引入服務器就是要避免出現各種各樣的不一致行為，讓速度快的機器等等速度慢的，大家盡可能保持相同的步調去執行遊戲邏輯。

這個服務器可以是獨立的後臺，就像一個網站那樣托管在某個雲計算廠商那裏；也可以讓某個玩家來充當服務器，在運行自己遊戲邏輯的同時也負責調度其他玩家的遊戲。不過，開發並維護一個獨立服務器的成本相對而言還是挺高的，所以我們選擇了第二種方案，就讓創建房間的玩家來兼職做服務器。Unity恰好有一個Host模式，支持一個玩家同時扮演服務器和客戶端。

• 創建房間：玩家A向Steam發起申請，並設置最大人數為2。如果成功，A就成為房間的所有者，進入角色選擇界面。同時，A還需要啟動服務器（NetworkServer），等待其他玩家的進入。
• 查詢房間：玩家B設置篩選條件去查詢當前列表，Steam會返回還有空余位置的房間。如果A創建的房間符合條件，該房間就會包含在返回結果之中。
• 進入房間：B申請進入A創建的房間。如果成功，A和B之間就可以通過Steam互相發送消息。但這時房間內的玩家只能進行基本的通信，還不能利用Unity提供的狀態同步等機制。
• 建立C/S關系：B向A發送連接請求（NetworkClient），A收到後建立連接。這樣，後續的遊戲同步邏輯就可以按照Unity的方式進行。
• 開始遊戲：B進入房間，選擇自己的角色。完畢後，A通知雙方加載遊戲場景。

以下是場景中需要註意的事項：

• 時間：許多場景的移動、關鍵動作的觸發都跟時間相關，所以當前遊戲進行的時間是場景保持同步的關鍵。
• 雜兵行為：我們遊戲中有一百多個雜兵，基於這些雜兵有八百多個不同的行為。這些行為都是用PlayMaker編輯的狀態機。要讓如此眾多的狀態機去支持聯網，手動去挨個修改是不可能的，只能利用腳本批量修改。
• 狀態機：我們設計關卡時，會根據遊戲進行的時間或者地圖移動的位置去指定某個雜兵的行為。這些行為一般遵循先創建雜兵單位，再移動射擊，最後被擊落或離開屏幕的規律。這裏邊包含兩部分，一是用於交互和同步的雜兵，二是控制雜兵行為的狀態機。在單機情況下，狀態機創建出單位緊接著執行後續操作；在聯網模式下為了狀態同步，場景中物體的創建和銷毀需要在服務器端進行。所以，原有的狀態機在服務器和客戶端上的執行不再一致。服務器創建的雜兵單位，會通過Unity的機制自動在客戶端上克隆出來，這樣客戶端不再需要自己創建，而是等待單位被服務器創建出來後作為參數傳入狀態機裏去執行後續動作。
• Boss行為：一般的雜兵行為比較簡單，在屏幕中存在的時間也較短，在服務器和客戶端上各自運行也不會產生太大差別。但Boss的行為比較復雜，運行一段時間後就會出現明顯偏差。我們在狀態機內部的關鍵節點上加入等待機制，讓各玩家在運行到節點處同步進入下一狀態。

• 有Unity3D項目外包歡迎聯系我們
• QQ 372900288
• TEL 13911652504
• WX Liuxiang0884

Unity外包團隊：關於手機unity遊戲開發的技術選型