Post 1 of 7 in the game-factory series.
What it is
There is a slot machine I built and deployed to AWS, and it looks, at first glance, like a novelty. The reels are filled with cloud service icons instead of cherries and sevens, a leaderboard tracks players in real time, and every so often a small quantum badge lights up in the corner of the screen for reasons that aren't obvious until you look under the hood. It has a tournament mode for live events, a hosted "big screen" leaderboard view for a projector, and a real-time risk gauge that most people don't expect to see on a slot machine at all.
Underneath that surface, it behaves like a real one. Random number generation with a defined design, return-to-player math, session tracking, bet escalation detection — all of the mechanics that make a slot machine a slot machine, implemented the way an operator would implement them. What it is not, deliberately, is gambling. There is no real money anywhere in the system: no deposit path, no cash-out, nothing a player can lose beyond a number on a screen. The cloud icons are the tell. Nobody wagers actual currency for the chance to line up three Lambdas.
That distinction — a slot machine built with the seriousness of a real product, but without the thing that would make it one — is the reason this project exists, and it's where the story actually starts.
Why I built it
I've worked with several clients in the iGaming space, and I came into that work knowing almost nothing about the industry itself. I had no real opinions about return-to-player percentages (the share of wagered money a machine pays back over time), volatility curves, or how a jurisdiction certifies a random number generator. I was walking into a domain with its own vocabulary, its own regulators, and its own math, and I needed to close that gap quickly.
Reading through documentation and sitting in on product demos told me what the industry talks about, but it didn't tell me how any of it actually works. That gap is where I usually end up building something — I learn a domain by trying to reproduce its hardest problems in code, not by reading about them. So I set out to build a slot machine that behaved like a real one: a random number generator designed the way a regulator would expect, responsible gaming features (tools and detection systems meant to catch harmful play before it escalates) implemented the way an operator is required to implement them, and session tracking structured the way a behavioral analytics team would actually query it. If I could get all of that working end to end, I would understand the industry from the inside rather than from a deck.
The AWS icons weren't just theming — they were the mechanic. Winning patterns in the game are architecture patterns: land two matching services and you score, land three of a kind and you score more, and the jackpot is landing a coherent AWS architecture across the reels. The symbols had to mean something for that to work, and cloud services were the natural fit. It also meant the game could teach a little AWS architecture on the side, almost as a byproduct of playing it.
Once I started, the project kept growing on its own logic. Learning about rule-based responsible gaming detection led me to want to try the ML-based version. Basic session tracking turned into a full analytics pipeline once I understood why operators care about it. A mentor of mine even suggested quantum-seeded randomness and then built the service himself, which gave me a real quantum RNG to integrate into a live spin path. What began as "understand how slot machines work" became "build the smallest complete iGaming platform I can, and treat every layer of it as if it had to survive a real audit."
What the game does
Strip away the infrastructure and the game itself is simple to describe: you spin, you bet, you try to land a pattern.
The basic win is matching symbols — two of a kind pays a little, three of a kind pays more. The interesting win is the jackpot, and it isn't a random combination. It's a real AWS architecture. Land S3 feeding Lambda feeding DynamoDB across the reels, for instance, and you've built something that actually deploys. The game keeps a small library of valid patterns like this, and hitting one is worth more than any three-of-a-kind. That was the whole point of choosing cloud services as symbols in the first place — the jackpot teaches the shape of a real system as a side effect of chasing it.
Sitting next to the reels is a live risk gauge, and this is the part that surprises people who've never thought about what's actually required of a gambling product. Every spin gets checked against a set of behavioral rules — are you spinning faster than a person normally would, are your bets climbing after a loss, have you been at this for half an hour straight. On top of that rule-based layer, a machine learning model periodically reassesses your session and produces a risk score, and the gauge moves accordingly. Because there's no real money in this version, nothing actually stops you when the gauge goes red — but the mechanism is the same one a real operator would use to intervene, and building it taught me more about responsible gaming than any article could have.
The badge in the corner is the quantum tell. Most spins draw their randomness from a standard, well-trusted source. Some spins, when a separate service is healthy and responsive, draw it from an actual quantum circuit instead — the service my mentor built, seeding the randomness from Amazon Braket (AWS's managed quantum computing service). I integrated it into the game as an experiment in whether quantum-sourced entropy could serve a live spin without anyone noticing the difference except for the badge itself.
And the whole thing isn't limited to solo play. Event mode turns it into something you can run in a room: players join with a QR code, a shared leaderboard updates live on a projector, and a tournament structure lets you run timed competitive rounds rather than open-ended play. That mode is what made the game night possible in the first place.
(A full technical writeup — Lambda counts, RNG seeding mechanics, security layers, analytics pipeline — is in the appendix at the end of this post, for anyone who wants the implementation detail.)
What actually happened
I ran the first version at an office game night. Booked a room, put the leaderboard up on a screen, and let people join by scanning a QR code so nobody had to type anything to get in.
It landed better than I expected. A small crowd gathered around the screen — people watching the reels spin, waiting to see if the badge would light up, watching the leaderboard reshuffle as new players joined and started competing for the top spot. The room reacted to it the way a room reacts to an actual game, which told me the work had crossed some threshold from a personal exercise into something that functioned as a real product.
The tournament mode scaled past that first small room, too. I ran a later event with a full leaderboard projected for a much bigger group, timed rounds, and a proper prize structure at the end.
The game is still running today. Real production deployment, a real Cognito user pool, real DynamoDB tables that have held up under actual use. The player count is modest, but every one of them has a genuine account and a genuine leaderboard entry, and the system hasn't needed to be rebuilt to support any of it.
More importantly, for the reason I started, the learning stuck. I can reason about RNG design, responsible gaming obligations, session tracking, behavioral analytics, and tournament operations from having built each of those pieces myself, not from having read about them. When I'm in a conversation with someone who actually knows this industry, I understand what they mean.
And there was one more thing I noticed, standing at that first game night watching the reels spin — something that felt obvious the moment I saw it, but hadn't occurred to me at all before then.
What came next
Here's the realization, in one sentence: almost everything that made this a slot machine was infrastructure, and almost nothing that made it this slot machine was.
The thirty-four functions, the machine learning, the quantum RNG, the six layers of security, the analytics pipeline — months of work, and none of it specific to this particular game. What was specific to this game was small by comparison: a set of cloud icons that could have been any set of images, a handful of hex codes for the palette, win patterns in a database table, sound files in a folder.
Which raised an obvious question: if the infrastructure stayed exactly as it was and only the theme changed, could I produce an entirely different slot machine — wizards and wands instead of cloud icons, or iron thrones, or football clubs — without touching any of the hard parts again?
Doing that by hand would just be a customization service, not a factory, and it wouldn't have taught me anything new. The version I actually wanted to build was one where the variation itself was automatic — where I could describe a theme in a single sentence and have something else produce the specification, generate the artwork, patch the code, test the result, and deploy it, with no manual editing anywhere in the loop.
That project became game-factory: a pipeline of six agents — Designer, Image-Gen, Background-Gen, Builder, Tester, and Deployer — that takes a theme prompt and turns it into a themed clone of this casino, deployed to its own address. It works. Two themed variants are live as of this writing. Getting there took a lot of wrong turns, and those wrong turns turned out to be the more interesting story.
The next six posts in this series are about those wrong turns and the patterns that came out of fixing them. If you're building agents that modify code, generate assets, or check their own work, some of what I learned along the way should transfer directly.
Appendix: technical implementation
The section above stays at the level a player or a curious reader needs. This is the level an engineer would want.
Frontend. A React application, hosted on S3 behind CloudFront. Several distinct modes in the same codebase: solo play, tournament mode with a warmup phase and timed rounds, an "event" mode for hosting live sessions, an admin dashboard for credit resets and pattern approvals, and a big-screen leaderboard view for a projector. Fifty-plus AWS service icons make up the symbol pool. Three ways to win — two of a kind, three of a kind, or a valid AWS architecture across the reels for the jackpot — each with its own payout.
Backend. Thirty-four AWS Lambda functions written in Python, organized by responsibility: authentication (registration, login, verification, password recovery), game logic (spins, credit resets, leaderboard), machine learning (behavioral event tracking, risk score inference), events and tournaments (creation, joining, spinning within an event, ending a round), and admin (analytics, feedback, pattern approval). Amazon API Gateway sits in front of all of it, with a WAF web ACL applying OWASP rule sets (the industry-standard list of common web application vulnerabilities), IP reputation filtering, and rate limiting, plus its own throttling — 30 req/s sustained, 100 burst. Amazon Cognito (AWS's managed user identity service) handles identity, tokens, and password recovery. DynamoDB holds players, sessions, behavioral events, tournaments, event participants, icon metadata, and winning patterns, all as configurable data rather than anything hardcoded.
RNG design. In production, the spin function calls Python's secrets.randbelow, drawing from the OS's cryptographically secure entropy pool — sufficient for a real product. A second path exists for experimentation, running the quantum service my mentor built. That service runs on ECS Fargate in Rust, and on startup submits 32-qubit circuits to Amazon Braket, using either the SV1 simulator or IonQ hardware when it's available. Each qubit gets a Hadamard gate and then a measurement, and each measurement collapses into a zero or a one — genuine quantum randomness. Those bits seed a ChaCha20 stream cipher (a fast, well-vetted algorithm for expanding a small amount of true randomness into a much larger stream of it) that fills a 100MB entropy pool, enough for roughly 12.5M spins, with a background monitor topping it off whenever it drops below 20%. The spin function calls this service with a 500ms timeout and falls back transparently to the standard path if anything is slow or unhealthy. A field in the response, entropySource, tells the frontend which path served the spin — that's what lights up the quantum badge.
Responsible gaming. Two layers running side by side. Rule-based, on every spin: evaluates against six patterns — spins under 6s apart, bets spiking above 5x the running average, 3x bet increases immediately after a loss, credits dropping below 10, sessions past 30 minutes, and long streaks of rapid consecutive spins. Any of those firing writes an event to a behavioral table in DynamoDB. Model-based, every 10 spins: a function pulls the last 30 days of a player's session data, computes 26 behavioral features across three groups — temporal (session duration, frequency), financial (bet sizing, credit depletion), and behavioral (impulsivity, loss-chasing) — and sends them to an XGBoost model (a widely used, tree-based machine learning algorithm) hosted on Amazon SageMaker (AWS's managed machine learning platform), which returns a risk score from zero to a hundred driving the live gauge, with four levels from low to critical. There's no real money in the system, so the gauge is a demonstration rather than an intervention — in a real product, high or critical scores would trigger deposit limits or a referral to support.
Security. A defense-in-depth model across six layers, arranged so that if one fails, the next one is still standing. Edge: CloudFront and a WAF handling OWASP rules, IP reputation, and HTTPS enforcement, backed by AWS Shield Standard. Network: API Gateway throttling and CORS restricted to the production domain. Identity: Cognito verifying JWTs (signed tokens used to prove a logged-in user's identity on every request) against its JWKS endpoint, brute-force lockout, short-lived access tokens. Application: every credit and win calculation runs server-side, admin endpoints check the caller's JWT against an allowlist, players can only ever read their own data. Data: encryption at rest, per-function IAM roles scoped to exactly the tables each one needs, public access blocked on every S3 bucket. Detection: CloudWatch alarms, X-Ray tracing on every Lambda, CloudFront access logs flowing into S3. None of it arrived at once — each layer got added as the domain's actual threat model became clearer.
Analytics. The behavioral events table is the source of truth. Every night at 2AM UTC, a scheduled export job scans the table and writes the day's events into S3 as Parquet, where Athena queries it with SQL and QuickSight turns it into dashboards — player behavior over time, risk score distributions, tournament participation, session duration trends.
Tournament operations. Before a live event, a warmup script provisions 10 instances of Lambda concurrency on the event-spin function so cold starts don't interrupt play, then tears the concurrency down afterward so the cost disappears with it.
Next: What is an agent, actually?
Also useful: Agent scoping — the cheat sheet
Top comments (0)