I just care about one thing with any new networking solution. Can I set the number of clients and hit play to spawn them in a little grid of windows? Doing builds just to playtest goes against everything that Unity is good for.
You still have to build your clients before testing.. but at least you can only compile the scripts now (BuildScriptsOnly) - then you can write a custom script to build and spawn your clients in a grid (you can give the position using the command line, and apply it on your client using Win32.SetPosition)
Sure, but that's a hack at best. I would have thought it'd be feature no1 on a rewrite of the networking system. Unity is all about quick iteration after all. At the very least they could internally do this quick build/spawn x clients and grid them thing (or give us a script hook so we can customise it) Plus having native debugging/inspector views/breakpoints etc on a selected client is vital to productivity. I dare not mention the U name, but they do it.
Take a look at ParrelSync (https://github.com/VeriorPies/ParrelSync). You can have multiple synced editor windows that can function as clients. I guess that might be what you're after.
I agree. But since they don't provide it, we have to workaround this limitation. And you still can have one client running on the editor, but I understand it doesn't make easy the hard task of developing a multiplayer game. @Johannski answer could help you, even if having multiple editor running may not be the answer you were looking for
Neat. I actually do that already, but with a normal folder sync project and multiple editors. This looks a bit more convenient.
I currently do the 'multiple projects with auto-syncing folders' thing, which is certainly better than doing builds, but my wish is that Unity realise they need to make it native. I actually talked to them years ago and they said they can't easily spawn multiple instances of the player from the editor. If that's the case, they really need to address it quickly, as an engine without native networking is going to fall behind very quickly. Everything from Roblox to Unreal make networking coding and testing quick and easy.
In my experience, to debug multiplayer games, you need: - excellent and smart logging coverage + tool to parse and analyze them - live debug data (using ImGui for ex) - not everything can be seen in the editor view - visual studio attached to all your instances You don't really need the editor IMO, but I totally understand the need to visualize whats inside your components during the prototype phase. The reason is you quickly can't test your multiplayer game alone.