whythisgames.com

Autorius: rytiskaralius@gmail.com

  • A Tiny Decision Can Change an Entire Project

    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.

  • How I’m trying to cheat complexity

    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.

  • How ChatGPT Changed My Project

    I’ve been asked a few times whether AI is making this game for me. The short answer is no. If anything, AI made me throw away more ideas than it created. I don’t use ChatGPT to generate code, build levels or write complete stories. There are people doing that and, honestly, it’s impressive. That’s simply not how I use it.

    What I discovered over the last couple of weeks is that ChatGPT became something completely different. It became the person you call when you’ve been staring at the same problem for three hours and can’t tell anymore whether your idea is brilliant or completely stupid. Sometimes you just need someone to argue with. ChatGPT is surprisingly good at that because it never gets tired and never gets offended when you tell it that its idea makes no sense.

    The funny part is that I rarely ask it to invent something. Most conversations begin with me explaining an idea I already have. Then we start pulling on threads. „What if this happened?” „Why would that system exist?” „Wouldn’t this break that other mechanic?” Before I know it, we’re discussing something that wasn’t even part of the original problem. Quite often we end up deleting the initial idea completely because a much better solution appears somewhere in the middle of the conversation.

    Looking back, I don’t think ChatGPT has given me many original ideas. What it has done is force me to justify my own. That’s a much bigger contribution than I expected. It’s very easy to fall in love with your own concepts simply because you’ve spent hours thinking about them. Having something constantly asking „Why?” becomes surprisingly annoying… and surprisingly useful. If I can’t explain why a mechanic exists, maybe it shouldn’t exist. If a story element only sounds cool but doesn’t improve anything else, perhaps it’s not worth keeping.

    One thing I also noticed is that our discussions almost never stay in one category. I’d start talking about procedural maps and somehow we’d end up discussing the philosophy of an AI character. We’d move from enemy design to world-building, then back to gameplay, then suddenly realise we’d accidentally solved a progression problem without even trying. At first I thought we were constantly getting distracted. Now I think that’s actually how interconnected design works. Good ideas don’t stay in their own little boxes.

    Perhaps the biggest change wasn’t adding anything at all. It was changing how I evaluate ideas. A few months ago my thinking was mostly, „Wouldn’t this be cool?” Now it’s more like, „Does this make three other systems better?” If the answer is no, the idea is probably weaker than I originally thought. That single question has probably removed more content from the project than any design document ever could.

    I’m still not convinced this is the right way to develop a game. Maybe experienced game developers will read this and immediately point out ten mistakes I’m making. That’s perfectly fine. I’m not writing these posts because I’ve already succeeded. I’m writing them because I’m figuring things out as I go. If this project eventually becomes something worth playing, these blog posts will be an interesting record of how it happened. If it fails spectacularly, they’ll probably be an equally interesting record of why.

    One thing is certain, though. ChatGPT didn’t become my game designer. It became my sparring partner. It doesn’t build the game for me. It keeps punching holes in my ideas until either they collapse or become strong enough to survive. Strangely enough, I think that’s exactly what I needed.

  • Chasing Systems, Not Content

    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.

  • When Gameplay Started Writing the Story

    One thing surprised me more than anything else while working on this project.

    I always assumed that game development followed a fairly straightforward process. You either start with a story and build mechanics around it, or you build interesting mechanics first and then find a story that explains them.

    Apparently, my brain had other plans.

    The project didn’t begin with characters or a world. It began with systems. Lots of them. I kept writing down mechanics I genuinely enjoyed in other games and trying to understand why they worked. Some of those ideas stayed. Others were thrown away almost immediately. At the time, none of them had anything to do with each other.

    The interesting part came later.

    Once enough systems existed, they started asking uncomfortable questions:

    Why does this mechanic exist?

    Why would a player be doing this?

    Why would the world allow it?

    At first, I tried answering those questions with more mechanics. That only made things worse. Every new feature solved one problem while creating two more. Eventually I realized that what was missing wasn’t another system—it was context.

    That’s when something unexpected happened.

    Instead of inventing more gameplay, I started inventing reasons. Not because I wanted to write a story, but because every mechanic needed to belong somewhere. One explanation would suddenly make three different systems feel natural. Then another system would stop making sense, forcing me to rethink the original explanation.

    It became a strange feedback loop.

    A gameplay mechanic would inspire a piece of world-building.

    That world-building would expose weaknesses in another mechanic.

    Fixing that mechanic would improve the story.

    The improved story would suddenly make another feature feel obvious.

    I repeated this process so many times that I honestly stopped knowing which ideas came first. Some mechanics survived because the story needed them. Some story ideas survived because they solved gameplay problems I hadn’t even noticed before.

    The biggest lesson I learned is that isolated ideas are rarely interesting. Connections are.

    A single mechanic isn’t particularly exciting. A mechanic that explains another mechanic is. A story twist isn’t memorable because it’s surprising; it’s memorable because it suddenly makes previous events feel inevitable.

    I’ve found myself deleting ideas much more often than adding them. Not because they were bad, but because they didn’t connect to enough other parts of the project. Every system now has to justify its existence by making several other systems stronger. If it doesn’t, it probably doesn’t belong.

    It’s a surprisingly satisfying way to design something. Instead of asking, „What else can I add?” I now ask, „What does this improve?” Sometimes the answer is nothing, and the idea gets discarded. Other times, one small change unexpectedly strengthens half the project.

    I’m sure this won’t be the last time I redesign everything from scratch. In fact, I’m almost counting on it.

    For now, though, I’ve stopped thinking of game design as collecting features.

    It’s more like solving a puzzle where every new piece changes the shape of the entire picture.

    However for now, i’m done. Everything explains everything, nothing is missing. No idea, storyline or system is left stupidly hanging in the air.

  • What Is This Game Actually About?

    One of the first questions people ask after hearing someone is making a game is surprisingly simple: „So… what’s it about?”

    The honest answer? I can’t tell you. Not because i don’t know. From mechanics perspective – it’s all clear. Can i write a short description for steam page? Easy.

    What I do know is the feeling I’m trying to create.

    This isn’t a story about saving the world. The world is already lost.

    Civilization collapsed centuries ago. Nature reclaimed cities. Strange phenomena became ordinary. People stopped asking why things exist the way they do because, eventually, that simply became reality.

    You won’t play a legendary hero destined to save humanity. You’re just an ordinary survivor who stumbles into something much bigger than himself. As the world slowly reveals its past, you’ll realize that every abandoned ruin, every dangerous anomaly and every strange creature has a reason for existing. Nothing is random.

    One of my biggest goals is to make gameplay and story support each other. I don’t like mechanics that exist simply because „games usually have them.” If the player discovers a new technology, there should be a reason why it exists. If an area becomes more dangerous, the world should explain why. If something changes, it should feel like a consequence rather than a game rule.

    That has probably become the core philosophy behind the project.

    Everything should have a reason.

    Not necessarily an obvious one—but one that makes sense once you discover it.

    Visually, I’m aiming for something that feels closer to a handcrafted dark tabletop diorama than a realistic battlefield. I love stylized games that age gracefully, and I’d rather create a world with its own identity than chase realism for the sake of realism.

    Mechanically, I draw inspiration from many games I’ve loved over the years. Some borrow ideas from RPGs, some from survival games, some from strategy games. The goal isn’t to copy them, but to understand what made them memorable and build something that feels coherent when all those ideas meet.

    Will it work? Honestly, I have no idea. That’s part of the fun.

    For now, I’ve already answered all „Why this” questions:

    Why does this system exist?

    Why does this place exist?

    Why would the player care?

    Why this comment?

    Why this event and not that?

    If I couldn’t answer those questions, the idea wouldn’t belong in the game.

    Maybe that’s also the philosophy behind the entire project.

    Not „bigger.” Not „more features.” Just better reasons.

  • Beginning

    Background

    I’ve always wanted to create my own game. Not because I believed it would become the next indie success story, but because, after thousands of hours spent gaming, I realized something interesting: none of my favorite games ever felt truly complete. Not objectively—perfection doesn’t exist—but subjectively. There was always a mechanic I wished worked differently, a progression system I’d redesign, or a story element I thought could be taken further.

    I’m sure many people have had the same thoughts. Path of Exile is incredible, but overwhelming. Escape from Tarkov is one of the most immersive shooters ever made, yet often punishes players more than it rewards them. RimWorld constantly creates unforgettable stories, although sometimes a little too randomly for my taste. Then there are games like Mass Effect, Heroes of Might and Magic III, Dota 2, Civilization… games I’ve played for hundreds, sometimes thousands of hours. Every single one taught me something. Every single one also made me ask the same question: „How would I solve this?”

    Eventually that question evolved into something much more dangerous – what if I actually tried to build my own game?

    I can do it

    The first mistake I made was thinking I could simply combine the best ideas from games I loved. Mass Effect’s world-building, Path of Exile’s passive tree and endgame systems, RimWorld’s event generation, Portal’s AI companion… the list kept growing. Obviously, I’m not delusional enough to think one person can build something on the scale of Path of Exile or write characters as memorable as those in Mass Effect. But I wasn’t trying to recreate those games. I was trying to understand why their systems worked so well and whether I could build something entirely different using the same design philosophy.

    That innocent experiment quickly spiraled into obsession. Story influenced gameplay. Gameplay reshaped the world. World-building demanded new mechanics. New mechanics forced changes in the story again. I repeated this cycle so many times that I eventually stopped counting. The project grew into more than two hundred pages of documentation—not vague ideas, but detailed systems, progression loops, world generation, combat mechanics, AI behaviours, data structures, and enough diagrams to convince anyone that I had absolutely no idea what I was getting myself into. I even opened Godot and started experimenting.

    And then… I stopped.

    I can’t do it

    Not because I lost motivation, but because something fundamental was missing. The project had systems. Lots of them. They connected reasonably well, but the game itself felt soulless. It was technically interesting but emotionally empty. After months of work I quietly archived everything and didn’t touch it for almost four months.

    I’m thirty-eight years old, a father of two, and, despite working in IT, I spend as much time as possible outdoors. Fishing, camping and barbecues are probably where I’m happiest. Gaming doesn’t excite me the way it once did. Maybe I’m getting older, maybe my dopamine receptors have simply seen too much over the years. Either way, I always find myself looking for another game. 4 months of no joy have passed.

    Or maybe i can do it?

    Over the following weeks something unexpected happened. I got back to a project. Instead of adding more mechanics, I started removing them. Instead of asking what else the game needed, I asked why each system existed in the first place. Slowly, everything began fitting together. The story justified the mechanics. The mechanics reinforced the world. Systems that once competed with one another suddenly became dependent on one another. For the first time, the project felt coherent, whole, finished.

    Reality

    I’m not a game developer. I’m not even a professional programmer. My background is in systems architecture, CRM development, workflow automation, AI, marketing and web technologies. I spend my days designing business systems, connecting software together and solving practical problems. Game development is an entirely different beast.

    Naturally, I did what everyone does—I opened YouTube. Every experienced solo developer gave the same advice: keep your scope small, focus on one or two mechanics, finish something simple. They’re almost certainly right. Unfortunately, I think I already have around ten interconnected dangerously complex systems, and removing any one of them now feels like pulling bricks out of an arch.

    Will this project fail? Honestly… probably.

    Will I spend the next couple of years building something nobody ever plays? Also possible. Until i burn out again and get back to it when i want.

    But even if that happens, I’ll come out of it having learned Blender, Godot, procedural generation, animation pipelines, AI-assisted asset creation and a dozen other skills I don’t have today. That doesn’t sound like failure to me.

    So, for better or worse, this blog marks the beginning of what is almost certainly a VERY BAD IDEA.

    Let’s see where it goes.