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.