Search Unity

After a quiet period of fixing bugs, improving docs and stabilizing the foundation layer of the multiplayer feature, we’ve started looking to the future and planning the next improvements to make. In this post we’ll take you through the improvements we’ve made, as well as what can be expected in the immediate future.

Fewer bugs, improved docs, and new learning material

Much of our time in the last few months has been focused on bug fixing.  The bug fixes will find their way to the next Unity releases.  We’ve also done a complete review of the Multiplayer-related sections of the official manual.  We’ve fixed and improved whole sections.  We’re now working with the documentation team so our words and style are consistent with the rest of the manual, so it’s easy for readers to consume.  We’ve also partnered with content teams to upgrade a multiplayer tutorial into a complete game, to fully demonstrate how to implement Multiplayer.  

The Tanks!!! Reference Project on the Asset Store, where you can download the entire project and find links to the game on various app stores.

New transport implementation

We’ve refactored and improved the transport layer to address problems which have been popping up for the previous implementation. This will not change the API much (NetworkTransport class and friends) as the changes are  mostly internal. The library is now more robust when running on less-than-reliable network conditions.  

For example, problems with running out of queue space for reliable packets will be a thing of the past. This is the same implementation that is essentially part of the multiplayer server DLL project,  so it contains server optimizations as well. The server DLL is getting closer to release, but at this time, the details have not yet been determined.

You will find the new transport in Unity 5.6, which is in late beta right now, and also in an experimental 5.4 build, which we released on the forums before merging to 5.6 to test its readiness. We’ve kept this build up to date with the latest changes, so if you are stuck on 5.4 you can give this build a try. See the Unity beta site for the 5.6 build and this forum thread for the 5.4 one.

What’s coming next?

In the past, we’ve talked about how we’d be working in three phases:

Phase 1: Setting up the foundation with all the tools needed to put multiplayer games into place. This focused on a kind of client/server architecture similar to the old network implementation (NetworkView etc classes), where one client runs as the host, although that is not a requirement and you can run a headless Unity player as a server.

Phase 2: More advanced server support with an optimized dedicated server, which we called the simulation server. The server DLL can be considered a step in this direction, as you can run a very bare-bones game server with just the network library and protocol along with your own game logic (outside Unity).

Phase 3: Moving in the direction of easily managing many simulation servers together in a huge simulation, entering into MMO territory.

Current and upcoming features

Right now, we’ll be focusing on the areas most requested by our users, namely improvements to the foundation layer. We’ll only move on to the later phases when the foundation is rock solid. The features we’ve started working on and will be coming later this year (after 5.6) are:

  • NAT punchthrough support. This will likely include an extra server type in our service, to facilitate NAT punchthrough connection setup and will add the feature to the transport layer and upwards (to high level API and network manager).
  • Improvements to the multiplayer dashboard. It is now easier to go live with auto-acceptance to limited CCU requests (this is live now) and it will be easier to get an overview of usage and statistics.
  • Improvements to matchmaking/relay service. This includes the much needed relay support for host migrations, notification messages about bandwidth thresholds and improved match filtering in the API.
  • Built-in Steamworks P2P API support. It’s currently possible to route message sending/receiving to another transport, but only in the high level API. We plan on adding specific support for Steam including  swapping the transport implementation in the transport API.

We will also work on improving the high level API specifically and on adding more debug tools at the transport level. Things which will make developing multiplayer games easier. By then we will most likely be at a place where we can say the foundation layer is in shape to support moving on to the later phases.

Removing the old RakNet based networking feature

With NAT punchthrough support, we’ll be ready to remove the old networking feature, which has been deprecated since we released the new implementation. There will be little reason to keep using that as it provides nothing you can’t get with the new feature. It’s not yet certain when an official release of the NAT punchthrough support will occur , but it’s expected by the next one or two major releases after 5.6 ships.


43 replies on “Update on Unity Multiplayer, Current and Future”

Still have same issue , which is when the server quit from the game , the game stop and asks the others clients to leave the room , this is a critical issue it increase the possibility of breaking the game , don’t know if you have something to fix this issue by switching the server to other client

A full blown host migration example of a simple procedural 3rd person multiplayer shooter showing off this functionality would really be nice and good advertisement for Unity Networking..

Is there by any chance going to be solutions for spawning multiple different player prefabs?
The current system supports only a single player prefab, though i’ve worked around it with the spawnable prefab list, it would be great if a less hacky and easier solution to implement would be availiable.

Are there any inroads towards the Unet standalone simulation server? This is all great, and I’m really loving the stability we are seeing so far. So thanks for that :)

When I looked at the low level API last time it was not clear about NAT punchthrough vs proxy servers.

I really think that the low level API needs more focus and clearer differentiation from the high level API. The low level API is what most complicated games will use.

Adding support for WebGL (WebSockets) and UDP clients being able to play together is really easy in the HLAPI using an additional NetworkServerSimple listening for one protocol and NetworkServer listen for another and then add connections of the NetworkServerSimple to the NetworkServer as ExternalConnections but having built-in support is a step in the right direction.

I myself have implemented this back then with the help of Sean (seanr when he was still at Unity) and I have a forum thread for it but please add support for it as a built-in feature.

UNet has not been without issues but the nice design of the HLAPI and LLAPI both made it interesting to use. I’ve shipped multiple games with it and am already working on one game using it.

Also please do test HLAPI features more, For example in 5.5 NetworkClient.Disconnect was causing MsgType.Disconnect not being received in the client while NetworkClient.connection.Disconnect was working fine.
I’ll test with 5.6 and file a report if I could reproduce

Thanks for the great job

Regarding HLAPI:

Just be sure to reduce multiple ways of doing things where it’s rather pointless doing so. This will send a clear and direct message that HLAPI is meant to be used one way. This is good. LLAPI is for people doing things many ways or asset store.

Sometimes the balance of ease of use becomes more like “wtf where do I start”, especially when there’s a lot of random interconnecting pieces.

I strongly agree with this, and also the LLAPI and HLAPI really should be in different namespaces to make sure people know what they should be using when not using the HLAPI

The ability to launch multiple windows for quick testing would help hugely. Making a build isn’t a very Unity way of doing it.

I know what you mean, but I think sadly that doing a full “it’s like Play mode, but running twice at the same time!” kind of thing would be a pretty massive undertaking, and probably not something we can do soon. (Specifically, keeping the data for each separate instance correctly isolated would most likely mean running your scenes in a separate process to the rest of the Editor, and then solving all the inter-process communication issues that relate to that – it is technically possible but definitely not easy or quick to do).

However, we are working on some pretty significant improvements to the build process, so hopefully even testing with builds will get a lot faster for you in the coming months.

Yeah, I imagine Unity was never built to do that. But, it’s probably worth bringing up to the core engine team as it does highlight a pretty big design issue (it probably should be fairly simple). I’ve heard that the play button actually does launch what is effectively a separate process, hence the delay.

What I did was make a clumsy .bat file that launched and positioned builds in a grid. This actually helped a lot, so at least this type of thing built in would speed things up considerably.
The other thing I tried was actually having 2 Unitys with different project names, synced with version control. This actually works pretty nicely and gives you editor access to both ‘instances’ (“Much Different” actually used to have an excellent program that manually synced 2 Unity projects seamlessly for testing their multiplayer lib. This was great, but I think was abandoned)

If you could get it working, it’d be pretty sweet to be able to click on different game windows and get the inspector/scene windows to link and show that instance.

btw Another engine *cough* does this quite well ;)

Actually now that I mention it, it wouldn’t be the worst idea in the world to actually just launch entire editor instances for x players testing. Since really, you actually want the editor to debug and fly about for each player. I know by default Unity doesn’t allow that, but I’m sure it could be rejigged for this.

When you launch Play mode, Unity recreates the Mono application domain – the scripting environment – and that’s a little like making a whole new process. Unfortunately, the scripting environment is only the tip of the iceberg: the other half of the story is the actual native engine objects and the majority of them are completely unaffected by what happens to Mono app domain. That’s the space where the work needs to be done.

Believe me, it’s an idea we have kicked around for quite a while, and there’s a lot of advantages to it if we could pull it off, but it’s anything but “fairly simple” – at least, not if you also want to keep being able to just click on objects, transform them, edit them in the Inspector etc without many seconds of delay – and without breaking most of the Editor scripts out there… :)

Some techniques for lag compensation in a server-client model require the reconstruction of previous game-states and quick/forced re-processing of physics steps, based on stored input. Are there plans to allow for more freedom managing the physics engine and its steps?

You should also add support for multiscene loading in the networking module. It is a nightmare to synchronize sceneIDs with the current implementation.

Unity does not offer enough global coverage with their relay servers. Completely unusable. My 4G cellular connection offers me 350 ping to the nearest Unity Relay server, and I live in Melbourne, Australia. Until we can fire up our own ray servers or until Unity atleast matches Photon Cloud’s coverage, we will be using Photon. For comparison, my game has 40 ping using Photon.

What is really missing, hear this from many people, is a UNET code based tutorial including the majority of features like sync-scripts, NetworkManager script, SyncList’s etc.

I followed those tutorials and the rest of the documentation and I notice a lack of proper documentation for the more specific network scripts, for instead I tried using the network animation script to sync the animations of my characters and I have these cases where I want to transition to an animation via a param “pulse” (turning a bool on to transition and then off again). Because the documentation doesn’t say anything about what’s doing behind the scenes I couldn’t figure out why it was failing to send the pulse so I had to change my whole mecanim tree and scripts to use variables that mimic states. Maybe this is the correct way of handling it or maybe I was doing something wrong before but I have no way of knowing it when there isn’t enough information on how it works.

Lack of adequate game server support is why I am not currently using Unity. If you can deliver on easy MMO support, I’m coming back.

It’s really amazing to location tha5 you have give an improvement in multiplayer. Recently I would like to start learn multiplayer so now I can learn updated section of the multiplayer directly. Thank you so m7ch to give this updating and you also update the learn section of the multiplayer .

Well those new enhancements are done having network support in my game is a nonstarter as It’s not reasonable to expect players of a simple game to learn network administration to play the game. I look forward than to beta Unity 2017.

We agree, players should not be expected to learn network administration. We don’t believe we added anything that would change that. Can you describe your concern a bit more?

Great news!

Is the management of reliable/unreliable, ordered/unordered messages part of the new NetworkTransport, or is it still an HLAPI thing? If I’m not mistaken, all that stuff was in NetworkConnection, ChannelBuffer, etc… of the HLAPI)?

Comments are closed.