Small Complex Game Guide

Building Small Games With Real Complexity

I spent about three years making tabletop games in my spare time — mostly small-batch print-and-play things — before I actually figured out how to make something that felt complex without being bloated. The difference between a game that works and one that stalls out in playtesting usually comes down to a handful of design decisions most people get wrong early on. Here is the practical framework I ended up using, along with the mistakes I made so you do not have to repeat them.

The Small Complex Game Guide

Start by defining your core loop — the repeated sequence of actions a player takes during a single turn or round. This is the spine of the game. Everything else hangs off it. If you cannot describe what a player does every turn in one sentence, your game probably has scope problems or it is waiting on subsystems to lock in. Once the loop is clear, layer in constraints and trade-offs. Complexity in small games does not come from adding mechanics; it comes from restricting what players can do and making each option genuinely costly. A card that lets you draw two cards but skip your next turn is more interesting than a card that simply lets you draw three. The tension between reward and penalty is where the decision space lives. I ran into this exact issue on my second project. I had designed a card-drafting game with twelve different resource types, six action phases, and three win conditions. Playtesters sat down, looked at the rulebook, and politely left after forty-five minutes. I trimmed it down to three resource types, a single phase per round, and one asymmetric win condition. Play sessions went from an hour to forty minutes, and people actually wanted to keep playing.

Component Count Versus Decision Density

There is a misconception that complex games need a lot of pieces. The opposite is usually true. Fewer components force players to think harder about what those components represent. A single deck of thirty cards with clear text can generate more interesting decisions than a board with twenty miniatures and five custom dice. When I design now, I start with zero components on paper. I write out the game state as pure information — what each player knows, what they can affect, and what changes each turn. Only after that exists do I think about cards, tokens, or boards. If you skip this step, you will spend weeks balancing plastic pieces instead of balancing decisions. The one exception is spatial games. If your game relies on board position, map generation, or tactical movement, then the board itself becomes a primary mechanic and you cannot abstract it away. Even then, I keep the board simple and let player actions create the complexity, not the other way around.

Asymmetry Without Bloat

Asymmetric design is one of the best tools for adding replayability without adding mechanical overhead. Two players using the same rules but different goals or starting conditions will experience the game differently at almost no extra development cost. In my third game, I gave one player a hidden objective and the other player information about what that objective might be. This created a cat-and-mouse dynamic that felt much deeper than the underlying mechanics suggested. The rulebook for that entire subsystem was eight sentences long. The pitfall here is over-asymmetric design. If Player A's role requires completely different rules, reference cards, and play patterns than Player B's role, you are not making one complex game — you are making two games that happen to share a box. The testing burden doubles, and most small teams never reach a state where both sides feel balanced. Keep asymmetry in goals and information, not in fundamental rulesets.

Playtesting Cadence That Actually Works

Most people playtest too late and too infrequently. The habit I switched to was running solo tests first, then getting eyes on the game within two weeks of initial design. Solo play catches broken loops and unbalanced economy faster than anyone else will tell you. If you cannot win and you cannot lose in a solo session, the game is not ready for other people. After solo tests, I move to blind playtesting — giving new players the rules and watching them figure it out. I do not help them. The rules that cause the most questions during blind tests are the rules you need to rewrite or cut. I track every question and hesitancy in a spreadsheet and revisit it after each revision. This process usually takes about six to eight weeks for a small game before it feels stable. Projects that rush to publication in three weeks almost always ship with unresolved balance issues that surface months later in reviews.

When This Approach Fails

The small complex framework does not work for every genre. Narrative-driven games, party games, and games built primarily on social interaction do not benefit from constraint-based design the same way. Trying to force a cooperative storytelling game into a resource-constraint model will strip the fun out of it. Know your genre before you apply this methodology. Additionally, if you are designing for young children or casual families who want a fifteen-minute experience, high decision density will frustrate them. There is a middle ground where games can be quick without being shallow, but achieving that requires exceptional clarity in rule writing and component design. It is harder than it looks. If you need a reliable reference while working through these steps, the Small Complex Game Guide covers the core principles in more detail and includes templates for tracking playtest data. It is worth keeping open while you design rather than reading cover to cover before you start.