antipattern

Use when

You are designing "the big version" of a system that worked when it was small.

What it is. The redesign that swallows every idea you cut from the first version. v1 shipped lean because you couldn’t fit more; v2 is where the backlog goes to be vindicated — and it drowns.

Why it hurts. The constraint that made v1 legible is gone, but the taste that constraint forced on you doesn’t automatically scale. You mistake “more surface” for “more depth” and ship something bigger in every dimension and smaller in focus.

The smell

The follow-up grows on every axis at once — more verbs, more resources, more menus, more systems talking to systems — and the core loop it was supposed to deepen gets harder to describe, not easier. Coined for software architecture; games have their own graveyard.

How it happens

The tell (check YOUR design)

AskSecond-system answer
Can you name the core loop in one sentence?It takes a paragraph now, or a diagram.
What did the sequel remove?Nothing. Only additions.
Which new system, cut, would players not miss?You can’t name one — everything is “load-bearing.”
Why is each feature here?”It was on the list” / “the first game couldn’t fit it.”
Is v2 easier or harder to teach than v1?Harder — the onboarding grew (antipattern-endless-tutorial).

If the honest answer to “what does this version say no to?” is nothing, you are building the second system.

The fix

Twist seams (design with the effect, not against it)

Seen in…

Verify / guard

This is a fun problem before it’s a content problem — an unnamed core loop fails the first gate in [[design/FUN.md]]. Before handoff via process-refine-and-handoff, run the tell table above and confirm the sequel can state, in one sentence, what it is and what it dropped. If it can only add, it isn’t a deeper system — it’s a longer list.

This module rendersthe repo's markdowndirectly — edit it there, it changes here.