Design game

design-game

Полный pipeline проектирования игры по линзам Джесси Шелла — от сердца опыта до релиза. Мульти-стадийный, со своими артефактами и точками BLOCK. Работает на любом масштабе: и AAA-концепт, и миниигра на 5 минут.

Где живёт проект: все линзы, шаблоны и субагенты (gd-*) — в gamedesign/ в корне workspace. Этот скилл лежит в глобальном .claude/skills/design-game/, поэтому все пути ниже даны от workspace-корня и начинаются с gamedesign/.

Принцип (на чём всё держится)

1. Управляющая идея — стержень. Формулируется первой (стадия 0), живёт в шапке каждого артефакта, является эталоном для каждого стадийного агента (линза Unification). Любой элемент, не усиливающий её, — кандидат на вырез. На mini она просто короче — но она есть всегда.
2. Линза = набор фокус-вопросов. Не предписание, а угол зрения. Полный справочник — gamedesign/lenses/lenses.md. Какие линзы на какой стадии и как урезаются под scale — gamedesign/lenses/stage-map.md (источник истины).
3. Правило петли (Rule of the Loop). Дизайн не делается за один проход. После каждой стадии — gd-keeper: переаудит всех предыдущих стадий на дрейф от управляющей идеи и противоречия.
4. Живой журнал. Ответы на линзы накапливаются по ходу, могут долго висеть open. Ведётся в LENS-LOG.md.
5. Engine-agnostic ядро. Движок входит только в опору «Технология», стадию «Прототип» и «Релиз». Прочее движко-независимо.
6. Прото = одноразовый зонд, не старт разработки. Дисциплина — gamedesign/lenses/schell-prototyping.md.

Разделение «человек / агент»

В гейм-дизайне продукт — это суждение дизайнера. Авто-прогон творческих ставок автоматизирует ровно то, что нельзя. Поэтому агент = спарринг-партнёр + писарь + зондировщик + аудитор; человек делает ставки.

Делает ЧЕЛОВЕК (ставки)	Делает АГЕНТ (механика/ассист)
Управляющая идея, сердце опыта	Прогон фокус-вопросов линз → выкладка ответов и напряжений
Центральная метафора / механический крючок, тема	Драфт документации (GDD-разделы, one-pager, питч)
Разрешение конфликтов линз, вкус / feel	Математика баланса, симуляции
«Достаточно ли хорошо»	Сборка disposable-зондов, прогон через Playwright
Truth / этические границы (advergame)	Аудит связности (gd-keeper)
Приоритеты рисков, вырез/добавление столпа	Форматирование, bookkeeping, ведение логов

Руль автономии

Три режима — кто кого ведёт по пайплайну. Выбирается на старте (Шаг 0), переключается в любой точке аппрува.

• co-design (дефолт) — агент предлагает, человек решает каждую ключевую развилку.
• assisted — агент драфтит, человек ревьюит/аппрувит на гейтах стадий.
• auto — агент гонит, человек смотрит на гейтах/финале; но каждое самостоятельное решение пишется в decision-log (auto ≠ слепо).

Правила руля:

1. На старте, перед выбором режима, в чате поясни, что будет в каждом флоу (кто решает, где гейты, что логируется).
2. На каждом гейте напомни текущий режим и что произойдёт дальше (подробное напоминание, не молча).
3. Переключение двустороннее, в любой точке аппрува: co-design ↔ assisted ↔ auto (напр. «база ясна → auto на вёрстку зонда»; и обратно — если на ревью ёкнуло). Предлагай переключение, когда уместно.
4. На тормозе (BLOCK / развилка) дай рекомендацию + открытый вопрос со свободным вводом — человек может ответить «да» по рекомендации или вписать своё.
5. В auto веди decision-log — каждое самостоятельное решение строкой (что решил, почему, какая линза/критерий).

Ключевые развилки — агент тормозит даже в assisted:

• пересмотр управляющей идеи;
• смена центральной механики;
• конфликт линз (взаимоисключающие фокус-вопросы);
• любое внешнее обещание (advergame — число/claim наружу);
• вырез или добавление столпа.

Шаг 0 — Бриф

Если пользователь не дал всё сразу — задай вопросы по одному (не списком). Минимум:

1. Идея игры — что это, в одно предложение (это зерно управляющей идеи).
2. Масштаб (scale) — mini (миниигра, один экран) / small (джем, вертикальный срез) / medium (инди) / large (большой проект). Объясни: scale управляет набором стадий и глубиной линз (см. stage-map.md), но не наличием управляющей идеи.
3. Режим — docs-only (чистые диздоки) или docs + прото-зонды по запросу. Объясни: зонд = одноразовая лёгкая проба под один рискованный вопрос, не старт разработки. Дефолта нет — спроси явно.
4. Медиум / движок — нужен только для опоры «Технология» и веб-зондов. По умолчанию engine-agnostic; если будут зонды про ощущение/тайминг — основной кодовый профиль веб (TS + Phaser/Canvas), его можно собрать и запустить прямо здесь.
5. Где артефакты — путь <game-path> (например games/<slug>/, route в сайте, или отдельная папка). Спрашивается под каждую игру.
6. Нарративная ли игра — если да, стадия 5 (История и мир) не пропускается даже на mini/small.
7. Тип игры — entertainment (только поразвлечь) или advergame / serious (продаёт продукт / меняет поведение / обучает). Детект обязателен. Если advergame/serious — на старте обязательно спроси (по одному):
   • (а) Secret Purpose — настоящая внеигровая цель (напр. «правдивый лидген: поднять боль + защитимо объяснить выгоду → квалифицированная заявка»);
   • (б) truth-ограничения — какие числа/обещания игра выносит наружу как реальные и что обещать НЕЛЬЗЯ (не вводить в заблуждение);
   • (в) число буквальное или иллюстративное и где живёт реальная правда (форма / калькулятор / дисклеймер).

   Это не косметика для финала: ответы питают стадию 3 (экономика/числа) — любое число-наружу там ограничено источником или пометкой «иллюстративное» — и стадию 7 (Honest Claim / Responsibility). Записываются в секцию «Secret Purpose и Truth-ограничения» CONTROLLING-IDEA.md. Для entertainment секция пропускается.

8. Режим автономии — co-design (дефолт) / assisted / auto (см. «Руль автономии»). Перед выбором поясни в чате, что будет в каждом флоу — кто решает развилки, где гейты, что логируется. По умолчанию co-design; переключить можно в любой точке позже.
9. Риск-теги / категории игры — сначала сам инферь свойства и риски игры из идеи (категории: advergame, multiplayer, narrative, competitive, kids, real-money, spatial/level, economy, …), затем дай человеку подтвердить/поправить. Эти теги питают подбор линз (проактивный pull по категориям, см. «Подбор линз»). advergame/serious из п.7 — частный случай этих тегов.

Зафиксируй ответы — они идут в CONTROLLING-IDEA.md (режим автономии и подтверждённые теги — туда же).

Шаг 1 — CONTROLLING-IDEA.md (стержень)

1. Создай папку <game-path>/ и скопируй туда шаблоны: gamedesign/templates/CONTROLLING-IDEA.md, LENS-LOG.md (пустой журнал), GDD.md, CONSISTENCY.md.
2. Проведи короткое интервью по стадии 0 (линзы Essential Experience / Emotion / The Player — см. stage-map.md) и заполни CONTROLLING-IDEA.md: управляющая идея в 1 предложение, желаемый опыт/эмоция, для кого, scale, 2–3 столпа, антискоуп.
3. Покажи пользователю карточку, получи подтверждение. Без согласованной управляющей идеи дальше не двигаемся.

Шаг 2 — Pipeline по стадиям

Иди по gamedesign/lenses/stage-map.md с поправкой на scale. Для каждой стадии 1→7 (стадия 0 закрыта в Шаге 1):

0) напиши мини-ТЗ субагенту (см. «ТЗ-контракт») — масштаб ТЗ по режиму автономии
a) стадийный агент применяет линзы стадии (ядро + foundational + pull, см. «Подбор линз») → дописывает GDD.md + LENS-LOG.md
b) (стадии 2/3 → дизайн зонда gd-prototyper, 2/3/6 → код зонда gd-builder; И режим = docs+прото) проверь risk-gate → при срабатывании зонд
c) проверка «ТЗ→результат» (тактическое ревью, см. «ТЗ-контракт») → масштаб по режиму
d) gd-keeper → переаудит всех стадий (стратегическое ревью) → CONSISTENCY.md
e) ГЕЙТ: напомни текущий режим автономии и что дальше; BLOCK? → останься, дай рекомендацию + открытый вопрос, дождись решения, петля. OK? → следующая стадия

На каждом гейте (шаг e) напоминай текущий режим и предлагай переключение, если уместно. В auto — фиксируй самостоятельные решения в decision-log.

Стадия	Агент	Артефакт
1 Концепт + тетрада	gd-concept	раздел GDD + one-pager
2 Ядро и механики	gd-mechanics (+ gd-prototyper дизайн зонда, gd-builder код)	раздел GDD
3 Баланс	gd-balance (+ gd-prototyper дизайн зонда, gd-builder код)	раздел GDD
4 Опыт и интерфейс	gd-experience	раздел GDD
5 Нарратив и мир (skippable)	gd-narrative	раздел GDD
6 Плейтест и итерации	gd-playtest (+ gd-prototyper/gd-builder)	секция PLAYTEST (+ билд)
7 Релиз и бизнес	gd-release	PITCH.md + раздел GDD

Как запускать агентов. Через Agent tool по имени gd-X, если субагенты из gamedesign/.claude/agents/ доступны в среде. Если не доступны (skill вызван вне контекста проекта) — прочитай gamedesign/.claude/agents/gd-X.md и передай его тело как роль обычному агенту; модель подставь по тиру из gamedesign/lenses/models.md под текущий тул. Каждому агенту передавай контекст: <game-path>, scale, режим автономии, режим прото (docs-only / +прото), мини-ТЗ (см. «ТЗ-контракт») и отобранный набор линз стадии.

Подбор линз (не по чистому scale). Линзы стадии набираются как обязательное ядро стадии + foundational (всегда-кандидаты: Essential Experience, The Toy, Flow, Curiosity + ядро) + pull по categories/рискам игры (подтверждённые теги из Шага 0) — источник gamedesign/lenses/lens-index.json. Это toolbox Шелла, а не фиксированный учебный подсписок по scale: scale влияет на глубину проработки, но не вырезает релевантную линзу. Дизайнеру показывай только отобранное (ядро + foundational + pull); полную колоду — по запросу.

Pre-flight каждого агента. Перед стартом агент читает errors.json в <game-path> (грабли этого проекта) — не наступать на свои же ошибки. Логи пишет оркестратор: lens-log.json (тонкий индекс) и decision-log ведёт только он; стадийные агенты дописывают свой .md; код-зонд gd-builder владеет probe.json.

После каждой стадии прочитай статус агента (OK | BLOCK + причина), покажи пользователю резюме в 1–2 предложения.

BLOCK-логика

• gd-keeper BLOCK (дрейф от управляющей идеи / противоречие между стадиями) → покажи CONSISTENCY.md; пользователь решает: править стадию / осознанно пересмотреть управляющую идею / принять.
• gd-prototyper «вопрос провалился» → зонд показал, что допущение неверно — это успех зонда (сэкономил недели). Верни решение стадийному агенту на пересборку.
• stage agent BLOCK (не хватает входных решений из предыдущих стадий) → собери недостающее у пользователя, перезапусти.

ТЗ-контракт и проверка соответствия (тактическое ревью)

Это тактическое ревью «выдал ли этот агент то, что в его ТЗ» — отдельно от стратегического gd-keeper (сходится ли вся игра с управляющей идеей). Не путать.

ТЗ-перед-запуском. Перед каждым субагентом напиши мини-ТЗ (acceptance-spec) — 5 строк, токен-СБЕРЕГАТЕЛЬ (дешевле переделки мис-таргетнутого агента):

• цель стадии;
• ожидаемый артефакт + его свойства;
• какие линзы прогнать (отобранный набор);
• критерии приёмки — по чему поймём, что годно.

Проверка «ТЗ→результат» — масштабируется по режиму автономии:

Режим	ТЗ пишет	«ТЗ→результат» проверяет
co-design	человек (или агент-драфт + аппрув человека)	человек на гейте
assisted	оркестратор драфтит → человек аппрувит	оркестратор + человек на гейте
auto	оркестратор, ТЗ логируется в decision-log	opus-верификатор (отдельный чек), всё в decision-log

Тип проверки:

• Объективное/проверяемое (билд запустился; линза отвечена; симуляция показывает заявленное) → дешёвый автоматический чек оркестратором ВСЕГДА, в т.ч. в co-design.
• Субъективное/качество (feel, метафора, вкус) → человек в co-design/assisted, opus-верификатор только в auto/high-stakes (иначе плата за ревью не берётся).

Застрял-режим (toolbox Шелла, реактивный)

Логика оркестратора, не отдельный агент. Когда человек роняет реплику дискомфорта («бесит / не пойму / что-то не так / скучно / не цепляет / выборы фальшивые / теряюсь»):

1. Замапь реплику на diagnoses (симптомы-затыки) из gamedesign/lenses/lens-index.json.
2. Подай 2–3 линзы-кандидата с их фокус-вопросами.
3. Спроси: «прогоним дизайн/прото через эту?» — линзу подаёшь в руку, смотрит через неё человек (он решает).

Параллельность

Стадии — строго последовательно. Один растущий GDD.md = один писатель за раз. Не запускай стадийных агентов параллельно над одним <game-path> (race по GDD/LENS-LOG). Параллелить можно только разные игры (<game-path>).

Прото-зонды

Запускаются только если режим = docs + прото и сработал risk-gate (стадии 2/3/6, либо явный запрос). Дисциплина — gamedesign/lenses/schell-prototyping.md: один вопрос на зонд, самая лёгкая форма (бумага/таблица/ASCII/веб), помечен disposable. Привязываться к коду зонда запрещено.

Разделение ролей зонда:

• gd-prototyper (reasoning) — дизайн зонда: формулирует ОДИН рискованный вопрос + выбирает самую лёгкую форму. НЕ кодит.
• gd-builder (новый, balanced-creative) — код зонда + прогон через Playwright + пишет probe.json (владелец JSON-лога зонда: вопрос, форма, константы, замеры/траектория, вердикт, disposable, links).

Финал

Когда стадии пройдены:

1. Покажи пути: собранный GDD.md, PITCH.md (если была стадия 7), prototypes/ (зонды + играбельный билд, если были веб-зонды), LENS-LOG.md, CONSISTENCY.md.
2. Сошлись на открытые пункты LENS-LOG (статус open) — что осталось проверить.
3. Если режим был docs+прото и есть веб-билд — напомни, что это зонд (disposable), а не релиз-кандидат.

Хендофф в сборку (build handoff)

design-game заканчивается на готовом дизайне, а не на собранной игре — полноценная сборка билда это отдельная дисциплина (отдельный скилл build-game, движко/язык-специфичный). Граница «проба ≠ продукт» намеренная (дисциплина Шелла: не привязывайся к зонду).

Когда диздок готов (стадии закрыты, gd-keeper OK) и пользователь хочет идти в сборку:

1. Собери build-ready хендофф по шаблону templates/BUILD-HANDOFF.md: управляющая идея + опора «Технология» (выбранный язык/движок из тетрады) + механики/правила + числа-константы (стадия 3) + выводы зондов (что подтверждено) + открытые feel-вопросы (что проверить на реальном билде) + цель/Secret Purpose + критерии приёмки среза.
2. Предложи передать его скиллу build-game (если установлен): «дизайн готов — собрать вертикальный срез на <язык/движок>?». Skill→skill хендофф: для пользователя бесшовно, внутри — два инструмента.
3. Прото-зонды (prototypes/) — НЕ кандидаты в продакшн. Build-скилл строит с нуля по спеке, а не «дорабатывает зонд».

Если build-game не установлен — BUILD-HANDOFF.md всё равно полезен: это готовое ТЗ на сборку для любого разработчика/агента.

Модели и портируемость

• Тиры моделей (reasoning-heavy / balanced-creative / mechanical) → конкретные модели по тулу — gamedesign/lenses/models.md.
• Перенос скилла под Cursor / Antigravity — gamedesign/adapters/.

Что НЕ делать

• Не свёртывай стадии в один проход — каждая стадия создаёт свой раздел GDD + записи в LENS-LOG.
• Не пропускай gd-keeper после стадии — без обратной сверки ломается «правило петли».
• Не пиши диздок без согласованной CONTROLLING-IDEA.md.
• Не привязывайся к коду прото-зонда — это проба, не продукт.
• Не тащи движок/технологию в стадии 0–1 раньше времени — ядро engine-agnostic.
• (advergame/serious) Не выдумывай числа-обещания, которые игра выносит наружу как реальные (экономия ₽/%/время) — нужен источник или явная пометка «иллюстративное» + эскалация пользователю. Молча сочинённый claim подрывает доверие к продукту.
• Не правь gamedesign/lenses/* и templates/* без явного запроса — это источник истины скилла.