我在游戏中使用旧的Unity 2017.3 UNET实现。玩家连接到服务器，并被放置在大厅场景中，直到队长选择另一个关卡为止。该实现只是默认NetworkLobbyManager的略微修改版本。
麻烦开始了，因为我已经开始通过为客户端运行已编译的构建，然后使用编辑器作为服务器来对网络代码进行大量测试。通常，在编辑器中运行的服务器将比编译的客户端版本慢很多。因此，当我使用NetworkManager.ServerChangeScene时，客户端会将场景加载到服务器之前，这将导致禁用客户端场景中的所有NetworkIdentity（因为尚未在服务器上创建它们）。
如果服务器运行的是编译版本，则发生的可能性要小得多，因为服务器几乎总是在任何客户端之前加载场景。但是，Unity本身确实面临更大的问题。不能保证在更改场景时服务器将可用。
在网络游戏中还有其他改变场景的方法吗？有没有办法确保服务器在任何客户端之前进入现场？还是我只是希望在场景变化之间网络保持稳定？
答案 0 :(得分：0)
好吧，我一夜之间考虑了一下，决定转向其他方向，因为更多的调查表明，有时服务器也首先加载场景时，网络标识有时仍然被禁用。
我一直在浏览UNET source code，并意识到服务器应该考虑到它在客户端之后加载场景的情况，尽管该代码对我来说似乎有点麻烦。我发现documentation支持了这一理论，我还说，启动时场景中的NetworkIdentity就像当服务器启动时动态生成一样。
现在知道了这些事情，我开始认为我只是愚蠢的，弄乱了我的东西。被禁用的对象是一个启用和禁用其他NetworkIdentity对象的管理器。我敢肯定，主要的问题是它在客户端上禁用了网络身份，而在服务器上仍启用了该身份，这使整个事情陷入了麻烦。
将来，我将尽量避免基于网络来启用和禁用游戏对象，并坚持将相关功能置于我自己的标记后面，以便我可以“软禁用”对象而无需调试所有传入的RPC或SyncVar数据。