Can I Vibe Code a Real Online Casino Game (Part 5)
Previous entries in this series: Part 1 · Part 2 · Part 3 · Part 4
If you’ve read the previous articles in this series, you’ll know I’ve been vibe coding a ‘real’ online casino game over the past few weeks.
But what does ‘real’ mean in this context? I don’t just mean a game that looks real. Vibe coding a front-end that looks and behaves like a casino game is so simple you can do it on a lunch break. You can give your AI screenshots of your favourite slot and it will build a simple front-end that looks and behaves a lot like it. But that’s not how casino games are built in the real world.
In the real world, the front-end can’t be trusted, because all its code is public. If all the game logic was held on the front-end, malicious actors could hack the game to change the results, or do myriad other disruptive things.
A real game consists of a front-end plus a remote gaming server (RGS), which hosts the Random Number Generator, the game logic, and the maths. The front-end communicates securely with the RGS over an encrypted connection. When the user places a bet, the front-end sends this request to the RGS, and the RGS responds with the outcome of the bet. The RGS, which holds all of the sensitive information, is not directly accessible by the user, and the front-end is only aware of non-sensitive, public information.
I’ve built my vibe-coded game this way from the start. The game, which you can play here: https://plinkovibe.scott.co.im is split into a front-end and an RGS. The RGS is hosted in Render and the front-end is hosted in Cloudflare. The two communicate with each other over the public internet using a TLS 1.3 encrypted connection.
But it doesn’t stop there. When you run a real online casino game, there are at least four moving parts:
I haven’t yet touched the casino website – the interface where you log in to your player account, make deposits and withdrawals, and choose the game that you want to play. When you launch a game, it’s from the casino website (which will usually launch the game in an iFrame, so you can easily access the cashier, lobby, and other website features).
Nor have I touched the Player Account Management system – a back-end system which holds all player accounts and their details – such as personal information, deposit and withdrawal methods, account balances etc. The PAM is a critical part of the casino infrastructure.
For this exercise I am interested in building the game in a realistic way, so I want to move the player account out of the RGS and into its own back-end service. Then I will build a log-in feature and add a simple cashier with currency support to the front-end, to simulate the casino website.
Underwhelming
In real life, there are companies who charge a lot of money for a PAM. To be fair, they are much more complex than the one I’m building, which is little more than a simulation. Real PAMs need to be very, very secure, as they are holding personally identifiable information, monetary transactions, and more.
My PAM is built with a single prompt.
No, really. I ask Cursor to plan its implementation of the PAM split, using Claude Opus 4.6. Then I use Sonnet 4.6 to build it… and it one shots the whole thing – the PAM itself, stripping the user account out of the RGS, secure communication between the two back-end components, even the front-end components for user account creation and cashier operations (simulating the casino website).
It takes me significantly longer to configure and deploy the new app structure than it does to actually build it, and that’s only because I make a human error when configuring the shared secret in the environment variables (needed for the two back-end components to communicate securely with each other).
Weirdly, this is one of the most underwhelming things I’ve encountered since starting the project. I find it satisfying when I have to get involved to solve problems or spot improvements. But on this occasion, all I can do is tweak the UI. (It’s still a little unpolished at the time of writing).
A New Development
Working on this project so far has been an eye-opening experience. The next and last post will wrap up what I’ve learned, and what I think it means for the casino industry and the people who work in it.
Why am I wrapping up the project at this point? Because going through the process has convinced me that yes, it really is possible to vibe code a casino game. So, with the help of two old friends, I’m going to try to do exactly that!
It won’t be PlinkoVibe, the game you’ve seen so far. Rather than build something for academic purposes, we’re going to build the most fun game we possibly can, and attempt to launch it with one of the industry giants. That means I’ll be taking the project private for a while.
We might not succeed in getting a game live, and if we do, it might not make any money. But if we are genuinely able to achieve it, it will be quite the achievement for just the three of us and our trusty friend Claude.