Beamable Network Docs
  • Welcome
  • PROJECT DOCUMENTATION
    • Roadmap
    • Whitepaper
      • Market Summary
      • Democratization of Game Development
      • The Direct-from-Imagination Era
      • Decentralization: a Solution to Trust
      • Decentralized Physical Infrastructure Networks (DePIN)
      • Technology Background
      • Decentralizing with Web3: Token Utility & Nodes
      • Incentive Mechanisms
      • Tokenomics and Unlock Schedules
      • References
    • Community Airdrop Campaign
  • Policies
    • Privacy Policy
    • Disclaimer
    • Terms of Service
    • Coordinated Vulnerability Disclosure Policy
Powered by GitBook

(c) 2025 Beamable Foundation

On this page
PreviousDecentralized Physical Infrastructure Networks (DePIN)NextDecentralizing with Web3: Token Utility & Nodes

Last updated 3 months ago

In the lifecycle of a game’s development and operations, a developer must:

  • Code new features and create rules, art, content, etc., from the authoring environments that each contributor is accustomed to

  • Build code, content, and data into servers and client binaries

  • Test builds within individual workstations, testing environments, playtesting servers, etc.

  • Integrate changes from multiple developers, including coders, artists, and designers

  • Deploy changes to different environments, up to and including “production”

  • Operate the live game (i.e., “LiveOps”): events, promotions, economy, etc.

  • Monitor results, cost, and performance

  • Plan from the results and plan for the next set of features, code, and content

Beamable’s software is an integrated platform for facilitating every step of a game’s lifecycle.

Facilitating the Game Development lifeycle

Beamable Tech Stack

The core of Beamable’s technology is a framework that bridges game development in 3D engines like Unity and Unreal to the processes around servers needed for Live Services games.

Beamable does this by allowing game developers to author inside the native editors of their preferred 3D engine and add custom server code that sits side-by-side with their client code. This integrated approach means that code authoring, debugging, deployment, scale-out, and live operations are treated as a continuous and integrated process, relieving developers of the need to stitch together numerous tools.

An example of the Beamable approach to game development is how easy it is to create, debug, and deploy server code from inside your 3D engine. In this example, a developer is writing C# code in Unity side-by-side with their server code:

Microservices

The logic of a game (calculating the damage for a spell, coordinating state in a multiplayer game, changing a player’s inventory, or anything else you can imagine) can be separated into distinct functions. These functions may be invoked by the game client or from server-to-server requests.

In Beamable, game logic is organized into “microservices,” an architectural paradigm in which server code is organized into units that may be independently changed, deployed, and released. The advantage is that multiple developers can work on a complicated codebase with a clearer separation of responsibilities, and the testing and release parts of the game development lifecycle become manageable.

Distributing and Scaling Microservices

Microservices connect to an API Gateway with a persistent websocket, authenticate using an API key, and register themselves for traffic when they start up. Beamable routes requests to microservices through the websocket connections and monitors the health of each service container. Should a service instance fail enough health checks, the connection is terminated automatically, and requests are no longer routed to that instance.

Containers

Microservices are little chunks of code executed from within another technology that contains the Beamable Tech Stack.

Containers are lightweight sandboxes at the operating system level. Because they are sandboxed from each other, their contents have no awareness of or access to the other containers' resources (such as network interfaces, storage, etc.). Containers allow for efficient, secure code distribution across varying hardware systems, unlike virtual machines that use a hypervisor to launch entire operating systems on the same piece of hardware, resulting in large amounts of resource duplication and utilization.

Docker is a Container implementation used by the Beamable distributed network to facilitate the execution of the Beamable Tech Stack across various server environments. This diagram illustrates how code images can be distributed to different hosts, including the developer's own machine, a QA environment, or a cloud provider such as AWS.

Deployment and Auto-Scaling

Beamable automates the deployment and scaling of microservice containers, leveraging a mixture of on-demand and spot instances to optimize for cost. Each is scaled to additional server instances based on average compute usage.

Stateful Workloads and Distributed Actors

One feature of most games is that they are stateful, meaning they maintain the state of the world between multiple participants from request to request (in contrast to most database applications used on websites or AI inference, where requests are transactional).

Distributed Actors are another technology Beamable utilizes in its tech stack to execute stateful workloads very efficiently. These workloads are vital to many game applications (e.g., Game Worlds, Matchmaking, Leaderboards, Tournaments, etc.). Combining this with decentralization will allow a whole class of advanced, decentralized capabilities to be run efficiently.

Actors are workloads that encapsulate state, cluster together and communicate with each other. Distributed actors (as opposed to local actors) can live across multiple processes and communicate with each other over the network. They are generally created in, at most, one place within the memory of an actor host process. This is a powerful paradigm for concurrency and distributed systems, as it allows for highly stateful workloads to be executed efficiently as the data doesn’t have to be unloaded/reloaded with each request and can be structured for optimal read/write access. Furthermore, actors are created or relocated to an actor-host proximate to the requester.