Can I Vibe Code a Real Online Casino Game?

I’ve worked in gaming for twenty years now, and in the past 18 months or so I’ve been working with AI a great deal, both to become more productive in my day-to-day work, and to build simple side projects and apps. Vibe coding (building apps using natural language, without writing code yourself) builds on a skillset I already have – earlier in my career I was a Head of Product at Microgaming, and before that at Full Tilt. In short, being good at vibe coding is similar to being a good Product Manager.

So naturally I wondered if I could combine the two things. Could I vibe code a real, working casino game? If I could, what would be the implications for this very, very profitable industry?

Background

Casino games are both wonderfully simple and deceptively complex. On the one hand, slot games are so simple to make that there are hundreds, if not thousands, of game studios doing it, and tens of thousands of people employed in the business. There are very few unprofitable game studios, and new ones are popping up all the time. Barriers to entry, at least in the unregulated markets, are low.

On the other hand, nothing is as simple as it first looks. The back-end and front-end of a casino game are completely different systems that are both interdependent and fundamentally isolated. Things like random number generation, determination of outcomes, the fundamental mathematics of the game, and transactions between the user’s casino wallet and the wagers and outcomes in the game absolutely cannot happen in the front-end, or it would be a massive security hole.

The front-end needs to be graphically beautiful, incredibly fast, and work on an astonishingly wide range of devices and browsers – both mobile and desktop. It needs to handle complex edge cases – how do you gracefully recover if the user is disconnected after they’ve placed a bet, but before the result is presented?

There are more complexities. Currencies. Languages. Integrations with operators.

This doesn’t even begin to cover the commercial side of casino games – which games will make money. Today’s slot studios know that, just because you’ve released a game, doesn’t mean that operators will publish or promote it. Similarly, just because your game is published doesn’t mean you’ll make a return on your investment, especially in the short term. Different markets like different types of games. Emerging markets and brand-new players like simple content. Long-established markets like the US and Canada tend to favour old-fashioned, low-volatility stuff. Asia likes table games and live dealer. Some players even care about RTP. These are massive generalisations – there are endless nuances and pitfalls, and I’m just scratching the surface.

The Goal

Despite this, I’m not put off. Perhaps this is because I’ve worked extensively with peer-to-peer games, which have all of the above complexities and many more to boot. More importantly I’d figured I’d learn a lot from trying. It’s a step up from the simple apps I have been building myself, and a way for me to get down and dirty with casino content in a way that I haven’t before.

That said, I know that the best way to vibe code is to start simple and iterate from there. I’m not trying to build the next blockbuster title here.

After considering even simpler ideas like Hi/Lo and Rock Paper Scissors, my soft spot for Plinko wins out. Plinko is easy to understand but also fun, even relaxing, to play. To succeed, it needs clean animations and an easy-to-understand front-end. Then there is the back-end to think about, and all the interactions between the two. Ideally, I want to get to a final product that could feasibly work in a real casino, but…

What I’m Expecting

The truth is I’m expecting to get about 80% of the way there and then struggle with the last mile. Real casino games need to be certified, and that costs way more money than this experiment will justify (and who knows if my game will even pass?) Beyond that, there are regulated markets to think about, and their myriad requirements.

Also, while I have tons of experience in UI/UX, I don’t have any graphical or sound skills. Graphic design, animation, and sound effects are a huge part of what make casino games fun to play. If a slot studio lost its designers, the feel of their games would change immediately. Since I don’t have these skills, I’ll be relying on AI to generate everything and in my experience, it is not always good at this. I’m expecting my game to look… basic.

There is also the possibility that what I end up with will look like a casino game, feel like a casino game – but be broken in some fundamental way that makes it useless. Maybe it won’t pay out correctly, the RNG won’t work, or something else. I once read that when you ask an LLM a question, what you are actually asking is ‘What would a good answer to this question look like?’. So I could very well end up with something that is a passable impression of a casino game, but utterly unplayable in practice. People get paid a lot of money to build casino games. Do I really trust an LLM to do it?

Day 1 – Building in Public

I decided to build in public, so that you can follow along with my progress and maybe give advice if you’re feeling generous. I’ll share the Github for this project soon, for those interested.

I know from experience that planning ahead makes a big difference in Vibe Coding, just as it does in Product Management. So I start by making a plan.

First, I use Perplexity to research Plinko games and remote gaming servers. I feed it examples of Plinko games I particularly like (my favourite is Hacksaw’s Dare2Win series, but there are lots of good versions which ironically are sometimes called ‘Originals’ despite being anything but original). I also include publicly-available material from Stake Engine, Tequity, and others, and ask it to produce a summary report that I can feed into other AI tools.

I’ll be using Cursor to build – I’ve been using it for over a year and it has developed at an extraordinarily fast pace in that time. I consider Claude Code as well, but that would require yet another subscription, and I do enjoy a GUI.

I feed as much context as possible into Cursor, including the documentation generated by Perplexity and screenshots of popular Plinko games, and tell it what I’m trying to do. I use Perplexity to iterate on the prompt and, while doing so, realise that I’m essentially building a simple RGS as well as a casino game. Oh well.

I ask my old friend Philip Atkinson, who has been building a web-based game for some time, if he would recommend any technologies to use. He suggests TypeScript as the primary language for various reasons, which I am somewhat familiar with and can understand reasonably well. Perplexity likes his suggestion.

Then I ask Cursor to use Opus 4.6 to make a plan. If you’re interested, here’s the prompt:

You are an expert full-stack game engineer and UX designer building a browser-based Plinko casino game with a simple Remote Gaming Server (RGS) backend.

Goals and constraints:
- The game must run in current versions of all major browsers (Chrome, Safari, Firefox, Edge) on both desktop and mobile.
- It must support both portrait and landscape orientations gracefully.
- The user experience must feel like a modern, polished casino game: smooth animations, responsive layout, and satisfying sound design.
- The game must run end-to-end on my local machine and be playable from iOS devices on the same local network.

Technology:
- Use a modern, widely supported stack. Preferred: React + TypeScript for the front-end and Node.js + Express for the backend. If you have a strong reason to pick a similar alternative (e.g., Vite, Next.js), explain briefly and then implement.
- Implement the backend as a simple RGS-like service that:
- Hosts the Plinko math and RNG.
- Manages player sessions and balances.
- Exposes REST endpoints for: creating a session, getting config, placing a Plinko bet, querying balance and recent history.
- Use a very small persistence layer (e.g., in-memory store plus JSON file, or SQLite) to keep balances and recent history between restarts.

Game design (Plinko):
- Implement a Plinko board with configurable number of rows (e.g., 8–16) and risk levels (Low, Medium, High).
- Each configuration (rows + risk) should map to a specific paytable and probability distribution, defined on the server.
- Use a math model where the server:
- Chooses the outcome slot index based on the configured probabilities.
- Looks up the multiplier from the paytable.
- Calculates the win = bet * multiplier.
- Updates and returns the new balance plus the outcome details.
- Implement at least one RTP variant initially (e.g., ~96–97%) but structure the code so that additional RTP variants (e.g., 98.98%, 94.3%, etc.) can be added as separate configurations.
- For now, use a designer-controlled probability distribution for each slot rather than a strict physical simulation, but keep the distribution shape roughly binomial-like (more hits in the middle, rare at the edges).

Front-end behavior:
- The front-end should never compute outcomes. It only:
- Lets the player set bet size, choose rows and risk level, and optionally enable autoplay.
- Calls the backend API to place a bet.
- Receives the outcome (slot index, multiplier, win amount, updated balance).
- Animates a ball dropping down the board into the final slot that matches the server’s outcome.
- Implement responsive design for both portrait and landscape modes on desktop and mobile.
- Use high-quality visuals and animations:
- Use CSS transforms and requestAnimationFrame-based animations (or a small animation library if needed).
- Make the ball movement feel physical and satisfying, even though the outcome is pre-determined.
- Implement basic sound effects for:
- Ball bouncing on pegs.
- Final landing.
- Wins, scaled by win magnitude.

Asset generation via AI:
- Use the latest Google Gemini model (via the appropriate API) to assist with visual design:
- Generate a cohesive visual style (color palette, background art, peg and ball styles, UI elements such as buttons and panels).
- Generate raster or vector assets where appropriate and integrate them into the build (e.g., exporting to a local assets/ folder).
- Optionally help draft sound design descriptions that can be turned into sound effects (or simple generated audio files if feasible within the stack).
- Clearly separate the asset-generation step from the main game logic so assets can be refreshed or swapped later.

Backend API details:
- Implement the following endpoints:
- POST /api/session → create or restore a session and return sessionId and balance.
- GET /api/config?sessionId=... → return current paytable, allowed rows, risk levels, and default settings.
- POST /api/plinko/bet → body includes sessionId, betAmount, selected rows, and risk level.
- GET /api/balance?sessionId=... → return current balance.
- GET /api/history?sessionId=... → return last N rounds (for debugging/analytics in dev).

- Log each round on the server (bet, outcome, multiplier, win, resulting balance) so that RTP can be inspected over many rounds during development.

Networking and local play:
- Configure the backend to listen on 0.0.0.0 so that it is reachable from other devices on the local network.
- Configure the frontend to either proxy API requests in development or to call the backend via a configurable BASE_URL environment variable.
- Document how to run the project:
- npm install / npm run dev (or equivalent) commands.
- How to obtain and configure Google Gemini API credentials.
- How to access the game from an iOS device using the machine’s LAN IP.

Code quality and structure:
- Organize the project with clear separation between front-end and back-end folders.

- Use TypeScript types for API requests/responses and shared game models where possible.

- Include comments where helpful, but prioritize clean, self-explanatory code

- Provide a short README explaining architecture, how the math model works, and where to adjust paytables and RTP.

Start by scaffolding the full-stack project (front-end + back-end + shared types), then implement the backend math and API, then the front-end UI and animations, and finally the asset-generation integration with Google Gemini.

Further context is attached.

I review the plan and, in my opinion, it doesn’t emphasise security nearly enough. I expand it, making it absolutely clear that all game logic resides in the RGS and must be completely isolated from the front-end. I emphasise that the user should never be able to affect the outcome or figure it out in advance, and so on. I add this to the plan and click ‘Build’.

Just thirteen minutes later, I have thousands of lines of code. I configure the dev environment and… it runs.

Have I just one-shotted a real casino game? In less time than the typical daily stand-up call?

(Find out in my next article!)

If you’re building in this space and you think I could learn from your expertise, I’d love to chat! Send me a DM, and lets connect!