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.