Beamable Best Practices

Many decisions that you’ll make as a Beamable developer will have business/cost implications for your studio as you grow your game, your team, and scale the number of players. This guide provides a high-level set of best practices for efficiently utilizing the Beamable platform and maximizing its 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 employs a combination of subscription and usage-based pricing models. Subscription prices cover the cost of Beamable in development. Usage pricing, based on API calls, developer seats, and microservice instances, covers the cost of your game as it scales up and utilizes more Beamable services and resources.

Beamable offers a free tier that includes 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 the steps that Beamable recommends 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, allowing our customers to have predictability and control over their costs.

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

We charge for all API calls to all endpoints. This includes session/platform calls required to operate Beamable, as well as all direct API calls, whether they originate from the end-user app, a custom game server, or a custom C# Microservice.

What endpoints are called for API counts?

Here is a list of billable managed API endpoints that will appear in your usage profile. In addition to these, any calls to a custom C#MS endpoint will also be counted. Called from C#MS to any managed service is also counted.

accounts
announcements
api
auth
BeamableApi.Auth
BeamableApi.Beamo
BeamableApi.BeamoOtel
BeamableApi.Lobby
BeamableApi.Mailbox
BeamableApi.Match
BeamableApi.Party
BeamableApi.PlayerLobby
BeamableApi.PlayerParty
BeamableApi.Presence
BeamableApi.Scheduler
BeamableApi.Ticket
beamo
calendars
chat
chatV2
cloud
cloudsaving
commerce
content
dbids
event-players
events
gamerelay
groups
group-users
history
inventory
leaderboards
legacy-cloud
legacy-entitlement-defs
legacy-promos
legacy-pvp-defs
legacy-timers
mail
notification
payments
push
realms
rest
session
social
stats
tournaments
trials

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 <1,500 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 <1,500 API calls per MAU, you can do the following:

• Don’t call Beamable more often than necessary. 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 to determine if you have inefficient loops or other patterns that may 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, rather than making constant requests. ** Only ask for data when you know the state has changed. Only ask for the data that you need.
• Design reactive systems for communication with Beamable.Beamable provides numerous notifications that you can subscribe to. ** This also applies to custom microservices. 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, select a specific subset. ** If a content type has items you don’t care about, or state changes 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 updates or fetch operations. Places where this is most common are 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 will 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, more resources are 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 its own seat. For security reasons, it’s important that every game developer, producer, administrator, and tester who is interacting with your game project has 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 who have privileged access to higher realms so people can’t accidentally or maliciously change data in the higher realms.

One of the most common reasons a team is required to increase its Beamable monthly subscription fees during game development is due to an expansion 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 essential to note that each instance of the microservice constitutes a single service. If you have two services in your project and they are 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 consume resources on Beamable. As such, our pricing reflects strict limits on the number of instances of microservices you can have at any given subscription tier.

At the free tier, you get one 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 pass through 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 in 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 additional considerations you can make to optimize efficiency with Beamable, including 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 optimal performance and facilitate 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 concerns regarding resource usage and its impact on billing, please contact Beamable support or your customer representative.