How to test Unity's new networking layer in separate game instances?

So I went through the documentation in Unity's open sourced multiplayer project on github. However, as I try to use the new networking package in another project, I'm not sure how to go about running separate instances of the server and clients in Unity. I can't open the same project in multiple instances of Unity, nor can I build and run multiple instances of the same game simultaneously. I'm wondering for those who have played around with the networking layer, what did you guys do to test this?

 

It's funny you should mention this, I just finished coding what appears to be the first-of-its-kind in-editor two-players no-compiling instant-start networked multiplayer kit this afternoon!

 

That's awesome! Are you planning to open-source this or put it on the asset store?

 

Open source. Here's a little teaser though:

https://www.dropbox.com/s/tyl68o0ixirri8v/Teaser.mov?dl=0

 

You sir are a legend. I can't wait for this, please keep me posted! Currently using multiple instances of the Unity editor and symbolic links to test multiple instances

 

doctorpangloss's solution aside, the typical approach is you create a build of the game, then manually run multiple instances of the build from the build folder - not choosing "build and run" in the editor. You can have the editor join or host the game as a single instance. Make sure you have the game set to run in background.

 

Just some progress on this topic. What you see in the teaser, engineering wise:

- An unlimited mix of editor and real clients is the goal, but naturally I'm testing with two editor clients right now.
- You'll have to organize your game a little different. Everything that corresponds to a single logical player, like the UI and player-specific effects, should be defined in a prefab. With prefab nesting in 2018, this isn't a big deal. In order to use the Singleton pattern in your code, you'll use a "PlayerLocal<T>" which is similar to a ThreadLocal<T> from Java except it will create an instance for each player. A bit more advanced than DOTS.
- This framework uses the idea of an "isomorphic" codebase. Your client and server code will have access to the same game logic, however you choose to write it. Very similar to DOTS.
- Your game data is represented by a networked-synchronized reactive array of a single type. This is sufficient for everything you could want to do, simple enough to not require generic subclassing, supports JsonUtility/[Serializable], and is forwards-compatible with DOTS. Unlike DOTS, you'll get something called conflict-free replicated data, so you'll be able to do client-side simulation versus authoritative server results seamlessly. If that's over your head, my point is you get a multimillion-dollar game feature for free.
- The network model is peer to peer or client-authoritative server. It's not realistic, however, to be the host of a game on an IL2CPP platform.
- The backend is based on AspNetCore, so you get a lot of the basics of what PlayFab / GameSparks offers, but you get all the source code, you don't pay per CCU, deployable to your own servers, and everything runs and is testable in editor/player as easily as hitting play with no web UI configuration bullshit. Probably long-term superior to DOTS.
- You should write your game logic to have no references to UnityEngine. No Vector3, no Color, no [SerializeField], nothing. Otherwise Unity will threaten sue you like they did Improbable, they want you to use whatever Multiplayer framework they author and this is how they'll enforce it. This is easy for non-physics games, basically impossible for physics games. But you're going to fail to make a physics based multiplayer game anyway