We Built a Browser Game Using AI — Here’s What We Learned

It started, like many things at Aleph Creative, with a half-serious idea that turned into a proper project. A couple of days ago we were playing around on Fable. The thing that immediately struck us was the sheer ambition of what people were attempting on it. Users were trying to clone Call of Duty. They were building Skyrim-style open worlds. Entire RPGs with branching dialogue, first-person shooters with complex mechanics, all from prompts. The creativity on display was genuinely impressive, even if most of the outputs were rough around the edges.

We decided we wanted in. But rather than chase what everyone else was doing because honestly, the world didn’t need another half-baked CoD clone, we thought about what kind of game would actually be fun to play casually in a browser. Something light, colourful, competitive, and immediately understandable. That’s how we landed on a water fight game. Simple premise, clear objective, and the kind of nostalgia that cuts across age groups. Everyone has had a water balloon fight or been soaked with a garden hose at some point in their life.

Then Fable got banned.

We’re not going to pretend that wasn’t frustrating, because it was. We were mid-process, had a rough concept taking shape, and suddenly the model was gone. However, these things happen and the honest truth is that it pushed us toward something better. We turned to Claude Opus 4.8, Anthropic’s most capable model, and rebuilt the entire project from scratch.

From Wireframe to Playable Game

The first thing we did with Opus 4.8 was establish a wireframe. Before writing a single line of game logic, we wanted to map out the structure, what are the core mechanics, how does a round work, what options does a player have, what does the UI actually need to communicate. This sounds obvious but it’s a step that’s easy to skip when you’re working with generative AI, because the temptation is always to just prompt your way into something that looks finished. In practice, that approach produces games that feel hollow. The wireframe gave us something to stress-test before we committed to any implementation.

From there, we went through multiple iterations. This is not an exaggeration, the version you’re playing today looks almost nothing like what we had after the first two or three rounds of development. Early builds had the right bones but lacked feel. The water mechanics were there but the gameplay loop wasn’t satisfying. The difficulty balance was off. The visual feedback, splash effects, hit indicators, score counters needed work before the game felt like a game rather than a technical demonstration.

Beta Testing Changed Everything

The real turning point was putting early builds in front of actual users. We shared rough versions with our team and sat back to watch what happened. The feedback was immediate and specific, users wanted more power-ups, they wanted the gameplay to escalate rather than stay flat, they wanted a reason to keep playing beyond the first minute. Some of the suggestions we’d already thought about but hadn’t yet implemented. Others we genuinely hadn’t considered.

Each round of feedback went back into a new prompt cycle with Opus 4.8. We’d describe what wasn’t working, share what users had said, and iterate on the output. This back-and-forth between real user testing and AI-assisted development is, in our view, the most underrated part of building something like this. The AI can generate mechanics quickly. What it can’t tell you is whether those mechanics are actually fun. That still requires humans.

The Multiplayer Problem

Here’s the honest limitation we ran into, what we actually wanted to build was an online multiplayer game. A real-time water fight where you’re competing against another person rather than the game’s AI that’s the version that would be genuinely compelling at scale.

The problem is that online multiplayer requires server infrastructure. Real-time game state synchronisation, latency management, user authentication. It’s a meaningful engineering and cost commitment, and for a new experiment it’s not something we’re ready to absorb yet. So what you have in front of you is essentially our public beta. A fully playable, polished single-player experience that lets us test the concept, gauge the response, and understand whether the appetite is there before we make a bigger investment.

Think of it less as a finished product and more as a proof of concept with proper production value.

What We Want From You

We want to know what you think. Not in a vague, leave-a-comment way, we mean specifically. Does the game feel fun? Does it get boring too quickly, or does the difficulty curve hold your attention? What would make you come back and play it again? If the multiplayer version were available, would you actually use it?

The future of Hydro Blast Heroes and honestly of any games we build at Aleph, depends on whether there’s a real audience for this kind of thing. We think there is. But we’d rather know for certain before we start spinning up servers.

Play the game, form an opinion, and let us know.