Why am I thinking about umbrellas in Harajuku?
TL;DR: I’m making a game, as a side project, with Claude Code. It’s called Takeshita Rainstorm and it’s about umbrellas, overtourism, and capybara rights. You can play the prototype here (requires a keyboard for now). I plan to blog about it as and when I have time.
“Takeshita Street” by Dick Thomas Johnson, via Wikimedia Commons, CC BY 2.0 (creativecommons.org/licenses/by/2.0)
Takeshita Street in Harajuku, Tokyo, is an intense experience. The original hub of the kawaii fashion scene, these days it's a tourist trap of Lolita fashion touts, animal cafes, and tornado potatoes.
I'm not the Lolita-dressing type (you'll be relieved to hear). But my partner and I have a taste for more restrained Japanese streetwear. On our recent holiday (long overdue) to Japan we'd been looking forward to hitting Harajuku for some serious clothes shopping. And on the day we had planned for that, Tropical Storm Chan-hom made landfall in eastern Japan.
Our shopping trip involved a few missions down Takeshita Street, en route to other places. It's narrow, and crowded, and in a rainstorm many people have umbrellas. (We and our son were brandishing three tweely identical granny brollies ourselves, panic-bought from the nearest Lawson konbini, much to the amusement of the designer clothes store assistants).
Back home, with Lawson granny umbrella and some of my Japan trip shopping haul. Vintage Enföld skirt from RAGTAG (actually the Sapporo branch), top by Base Calm, trainers MOISTHROUGH360.
Getting down a busy street in the rain turned out to be a scramble to do two things at once: dodging through the gaps between people, while raising or dropping our own umbrellas to get them past everyone else's.
With all the other bonkersness around us, it felt somehow like a game. Something in the spirit of Crossy Road, maybe. With a bit of House of the Dead (bedraggled people looming suddenly at us out of the rain). My son and I laughed about it, but it stuck with me. I wrote the concept down, cobbled a few other ideas around it (costumes, crepes, thoughts on overtourism and the animal welfare of capybaras), and then sat on it for a bit.
A few weeks later I started building this as a web based game with Claude Code. The working title is 'Takeshita Rainstorm'. (Claude solemnly advised me to avoid anything involving the word 'Harajuku', lest I upset Gwen Stefani's lawyers. My robot friend is taking my silly side project very seriously, for which I am grateful, and I do not want to let it down. You can psychoanalyse me later).
Anyway, I've decided to write about it as I go. I have no fundamental point to make here, no pretence of any new insights about AI. Nor do I pretend to have discovered some NEW CLAUDE CODE TRICK YOU MUST ADOPT IN THE NEXT 2 NANOSECONDS OR BE FOREVER UNEMPLOYABLE (though I am not immune to the anxiety). I'm just documenting my process and seeing what comes of it. Obviously Claude is helping with that as well (life is short), but we are a writing team.
Why make it
3 reasons. Ha! Perhaps I've spent too much time with Claude ;)
I had an idea and wanted to see whether I could make something of it, for once, because it's now possible to do so.
Everyone and their dog is building something with AI now, and of course I wanted to have a go too. But I wanted to do it with a degree of rigour. I've long worked in tech but I'm not an engineer myself, and I wanted to learn something about how the process of modern agentic software engineering works.
This one only emerged once I'd started: it's an experiment in using AI to learn about something a long way outside anything I know. I have never made a game. I'm utterly rubbish at playing most of them. But I'm learning how games get made, from Claude, and it's pretty cool. Or as Claude would have it, "genuinely fascinating" ;)
This isn't vibe coding
Vibe coding means describing what you want, accepting whatever comes back, and prompting again until it looks right. That's fine for something you'll throw away, but I wanted to take this semi-seriously and see where it went.
Claude writes all the code here, of course. But nothing gets built until I've read and approved a written design, and every design decision is ultimately mine. Claude lays out each decision with a recommendation, which usually seems sensible, though sometimes I know something it doesn't. We're working in a series of prototypes, each one testing a clear hypothesis with a clear definition of what success looks like.
How it's set up
I'm using Claude Code with a free plugin called superpowers, on Simon Frost's recommendation. Superpowers makes Claude follow a disciplined engineering process instead of diving straight into code. Each piece of work goes through the same steps:
Brainstorm. Claude asks me questions one at a time, each with options and a recommendation. I answer, push back, and decide.
Spec. The outcome is written up as a design document, which I read and approve.
Plan. The spec becomes a list of small steps, each one starting with a test.
Build. Claude builds it unattended, then a second, fresh Claude reviews the work with no memory of having built it.
Play. I play it, other people play it, and we decide what to do next. Claude writes playtesting scripts that guide what playtesters do and capture structured feedback.
We embellished this process with a few things of our own. The project keeps its own memory as plain files: a task list, a numbered log of every decision, and a record of the work. All this, plus the code, is in a private repo in GitHub. I pick this up in bursts, sometimes weeks apart, so every session opens with a short list of what's waiting for me.
I also asked Claude whether game development has a process of its own. It does, and Claude has been walking me through it as we go.
Claude and I have a clear division of labour. Anything that needs a password, an account or a design call is mine. Claude gets on with the rest. Sometimes I feel a bit like a toddler in the back seat of a car with a toy steering wheel, but ultimately I get to decide which direction we go in.
Lo-fi first
One thing that surprised me is how familiar some of the game design process felt. I used to be a UX designer, in the ancient days when we wireframed everything first (and product managers hadn't yet tried to eat designers' concept development lunch). This is not a million miles from that.
The game today is grey boxes walking down a grey street under flat discs. It is ugly on purpose. It's a prototype to test one hypothesis: is dodging with your feet and your umbrella at the same time readable and fun? Until real people have played it and we know the answer, there's no point drawing even a single raindrop.
That is a wireframe prototype by another name. These days, AI makes it so easy for UI designers to jump straight to a polished interface. Old hands like me moan about teams skipping the stage where you find out whether the core idea actually works, before you put lipstick on the proverbial pig. Seeing Claude recommend this, I feel like the way I still think about design is not irrelevant after all. High fidelity might cost far less than it used to, but there's still value in stripping out detail that can distract users from responding to your underlying concept.
Grey box prototype, focused on honing the difficulty curve
Where it is
There is a playable prototype here in the browser (the controls are keyboard only right now so it won’t work on a phone): https://takeshita-rainstorm.pages.dev. Two rounds of playtesters have tried it, and I now know several things that are wrong with it, which is what a prototype is for. Much of the recent work has been honing the difficulty curve. It's been too steep, and then too shallow, but we're working on it. By the time you read this it might have moved on. If you'd like to be one of my playtesters (it's about a 15 minute commitment, occasionally) then drop me a message (LinkedIn better than emails to this site).
There's far more to say than fits in one post. I make no commitment to regular blogging, but things I might write about next time: what Claude did before it wrote any code, iterative prototyping and playtesting, and what it's like to be the least qualified entity on your own project.