These backends “solved” their platform’s rigidity by tacking on a clunky scripting layer [1] [3] with a proprietary KV database [2] [4] (look ma, no transactions!). They proceed to claim you can build a LiveOps game on this rubbish without testing, database migrations, monitoring, BI tooling, etc.

We got fed up and built an open-source backend engine as an alternative: Open Game Backend.

OpenGB is comprised of four components: the engine, modules, scripts, & registries.

Modules & Registries

No two games have identical use cases, but these game backends try to provide the same API to everyone. For example, PlayFab has 44 API endpoints for their economy API [5], yet every developer I know still finds it too restrictive to use in a serious game.

Instead, OpenGB assumes game developers will start with off-the-shelf modules, then fork & write new modules as their needs grow. Everything down to auth, tokens, & rate limiting are implemented as modules so they can be modified. Forking a module is as simple as `opengb fork <module>` to pull code in to the repo.

Scripts

I love niche game engines & languages, so I’ve seen a lot of weird tooling. But these cloud scripts are some of the most tedious platforms I’ve written code for. Even their example code has race conditions [6] and requires 306 LOC to implement a simple transaction [7].

We built the scripting API to feel as much like a game engine as possible. All of the complexities of database queries/migrations, schema validation, and networking are abstracted away in a cozy engine-like scripting environment where game devs feel at home. It's dead simple to write a leaderboard module from scratch in a couple minutes: https://opengb.dev/build/crash-course

Official Registry

We don’t intend to ship a truckload of half-baked services like PlayFab & UGS does. We want to build a solid engine that others can extend with modules.

To help developers bootstrap their backends, we maintain an official registry of modules (written by us & external contributors) that are thoroughly reviewed for performance, testing, & docs. We hope other devs also share their registries, similar to the Unity Asset Store community. See: https://opengb.dev/modules/overview

We’re currently working with a few studios rolling OpenGB out to production. If you give it a spin, we’d love to hear your thoughts below or in our Discord: https://rivet.gg/discord

Documentation: https://opengb.dev

GitHub: https://github.com/rivet-gg/opengb

A few more notes:

- Licensed permissively under Apache 2.0, go nuts

- Leverages PostgreSQL’s features & extensions, similar to Supabase

- Generates type-safe client SDKs & Open API specs for your modules

- Supports Deno, NodeJS, Cloudflare Workers

[1] https://learn.microsoft.com/en-us/gaming/playfab/features/automation/cloudscript/writing-custom-cloudscript

[2] https://learn.microsoft.com/en-us/gaming/playfab/features/entities/entity-objects

[3] https://docs.unity.com/ugs/en-us/manual/cloud-code/manual/scripts

[4] https://docs.unity.com/ugs/en-us/manual/cloud-save/manual

[5] https://learn.microsoft.com/en-us/rest/api/playfab/economy/catalog

[6] https://github.com/Unity-Technologies/com.unity.services.samples.use-cases/blob/main/Assets/Use%20Case%20Samples/Daily%20Rewards/Config%20as%20Code/DailyRewards_Claim.js#L38

[7] https://github.com/Unity-Technologies/com.unity.services.samples.use-cases/blob/main/Assets/Use%20Case%20Samples/Command%20Batching/Config%20as%20Code/CommandBatching_ProcessBatch.js