I wanted to build a game like Free Fire.
Not an API. Not infrastructure. Not a platform. A real game. The kind with players running through maps, shooting, the kind of chaos that makes you forget you 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, and watched a 3D world appear on my screen from nothing. That feeling — I don't think I will 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. The architecture I had wasn't built for what I was trying to do. 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 following along with someone else's finished project. I understand 3D game architecture better now because of that breakdown.
But it forced a question I couldn't avoid: if I can't build the game I want yet, what can I build that actually matters?
The problem I kept seeing
Every time I looked at apps, I asked the same question. Betting platforms, fintech products, social apps, loading interfaces — why does adding a multiplayer game to your product require hiring an entire game engineering team?
A company wants Ludo on their platform. A fintech app wants Chess as a loading interface between transactions. A social platform wants something to keep users engaged between posts. None of them want to learn WebSocket architecture, matchmaking theory, or real-time state synchronization. They just want the game to work.
Nobody had built that bridge. So I decided to.
A Games as a Service API. One integration. Any developer embeds 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. Then 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 give serious time to your vision without compensating them. That's just the reality of building anything without funding.
Being a freelance developer in Cameroon means your income is your oxygen. When a client project comes in, you eat. When it doesn't, you don't. No freelance income means no internet. No internet means no development. No development means the project sits still. The loop is vicious and most people on the outside of it don't understand how completely it can shut you down.
There were stretches where I couldn't work on Beta Gamer at all. Not because I didn't want to. Because I had to survive first.
Power cuts in the middle of sessions. Mobile data as my only connection for weeks at a time. Academic deadlines running parallel to a platform that needed my full attention. Supabase requiring me to be online just to test authentication flows — which sounds small 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.
The difficulty becomes the proof. Every impossible thing you solve gets baked into the product permanently.
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 companies inject bots into live WebSocket game sessions through a simple API endpoint. Not baked-in bots. Not hardcoded behavior. Companies controlling bot logic from entirely outside the system, in real time, while a game is already running. I solved that and sat back and just stared at the screen.
Or designing the group matchmaking engine.
Most platforms build 1v1 and bolt group support on later. That is why their matchmaking systems end up a mess. I started with the general solution and let everything else follow. A 1v1 game is just a group of two. One architecture. Every format.
Then I started thinking about what comes after turn-based games. Chess, Ludo, Checkers — one player moves, then the next. Clean. But football? Shooting games? Everyone acts 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 (an African card game), and more. Multi-tenant architecture with isolated matchmaking per partner. Hosted matchmaking mode where your own backend controls the queues. Bots injectable via API endpoint into live sessions. SDKs on npm for React and React Native.
Built alone. In roughly five to six 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 people reading this who are building something real, under real constraints, with no safety net, and they need to know the building is worth it even before the reward shows up.
The next post will be technical. How the group matchmaking engine actually works. How bot injection via API is architected. How I think about simultaneous move resolution for real-time games.
The code doesn't exist without the person who wrote it. And the person is never just the code.