AI Game Design Tool — baki.io

AI Game Design Tool

Domain
games
Date

I’ve been playing games for years. The Fractal Game - a procedural audio experiment where every system connects to every other system through an interconnected health model. The IDLE Game - base building with offline progression and resource loops that compound while you sleep. In both cases, the hardest problem was never implementation. It was playtesting inside my own head.

Then I started having design conversations with LLMs, and something shifted.

The messy process

Here’s what game design with AI actually looks like. It’s not “generate a game for me.” It’s closer to rubber-ducking with a partner who has read every GDC talk but has never actually played a game.

For the Fractal Game, I was stuck on the health system. I wanted interconnected subsystems - audio health, visual health, structural health - where damage to one cascades through the others. But the balance was impossible to intuit. I’d sketch a dependency graph, stare at it, and have no idea if it would feel right in practice.

So I described the system to Claude and asked: “If a player takes 30% audio damage and 15% structural damage simultaneously, walk me through what happens over the next ten seconds.” The response wasn’t correct - it couldn’t be, without running the actual simulation. But it surfaced edge cases I hadn’t considered. What if the cascade creates a feedback loop? What if recovery in one system blocks recovery in another?

Warning

AI design conversations generate hypotheses, not answers. Every interesting suggestion needs to be tested against actual player behavior. The model hasn’t played your game. You have.

Simulating players you haven’t met

This is where my UX research background collides with game design in a useful way. In research, we talk about the gap between what users say they want and what they actually do. In game design, the gap is between what the designer intends and what the player experiences.

LLMs can approximate player archetypes. Not perfectly - but well enough to stress-test assumptions. For the IDLE Game, I asked models to roleplay as different player types: the optimizer who min-maxes every resource, the explorer who ignores efficiency, the hoarder who never spends. Each “player” surfaced different failure modes in the progression curve.

The optimizer found an exploit in the offline calculation I’d missed. The explorer revealed that my tutorial locked out an entire branch of content. The hoarder showed me that resource caps felt punitive rather than strategic.

None of these insights replaced actual playtesting. But they compressed weeks of blind iteration into hours of directed conversation.

Procedural generation as philosophy

There’s a deeper connection here that I keep returning to. Procedural generation in games isn’t just a technical choice - it’s a philosophical stance. It says: the designer creates the rules, not the content. The content emerges. That’s uncomfortably close to how I think about life in general.

When I use AI in game design, I’m doing procedural generation of the design process itself. I set up the constraints - the mechanics, the feel I’m going for, the player experience I want - and let the conversation generate possibilities I wouldn’t have reached alone.

Tip

The best AI-assisted design sessions start with constraints, not blank canvases. “Design me a game” produces nothing. “This resource loop feels punishing after hour three - why?” produces insight.

The tool doesn’t replace the designer. It makes the design space navigable. And navigating possibility space is, when you strip away the jargon, what game design has always been about.