The real story behind building a multiplayer game API from Cameroon - the failed 3D game, the financial pressure, the nights I almost quit, and why I kept going anyway.
I wanted to build a game like Free Fire.
Not an API. Not a platform. Not infrastructure. A real game. Something with players running, shooting, the kind of chaos that makes people forget they have responsibilities.
I watched tutorials on Three.js and got started. Built an object class for each game component, hooked everything into a central render method, watched a 3D world appear on my screen from nothing. That feeling, I don't think I'll ever forget it. 🎮
Then the game started scaling.
Player controllers. Animation states. Interactions. Physics. Collision detection at speed. The tutorials had gotten me through the door. But scaling is where tutorials stop and real engineering begins. It became clear fast that I didn't have the architecture for what I was trying to build. I had to stop, step back, and go back to vanilla JS and 2D games.
That wasn't failure. That was education. I learned more about how 3D games actually work from crashing into those walls than I ever could have from just following along. I understand 3D game architecture better now because of that breakdown.
But it forced a question. If I can't build the game I want yet, while learning ... what can I build that actually matters?
The Problem I Kept Seeing
Every time I looked at apps, betting platforms, fintech products, social apps, I kept asking the same question. Why does adding a multiplayer game to your product require hiring an entire game engineering team? Why is that barrier so high?
A game company wants Ludo. A fintech app, Duolingo wants Chess as a loading interface. A social platform wants something to keep users engaged. None of them want to learn WebSocket architecture, matchmaking theory, or game state synchronization. They just want the game.
Nobody had built the bridge.
So I decided to. A Games as a Service API. One integration and any developer can embed real-time multiplayer games into their product. Under their brand. With their rules. Without touching a single line of game logic.
I called it Beta Gamer. And I started looking for people to build it with me.
The Part Nobody Talks About
I found nobody.
Not because people weren't interested. Because I couldn't pay them. And you cannot ask people to dedicate serious time to your vision without compensating them. That's just reality.
See, the thing about being an African freelance developer is that your income is your oxygen. When a freelance project comes in, you eat. When it doesn't, you don't. No income means no internet. No internet means no development. The loop is vicious and most people outside of it don't understand how completely it can shut you down. 🥀🥀
There were periods I couldn't work on Beta Gamer at all. Not because I didn't want to. Because I had to survive first.
There were nights I thought, should I just ship it with 2 games? Get something out there, prove the concept, add more later? But I knew what that meant. The matchmaking engine I was building was designed to scale. Shipping early and upgrading it later would have been hell. The architecture would have fought me every step of the way.
So I made a decision that cost me time but saved me from a worse problem. I would build it right the first time, even if it took longer.
That decision required patience I sometimes didn't have. Power cuts in the middle of sessions. Mobile data as my only connection. Academic deadlines running parallel to a platform that needed my full attention. Supabase requiring me to be online just to test authentication flows, or searching a bug,
which sounds like a small thing until your data budget runs out at 11pm and you're mid-feature.
I won't pretend it didn't get to me. It did.
But here's the thing about building something genuinely hard. The difficulty becomes the proof. Every impossible thing you solve gets baked into the product permanently. It stays there, working, long after the stress of building it is forgotten.
What Kept Me Going
Honestly? The problems. 🔥
Every new thing I added that seemed impossible before I tried it. Like figuring out how to let external tenants inject bots into live WebSocket sessions through an API endpoint. Not hardcoded bots. Not internal bots. Bots controlled from outside the system entirely, by companies integrating Beta Gamer into their own products. I solved that and sat back and just stared at the screen.
Or designing the group matchmaking engine.
Most platforms build 1v1 first and bolt group support on later. That's why their matchmaking systems become a mess. I started with the general solution and let everything else follow.
The structure is Group[x] vs Group[y], where x and y are player counts that fall within a min and max defined per game. A game with fixed sizes just sets min and max equal. A game with flexible sizes sets them differently and the match starts when the minimum is met. 1v1 Chess is Group[1] vs Group[1]. Four player Ludo is four groups of one. A flexible team game is Group[2-4] vs Group[2-4].
One engine. One set of rules. Every game type falls out of configuration, not separate code. Reusable. Modular. The game defines its own rules and the engine just executes them.
And if tenants want to manage their own matchmaking logic from outside the system? They can do that too.
Then there's the thinking I haven't fully built yet but can't stop thinking about. Turn-based games, Chess, Ludo, Checkers, one player moves then the other. Clean. But football, shooting games, everyone moves simultaneously. Different timing model. Different conflict resolution. Different architecture entirely.
That thought kept me at the keyboard on nights I probably should have slept.
Where Beta Gamer Is Now
10 games live. Chess, Ludo, 8-Ball Pool, Archery, Piano Tiles, Connect 4, Check (Chkobe, an African card game similar to Uno), and more. Multi-tenant architecture with isolated matchmaking per partner. Hosted matchmaking mode where tenants control their own queues. Bots injectable via API endpoint. Flexible group sizes with configurable min and max per game.
The SDK ships three things separately. UI components, socket hooks, and game hooks. Tenants can use the default UI, replace it entirely, or just take the hooks and build whatever interface they want on top. You will never know it is Beta Gamer running underneath unless someone tells you. That is the point.
React and React Native packages are live on npm: @beta-gamer/react and @beta-gamer/react-native.
Built alone. In roughly 5 to 6 months of real working time, stretched across a longer calendar of power cuts, connectivity drops, financial pressure, and a full academic load that ended with a BSc in Computer Science from the University of Buea.
About 80% done. Not because I ran out of ideas. Because I refuse to ship something until it is right.
What I Hope For
I am not writing this for sympathy. I am writing it because I think there are developers reading this who are building something real, under real constraints, with no safety net, and they need to know that the building is worth it even before the reward shows up.
The next post will be the technical one. How the group engine actually works. How bot injection via API is architected. How I think about simultaneous move resolution for real-time games.
But I wanted to tell this part first.
Because the code does not exist without the person who wrote it. And the person is never just the code. 🏗️
Beta Gamer docs (Demo): https://beta-gamer.onrender.com/docs/overview
npm: @beta-gamer/react and @beta-gamer/react-native
Top comments (0)