Skip to content
Index

Games 2026

Hue Hunt

One of my first projects built almost entirely with AI. It's a browser party game of colour and clues that you share with a link. I wrote the briefs and set the direction; the code got built hands-free. The story here is the process, and one early lesson about giving an agent the right context.

  • React
  • TypeScript
  • Vite
  • Tailwind
  • Supabase
  • Realtime
  • i18n
  • Grafana
  • Claude Code
Play it ↗ (opens in a new tab)
The Hue Hunt landing page in motion - the rainbow-shifting title above a slowly panning grid of pastel colour tiles, with Quick Play, Create Room, and Join with Code buttons.
fig.03 - The Hue Hunt landing page in motion - the rainbow-shifting title above a slowly panning grid of pastel colour tiles, with Quick Play, Create Room, and Join with Code buttons.

I saw Hues and Cues being played on YouTube. It looked fun, but it wasn’t worth the price on the box. What I noticed was that it would work well as an online party game: send a link, no setup, start in seconds. So I used it to learn.

I wanted to understand how to architect a multiplayer game. I enjoy board games, so I figured that knowledge would be worth having for a long time. It was. It’s the groundwork I used later to build GAFO.

Hue Hunt is a browser colour-guessing party game for small groups. One player gives a short clue for a colour. Everyone else places a guess on the board. The points come from how close the room gets. It runs in realtime, so everyone plays from their own screen, and it’s localised, so friends in other countries can play in their own language. It’s inspired by Hues and Cues. The name and the interface are my own.

This was my first properly hands-free app. I soon realized that I was stepping into a new age when I was able to build the framework of the game from my phone while I waited for my flight at the airport. I set the direction and the code got written for me.

Building with AI clicked for me almost right away. I was still trying out tools, and most of the work still happened in a chat window. This is where I settled into what I called four-hour sprints. I’d write a brief for exactly what I wanted, paste it into Claude Code at the start of a fresh session, and build against it until the tokens ran out.

The hardest lesson came mid-project. I found out Claude had never properly ingested the rules from the rulebook. It had missed a nuance of one rule. I spent over a day testing and fixing before the game played correctly again. It was early and it was painful. It taught me the value of setting up context. Do that first and the building is easy.

The bigger learning ran across all of these projects: understanding the role I actually play. When the code gets written for you, judgement, taste, and direction matter more, and you have to get good at them. I’m glad I’d read The Design of Everyday Things around then. It gave me the language for it. Making the game was fairly straightforward. The thinking around user flow, the small details that make a game easy to share, took the real effort. That’s what I hope you notice first.

Friends and family played it and had a good time. I also posted it on Reddit and watched people from all over the world give it a try. That was fun to see.