Search Unity

As part of our commitment to solving challenges for connected games development, we’ve focused first on real-time multiplayer games, and we’ve learned a lot from our prior attempts to democratize this space. First and foremost, we know that in order to build the right new technology, we need your feedback every step of the way. So as we begin this new chapter, we welcome you to build alongside us, give us feedback, and in return, we promise to give you frequent updates and high transparency.

Following a previous blog post announcing the deprecation of UNet, it became immediately apparent from the feedback we received that we would need to provide more details about our plans moving forward. In this blog post, we will address this by sharing both our long-term vision and the first releases, which will be available this fall.

Networking: Performance and scalability

Long-term:

“Performance by Default” is how we describe several ongoing feature-initiatives, including the Job System (multi-threaded processing), Burst Compiler (specialized for Unity game code), and the Entity Component System (data-oriented game code), which together can provide major improvements in performance of multiple orders of magnitude.

Together, these initiatives mean that Unity will be able to support virtually any game you dream of regardless of the scale. Large maps, many dynamic objects or AI, and even large numbers of networked players, are all viable.

In this new paradigm, it is significantly easier to enable components for a networked environment. What’s more, the highly structured data of ECS enables elegant solutions for higher-level simulation like delta compression, interpolation, and more.

We’re building the new networking stack with these key principles in mind:

  • Transparency: Packages enable us to provide the source code for our new solutions and ship rapid updates as previews outside the four-month release cycle. You may debug and extend our networking solutions as your game requires.
  • Modularity: Monolithic libraries add unnecessary overhead for features you likely don’t need. Each new feature beyond the baseline transport will therefore be separate and optional.
  • Performance and scalability: We recognize that performance is a key requirement to all of our features, and networking will play a crucial part in our “performance by default” vision for the future. We are ensuring that, from the beginning, networking will scale to the needs of modern games.
  • Archetype specificity: We now understand that there is no single solution that is ideal for all game types. So instead, we will create different solutions for common network archetypes used in games, such as FPS, RTS and fighting games. The initial focus is on the client-side prediction model commonly used in FPS games.

Short-term:

In the short-term, we’re building the new networking stack from the ground up, starting with a very minimal transport layer: UDP-based send/receive functionality provided with source as a preview package. The APIs included out-of-the-box will be Job System compatible and optimized to pair well with ECS-based games, though neither are required. This first step is a bare-bones beginning, and we know many critical features (including Reliability and Sequencing) may be required before you have everything you need for your game.

In parallel, we will release a full source FPS sample game that includes production-quality sample code for client-side prediction, interpolation, and delta compression built on the new transport. The first step toward other archetypes will be released at a later date.

Hosted dedicated servers: Consistency and security

Long-term:

After analyzing the landscape of real-time multiplayer topologies, we’ve come to the conclusion that a dedicated game server (DGS) model is the best option for real-time multiplayer games because it provides:

  • Consistency:  The processing and logic are moved to a resource that you control. This enables predictable connection quality and no “host-advantage” for latency-sensitive games.
  • Scalability: While Peer-to-Peer connections struggle to expand beyond a small pool of players per game instance (typically a dozen or fewer), DGS can support much larger populations on more powerful machines.
  • Security: Server-authoritative code enables cheat prevention rather than having to detect it after an unfair event has already occurred.
  • Fast iteration: Tuning a multiplayer game often requires significant iterations even after launch. However, with the DGS model, no client patches (which may have to pass cert) are required to update logic that is only running on the server.

This is one of the main reasons we brought Multiplay into the Unity family. Their proven dedicated server-orchestration technology enables developers to scale up and down a server fleet seamlessly to meet the needs of their games. Multiplay also optimizes costs at scale through hybrid bare-metal and “burst cloud” hosting. Their technology has already been proven with custom, engine-agnostic, enterprise solutions for games such as PUBG, Titanfall 2, Gang Beasts, and many more.  For more on what Multiplay does, check out a session recording of Multiplay at Unite Berlin 2018.   


Short-term:

We’re currently focused on integrating Multiplay technology into the Unity ecosystem with self-serve accessibility. Soon you’ll be able to enable development game-hosting servers that you can use to playtest your game with team members and friends, even when they don’t share your office space. The initial alpha release will include fleet provisioning, Linux server build upload and deploy, a package for Server Query Protocol, and some simple stats and logs to monitor what’s happening on your server.

Matchmaking: Flexible logic and seamless integration

Long-term:

Matchmaking is the art of matching a set of players with one another in order to maximize their enjoyment of the game, and it isn’t easy to do well. We’ve heard repeatedly that each game has unique goals and match rules, making it difficult for an off-the-shelf matchmaking solution to be flexible enough to support them.

We announced Open Match, an Open Source matchmaking project with Google, at Unite Berlin as an initial step towards solving this problem. This project is intended to provide scalability with an extensibility-first design. It allows you to customize match logic and orchestration modules however you need in order to fit the needs of your project.

Unity is building a managed matchmaker with Open Match at its core, and it will continue to benefit from growth and improvements to Open Match. We will also provide additional unique benefits to Unity developers:

  • Fully managed service: We will run, scale, and manage a matchmaker service on your behalf, so you can focus on building your game.
  • Scalable game-server hosting: By default, Unity’s matchmaker will seamlessly integrate with Multiplay orchestration technology to enable scaling of game-hosting server capacity up and down based on the number of players seeking to play. This means Unity developers will not need to learn about the complexities of server lifecycles as long as they use this service.
  • Accessibility: In future iterations, the Unity-managed service will provide simple off-the-shelf options that enable game developers to tune the balance of latency, skill, and wait time without writing custom logic.
  • Customizability: For games with additional custom requirements, we will enable fully custom match-logic in a managed environment later in 2019. It will be possible to deploy this match logic to your matchmaker from within the Unity environment, written in the standard Unity C# language. This adds great peace-of-mind to know that if the off-the-shelf solution is insufficient, there will be options to customize the match logic that’s unique for your game.

Short-term:

Open Match is readily available with its v0.1 release last week, and we will continue to work alongside Google and others in the community to grow this solution, both in terms of features and quality.

In parallel, we will soon release a simple first version of the managed Matchmaker in the Unity ecosystem, which includes player count configuration, seamless integration with server allocation, client libraries in a package, and automated deployment. In this first version, a server will be seamlessly allocated once the player count is met, and the game clients will be connected to their server.

Server runtime: Cost and modularity

Long-term:

When hosting dedicated servers, the biggest concern we hear about is related to costs. In a public cloud-environment like Google Cloud, the costs are based on a combination of the virtual machine specification, time used, networking bandwidth (egress) used, and license fees for the OS. In order to reduce costs, you need to:

  • Minimize the consumption profile required for your server runtime so you can reliably run your game at top performance on the smallest possible VM spec.
  • Minimize server time used with server orchestration and matchmaking that only spins up and allocates a server when your game needs it to meet player demand.
  • Minimize networking bandwidth with great simulation code (like delta compression) that only sends the most-relevant data that has changed since the prior frame.
  • Run servers on Linux OS to avoid significant license fees for proprietary operating systems.
  • Blend bare-metal with cloud bursting once your game reaches sufficient economies-of-scale to benefit from a constant baseline of bare metal servers.

We’ve already discussed solutions for the last four of these five points, and the server runtime consumption profile is also something we are very much focused on at Unity today. We believe that the new package management system, once fully implemented, should enable developers to run Unity as a server runtime with a very slim profile. This minimal profile will allow you to include only the packages your server requires to meet the goals of your game.

Short-term:

We’re currently focused on optimizing the “headless” version of Unity Linux runtime by finding low-hanging fruit, such as removing any rendering, animations, and audio that are unintentionally still executing in “headless” mode. It’s our goal to minimize memory, build size, and CPU consumption while increasing stability and uptime in our current version of “headless” Unity.

In 2018.3 we’ve also added developer workflow improvements, with a new “Server Build” option for all standalone players that is headless by default and enables a new UNITY_SERVER define for separating server script logic.

Stay in touch

  • Keep track of what we’re working on by visiting unity3d.com/connectedgames.
  • Have feedback? Please share it in the sticky threads of the Connected Games forum.
  • Interested in alpha testing some of the new technologies? Contact us here.
  • Keep watching the blog.  We’ll continue to share and communicate more.

48 Comments

Subscribe to comments

Comments are closed.

  1. So will it be possible to use p2p for optimization purposes? Like if you have a small group of players that are far away from everyone else, they could be treated as a p2p group instead of having them all relay through the server?

  2. Hello,

    With your new Unity/Google Cloud multi-player system, what will be the maximum number of simultaneous players you will support in the same room at the same time?

    Right now im using PHOTON PUN multi-player system for Unity, its nice and easy to use, but seems it can only do maybe 6 to 10 players tops per room, i need way more than that, maybe 50 to 100 or even 1000. Can you guys swing that?

    Thanks!

    1. You should really check your code, sounds like you could use some optimizations. Our game warscrap.io has 10 players per room and over 20 bots + vehicles.

  3. What is the recommendation from Unity on starting a new project today for a networking heavy game? Work through everything in a networking free setup for now until the new Multiplayer Connected stuff is done, or something else?

  4. Hi guys, any plans on in editor client + server splitscreen like in Unreal 4?
    I feel like the need to build and launch a server any time you want to test anything is the major drawback and i’ve seen many people
    trying to work around it by building separate assemblies and what not.
    I don’t see any mention of that, is that being worked on?

  5. Authoritative server models are welcome since at UNET this is a big headache and a mess to reach. Glad to see that there will be an FPS sample, prediction and safety are the most important things to it.

    1. Thanks Tomas – looking forward to your feedback when the Alpha comes out soon.

  6. I don’t quite understand where this leaves me, I have very little experience in multiplayer, I built what I thought was a p2p authorative model in a game i’m making.

    the idea being is that a player is a host, but not a server, its a single screen game, all input values are fed to the host and the host moves the players, which is then authoratively sent back to the clients. there is a small delay but for the most part its working well.

    this was all done in UNET HLAPI and syncvars. matchmaking is being used but no servers are hosting the games.

    are we now saying this setup will no longer be possible or supported in the new networking system?

    1. In the new system, instead of running the server on local hardware (that is inherently hackable), it will be by default hosted on a separate box (either by Unity/Multiplay or by other means of your choosing).

  7. The big question – Will there still be a completely “Free” tier for those small “between friends” games that use <1GB / year as we currently have with the UNet servers? Alternatively, will we still have self-hosting options?

    1. The networking code is agnostic, so self-hosting is certainly possible. LAN multiplayer games are always free and will definitely be supported since it’s required for development purposes anyways. Beyond this, pricing is still something we are working on with our Google Cloud partners.

  8. This is truly great news. My studio are working on a multiplayer RTS that cannot work with lockstep because of the complexity of the game. Support for the server-authoritative client-predictive archetype will make our lives easier in the coming months.

    I would really like to know exactly where Unity now will make the API’s. What will we as a studio have to do for ourselves and what will we be able to do in Unity?

    1. If there are specific features you most need – please let us know! Our roadmap is still evolving, and there will be many more features even after the upcoming alpha release.

  9. I hope there is still peer to peer for small scale free non competitive project, I pray the sin and the moon, even the cloud and teh rain!

    1. For small games, you may want to consider LAN or local multiplayer. You may also be surprised by cloud hosting; you only pay for what you use since the servers spin up/down based on player demand.

  10. At this point, I would love to see a post about what we should be doing right now to prepare for these changes. How should we architect now to avoid too much hassle in the future? What would a networking interface look like now that would/could work with both systems?

    For everyone that’s starting projects now that need networking, news of something so much better on the horizon is great but stressful. Multiplayer can be so deeply rooted in an application, it’s not something you want to completely refactor in a year.

    How do we create an application now, that is new-networking-ready?

    1. That is an excellent point and I’d like to hear something about this too.

    2. Hi Michael – there will be an alpha version to explore in more detail soon, and beyond that, we recommend using the LLAPI or other UDP-based transport. The API’s will be most similar on day-1.

  11. Great news, and I’d like to hear more about RTS archetype specificity. I am making a RTS right now, but have had to create an authoritative client-server using LLAPI. Unfortunately this will not scale when the number of players or units increases, and I’ve had to assume a low unit pop cap, using my own algorithms which send mostly deltas for moving units.

    My game uses Unity’s lovely pathfinding/flocking, and I also integrated the code Unity released which allows pathfinding on 3D objects generated at runtime. But because Unity’s internal logic isn’t deterministic this means making some sort of more traditional lockstep solution is out of reach right now. There have been deterministic lockstep solutions made with Unity… but not for my requirements, with pathfinding on dynamically generated 3D terrain at runtime!

    For my project, I do not want a dedicated server system. When AOE2HD came out even LAN games were routed through a dedicated server somewhere else… which meant playing a LAN game in a flat in London with a ping of over 200. Matchmaking sure, but dedicated servers hosting games will be too expensive for me as a lone indie dev.

    I’d just like to know if there’s anything you can tell me about how RTS or my specific case will be helped by these changes? I’m trying to make something innovative, but am having to deal with technical compromises I’d rather not have to make. Thanks.

    1. Hi Richard – nothing we’ve shared here is going to be immediately useful in an RTS-lockstep networking archetype. The baseline transport and parallel processing of ECS / Job System can help performance, but the simulation code for an RTS will not be a major focus until we feel great about the “server-authoritative client-prediction” archetype.

      As you mention, strict determinism is a BIG requirement, and it’s something we care a lot about. You’ll see big steps forward towards this over the next year, but depending on the timeline of your game, they may not be soon enough.

      1. Thank you very much for responding so quickly! I am glad to hear there will be progress towards determinism eventually, though I understand client-server model is more popular and a solid choice for many other games, so it makes sense for you to work on that first. If you could release some deterministic feature which would enable lockstep with Unity’s dynamic navmesh magic, that’d be really great!

  12. I am glad that you focus on “perfomance by default” and transparency. In my opinion you are going in the right way. I am sure you are already thinking on it but cross-plataform will be a nice adition!

    1. Thanks Adrian – agreed completely that cross-platform is a critical part of this story.

  13. As with the last post about the new networking system, this is entirely focused on games. Unity is increasingly used by businesses for non-gaming applications, many of which will use multi-user. These often cannot be cloud hosted and must be on separate (non-internet) connected networks. To extend on earlier questions, will there be full support for entirely lan based applications? And if I can sneak in another question – proper support for VR based multi-play?

    1. Hi Nigel – in the past we’ve struggled with focusing on solving too many use-cases at once, and the end result is that we often don’t solve any really well. Even games have a huge range of specific needs, so even within these, we’ve narrowed the initial focus to Real-time Multiplayer Session-based games that can use a “Server-authoritative client-prediction” networking archetype. This is certainly very specific, but a lot of the core challenges we solve in this use-case will speed our progress in future use-cases as we move forward.

      Per LAN-based connections, this will definitely be a supported development feature for the networking and server runtime, and I do not know of any reasons it couldn’t work as a production feature long-term. Services like matchmaking and orchestration are developed and designed for the cloud, but these aren’t particularly valuable for LAN-only games/applications anyways.

      VR is unique in that lagged frames and performance are of the highest importance. Locking a frame to wait for a network packet is just a bad idea no matter the connection speed (LAN or Cloud). Most VR multiplayer titles we’ve seen so far use the “server-authoritative client-prediction” model we are working on today – i.e. the game client continues to attempt to move forward with stale data and then corrects if/when incorrect assumptions were made. We’ve seen both DGS and LAN-based titles succeed.

  14. Is support for windows servers somewhere on the road map? I already have a windows infrastructure and that is the OS I am familiar with. So just wondering if that is coming or if it is not even being considered, thanks.

    1. Windows runtime will also support the “headless” player and will benefit similarly from some of the optimizations in progress today. However, cost reduction in a cloud environment by using Linux is great enough that our self-serve environment will focus on Linux for quite a while.

      We want to offer hosted servers at the lowest possible costs, and that will remain a top priority long-term.

  15. Hi,
    What percentage of the code will need to be changed to switch from unet to the futur API ?
    I am very slow dev, maybe when futur API comes my project “allmost” complete will not be really finished.
    will i need to change everything to make my project work when the next multiplayer code come ?

    1. If the majority of your code is written and working, it’s better to move forward as-is on 2018.3/4 LTS. This version of the API’s will be supported for at least 2 more years (critical fixes), and if you are relying on the Relay, it will remain live until 2020 or later. We’ll ensure there’s a sufficient migration path before that date.

      1. This answer sounds like there will be no nice solution to port existing UNET projects to the new networking library. If this is the case I think it’s very disappointing. Because it’s a punch in the face for projects who are created with existing UNET but still want to keep close to latest unity versions AND want to port to the new networking stack (for good reason).

  16. As part of the effort to make the Unity dedicated servers run better on Linux, I’d love to see IL2CPP support for Linux builds. I’ve heard Unity engineers say in the forums that was put off because the Linux user base is very small, but that of course isn’t the case when you included dedicated servers. If you agree, please vote on my Unity Feedback submission https://feedback.unity3d.com/suggestions/il2cpp-for-linux-standalone-especially-useful-for-cloud-server-efficiency

    1. This is in the Roadmap! Linux support is increasing drastically at Unity today due to Server runtime requirements as well as non-games requirements.

      1. Good to hear! Thanks for the reply. Looking forward to hearing more news on this :)

  17. An out of the box patching system would be awesome. I feel like that goes hand in hand with multiplayer games.

    1. Do you mean client or server patching, or both?

      We do have plans to support development and production versions of fleets, and we will figure out a good pathway for promoting a new server build to the production fleet. Sometimes when an update requires a change to both client and server, we will run into server compatibility constraints, so we will need an answer in both matchmaking and orchestration to ensure clients are only connected with server builds that support them. These are all somewhat complicated challenges, but they are on our radar!

      Client patching is largely determined by the platforms themselves. It’s unclear how much we at Unity can help improve this process, but we’re open to ideas!

      1. Sorry I should have been more specific. Desktop client patching would be amazing. I do understand that most games go through a platform such as steam or origin that provide the ability to update a game, but there are cases where a developer might choose not to. An out of the box desktop patching system someday would be pretty great!

  18. Make sure you provide as many visual tools for non programmers as possible. i.e. a system where with nodes you connect sources of data (ie. player inventory, score to a user blob,) and another node connection taking that score and connecting it with a global ranking system.

  19. Hi Brandi and team!

    Great to know your plans. Can I help? Want to add it to my game in development. It might be difficult for you as it’s for console and not sure where support is there at the moment :)

    Thank you for the detail in the blog, it’s really nice that you go into detail, and I think we all want that.

    1. Thanks Robert! The very early alpha versions of this tech support desktop (PC/Mac with Linux DGS), and we’re hoping to provide updates as soon as possible to include mobile and console. We’d still love your feedback as soon as it makes sense to you, and we will be in alpha soon.

  20. What if I want to build a client hosted game? Something small like a game jam project or local party game that I don’t want to be spinning up cloud hosting for. Given Unity is moving toward hosted game servers, how easy will it be in with the new architecture to locally host games?

    1. This is my main concern too, would be interested on what the answer is…

      1. Unity being used a lot by small indie game developers, i’m also curious what is the plan for P2P.
        HLAPI is being deprecated and has been abandonned for a few years already, and the new system is focused on dedicated server, i feel like there will be a few more dark years for those games.
        I hope they just don’t hope everyone use the over expensive Photon solution…

    2. +1 for this

      It is crucial to still be able to do client-hosted games. Partly because it’s useful for development purposes, but also because sometimes it’s the best option for some games.

      I’d just like to be reassured that there will be no obligation to use Multiplay or Google Cloud or any of that with this new networking API, and we will remain free to choose whatever approach suits us best

      1. In this post, we didn’t talk much about anticipated development workflows, but we do know that local and LAN support are important for speed of iteration. This use-case will be supported regardless of where and how you host your game. You may host your game on any servers of your choosing, and we’ll provide fast workflows, fast set-up, and cost optimizations if you choose to use Unity’s orchestration and Matchmaking services.

        Production client-hosted games still fall into the P2P model that we’ve seen many/most games fail to succeed with, so it’s not an immediate priority for us to create a new Relay service to support it. However, there will be nothing in the networking and runtime preventing you from finding other pathways if you are certain this is the best option for your game.

        1. It is vitally important that players have access to the server software. One day, both Unity Technologies and Multiplay will no longer exist, and when that happens people should still be able to play their multiplayer games. Dependence on a third party for server hosting like this makes me really nervous.

          Unless I’m misunderstanding what is meant by the DSG model? (I hope I am)

        2. When you say “server software”, I’m assuming you mean the server runtime (i.e. the code running on a server). The server runtime is completely in the developers’ control – you can choose to use Unity headless runtime, or you can even create a custom server runtime. If at any time, Unity’s hosting service is no longer sufficient for your needs, you can take that runtime and host it wherever works best for you.

        3. There’s a huge difference between P2P multiplayer and client-hosted dedicated server software. Without support for the latter, a lot of games will die due to official servers going down, dropping support, etc. And there are plenty of examples of successful games with that model, like ARK, Minecraft, Garry’s Mod, 7 Days to Die… hell, even the unofficial WoW hosting servers were crazy popular before Blizzard shut them down. There are much bigger things that make a game is unsuccessful than whether the dedicated server software is cloud-hosted or local-hosted.