Part 1: Building an RTS in Godot. What if Claude writes ALL code?

I challenged myself to build a game in Godot. I have a web-dev background but very little experience with Game Dev. I watched some tutorials, built tiny projects, but never finished a game to share it.

This is about to change. I'm creating a pixel art clone of the lesser-known Real Time Strategy game "Gangland". It wasn't well received by critics (after watching the trailer I understand why), but as a kid I really enjoyed this pixel mush. There was something captivating about curating your crew of mafiosi to take over the neighborhood with tommy guns and persuasion. I've deliberately decided to start by copying a game to avoid getting stuck in overthinking.

You know what else is exciting? Seeing your own ideas come to life in your own creation. But it takes time and frustration to do that. If you have a full-time job and other responsibilities, you need to find the time and energy to do that. And even then, there are hundreds of distractions that can keep you from working on ambitious projects. Then there is also the mighty force of "fear of failure" (disguised as "perfectionism") that keeps me from building something like this.

But what if we could avoid some of that time suck and frustration by handing it over to our good friend Claude? Then I could see my own ideas and past impressions come to life, even with my limited time.

Introducing my experiment: "What if Claude writes ALL code?" This means:

1. I use Claude Code for everything I’d typically write down by hand

I reach for this extreme measure because I hope I will find some exciting truths if I lean all the way into this direction.

The only exceptions are some game-design related markdown files. Claude needs a ground truth to work with and I can't risk the truth changing behind my back. So the game's rules and ideas are handwritten.

2. The brain rot is part of the experience

The experiment aims to find out if building the game solely with AI is possible and to learn another workflow on the side.

• Will my brain rot or will I shift my skills from coding to thinking deeply about the game’s fun aspects?
• Will solely working with agents exhaust or energize me?
• How does context switching affect me?
• How will I handle situations where Claude can't figure out the solution? What are the options?
• Will Claude drift into spaghetti Code?
• Will I learn anything about Game Development through osmosis or
• How do I adjust my workflow for this new meta?

Preliminary Results

I'm roughly 8 hours into the project and I've already made some interesting discoveries about building with my fingers glued to the Claude console.

The Importance of Clear Context

LLMs are great at whipping out "something" that resembles your request. But whether the result matches my expectation or not seems to largely depend on how precise I phrase my request. Not a huge surprise here. But nevertheless, I see myself writing short unspecific prompts all the time. Sometimes because I'm lazy, but mostly because I assume Claude can get the rest from the surrounding files and subtext.

But when I have a specific solution in mind, I need to communicate it precisely. That's where manual context provision comes into play.

I've created a folder where I document the entire game idea in markdown files. This serves as a ground truth for Claude, so I don't have to repeat myself all the time, but also to keep the game coherent for both the AI and me.

This approach has already paid off. When I first started building the game, the context contained conflicting information about how the character can move. Because of this, Claudes first character controller implementation didn't allow the main character to move around freely on the map. But because I've documented the intended behavior in my markdown files, I could easily resolve this misconception by pointing Claude at the right files and rephrasing things slightly.

Claude Code also draws context from adjacent code files in your project. But if your code doesn’t accurately represent your vision, Claude may draw wrong conclusions. The markdown files help to resolve those ambiguities.

I'm not yet sure if it's a good idea to separate the markdown files into multiple files, but time will tell.

Pushing the limits of Claude Code

My main issue with the current approach is that I’m using Claude Code reactively. I request a neatly defined feature and Claude delivers a usable result in under 5 minutes. This fast feedback loop is great for getting a feel for the tool because, but it leaves me in an awkward position where working on anything else wouldn’t make sense because Claude could be done any second. I’m treating Claude like a quick-response coding assistant, but it could tackle larger, more complex tasks that take real time to complete.

We’ll explore Claude Code’s limits in the next part of this series!

I'll keep you updated on what I'm learning about the process of developing a game without manually typing any code. And as a bonus, you'll see how a crappy prototype turns into a (hopefully) fun game!