如何評價Unity5中多人遊戲和網路模塊UNet？

01-13

在Unity5中出現的新的網路模塊UnityEngine.Networking
Unity - Manual: Multiplayer and Networking
Announcing UNET

Intro Video:
youtube.com 的頁面

目前來看，對於中國國情有點蛋疼。Unity之前版本有Master Server，用於提供在互聯網平台上的匹配房間創建和查找，並且可以Net穿透數據。但是UNet拋棄了原有的Master Server，使用類似於阿里雲的Unity Cloud按使用量付費的形式作為互聯網的聯機的平台，而且到目前5.3.1版本為止還沒有可以單獨部署伺服器的版本。鑒於中國到Unity的網速，要麼你只能使用Unet做成區域網版本，要麼只能發布國外了。

補充下答案

目前Unet這個功能在Unity應該會分為3個階段開發

1. 完成點對點數據同步，基於UDP的P2P可靠與不可靠網路。

2. 提供伺服器版本庫，可以自行開發獨立於Unity的伺服器版本（非Headless模式）

3. 提供分區架構負載均衡版本的伺服器

目前版本截至5.3位置相當於階段1中

僅僅提供點對點的同步功能，還缺少主機切換，驗證服功能等，基於互聯網匹配同步的版本需要使用Unity Cload完成。

階段2的時候就應該可以自行通過Unet庫開發伺服器管理，機器人AI，等一些脫離Unity的本地版本

階段3的時候就是一個能適應MMO項目的伺服器

目前階段2大概要Unity6公布

至於階段3遙遙無期中

Roadmap可以見：

Unity - 產品藍圖

找Net那部分就是了

用UNet做完兩個Demo的人路過，現已切換回Photon (2016/11/28 @ Unity 5.5)

先說說好的地方：

編輯器原生支持
自動化程度相當高的數據同步/事件回調設計

然後就該說說缺點了：

整個API設計初衷良好，然而實際上卻是個災難。UNet的開發人員為了減少使用者各種顯式調用網路相關方法，保持代碼風格與單機開發風格相近，做了一大堆的編譯器hack：比如變數上加標[SyncVar]就會自動實現數據同步；方法上加標[ClientRPC]那麼在正常調用此方法時就會自動在多個客戶端上同時調用此方法……初上手的時候這些功能確實很先進很美好，但你做著做著就開始感覺不對勁了，比如：

各種不標準的命名潛規則。比如RPC方法名必須以Rpc開始，通過繼承SyncList聲明新的自動同步列表類時，類名必須以SyncList開始。然後如果你違反了這些潛規則，代碼可以正常編譯可以正常運行也沒有報錯，唯獨就是運行結果和你想的不一樣……
有些地方hack不到位。比如你在Player上聲明一個Command方法，如果你在Player類內部直接調用Command方法呢編譯器是可以給你正常處理的；但你要是換個寫法，嘗試從外部類中調用這個方法呢編譯器就傻了，會導致command無法正常執行。同樣，代碼可以正常編譯正常運行且無報錯。
3. 所有的修飾Attribute對介面完全無效。
4. 極偶爾會遇到神秘的編譯器錯誤。比如Unity一次編譯後網路部分代碼其實並不正常，需要重新再編譯才行……

缺少獨立的服務端。獨立Server端我沒記錯的話，一開始在5.3路線圖中，等5.3出來跳票到5.4，等5.4出來直接就進入遠期規划了。當然後來聽聞是一開始搞UNet的那個挖坑人做到一半跑路了，於是整個網路部分就全坑了。現在5.5也出來了，更新列表裡也是沒UNet什麼事，可以一窺此坑之深度……
Unity Cloud基本也是半殘（國內）。配合上一條基本就是只能做做區域網遊戲了。雖然UNet允許你專門做個Unity客戶端當成主機，但是正經商業項目你敢這麼玩么……別人跑幾百人同時在線的伺服器換到UNet上只能帶十几几十號人你能接受么……

反正UNet用下來的感覺就是這玩意是個長得挺漂亮的奇行種太監……拿來做正經商業項目那肯定是要死無全屍的，拿來做做小Demo也就還湊合……然而API設計上的一堆巫毒術導致了其帶來的小便利基本上抵不過憑空增加的Debug時間……你看我羅列的這一二三四啊，都是血淋淋的體驗啊……

於是我就又換回Photon了……

之前做個Unet方便的研究，樓上幾位說的都沒錯。現在Unity在這塊並沒有開發的非常成熟，用來做區域網遊戲可以，拿來開發網路遊戲就不行。

但是方便進行區域網操作已經可以解決很多問題了。

創建房間，加入遊戲的代碼非常簡單，只用腳本繼承NetworkManager就可以了

進入遊戲如果要同步你的數據和收發消息只用加入Command和ClientRpc屬性就能搞定

最關鍵的是伺服器和客戶端是一套代碼非常方便維護

因此結論可以下來了，如果你們的項目正在Demo階段，而正想開發一套網路同步代碼。可以實時Unet來解決，它能很快的測試出你代碼裡面有何同步性問題，而且只用一台電腦一個程序員就能搞定。

而且還能模擬延遲效果，測試時非常的方便。

後期若Unity能搞定獨立服務端的問題，以後的獨立遊戲估計會有更多很多網路遊戲出現吧。

目前使用UNET開發了兩款區域網對戰的小遊戲。

對於初中級程序員（自己寫Socket通訊困難）來說使用起來還是挺方便的。

好處是客戶端和伺服器使用同一套代碼，當然也可以寫一個專用伺服器。

Youtobe上有人做了簡單的教程，下載了下來，分享到了百度雲http://pan.baidu.com/s/1jIMyWTK。

大廳部分參考了AssetStore中官方的Demo Asset Store。

基本上參考這兩個做出來一個簡單的例子不成問題。

還有就是UNET是開源的，對於中高級用戶來說可以哪裡不爽改哪裡Unity-Technologies / Networking

Networking是一種軟體研發在跨平台路上更近一步的體現，真正做到了：anytime，anywhere，one code for all platform！
Networking出現之前，Unity仍然是一個客戶端遊戲開發引擎。Networking出現之後，Unity甚至成為了跨客戶端服務端的遊戲開發引擎。
同樣的組件在Unreal中早有產生，但追溯到最早的話，那可能就是國外各大遊戲公司的私有引擎了。但Unity的威力在於其廣泛的普及程度，所以它是首次將該組件推廣至光羅大眾的商業引擎。
Networking本質上是對傳統C-S架構軟體下的網路層的高度抽象。
伺服器邏輯和客戶端邏輯在一個類裡面編寫（這裡會帶來一些代碼整潔度上的麻煩~~）
伺服器和客戶端要做數據同步，不用發包了，在屬性前面加上[SyncVar]標籤就自動同步了。
客戶端調用伺服器，不用發包了，函數調用即可。
伺服器調用客戶端，不用發包了，函數調用即可。
帶來的好處太多都不用說了。
帶來的壞處，安全性上堪憂，設想一下，如果客戶端和伺服器邏輯都在一起，一旦客戶端被反編譯了，那麼是不是伺服器邏輯都泄漏了。
帶來的壞處2，伺服器程序員可能不需要寫遊戲邏輯了。。

謝邀不過已經被公司抓取做UE4了真心沒接觸過Unity5的network UE4相比Unity4在網路上還是好很多的從Actor層（相當於Unity中的GameObject)就設置了網路同步的功能

2016年4月更新：UNet適合搞demo，但目前不建議使用UNet作為正式關鍵遊戲伺服器。原罪並不歸於UNet，而是歸於Unity Engine/Unity Headless Mode，有比較大的不可控消耗，並不能做到足夠的Modulation。

和Unity Engine的人面對面就UNet詢問過，其原話回答包括：

- 「modulation is way too difficult」（就是說，server版本的Unity，目前肯定消耗很大）

- 「Should not run unity on the server」。

另，就Unity的Roadmap看來，UNet的更新變得相對變少，個人有種「項目瓶頸」甚至是「項目停更」的感覺。最關鍵規避Unity在伺服器消耗問題的UNet更新「Networking: Server Library」，其本該隨Unity5.4發布的，但現在被嚴重delay到Roadmap中的Alpha Version中。

--------------------

以下為原回答

--------------------

現在的評價應該都還不是經過大量用戶大型產品驗證過的評價。至少半年後才能給得出真實客觀的評價。

1、對比傳統server高權威要求的c/s方式（server照跑AI物理尋路等幾乎一切邏輯），uNet帶來好處是開發效率提高（unity豐富的引擎工具功能和統一cs代碼），壞處是帶來mono額外消耗、引擎額外消耗、代碼風險全集中在「unity開發同學」身上。

2、對比傳統server低權威要求的c/s方式（client上報物理尋路位置命中、server僅處理數值血量狀態技能可否使用等關鍵邏輯、事後校驗），uNet可以讓你較方便改成高權威server提高安全性，帶來壞處是server負載變高許多、增大帶寬消耗、代碼風險全集中在「unity開發同學」身上。

3、對比傳統幀同步（lockstep）或bucket同步方式，uNet可以讓你改為高權威server提高安全性，減少蝴蝶效應帶來的不同步，不需重寫determinstic的數學庫物理庫、不需實現落後者加速重播機制。但放棄了幀同步的簡單性，和帶來上面1、2點提到過的壞處。（由於手游盛行，手機作弊難度*目前*較大，現會有手游項目採用類幀同步方式）

整體來看，uNet是未來的方向。坑要躺，一起躺。

還未了解過Unet，關於是否使用unity提供的network模塊，要看公司關於伺服器技術的選型。

網路模塊目測用處不是特別的大，一般通信都是單獨寫的，需要看公司後台用什麼技術和協議。

謝邀。目前手頭項目fps類手游正在試用。相比舊版，感覺非常好，值得一試。

雙端同工程。在這一點上，通訊同步確實做得非常方便，甚至不需要關心底層數據交互。

目前初步擔心是io量略大，待進一步了解再做實評。

看了一些簡單的tutorial之後在一次GameJam中做了個區域網聯機的遊戲，雖然最後基本的同步都實現了，但還是被裡面的各種隱晦的規則繞的雲里霧裡。

建議在還沒有特別成功的案例之前不要用到自己的項目中。

這兩周一直在折騰Unity的多玩家方案。

目前其實做這一塊的基本就兩家把，UNET和Photon。

一開始我使用UNET實現，區域網效果不錯，使用免費的伺服器模式就不行了，卡到不行。所以我就想著直接購買服務把，仔細一看，這服務還要先申請才行，而且個人版的Unity不能申請。

鬱悶的我於是找到了Photon，比起Unity不能自己搭建伺服器，Photon一鍵運行exe跑伺服器很是方便，又編寫了簡單的代碼，發現條理比UNET清晰多了。

建議用Photon吧。

Photon入門請看Photon Taiwan 的 TrueSync, 多人完全同步物理引擎入門。

我們項目也在用UNet，選擇它的原因是Reliable UDP跟官方提供，Hight Level Script Api 一點都沒用到，只用了最底層的同步介面，目前還沒遇到什麼問題

我們項目也是用unity做戰鬥伺服器，不過用的不是UNET，而是自己寫的Socket，並發問題不大，這些都用機器人測試過。我現在唯一擔心的是mono的帶來的GC消耗和unity底層的穩定性。期待IL2CPP技術帶來的性能提升。