Pastabos

One thing I’ve learned from previous software projects is that complexity rarely comes from the big ideas. It usually comes from the tiny details you didn’t think about at the beginning. Those details have a nasty habit of quietly spreading into completely unrelated parts of the project until, one day, you realise you’re no longer changing a feature. You’re changing the architecture.

That’s one of the reasons I spend so much time writing before I start building. Not because I enjoy documentation for its own sake, but because I enjoy discovering expensive mistakes while they’re still free to fix.

Take something as shooting.

Most people imagine it as a fairly isolated mechanic. The player presses a button, a projectile appears, travels forward and deals damage. That’s a perfectly reasonable starting point.

Then the questions begin.

Can different weapons shoot differently?

Can projectiles penetrate walls?

Can walls be destroyed?

Can they cause explosions?

Can enemies shoot through cover?

Can bullets leave visible damage?

Every answer quietly pulls another thread.

At first you’re improving a shooting mechanic. Half an hour later you’re redesigning your environment system.

That actually happened to me.

Originally I imagined a pixel-art world. It sounded simpler, faster and much more achievable for a solo developer. Then I started thinking about penetrable walls and believable destruction. The more I analysed the problem, the more I realised I wasn’t fighting the shooting mechanic anymore. I was fighting the limitations of the representation itself.

Could I fake it?

Probably.

Games fake things all the time.

The real question became different.

How many other systems would also need to be faked?

Eventually I realised that moving to a 3D top-down world would actually make several future systems easier instead of harder. Not because 3D is simpler—it certainly isn’t—but because the world itself naturally supports interactions that I would otherwise spend weeks trying to imitate.

That single decision had nothing to do with graphics.

It had everything to do with architecture.

This is exactly why I keep decomposing ideas before writing code.

Whenever I describe a mechanic, I don’t stop at the mechanic itself. I keep asking what it depends on, what depends on it, what assumptions it makes and what happens if those assumptions change. I keep breaking the problem into smaller and smaller pieces until I can’t meaningfully split it any further.

This is also where AI fits into my workflow.

Not because it thinks for me.

I’ve been working this way for years. AI simply makes the decomposition process faster. I can describe a system in plain English, ask it to identify missing pieces, challenge my assumptions and keep digging until the architecture makes sense. Only then do I start thinking about implementation.

I saw exactly the same thing while building business software. One of the larger Python projects I worked on eventually grew to roughly 20k lines of code. One script alone exceeded 5k lines. I didn’t know Python when I started. I knew programming concepts, automation and systems architecture, but Python itself was completely new to me. Yet the project remained surprisingly manageable because the architecture was documented first. AI wasn’t guessing how the system should work. It already knew the project’s rules, the surrounding software and the constraints it had to respect.

Maybe game development is totally wrong environment for it? I have no idea, but i know, that solid understanding of systems transfers surprisingly well between technologies when you have the right documentation and tools.

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.

The more I work on this project, the more I realise that I’m probably approaching it differently than I imagined I would. Whether that’s a good thing or a terrible mistake, I honestly don’t know yet. Maybe in two years I’ll look back at this post and laugh at how naïve I was. For now, though, this is the way my brain naturally keeps solving problems.

Whenever I think about adding something to the game, my first instinct isn’t to ask, „How many of these do I need?” It’s usually, „Can I build a system that creates them instead?”

That doesn’t mean procedural generation is automatically the answer to everything. Quite the opposite. I’ve already discovered plenty of situations where handcrafted content is simply better. What I’m chasing is something slightly different. If I find myself creating the same thing over and over again, I instinctively start wondering whether I’m solving the wrong problem.

Take enemies as an example. My first reaction isn’t, „I need a hundred different creatures.” It’s more like, „Could five or ten interesting creatures become a hundred through variation?” Maybe appearance changes. Maybe behaviour changes. Maybe the environment changes them. I don’t know yet. I’m simply more interested in designing the machine that creates variety than manually producing every variation myself.

Maps lead me to exactly the same line of thinking. I don’t really dream about making hundreds of unique locations by hand. Instead, I keep asking what makes a map feel believable. Is it the roads? The objectives? The way players naturally move through it? If I can answer those questions, perhaps the map becomes the result of a set of rules rather than a collection of manually placed objects. Whether I’ll actually manage to build that system is another story entirely.

The same thought process appears almost everywhere else. Instead of asking how many skills the game should have, I find myself wondering whether a smaller set of mechanics could interact in enough interesting ways to create meaningful choices. Instead of designing endless variations of equipment, maybe the interesting part lies in how equipment pieces combine with one another. Instead of creating dozens of unrelated events, perhaps a handful of systems interacting naturally will produce situations I could never script myself.

I suppose this way of thinking comes from my day job. Most of my professional life revolves around business systems, automation and process design. Quite often, solving a problem once isn’t the real objective. The real objective is understanding why the problem keeps appearing and whether a better process could prevent it entirely. I’m beginning to notice that I approach game development in much the same way.

Of course, there is a danger here. It’s very easy to become obsessed with building systems instead of actually building a game. I catch myself doing that more often than I’d like. Sometimes the elegant solution is simply making one really good enemy or one really memorable level. Not everything needs another layer of abstraction, and I have to remind myself of that constantly.

Still, I can’t ignore how satisfying it feels when one system unexpectedly improves three others. Those moments have become my favourite part of the project. A small idea suddenly solves several unrelated problems, and the whole design feels a little cleaner than it did the day before.

Maybe that’s completely the wrong approach for solo game development. Most experienced developers would probably tell me to stop overengineering everything and just start making content. They’re probably right.

But this project has never really been about proving that I know the correct way to make games. Quite the opposite. It’s an experiment. I’m trying to discover whether a game built around interconnected systems can feel richer than one built around sheer quantity.

Maybe I’ll fail spectacularly. Maybe I’ll discover that some things simply have to be handcrafted.

Right now, I genuinely don’t know. And, strangely enough, that’s probably the part I’m enjoying the most.