Game design bar — what the studio is allowed to build

The one rule: every Vibegame must show its world on screen with real graphics and animation, and be played with your hands. We build a fun, mechanic-first game first, then dress it in a theme — never the other way round — and we build it to grow into a real title: depth, progression, and a genuine campaign are encouraged, not capped. Text-heavy, text-only, and menu-only games are never built, no matter how good the subject.

The litmus test, applied at pitch time and at QA:

Cover up every word on screen. Is there still real, skill-based gameplay you can see and control with your hands? If not, we don't build it. If yes, go deep — more levels, real progression, and a genuine campaign are encouraged, not capped.

Last Server Standing (2026-07-10, removed) is the cautionary tale: a great subject (tech layoffs) married to a turn-based, text-and-menu management sim. It read like an interactive novel with a meter bolted on. The subject wasn't the problem — the interface was. Nobody made a mistake; the pipeline was subject-first and let the news pick the genre. This policy inverts that.

Mechanic-first, theme-as-skin

The trend radar's job is to supply a theme — a setting players are buying into right now (dark fantasy, cyberpunk, post-apocalyptic, pirates…). It must not pick the form. The form always comes from the studio's own curated palette — a fun arcade loop we already know builds well in a session. So:

- ❌ "Dark fantasy is selling → what game is about dark fantasy?" → a lore-heavy RPG of menus and dialogue. - ✅ "Side-scrolling brawler through a cursed gothic kingdom." → an arcade game dressed in dark fantasy.

(Until 2026-10-09 the radar supplied a news subject — a topical thing to parody or ride. That side was retired: see [docs/trends.md](../trends.md).)

The palette (edit it in HQ)

The actual, editable lists live in state/studio-config.json → gameDesign, surfaced on the Studio HQ /config page → "Game design bar". The owner edits them there; the pipeline reads them live. Three lists:

- Preferred (arcade) forms — the strong default: real-time, skill-based forms (e.g. platformers, brawlers, physics artillery like Mole Mayhem), plus short point-and-click adventures in three.js when the scene has real interaction. Read the live list from config — it is the owner's and it changes; this page deliberately doesn't copy it (a copy here once kept recommending two forms the owner had since banned). - *Allowed — only if graphical & animated — any genre is fine when it is shown, not described: a management/tycoon game is fine when you see a 3D office full of devs*; a card battler is fine with animated cards and board effects; an idle/clicker is fine when things move and animate on screen; a puzzle is fine when it's visual, not word-based. The genre is never the disqualifier — a text/menu presentation is. - Banned (never build) — text/menu-first games of every kind (text adventures, visual novels, "read a paragraph, pick an option"), plus whatever else the owner has banned; the live list is in config.

If the lists in config and the examples here ever disagree, config wins — it's the live control surface; this doc is the reasoning behind it.

Enforced at

- Creative Director (.claude/agents/creative-director.md + the /creative-director skill) — pitches a preferred form × trending theme (or follows the owner's direction ticket), names the real-time/visual loop, and runs the litmus test before filing the ticket. Never pitches a banned form. - game-creator (.claude/agents/game-creator.md) — the core loop it ships must be visual and hands-on; it never ships a text-only or menu-only game, and a genre from the "allowed" list must arrive with real graphics + animation. - game-QA (.claude/agents/game-qa.md) — a hard gate: a game whose entire interaction is reading text and picking menu options FAILS, the same way a parody violation FAILs. This is the backstop that was missing.