Some time ago, while wrapping up the manual for the 3rd iteration of “Vienna 1814: The Waltz of Nations”, an unexpected thought appeared — what if my game is too complex?
Maybe it was the fact that the manual had grown to almost 30 pages. Or that I had just spent two hours self-testing it.
But how would I even know? My goal was always to design something a bit complex. I enjoy games that take around 3–3.5 hours — that’s my sweet spot, especially for thematic euros.
During the design process you inevitably encounter problems. Some are easy to adjust. Others signal deeper structural issues. The hardest part is noticing them — especially when you’re emotionally attached to your project.
These signals are often called red flags.
Red flags can appear at any stage of development. Not every one of them means your game is broken. Sometimes what looks like a problem is a conscious design choice. And this is fine. But when several appear at once, it’s usually a warning sign.
Below I list few of the most common ones, ordered from those you might notice earliest in the design process, to those that only surface during playtests:
Ambitious overdesign.
If your first game is already an epic universe with planned expansions, your expectations might be outrunning your experience.
Unclear target player.
There is no game for everyone. Trying to design for everyone often results in designing for no one.
Too many mechanics and too much nuance.
“How many is too many?” is a dangerous question. Adding new mechanics feels productive, but they can accumulate quietly.
Component and design overload.
Wanting to include everything often leads to a table overflowing with components — and overwhelmed players.
Teaching Time Disproportion.
If explaining the rules takes longer than the gameplay itself, something may be fundamentally off.
Rule complexity.
Small modifiers, edge cases, and conditional bonuses quickly increase cognitive load. At some point remembering it all becomes impossible.
Players are repeatedly confused during playtests.
If different players stumble in the same places, something hasn’t “clicked” in the system. This require deep insight.
Reading this, it may all seem obvious. In practice, it isn’t.
One reason is the sunk cost fallacy. You’ve spent months designing your game, refining mechanics — removing some part of it now feels like admitting that time was wasted.
Another reason is simply love. When you fall in love with your project, you become blind to its flaws.
“Not my game. It wouldn’t do that.”
And sometimes it’s even simpler: it worked in your head.
Our brains are excellent at connecting ideas — and terrible at simulating friction, real-time decisions, or the simple act of moving a pawn across a crowded board.
So what can you do?
Test.
Self-test. Then test with real people — at a real table.
Watch the energy. Notice hesitation. Afterward, ask about the most confusing or unnecessarily complex moments.
And most importantly — be ready to remove things.
Limit elements. Simplify where possible. Kill your darlings.
In the upcoming posts, I will look at each of these red flags in more detail — sharing my own experiences and exploring what can actually be done about them.
