Multiplayer Connected Games: First steps forward

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.

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.

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.

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.

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.

• 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.