如何评价Unity5中多人游戏和网络模块UNet？
如何评价Unity5中多人游戏和网络模块UNet？ 之前做个Unet方便的研究，楼上几位说的都没错。现在Unity在这块并没有开发的非常成熟，用来做局域网游戏可以，拿来开发网络游戏就不行。但是方便进行局域网操作已经可以解决很多问题了。
创建房间，加入游戏的代码非常简单，只用脚本继承NetworkManager就可以了
进入游戏如果要同步你的数据和收发消息只用加入Command和ClientRpc属性就能搞定
最关键的是服务器和客户端是一套代码非常方便维护
因此结论可以下来了，如果你们的项目正在Demo阶段，而正想开发一套网络同步代码。可以实时Unet来解决，它能很快的测试出你代码里面有何同步性问题，而且只用一台电脑一个程序员就能搞定。
而且还能模拟延迟效果，测试时非常的方便。
后期若Unity能搞定独立服务端的问题，以后的独立游戏估计会有更多很多网络游戏出现吧。 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是未来的方向。坑要躺，一起躺。 看了一些简单的tutorial之后在一次GameJam中做了个局域网联机的游戏，虽然最后基本的同步都实现了，但还是被里面的各种隐晦的规则绕的云里雾里。
建议在还没有特别成功的案例之前不要用到自己的项目中。 目前使用UNET开发了两款局域网对战的小游戏。
对于初中级程序员（自己写Socket通讯困难）来说使用起来还是挺方便的。
好处是客户端和服务器使用同一套代码，当然也可以写一个专用服务器。
Youtobe上有人做了简单的教程，下载了下来，分享到了百度云http://pan.baidu.com/s/1jIMyWTK。
大厅部分参考了AssetStore中官方的Demo Asset Store。
基本上参考这两个做出来一个简单的例子不成问题。
还有就是UNET是开源的，对于中高级用户来说可以哪里不爽改哪里Unity-Technologies / Networking 用UNet做完两个Demo的人路过，现已切换回Photon (2016/11/28 @ Unity 5.5)
先说说好的地方：
编辑器原生支持
自动化程度相当高的数据同步/事件回调设计
然后就该说说缺点了：
整个API设计初衷良好，然而实际上却是个灾难。UNet的开发人员为了减少使用者各种显式调用网络相关方法，保持代码风格与单机开发风格相近，做了一大堆的编译器hack：比如变量上加标就会自动实现数据同步；方法上加标那么在正常调用此方法时就会自动在多个客户端上同时调用此方法……初上手的时候这些功能确实很先进很美好，但你做着做着就开始感觉不对劲了，比如：
各种不标准的命名潜规则。比如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了…… 目前来看，对于中国国情有点蛋疼。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那部分就是了 Networking是一种软件研发在跨平台路上更近一步的体现，真正做到了：anytime，anywhere，one code for all platform！Networking出现之前，Unity仍然是一个客户端游戏开发引擎。Networking出现之后，Unity甚至成为了跨客户端服务端的游戏开发引擎。同样的组件在Unreal中早有产生，但追溯到最早的话，那可能就是国外各大游戏公司的私有引擎了。但Unity的威力在于其广泛的普及程度，所以它是首次将该组件推广至光罗大众的商业引擎。Networking本质上是对传统C-S架构软件下的网络层的高度抽象。服务器逻辑和客户端逻辑在一个类里面编写（这里会带来一些代码整洁度上的麻烦~~）服务器和客户端要做数据同步，不用发包了，在属性前面加上标签就自动同步了。客户端调用服务器，不用发包了，函数调用即可。服务器调用客户端，不用发包了，函数调用即可。带来的好处太多都不用说了。带来的坏处，安全性上堪忧，设想一下，如果客户端和服务器逻辑都在一起，一旦客户端被反编译了，那么是不是服务器逻辑都泄漏了。带来的坏处2，服务器程序员可能不需要写游戏逻辑了。。
谢邀 不过已经被公司抓取做UE4了 真心没接触过Unity5的network UE4相比Unity4在网络上还是好很多的 从Actor层（相当于Unity中的GameObject)就设置了网络同步的功能 还未了解过Unet，关于是否使用unity提供的network模块，要看公司关于服务器技术的选型。
页:
[1]
2