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!
Top comments (6)
I have been thinking about the best game enginge for LLMs, how do you feel Godot works in this scenario? Can you do all through code? Great idea about the game logic in their own files just for LLM.
What I love about Godot, is that almost all changes made through UI are reflected in some configuration file that can be tracked through version control. This makes is a) easy to track "oh I accidentally turned on feature xyz", and b) allows LLM's to keep track of those changes as well.
I wrote a small post a while ago where I benefitted from those human readable config files. idkshite.com/posts/collision-shape...
I have to say that my experience with other game engines is quite limited, but at least with unity I didn't have that level of transparency.
Either I didn't see those configuration files back then, or they were not as straightforward to read as the godot ones.
To answer your question. I don't remember anymore how often I needed to make use of the UI, because Godot couldn't make the change through the MCP or the config files. But I would argue that its a great candidate for LLM use because the super transparent (human readable) config files. :)
Interesting! I have mainly been looking at Love2d (Lua) and libGDX (Java) for LLM-powered game dev since they are 100% code and fairly mature so they are probably already in most LLMs training data (faster answers, less tokens etc.). But will for sure try with Godot as well :)
I also noticed there is already unofficial MCP for Godot such as:
github.com/Coding-Solo/godot-mcp
Thoroughly enjoyed reading about your experiment :)
I came across your post whilst doing something very similar myself, except I've been using VSCode + GitHub Copilot + Claude, and I'm thinking of trying out Claude Code and seeing how it goes in comparison.
I'm trying to make a game that's a bit like the TV show Alone - where you have to last as long as you can in the wilderness.
With my setup so far, I've found that making the systems for my game (day-night cycle, fog of war, inventory, etc) has been rapid to develop, and the creation of the scripts is pretty good. But it often favours something complex in a script, when there could be a simpler solution using scenes.
I'm looking forward to following your progress to see where you end up.
Good luck!
I'm really curious if relying on AI for all code lets you focus more on the fun, creative parts of game design long term. Did you notice any big shift in how much you think about gameplay versus technical details yet?