My Game Design Process — Blog

Every game starts with a spark — a "what if?" moment that makes you sit up straighter. But the journey from that initial spark to a document someone can actually build from? That's where the real design work happens.

In this post, I'll walk you through my personal process for turning game ideas into structured, production-ready Game Design Documents.

Step 1: The Concept Seed

I keep a running list of game ideas — most of them terrible, some of them interesting. The key is volume. I don't judge ideas when I write them down; I judge them later when I'm looking for something to develop further.

A good concept seed answers one question: "What is the core experience I want the player to have?" Not "what are the mechanics" or "what's the story" — but what should the player feel?

Step 2: Research & References

Before I design anything, I play games in the same space. Not to copy — but to understand what's been done, what works, and where there's room to innovate. I take notes on:

What mechanics create the feelings I'm targeting
Where existing games fall short of their promise
What UI/UX patterns players already understand
How other designers solved similar problems

Step 3: Core Loop Definition

This is the most critical step. I define the core gameplay loop before anything else — the 30-second action that the player will repeat thousands of times. If this loop isn't inherently satisfying, no amount of content will save the game.

I use Machinations to model my loops visually, testing resource flows and feedback cycles before writing a single line of code.

Step 4: Systems Mapping

Once the core loop is solid, I map out how supporting systems interact with it. Economy, progression, narrative beats — everything needs to feed back into making that core loop more interesting over time.

I use Miro boards for this, creating visual maps of how systems connect. It's like drawing the circulatory system of the game.

Step 5: The GDD

Only now do I start writing the formal document. By this point, I have clarity on what the game is, how it works, and why it's fun. The GDD becomes a communication tool — a contract between design intent and implementation.

A GDD isn't a novel. It's a blueprint. Every word should help someone build the game correctly.

What I've Learned

The biggest lesson? Design is iteration. My first version of anything is wrong. The second is better. The fifth is usually where the real game reveals itself. The process isn't linear — it's a spiral, with each pass adding depth and removing noise.