Game design is one of those skills I don’t think gets practiced enough. Of course most developers care about good game design. But long projects work against it in ways that are easy to miss until you’re already rusty. I’ve been thinking about this a lot lately. I worked out a system that helps.
Game Design Practice Gets Overlooked
Early in a project, design decisions happen constantly. Scope, systems, player loop, level structure. A lot of active, intentional thinking. This is game design: deciding what the game is, how it works, and why.
Then the project matures. The design locks in. You shift into development mode. Now you’re asking different questions entirely. Not “what should this do?” but “how do I make this work?” You’re writing code, fixing bugs, optimizing systems. That’s valuable work. It’s just not design work.
And that’s not a bad thing. That’s just how projects work. But it means you can spend months making implementation decisions without making a single design decision. The two feel similar. And they are similar. But they’re not the same skill.
By the time your next project needs real design decisions, you may find you’re slower than you expected. The instincts for scope and structure don’t stay sharp on their own.
The Problem With Game Jams
Game jams seem like the obvious answer. Low stakes, short timeline, something new to build. A good reason to make design decisions again.
In practice, switching projects has a real cost. Stepping away from your main project means rebuilding context when you come back. That overhead eats into the week more than most people expect.
Once you start building, the same thing happens as with any larger project. Design gives way to development. The early hours force design decisions: theme interpretation, scope, core loop. But as soon as the prototype takes shape, you shift into implementation mode. You stop asking what the game should be and start asking how to make it work.
Jams compress the timeline. They don’t change the pattern.
Design-Only Jam Sessions
I do this roughly once a month to once a quarter, depending on whether an interesting jam is happening. When one comes up, I still use the full game jam duration. I just don’t build anything.
Instead, I write a full technical design document for the jam concept. Not a one-pager with a concept and a mood board. A real document that thinks the project all the way through: every major system, design decision, and constraint. The jam theme and deadline still apply. The only thing that changes is that nothing gets built.
The document ends up closer to a TDD than a traditional GDD. I’m not writing narrative or art direction memos. I’m asking the same questions I’d ask at the start of a real project. What does the player do? What systems does that require? How do those systems talk to each other? What would actually have to exist for this game to ship?
The Most Important Rule
This exercise cannot touch your main project’s scheduled time. The thinking happens in the margins: commute, lunch breaks, a walk, time that isn’t going toward active development. It’s still deliberate. The design decisions are real. The constraint is just that none of it displaces actual project work. The moment it starts competing with your main project, it stops being useful.
What Goes Into the Document
- Core player loop and moment-to-moment gameplay
- Core systems and how they interact
- Programming architecture for those systems
- Visual style and reference points
- Color palette direction
- Art direction and asset scope
- Music style and tone
My background is in programming, so I lean hardest into the systems section. How would I structure this? What components need to talk to each other? That’s where most of the design thinking lives for me.
For art and music, I approach it from a communication angle. If I had an artist or a musician on the team, what would I need to tell them? What assets are needed, what mood do they need to hit, what style are we working in? It forces specificity instead of vague aesthetic instincts. That’s useful even for a fictional project.
The goal isn’t a pitch document. It’s a thinking exercise. The jam timeline still applies as a constraint. The pressure just drives design decisions instead of development ones.
What You Give Up
Obviously, nothing gets shipped at the end. No itch.io page, playable build, or jam rating. You also lose external feedback on your concept. Though if you publish your design docs somewhere (like I do right here on this blog!) you can get some of that back.
You also lose the hands-on learning that comes from actually building something. Some design problems only reveal themselves in implementation. A document can’t catch everything.
Why It Still Works
The core of game design practice is in the decision-making, not the building. Designing a system you never implement still forces you to make real choices: scope, constraints, technical trade-offs. Those are exactly the decisions that stop happening mid-project.
It also builds a clearer sense of what’s actually achievable. Scope is one of the hardest things to get right, especially in shorter jams. Working through full design documents repeatedly makes technical limitations easier to spot early. The more you practice thinking through entire projects, the faster you recognize when something is too big for the time and resources available.
Once the document is done, it’s out of your head. That mental space goes back to your main project. And if the concept turns out to be genuinely strong, you’re not starting from zero when you’re ready to build it. The thinking is already done.
Final Thoughts
For me, game design is the part that doesn’t get practiced enough on its own. Programming, debugging, optimization: those happen constantly during a long project. Design decisions largely stop once the foundation is set. This is a way to keep making them intentionally, without pulling time away from the work that actually needs to ship.
Once a month or once a quarter is enough. The frequency matters less than the consistency. The goal is to stay in the habit of thinking through entire projects: what they would take, where the complexity lives, what the trade-offs are. That kind of thinking gets sharper the more you do it.
If game design practice is something you want to be more intentional about, this is how I do it without derailing my current project’s momentum.
I’m starting to publish my own design documents right here on the blog. If you want to check out some of my ideas or get inspired for your own design docs, check them out right here: design concepts.
0 Comments