The Blank Stare Phase of Game Dev

Back when I first was learning C#, I learned a lot about classes and interfaces. And in my research, I learned how, when used correctly in game development, can reduce a lot of redundant code. It’s like I completely forgot all about that.

After getting the ingredient input system about 90% of the way there, I went to copy and paste the code I had written into another script for my distiller. Luckily, the bad-practice alarm bells rang violently in my head and I stopped myself in my tracks: “this is definitely not best practice” lol.

I sat and just stared at my computer for a minute, trying to think through this problem. Here I had two nearly identical tools that I wanted to behave very similarly. Their differences were minor, but I wasn’t coding their differences right now. Visually, they were going to respond the same way to the player. So it’s the same code. I could just copy and paste the same code into a new script, but that’s neither efficient nor optimal. What if I need to fix a bug? What if I want to change the way it behaves? Having to edit and fix two different but identical scripts sounded like a development nightmare.

Okay, what if they shared the same script? Yeah. That could work. I could write a generic and basic script and then hard-code the differences in their own scripts. But it still didn’t sound super ideal. And that’s when I remembered classes and interfaces. Duh. Obviously. I can’t believe I didn’t think of that.

For those unfamiliar, classes are basically blueprints for objects—they define the structure and behaviors you want, and then you can just spin up as many versions of that thing as you need. Once I remembered that, it just made sense. Instead of copying and pasting code like an unhinged novice solo indie dev, I could just write a single class and make both tools use it. Simple. Effective. Way cleaner than what I was about to do.

So I refactored everything. And honestly? It felt good. Now, both my ingredient input and my distiller use the same class, and I can tweak or improve the behavior in one place without worrying about missing something. It’s way easier to read, too—future me is going to open this project and not want to scream.

It also kind of opened my eyes a bit. I’ve been so focused on just getting things to work that I forgot how much smoother things go when you take the time to design them properly. It’s not even about writing fancy code—it’s just about not making your own life harder later.

What’s funny is that this is the very thing I was scared about doing months ago when I started planning Martian Alchemist. Obviously, I’m going to make mistakes and, trust me, you don’t want to see my code, but I think that this is honestly just how development goes. It’s rarely linear. It’s messy. It’s full of rewrites and refactoring and tossing out entire days’ worth of code. It’s sitting at the computer screen, the IDE burning lines into your screen, not typing a single thing, but deep in thought. In your head you’re working through the problem, trying to figure out the solution to a problem no one has seen before because at the end of the day, that’s what you’re doing: you’re building something that’s never been built before.

To the untrained and untechnical eye, this delay in “work” must be maddening. But trust me, some of the best solutions to these weird problems are found, deep in thought, with the IDE burning a hole in your screen, the cursor patiently waiting, and with copious amounts of caffeine please.

And when the solution finally clicks into place, it feels like magic. There’s this quiet little rush of adrenaline, like I just leveled up. I swear I could hear the XP counter dinging in the background. It wasn’t even some big, complicated breakthrough—it was just remembering that I already knew how to solve this. I just needed to slow down enough to let my brain catch up to my ambition.

This whole moment also reminded me why I love making games in the first place. It’s not because it’s easy (because let’s be real, it absolutely is not), but because it constantly pushes me to think differently. To take a step back and re-examine not just my code, but how I approach problems in general. That moment of staring blankly at my monitor wasn’t wasted time; it was part of the process. It is the process.

There’s this weird myth that good developers just know everything off the top of their head, like they’ve got some magical catalog of perfect solutions for every problem. But honestly, it feels more like being a stubborn detective. You hit a dead end, you double back, you rethink the whole route, and eventually, you find a way through. Even if that way involves pacing around the room, mumbling to yourself like a maniac, until you remember: “Oh right, classes exist.”

So yeah, lesson learned (again). If you’re in the middle of a messy project and you’re feeling the urge to copy and paste your way out of a problem, take a breath. Step back. Stare at your IDE until it stares back at you. The answer is probably already in your toolbox—you just forgot it was there.