Welcome to Game Design Bites - a personal take on game design, straight from years of experience in the industry!

If this interests you, subscribe to get game design insights straight to your inbox for free!

Subscribe now

---

[

](https://images.unsplash.com/photo-1517373116369-9bdb8cdc9f62?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wzMDAzMzh8MHwxfHNlYXJjaHwzfHxjb21wbGV4aXR5fGVufDB8fHx8MTc3NzkwOTE0M3ww&ixlib=rb-4.1.0&q=80&w=1080)
Photo by John Barkiple on Unsplash

I was recently reading this post on ’ Substack about building tools with AI. He makes a point that really stuck with me: the real challenge isn’t figuring out how to build with AI tools, but deciding whether you should build the feature in the first place.

That really hit home for me. We’re often so busy worrying about the how (like getting the perfect difficulty curve, writing cleaner code, or making the UI look “just right”) that we skip the only question that actually matters: Do we even need to build this?

This line of thinking led me to explore the philosophy of YAGNI (You Ain’t Gonna Need It). While it isn’t a completely new or revolutionary concept, learning this specific vocabulary made me wonder how I could apply it to my own design workflow. It echoes familiar ideas like MVP, MDA framework, or just plain ol’ prioritization, but there’s something about its blunt, direct framing that acts as a real wake-up call.

🧭 The Design Trap

If you’ve spent any time in the “design weeds,” you know exactly what I’m talking about. It’s that moment when you start thinking big. You’re mapping out a complex progression system, five different currencies, and a massive branching narrative before you’ve even figured out if the core movement feels good.

We love to over-design, usually out of fear. We get scared that our core loop is too simple, or we fall for the illusion that more features automatically equal better player retention. I’ve definitely been guilty of trying to mask a boring core mechanic with a complicated progression system, only to realize later that the foundation itself was completely broken. We convince ourselves that if we just add enough features, enough “juice,” or enough complexity, the game will somehow become better. But more often than not, we’re just reinventing the wheel because we think we might find a “cooler” way to spin it.

Honestly, you shouldn’t over-design something if you don’t know how much you’re actually going to use it. It’s so easy to trick yourself into thinking you’ve found a “better” way to do things, when you should really be asking if a solution was even needed.

🕹️ YAGNI: You Ain’t Gonna Need It

YAGNI is a simple philosophy, more common in programming circles: don’t build it until you need it. Note that this doesn’t mean writing bad code or completely ignoring future plans. It simply means keeping your current implementation focused solely on current needs, saving your future self from maintaining unused features.

Think about the actual cost of building something you don’t need right now. It’s not just wasted hours. Every unnecessary mechanic you jam in introduces new bugs, requires its own UI, completely messes with your balance, and worst of all, distracts you from polishing the actual core loop. Building things you don’t need actively harms the things you do need.

In game design, this means keeping your basics tight. If you’re making a single-player level-based game, or a multiplayer shooter, or a roguelike, those are your foundations. You can’t take those lightly. That’s the base of your structure.

But everything else? The exact racing speed, whether you have five obstacles or ten, and that shiny new power-up you just thought of, those are things you can experiment with later. As you level up as a designer, you start to develop a filter. You start to see what’s a “must-have,” what’s a “good-to-have,” and what’s just “not-important-but-I-feel-we-should-have-it-because-I-think-so.”

The last one is the one you should probably remove first.

📈 The Power of “Playable Now”

It’s frustrating to realize you spent hours, if not days, deep in the details of a system that isn’t even being used. Trust me, it happens to me every other day.

But the best way to get over that disappointment is to have a crystal clear view of what makes sense for your game and what doesn’t. Spend more time thinking through the core experience. Separate your “must-haves” from your “good-to-haves.”

Now, this exact mindset becomes a lifesaver when you’re up against an actual release deadline. You can easily get stuck in the nitty-gritty details of a system for weeks. But if you can’t actually ship the experience on time, all the hours you spent crafting what you thought was a “great” solution are just wasted. These days, whether I’m approaching my own work or reviewing something for the team, the very first question I try to answer for myself is: is this even necessary?

We shouldn’t just focus on “finishing” things. The real win is getting them in front of players as fast as we can. The sooner people play it, the sooner we can identify the parts that actually suck.

Players are inevitably going to interact with your game in ways you never even imagined. All those hypothetical, perfectly-designed systems you planned out for the future? They usually shatter the second they make contact with a real player. Getting to a “playable now” state prevents you from designing for a player that doesn’t actually exist.

🐝 Case Study: Beeline

I’ve been putting this into practice with my latest experiment, Playable Things. My goal is to work with AI tools to get something playable as soon as possible.

Take my newest game, Beeline. It’s a strategic puzzle game I started by using a prompt from an older game jam. Using the prompt was my way of challenging myself with constraints to make me think about designing around them. My initial plans were ambitious. I wanted a massive level selection screen, staged levels, and some complexity added to the meta-game.

Instead, I built a quick prototype with bare-minimum UI just to see if the core mechanic worked. Since the game heavily depends on visual placement, I realized prompting an AI for level design wouldn’t be enough. I needed absolute control. So, I spent time also building a level editor, using AI to help me with building it. It was messy under the hood, but it allowed me to quickly test the limitations of the design and tweak it on the fly. Building the editor in this scrappy way was a YAGNI decision in itself: I didn’t need a perfectly scalable, beautiful editor, I just needed something to solve the immediate problem of testing the mechanic.

Once I actually played it, I realized a lot of my initial plans didn’t make sense. By cutting the “fluff”, like those extra power-ups, meta-game elements, and staged levels, I could focus on what actually mattered for me: building a solid amount of content that’s playable as soon as possible. I gave up on many of my initial “good-to-haves” just to get the game to a presentable, playable state.

Because of this brutal cutting, I actually had a game I could share. More importantly, it freed up my mental space to focus on the next thing to build. We all know how easy it is to ‘never-finish’ personal projects. But the more you can force yourself to reach an acceptable finish point, the sooner you can start working on new things equipped with all the hard learnings from your last project.

Try Beeline here

🛣️ The Path of Least Resistance

I’ve always believed that laziness is a game designer’s good friend.

When you approach a problem by being a bit “lazy,” you start looking for the path of least resistance. You find solutions that achieve the goal without building extra overhead for your future self to handle. Plus, extending the scope of your project just means it stays in “WIP mode” longer, and if there’s one thing I want to avoid, it’s being stuck in WIP purgatory.

Think about what your future self will thank you for. Design in a smart way. Always remember what problem you’re solving. As I’ve said many times before:

Great design is just a great solution.

If your design doesn’t solve a problem, it’s probably something that YAGNI.

If you’re interested, you can read more about my thoughts on good design. Or, if you prefer a visual format, you can watch my talk from last year.

📝TL;DR

• Ask “Should I build this?” : Before you worry about how to build something, ask if it’s even necessary.

• Embrace YAGNI : Don’t over-design features until you’re absolutely sure you’ll use them.

• Focus on Foundations : Keep your core mechanics solid and leave the “nice-to-haves” for later.

• Get to Playable Fast : The sooner you experience your design, the sooner you’ll know what’s broken.

• Be Smart Lazy : Find the path of least resistance to avoid creating future overhead.

• Design solves problems : If it doesn’t solve a problem, it isn’t good design.

Do you have any stories of “over-designing” that you regret? Or maybe a time where cutting a feature actually made the game better? I’d love to hear from you!

---

Thanks for reading Game Design Bites! Subscribe for free to receive new posts and support my work.