One thing became obvious very early in this project: if I tried building everything manually, I’d never finish. That’s not pessimism; it’s simple math. I’m one person with a full-time job, a family and a healthy collection of hobbies that I don’t intend to abandon just because I decided making a game sounded like a good idea.
That means I have to be realistic. I don’t have the luxury of brute-forcing problems. If a task normally takes a team of people, my first question isn’t, „How do I work harder?” It’s, „Is there a better tool?” Maybe that’s my systems background showing again, but I genuinely believe the right workflow is often more valuable than working twice as long.
The first decision was the game engine. Godot was an easy choice. It’s open-source, lightweight, easy to understand, has an incredibly welcoming community and, perhaps most importantly, it doesn’t feel like I’m fighting the engine every time I want to experiment. Could Unreal produce prettier graphics? Absolutely. Could Unity offer a bigger ecosystem? Probably. But this project isn’t trying to compete with AAA games. My goal is to finish something, not spend six months learning features I’ll never use.
The same mindset applies to programming. I’m not pretending to be a professional game programmer. I’ve written plenty of automation, business software and low-code systems, but gameplay programming is a different discipline. Instead of treating AI as something that magically writes code, I’m trying to build a workflow around it. Right now I’m experimenting with Claude, Git, Godot and a few other tools to see whether they can become part of the development process rather than isolated assistants. I don’t expect AI to replace understanding. Quite the opposite. I’m trying to make understanding happen faster.
The biggest surprise so far has been 3D asset creation. I honestly expected this to become the biggest bottleneck. Instead, AI tools have completely changed my expectations. A few years ago, the idea of generating a usable 3D character from a concept image sounded like science fiction. Today I can generate a concept, turn it into a rough model, rig it and have something standing inside a game engine within a relatively short amount of time. Is it production-ready? Not always. Is it perfect? Definitely not. Is it good enough for a solo developer building prototypes and gradually improving them? Surprisingly… yes.
That’s probably becoming my favourite phrase throughout this project.
I don’t need the world’s greatest character model. I need something convincing enough that I can continue building gameplay. I don’t need Hollywood-quality animations if they communicate what the player needs to understand. Perfection is expensive. Progress isn’t.
When I’m trying to solve a programming problem, I almost never ask the AI to write code immediately. Instead, I spend most of my time describing the problem itself. Sometimes those prompts become absurdly long. Several pages. Detail by detail – everything explained from A to Z in various layers and levels. Not because I’m trying to impress the AI, but because I’m trying to organise my own thoughts.
A typical conversation looks nothing like, „Write me a shooting system.”
Instead, it starts with questions.
What does a shooting system actually need?
Which parts should know about ammunition?
Who decides whether a shot is valid?
What information belongs to the weapon and what belongs to the player?
Which parts might be reused elsewhere?
Only after I understand those relationships do I ask the AI to describe the architecture. Then I rewrite it in my own words. Then I remove half of it. Then I adapt it to the rest of the project. Only after that does code become relevant and usually works from the 1st go.
One thing to mention is the context. The more Context AI knows, the better it works, that’s why Godot -> Git -> Claude connection is important.
Maybe there’s a proper name for this process. The closest thing I can think of is reverse engineering/verbal programming??? xD. I’m not asking AI to think instead of me. I’m asking it to expose the structure of a problem until I understand it well enough to make my own decisions.
Will this workflow survive an entire game project? I honestly have no idea.