Update on Unity Multiplayer, Current and Future
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.
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.