Beamable Best Practices

Many decisions that you’ll make as a Beamable developer will have business/cost implications for your studio as your grow your game, your team, and scale the number of players. This guide is a high-level set of best practices for how to make efficient use of the Beamable platform and maximize the value to your game studio.

If you have questions that aren’t covered in this documentation, or would like more detail, please email your customer success rep, or join our discord channel at https://discord.gg/beamable and ask the question there!

Pricing

Beamable uses a combination of subscription and usage-based pricing. Subscription prices cover the cost of Beamable in development, and usage pricing based on API calls, dev seats, and microservice instances covers the cost of your game as it scales up and uses more Beamable services and resources.

Beamable provides a free tier that consists of a limited number of monthly API calls, developer seats, and microservices.

For an explanation of free and paid subscription tiers, as well as an FAQ of pricing, please visit the Beamable pricing page at: http://beamable.com/pricing.

By using Beamable, you agree to the terms of use and licensing of Beamable which includes this pricing. You can review the Beamable license at https://beamable.com/license. If you use more resources than the free tier of Beamable, you will automatically receive an invoice at the end of the month to the email address on file for your customer ID (CID).

Maximizing Value

To make the most efficient use of the Beamable platform, some key decisions are necessary:

How many API calls is your game going to make?
How many game developers are on the team?
How many custom microservices should you use?

The following are what Beamable recommends you do to achieve the highest value with the Beamable platform.

Minimize your API calls

What is an API call?

Beamable operates on an API usage-based model so that our customers can have predictability and total control over their costs.

An API call is defined as any request made by the game client or custom game servers to Beamable resources.

Beamable does not charge for any API calls which Beamable makes implicitly, or extra hops made by Beamable managed services (e.g. events service calls to leaderboards, or how the chat system will query groups for membership).

Beamable does, however, charge for all API calls that the game developer decides to make to any Beamable managed services, whether they originate from the end-user app, a custom game server, or a custom C# Microservice.

How many calls should I expect to make?

Games are extremely diverse in their genres, player engagement, play sessions, and feature usage. As such, every game’s use of backend resources is going to be extremely different.

On average, if you are making efficient use of Beamable, you should expect to be able to deliver your game functionality for <2000 API calls per MAU. This is the average number of calls made by all players in your game over the course of a month. We use MAU because it is a combination of new players, old players, highly engaged players, and churned players.

API Call Best Practices

To achieve <2000 API calls per MAU, you can do the following:

Don’t call Beamable more than you need. Identify the services that will be the most impactful for your game.
Implement features incrementally. See how a feature performs, then build it out from there. Constantly test and profile your usage so you are aware if you have inefficient loops or other patterns that might drive high API usage, saturate network connections, or create performance issues at scale.
Avoid polling against beamable endpoints. Design systems that communicate with Beamable to be as reactive as possible instead of making constant requests. Only ask for data when you know state has changed. Only ask for the data that you need.
Design reactive systems for communication with Beamable. Beamable provides plenty of notifications that you can subscribe to. This applies to custom microservices as well. Build them so state changes publish notifications, your players subscribe and only fetch the state when the data has changed.
When you subscribe to notifications, subscribe to a subset. If a content type has items you don’t care about, or state change you don’t care about in your game client, do not subscribe to those changes or it will cause an unnecessary refresh of state. Be specific in your subscriptions. This applies to the content manifest. This applies to commerce stores. Be targeted.
Use batch APIs wherever possible. Avoid making individual update or fetch operations. Places where this is most common is in inventory updates and player stat retrieval.

If you have questions about these architecture options, contact Beamable support for examples or post in our discord channel.

Scaling your team

As you begin and accelerate development on your game project, your team is going to grow. You’ll invite them to your game project through the Beamable LiveOps Portal. Those game devs will need to connect to the various realms used in your project. As you add developers, there are more resources in use across the tooling and realms. Beamable’s pricing tiers up based on the number of developers you have on your project. You can reference the number of dev seats you get at each tier at https://beamable.com/pricing.

Beamable’s best practices for scaling a team are:

Every role on the team should have their own seat. For security reasons, it’s important that every game developer, producer, administrator, tester, that is interacting with your game project have their own account and permissions for security and audit purposes.
You should expect to have one realm per game developer. This keeps content authoring and code changes isolated and clean. Larger teams will have larger numbers of realms. Developers are admins of their own realm, but should be limited in their ability to promote or author in higher realms.
You can have developers share realms. If you have a large number of developers who aren’t changing or creating game content, they could share a realm.
You will also have higher realms for testing. You’ll want to make sure that there are higher realms (typically organized by division/function) to roll up and test the content, microservices, and code from a group of developers.
Assign release managers. You should have specific release managers that have privileged access to higher realms so people can’t accidentally or maliciously change data in the higher realms.

One of the most common ways that a team is required to move up their Beamable monthly subscription fees while a game is in development is due to an increase in team size. Larger teams require more support, ask more questions, and require more resources in development and the Beamable subscription pricing reflects this.

Consolidate your Microservices

C# Microservices allow you to build custom game server functionality by writing C# code directly inside of Unity, side by side with your client code. You can run and debug the services locally in a Docker container on your development machine, and then promote the service up to higher environments for testing and eventual deployment.

How do Microservice Instance counts work?

It is important to remember that each instance of the microservice counts as a single service. If you have 2 services in your project, and you have them running in three different environments (dev, staging, prod) that will count as six (6) microservices from a Beamable resource perspective.

Microservices require resources regardless of the amount of traffic they are serving. Even a microservice deployed to a development environment and sitting there over the weekend will generally compute resources on Beamable. As such, our pricing reflects strict limits on how many instances of microservices you can have at any subscription tier.

At the free tier, you get 1 microservice that you can deploy to dev, staging, and prod, so this means you have 3 microservice instances available in the free plan. Anything above that will require you to upgrade to higher subscription tiers.

Microservice Architecture Best Practices

To be efficient with your C# Microservice architecture, please follow these suggestions:

Always start with a single microservice. This is a monolithic architecture where all of your cloud functions are in a single service. In almost all cases, you shouldn’t need more than a single microservice with multiple functions. In a single service, all type definitions are in sync and always part of the same build output.
If functions need to talk to each other, do it inside a single service. Communicating between MS creates more latency as those requests go across the HTTP gateway.
Organize your code with partial classes instead of separate services. Many developers choose to build multiple custom C# Microservices for code organization. This is inefficient and costly. You can instead use partial classes.
Only consider multiple microservices if there are large differences of scale. A difference of scale would be where a couple of functions are called at wildly different rates so they can scale independently of each other. If you have questions, contact Beamable support for guidance.
You might want multiple microservices if one contains generalized logic across game projects. But even in that case, you can also share the code with partial classes and maybe not need another separate instance of a microservice.

If you have any questions about your C# Microservices architecture, don’t hesitate to contact support through your customer rep or the discord channel.

Other Best Practices

There are a few other things you can consider to optimize efficiency with Beamable on API calls and resource usage. These are:

Use Indexes - If you are using microstorage USE INDEXES on your most used queries or it will harm performance. Beamable provides a custom initialization attribute to ensure this happens when a microservice is deployed.
Avoid large documents and unnecessary reads/writes - Split your data into documents according to their access pattern and ensure individual documents aren't too large to guarantee you don't run into rate-limiting problems.
Use as few storage objects as possible with multiple collections. This will ensure the best performance and easier data retrieval.
Limit the size of the payload/requests to help with performance. Don’t ask for more data than you need. This generally helps players with poor internet connections.
Limit long-running tasks in client callable. There is a hard limit on all calls to microservices of 10 seconds. You need to stay within that when crafting your calls.
**Avoid long-running loops such as while loops in client callable. A loop that never terminates will degrade the performance for all other requests.

If you have any questions about pricing, Beamable API efficiency, or any other questions on resource usage and its impact on billing, please contact Beamable support or your customer rep.