BB’s Feast: Reflections on Building a Game With A Hallucination-Prone Genius Named Claude

BB’s Feast launched this week, now available on iOS and Android, and I thought it would be a good opportunity to write down some reflections on the process. This whole thing was a bit of a whirlwind. What started as an avenue for exploring creation with AI, turned into one of the most fun and satisfying (and large!) solo projects I have undertaken. I learned a ton about working with AI, managing a software project, sound design, sprite animation, marketing and media outreach, and on and on. With all of that in mind, I would like to walk through some of the lessons and learnings that I had during these past months.

1. I Love to Design

This one isn’t terribly novel, as I have been, and have generally enjoyed, being a designer for 15 years or so. However, it has been a long time since I have been involved in a project that has really forced me to flex my existing creative muscle (UX, visual design, interaction design, etc.) while also really building a raft of new skills (sound design, sprite animation, game design, music editing, etc.). It felt really good to get thrown into the murky and turbulent waters of being truly bad at these new skills and having to just push through and solve design problems because they needed to be done.

Nowhere was this more true than the creation of the BB character. Getting the look and feel of BB right was both a total necessity for making the game engaging (she is the star, after all), but I also felt a personal need to do it right for my beloved little dog that she was named after. I wanted the character to look and feel right, and have some of the quirkiness of the real thing. This was a scary proposition. I had zero experience working with pixel art or animation, so I was wading into the unknown with some nagging doubts that I would be capable of doing it. I put it off as long as I could, but after most everything else about game dynamics, player experience, physics, and other visual elements (environment, food, etc.) had been figured out, I was forced to finally do it. The game art and design community helped a ton. There are a ton of asset packs to start with (BB’s DNA began with this pack), tutorials, and affordable but powerful tools that gave me the confidence and skills I needed to create what I set out to.

I was able to use existing dog sprites to help speed up animating the action, but that largely helped with complex movement like tail wags and, to some extent, the running. However, I needed to make some major changes to account for BB’s peculiar and singular self: her short-legged body shape, shaggy coat, goofy lolling tongue, and also create a flying state which, unsurprisingly, no premade dog packs thought to include. After a ton of iterations of fluffing up her fur, adjusting her adorable face, and upping the fun of her flying states, I feel like I have captured the spirit of BB and created a character that imbues the game with a bit of levity and joy.

2. Working With AI, Like Working With People, Requires Strong Communication

Throughout this process, I had to repeatedly learn my lesson to be extremely clear with what I was doing and why. LLMs are famous for their tendency to fill in details, even when you don’t want them to. From inventing legal precedent to bolster a case to hallucinating romantic relationships, AI is inclined to create something fully rather than investigating knowledge gaps. While AI tools can be obsequious to a fault (“no Claude, that wasn’t really that good of a question, just a normal one”), they aren’t particularly good at caring what you actually want. If you have a specific goal or vision in mind, it is incumbent upon you to write that out in as clear of language as you possibly can, or you are liable to get what the AI thinks is best, which isn’t always great.

An example of this was how Claude approached speed and the visual presentation of speed for BB’s Feast. I was somewhat loose when I was first defining how I expected physics to work, since, in my head that was pretty straightforward. The trainer supplies data, BB’s Feast would translate that to the game environment. This created issues when I was needing some of that data to do something unnatural like using power to dictate BB’s altitude. As I began to define the flying behavior and working out how that might work, Claude really ran with the idea of crafting a robust physics engine to manage power interpretation. In the midst of what seemed to me a pretty discrete request (“user power to define y-axis”), I got a physics engine that scrapped the perfectly fine speed data from the trainer, and replaced it with its own version that defined speed based on power, fake wind, and a few layers of smoothing. The end result was forward motion that felt really unnatural and jittery.

It took me a long time to work out why it felt so broken, and when I finally did, I couldn’t believe how much extra complexity had been layered into something so simple. If I was to do it all over again, I would have done a couple of things differently to get to my desired result. First, I would have been much clearer that I was focusing purely on power as it relates to vertical height and work through the options of how to make that work in isolation of other movement. Second, I would have (and have since then did) add instructions to the project to try to find the simplest solutions first and then move on to more complex ones. In my second game, I was very explicit that we should try to use pure trainer data where possible, as that is the interface users are most familiar with, so the more my games differ from its input, the higher the likelihood that the game will feel unnatural to them.

3. Keep Thinking and Doing Separate

I started working on this project in the early days of Claude Code, prior to it having any sort of thinking mode. It took me about one time of trying to explain a task to Claude Code to realize that without the context of my specific project, Claude Code was wholly incapable of coming to the correct conclusion except by accident.

After a few botched attempts at running straight to doing, I revised how I worked to use the power of Claude Projects as my thinking space, and then using Claude Code for doing. What this looked like in practice was that I used my Project as the contextual center of my work. It was within the project that I had the full requirements, a history of the evolution of the game, and all the details related to intent. This allowed me to work through ideas and changes with a more invested and knowledgeable “peer” so I would be able to really crystallize my intentions before executing on them. Once I had really hashed out an idea within Claude, I would have it write me a prompt, or series of prompts if it was a large change, that I could use in Claude Code to actually implement.

With the prompts in hand, Claude Code was able to make really large and meaningful changes within minutes, and since they were developed with clear understanding of the context they almost always matched my intent. I could then work within Claude Code to fine tune the experience by prompting visual changes, bug fixes, or error interpretation, which leaned heavily on Claude Code’s superpowers of understanding the software context and being able to make changes there without necessarily needing to understand the weeks of planning and ideation that existed within the Project.

4. If You Think You Can “Vibe” Without Thinking, GTFO

While creating an app or website is much, much, easier than it used to be thanks to modern AI tools, the idea that anything of value will come out of mindlessly feeling your way to a solution is horseshit. You still need a clear vision, an understanding of how software development should work, the ability to think critically and creatively in problem solving, and a willingness to babysit a sometimes hallucinating genius collaborator to be able to pull off anything beyond the simplest projects.

Had I trusted Claude alone to create my game, it would have been a mess. Areas that would have been completely botched had I let Claude go it alone: a QA mode to allow me to test without connecting a bike, a loading screen when opening the app, any element of gameplay that requires human senses (hint, it was a lot), a points system that wasn’t in decimals, and most of the details that make games fun including leaderboards, bonus point systems, and good but not overwhelming audio or visual stimulus (Claude layered sound, food, and obstacles heavily!).

All in all, I learned a ton through this process and feel like I grew as a creator, all while having a great time and creating something totally novel that I enjoy and think others will too. And it really feels like I am merely at the beginning, since I have had so much fun that I don’t think I can stop at just a couple of games. There is something deeply satisfying about the world building of game design that I really enjoy. I look forward to sharing the rest of this journey here as game 2 and beyond come together!