Alex Scott

I Vibe Coded a Real Casino Game (Part 6)

Previous articles in this series: Part 1 · Part 2 · Part 3 · Part 4 · Part 5

You might have noticed that the last five posts in this series were called ‘Can I Vibe Code a Real Online Casino Game’, while this one is called ‘I Vibe Coded a Real Casino Game’. As I explained in the last post, I’ve discontinued further work on PlinkoVibe, my entirely vibe-coded casino game, because through the process of building it, it became blindingly obvious that vibe coding a casino game was definitely possible, and I wasn’t even the first person to do it.

So now, I am working with a small group of friends to commercialise and launch a casino game idea. Will we succeed? We’ll find out in the next couple of weeks. This article is not about that new game, but about what I’ve learned in the process.

Quick Recap

Using Cursor and various LLMs, I was able to build:

  • A casino game front-end, ‘PlinkoVibe’ – https://plinkovibe.scott.co.im
  • A basic remote gaming server (RGS) and maths model
  • A basic player account management (PAM) system

The three parts were built separately, and hosted on different infrastructure, to be reasonably faithful to how a real casino game would be designed. I didn’t take the easy route of building everything in the front-end, because the goal was to go in-depth on how feasible it is to build casino games with AI, and to draw reasonable conclusions from this – and that can’t be done without a model which at least approximates real conditions.

In the process, I found some things surprisingly easy and others surprisingly hard. Here’s what I learned.

What Was Easy

I’m focusing here on things that were easy for me personally, so this list might be atypical. I’ve worked in the gaming business for a long time, and understand the mechanics of gambling games really well. Plus my background is in tech. But I still think these conclusions are interesting.

  • Building an initial prototype was incredibly easy. Once I had the idea to start with Plinko (because it’s simple, and I enjoy playing it) I simply had to research the game – much of which I outsourced to Perplexity – and then use Cursor in Planning mode to sketch out the implementation. I am not exaggerating when I say that within 2 hours of work, about 80% of the entire project was complete. AI is incredibly good at prototyping and MVPs. Of course – the game looked awful, and there was another major issue I’ll come to later. But this part is so simple anyone can do it.
  • Building a simple RGS and PAM was surprisingly easy. There were two factors that helped here. The first is that casino systems are surprisingly well-documented online, and so AI had a mountain of context that it could refer to in designing the systems. The second is that both an RGS and a PAM are fairly typical back-end systems from a software engineering perspective. Many of the architectural considerations (security, performance, etc) apply to many other types of computer systems, and as such the general principles of systems architecture apply to them as well. There’s devil in the detail here of course. A real RGS needs to do a lot more than mine does, at a much larger scale, and would therefore be a lot more complex than the one I built.
  • Maths. Historically, developing gambling maths typically meant building a maths model in a spreadsheet (or maybe Python, if you were really advanced), and tinkering with the model for hours upon hours until you achieved the right RTP, volatility, prize distribution and so on. This process could be incredibly time-consuming and frustrating, as you changed one variable after another to try to achieve the desired result. Then you’d have to validate that you’d implemented it properly on the RGS by running tens of millions of simulations, which could take hours on end. AI can take a lot of this pain away. Start with a basic maths model, or even an idea, and AI can do things like achieving a target RTP or volatility, fixing imbalances, running simulations and correcting itself, all in a simple prompt. A simple example from my project – I wanted to change the multipliers at the bottom of the Plinko board from awkward numbers like 1.37x, 1.78x and so on, to round numbers like 1x and 1.5x, without changing the overall RTP of the game. That process might have taken hours with a spreadsheet but was done in 5 minutes with AI. It’s incredibly powerful and it opens the doors to both more complex maths models and for maths to become far more accessible. (NB. In part 2 of the series, I wrote about the silly mistake that AI made when it first built the maths. Because I’m experienced with gambling maths I spotted this problem immediately and it was very easy to both resolve it, and guard against it happening again. But this is a good reason for those who build with AI to ‘stick to what they know’.)
  • Upgrading dependencies, refactoring code, eliminating tech debt, handling console errors etc. This might surprise people who’ve worked in software development before, but one of the great side-effects of using AI is that you’re forced to regularly refactor and improve your code. This is for a couple of reasons – first because AI’s context window limitations require you to break up the code into smaller, more focused files on a regular basis. But also because AI is improving so frequently, that it often finds ways to improve on what it wrote before. During the project I upgraded both minor and major versions of dependencies, performed code regular code reviews for both security and performance reasons, solved console errors that would otherwise have been too time-consuming, and so on – all with a single prompt.
  • Testing. I asked AI to build automated tests. Whenever it changed part of the code, it ran these tests, and if it broke something, it just fixed it without any intervention required on my part. Bug fixing was a little more problematic – but bugs that would have taken human engineers many hours were often fixed in a couple of prompts. The trick, as ever, is to describe the bug accurately and with enough context for the AI to be able to figure out the probable cause.
  • Deployment. AI built the CI/CD pipeline, could automatically commit and sync changes to Github – and both my front and back-end hosts could automatically build and deploy straight from Github. I remember working on a project about 10 years ago that required a CI/CD pipeline to be built from scratch, and we assigned a team of engineers to work on it over a period of months, if not years. I’m convinced that with today’s technology, it could be done in days.

What Was Hard

  • Graphics, creativity and the human touch.

That’s it. That’s the list.

With most of the technology friction now gone, the hardest part of building a casino game today is making it graphically beautiful, well-differentiated and fun to play. All of that requires human creativity (for now).

Building a rubbish-looking casino game is easy. I did that with one prompt. Building a casino game that looks great on thousands of different devices, running in different combinations of currencies, languages, and regulated market conditions, is hard and requires good taste, skill and judgement.

AI has terrible taste. It builds functional interfaces that are at worst ugly and at best generic, with weird control hierarchies, unnatural use of language, and so on. This will probably change, and in recent weeks we’ve seen things like Google Stitch and ways for AI to integrate with your company’s brand guidelines, that have meaningfully moved the needle. In a year’s time things will probably be different, but to make a casino game look good today, you still need a good group of human graphics designers.

AI also can’t build a differentiated product for you, and this is an enormous challenge in casino (both B2B and B2C) which is about to get even worse, thanks to the inevitable wave of AI slop on the way. There are tens of thousands of online casino games. You can copy any one of those games with AI relatively easily. Making yours different so that it stands out in a crowded marketplace is very hard and requires expertise, judgement and taste.

Finally, making a game fun is probably the hardest thing of all. Even if your game is beautiful, even if it’s well-differentiated – doesn’t mean it will be fun to play. (And of course, what is fun for one person, may not be fun for another). In the course of building our new game, we encountered this problem on more than one occasion, and it took time and a lot of experimentation to finally arrive at something that we believe will be fun to play.

A Message to the Skeptics

There are many AI skeptics out there and some of them sent me DMs or commented on my posts. At the conclusion of this experiment, to those people I would say a couple of things.

  1. The pace of progress is real. I’ve been ‘vibe-coding’ with AI for over a year now. The frontier AI models today are approximately twice as good (on coding benchmarks) as they were one year ago – the mistakes that Claude 3.5 made just don’t happen anymore with Claude 4.6. Fewer bugs crop up in the first place. Those that do are more easily fixed. The AI gets confused a lot less frequently, can understand more languages, and can work on bigger codebases. Don’t base your opinion of AI on what was possible the last time you checked, unless you checked today.
  2. Don’t criticise AI for things that are also true of human developers. Common criticisms like ‘AI is responsible for security flaws’ or ‘AI writes code with bugs’ are also true of human developers, possibly even more so. I’ve been working with developers for a long time and there have always been security flaws and bugs. And triaging and fixing security issues and bugs with AI is a hell of a lot easier than doing it manually.

Conclusion

Making casino games today is a lot easier than it was even one year ago, thanks to AI. This will have a dramatic impact on casino games development and has the potential to reshape the industry.

Not having a plan for AI today is as catastrophic as not having a plan for mobile devices in 2014. If you’re still building everything manually with huge teams of human developers, you might as well be making games in Flash.