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

技術選型

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