I’m tired of getting screwed by game backends like Microsoft PlayFab and Unity Gaming Services. To get a simple cross-platform friends system, we’ve bent over backward fighting against their limited APIs to jerry-rig the behavior we need.<p>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.<p>We got fed up and built an open-source backend engine as an alternative: Open Game Backend.<p>OpenGB is comprised of four components: the engine, modules, scripts, & registries.<p>Modules & Registries<p>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.<p>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.<p>Scripts<p>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].<p>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<p>Official Registry<p>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.<p>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<p>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<p>Documentation: https://opengb.dev<p>GitHub: https://github.com/rivet-gg/opengb<p>A few more notes:<p>- Licensed permissively under Apache 2.0, go nuts<p>- Leverages PostgreSQL’s features & extensions, similar to Supabase<p>- Generates type-safe client SDKs & Open API specs for your modules<p>- Supports Deno, NodeJS, Cloudflare Workers<p>[1] https://learn.microsoft.com/en-us/gaming/playfab/features/automation/cloudscript/writing-custom-cloudscript<p>[2] https://learn.microsoft.com/en-us/gaming/playfab/features/entities/entity-objects<p>[3] https://docs.unity.com/ugs/en-us/manual/cloud-code/manual/scripts<p>[4] https://docs.unity.com/ugs/en-us/manual/cloud-save/manual<p>[5] https://learn.microsoft.com/en-us/rest/api/playfab/economy/catalog<p>[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<p>[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