Beamable Mercury: Our Latest Release

Beamable is the open platform for game server technology, and we are thrilled to be entering our latest release phase, Beamable Mercury, which includes our Unity 2.0 SDK, our CLI 3.0, and our first official Unreal Engine 1.0 release! All of these products are about equipping game developers with best-in-class tools to develop, deploy, and manage microservices and databases. For a complete overview of the Mercury release, check out this video:

Beamable Microservices

Beamable has long offered Microservices as an integrated part of our Unity SDK, and now we are extending them to work wherever our developers work, inside Unity or Unreal, or simply in a code-first environment. 

Microservices are built as dotnet 8 applications. They are integrated seamlessly into our Unity and Unreal SDKs and can be managed directly by the CLI. In Unity, Microservices are no longer part of the Unity compilation pipeline, which means Unity developers have access to full msbuild and nuget capabilities inside their Microservices. The Microservices offer a slimmed-down Dockerfile so developers can customize their deployed containers. Publishing Microservices is safer and faster than before, enabling developers to create and deploy Microservices in minutes. 

When you write a Beamable Microservice, our tooling will automatically generate code-code in Unity or Unreal, so you don’t have to spend time writing boilerplate. We handle request routing, auto-scaling, and security- so you can focus on building your game. 

Unity SDK Updates

The Beamable Unity 2.0 SDK is available today. The new SDK is powered by our CLI running behind the scenes. The Beamable SDK will automatically adapt your Unity project into a Beamable CLI-compatible project, meaning Unity developers inherit all the advantages of using the CLI and maintain integrated workflows within the Unity Editor. 

To take full advantage of the CLI, the 2.0 SDK will migrate your old 1.0-era Microservices into CLI-compatible Microservices. These CLI-compatible services are called Standalone services because they do not rely on Unity’s compilation pipeline. Instead, standalone services are compiled with dotnet 8, which unlocks a variety of powerful features for developers to utilize. 

You can run your services directly from an IDE. Debugging your services has never been easier. You can place a breakpoint in your Microservice code and use your IDE of choice to start debugging the application or attach it to a running process. Debugging in the 1.0 era of the SDK was complicated and involved complex and brittle configurations. None of that is necessary anymore, and debugging is as easy as starting the application. 

Your services have full access to Nuget and MsBuild. Nuget is dotnet’s standard package management tooling and there are a wide variety of packages available to add your Microservices, such as Newtonsoft. MsBuild is the tooling used to build dotnet 8 applications, and you can extend your csproj file to include custom files, manage complex builds, or run post-build scripts. The Program.cs file is also customizable. 

When Microservices are published to the Beamable Cloud, they are dockerized images. We have exposed a slim Dockerfile you can use to configure your build images. The build and upload process of the images has been dramatically optimized, and you should notice much faster Microservice publications. 

While all of these new features are available outside of Unity, we have maintained a strong Unity Editor workflow integration. We have rebuilt the Microservice Manager window to integrate the capabilities of the new standalone services. We have renamed the window to Beam Services, and it allows you to create, run, stop, view logs, manage, delete, and publish Microservices and Microstorage objects. 

Your old Microservices will be migrated to the new Microservice format the first time you open the Beam Services window. We strongly recommend you back up your project before starting the migration. The migration will handle the vast majority of existing Microservices, including those with .dll references, Assembly Definition references, Storage Object references, and custom code. Please see our documentation for more information on how the migration flow works, as well as a few limitations of the migration flow that will require manual intervention. 

We have removed the Beamable Toolbox window and the prefabs that existed inside it, such as Account Management. The skinning and theming controls have also been removed. If you already use these prefabs, they still exist within the package, so you can still use them. However, they are obsolete and will not receive patches in the future. 

Instead of the Toolbox, we are introducing LightBeams, which are Unity Package Manager Samples available from either the Package Manage or the new Beam Library window. LightBeams are meant to be lightweight samples that teach you how to use the Beamable SDK. They are not meant to be drag-and-drop shippable. The only exception is our Admin Console prefab, which is available in the Beam Library. Our goal is to develop each LightBeam as a simple example of how to use our SDK instead of building complex, fully featured game examples that may obscure the actual SDK usage. These LightBeams are also developed internally by Beamable Developers in the same repository and Unity project as the SDK itself, which means they will stay updated with the latest Beamable features and code. 

The Toolbox used to have buttons that allowed you to log in or out, change your realm, open the portal, and navigate to the other main areas of the Beamable Editor SDK. All of those functions now exist in the Beamable Button, which is located at the top of the Unity Editor. In 1.19.23, the button showed the currently installed SDK version number, but now it shows the currently selected Realm. If you need to find the version number, check your manifest.json file or go to the account page. 

Unreal SDK Updates

Unreal’s first official release was developed alongside early adopters and focuses on Beamable’s Core Features:

• Microservices and Federations
• Content
• Stats and Inventories
• Lobbies and Matchmaking and Dedicated Server Build support.

We have been in preview for a while now, but with the release of 1.0.0, we’ve taken all the feedback from our partners and developed SDK workflow improvements all around. 

In particular, we have a brand new Editor Content Window and Subsystem that is much more VCS-friendly while retaining the Unreal-native look and feel.

We also have a brand new Microservice Window that allows you to Run/Stop microservices locally through the editor, see the logs the service is emitting, configure Federations, and even enable a brand new collaborative workflow made possible by Beamable’s Microservice approach to cloud code. This also automatically detects it when running the service through the IDE, courtesy of our CLI-backing.

We understand that a lot of Unreal developers work on Dedicated Server games. As such, a lot of you will want to use our Federated Game Server capabilities to integrate Beamable’s microservices with your choice of Game Server Orchestrator (we hear Hathora is a good one). It used to be the case that our Beamable servers could not route requests to federations in your locally running services. This meant that for every code change you made in the federation logic, you had to publish the microservice to a realm to be able to test it. This was a problem because publishing would affect the entire realm, AND it took a lot of time.

We are happy to announce that such problems are no longer relevant. Not only are Microservice deployment speeds significantly faster now (down to 30s~1m from 5m~10m, in a lot of cases), but you can also change your service’s code, set up a content-based filter via the Editor or CLI, and then run your service. Any match made from the selected content types will be forwarded to your local microservice instead. This is a massive iteration time improvement and should make working on a dedicated server game much easier.

That is not all, though. Earlier, we mentioned a new collaborative workflow. Well, this is it: any developer can now share their locally running service with another developer in the same realm! This means that debugging collaboratively with teammates can happen much more organically. For example, if a designer runs into a bug with the deployed microservice. An engineer can hop on a call with them, run that microservice in their machine, have the designer point their PIE mode towards their local service, and then reproduce the issue while you have logs and a breakpoint added to your code. 

Working this way can help engineers quickly unblock designers being hampered by critical bugs and make team communication much more fluid and efficient. I’m sure you can imagine other interesting applications for this collaborative workflow, too.

To round out this release, all of the above is joined by many fixes around Lobbies, Matchmaking, Stats, Inventory subsystems, and the early stages of MicroStorages in-editor support.

That’s all we have for Unreal, folks! Read along for more information on the CLI, as the CLI plays a significant role in Unreal development with Beamable.

CLI

The Beamable CLI 3.0 empowers both our engine integration SDKs. The major change from CLI 2.0 to 3.0 is how the CLI is installed in your project. Previously, the CLI was installed as a global dotnet tool. This meant that if you had multiple projects using different versions of Beamable, you had to switch your global installation version each time you switched between projects. To solve this limitation, in 3.0, the CLI is installed as a local dotnet tool. This means that the project knows its current CLI version number, and when you run the dotnet beam version, you will be using the CLI version for the current project. The version number is stored in the .config/dotnet-tools.json file in your project root directory. This is a standard practice of dotnet tools. Microservices and Storage .csproj files will automatically reference this version of Beamable as well, which means when you need to change your version of Beamable, you can use the beam version install command once, and it will upgrade your CLI as well as your SDK. 

Experience Mercury Now!

Beamable’s Mercury release delivers a powerful evolution of our game development tools. With the enhanced Unity 2.0 SDK, first official Unreal SDK release, and a revamped CLI 3.0, developers can build faster, debug effortlessly, and collaborate seamlessly across diverse environments.

The Unity SDK introduces streamlined microservices management and robust integration with modern dotnet tooling, while the Unreal SDK provides advanced support for dedicated servers, federations, and collaborative workflows. Our CLI 3.0 further simplifies version management and project-specific tooling, ensuring a smooth and efficient development experience.

To explore these updates and more, sign up or log in to your portal now, grab the latest SDK versions, and build on Beamable today.