# 06. Рекомендованный MVP и архитектура AI GameMaster

## Продуктовая ставка

Первый продукт — **законченный голосовой one-shot на 3–5 игроков длительностью 60–120 минут**, работающий в mobile и desktop браузере. Не бесконечная кампания, не тяжёлый VTT и не универсальный конструктор правил.

Причины:

- русскоязычное исследование указывает на длительность 4–8 часов и объём правил как барьеры, а короткий юмористический контент — как более доступный [S012];
- прямые конкуренты уже обещают AI-GM и долгую память [S018, S020, S023, S024];
- полноценная длинная кампания — самый дорогой и рискованный способ впервые проверить спрос;
- one-shot позволяет измерить завершение целой истории, а не engagement в бесконечной генерации.

Архитектуру при этом нужно строить на событиях и типизированном состоянии так, чтобы позже поддержать кампании.

## Пользовательский цикл MVP

1. Хост выбирает готовое приключение или задаёт параметры собственного: тема, тон, длительность, границы, допустимая жестокость, сложность.
2. Система генерирует черновой корень сценария в структурированном виде и показывает хосту краткое превью без спойлеров игрокам.
3. Хост создаёт комнату и отправляет ссылку.
4. Гости входят без оплаты, выбирают готового персонажа или проходят короткую сборку.
5. Все проверяют микрофон, согласуют safety boundaries и начинают.
6. Обычная беседа идёт свободно. Когда система ждёт каноническое действие, активному игроку доступна кнопка «Совершить действие».
7. Игрок записывает короткую реплику. Система показывает transcript и либо:
   - распознаёт однозначное намерение;
   - задаёт конкретный уточняющий вопрос;
   - сообщает, почему действие невозможно в текущем состоянии.
8. Rules engine определяет нужный бросок; игрок нажимает кубик; сервер фиксирует результат.
9. После подтверждённого изменения состояния narrator создаёт текст, TTS и при необходимости новую сцену.
10. После финала группа получает recap, решения, броски и галерею сцен.

## Важное разделение: разговор и действие

Если блокировать микрофон всех, кроме активного игрока, исчезнет социальная химия — одна из ключевых ценностей ПЧК [S010, S012]. Поэтому:

- **social audio** открыт постоянно для шуток и обсуждения;
- **canonical action clip** записывается отдельно, имеет одного автора и проходит STT → validation → state transition;
- в бою и структурированной проверке кнопка строго привязана к initiative/turn;
- в исследовании мира AI или host передаёт «право действия», но разговор остаётся открытым.

Это снижает стоимость и privacy-риск: не нужно непрерывно распознавать и сохранять всю беседу.

## Архитектурный принцип

AI не является базой данных, кубиком или окончательным судьёй состояния. Он выполняет языковые задачи вокруг детерминированного ядра.

```mermaid
flowchart LR
    A["Голосовой action clip"] --> B["STT + speaker identity"]
    B --> C["Intent parser"]
    C --> D{"Намерение однозначно и допустимо?"}
    D -- "Нет" --> E["Точный уточняющий вопрос"]
    E --> A
    D -- "Да" --> F["Rules engine + server RNG"]
    F --> G["Append-only event log"]
    G --> H["Materialized game state"]
    H --> I["Narrator context builder"]
    I --> J["Текст + TTS"]
    I --> K["Scene/image job при смене окружения"]
```

## GameMaster — один интерфейс, несколько обязанностей

Пользователь видит одного GameMaster, но внутри это не свободно общающийся «рой агентов»:

| Компонент | Отвечает за | Не имеет права |
|---|---|---|
| Scenario planner | Структура one-shot, узлы, NPC, цели, секреты | Менять живое состояние после старта напрямую |
| Intent parser | Превращает transcript в типизированное предложенное действие | Применять действие |
| Rules engine | Проверяет возможность, сложность, roll, damage/status | Сочинять факт мира |
| State service | HP, stats, inventory, location, initiative, quests, ownership | Генерировать художественный текст |
| Memory/context builder | Выбирает релевантные факты для текущей ветки | Читать приватные события другой ветки без разрешения |
| Narrator | Повествование, NPC-реплики, варианты уточнения | Самостоятельно менять канон |
| Safety service | Возраст, consent, report/block, policy boundaries | Скрыто переписывать допустимые игровые решения |
| Media workers | TTS и изображения | Блокировать commit игрового хода |

Такое разделение делает ошибку локализуемой и позволяет воспроизвести сессию.

## Надёжная память без деградации

Рынок уже использует summaries, постоянные инструкции, сущности и retrieval [S018]. Это оправдано: исследование Lost in the Middle показывает, что модель хуже использует факты, спрятанные в середине длинного контекста; большое context window не гарантирует надёжность [S028].

### Канонические слои

1. **Append-only event log** — каждое принятое действие, бросок, результат, переход сцены и исправление.
2. **Materialized state** — текущие HP, инвентарь, статусы, местоположение, initiative, отношения и открытые цели.
3. **Entity cards** — устойчивые факты о NPC, местах, предметах и обещаниях.
4. **Scene/branch summary** — редактируемое краткое содержание каждой активной ветки.
5. **Global chronology** — упорядоченные общие события и время мира.
6. **Recent-turn window** — последние реплики текущей сцены.
7. **Retrieved memories** — только релевантные факты, разрешённые visibility scope.

Полный transcript не передаётся модели на каждом ходу.

### Контекст каждого хода

В фиксированном порядке:

1. версия правил и safety contract;
2. роль narrator и формат ответа;
3. authoritative state активного игрока;
4. текущая scene/branch;
5. разрешённые entity cards;
6. краткая глобальная chronology;
7. релевантные воспоминания;
8. последние ходы;
9. подтверждённый результат rules engine.

Модель получает **результат**, а не просьбу придумать результат задним числом.

### Исправления

Нельзя тихо переписывать прошлое. Исправление — отдельное событие с автором, причиной и ссылкой на исправляемое событие. Materialized state пересобирается или обновляется из журнала.

## Уточнение неоднозначных действий

Не следует полагаться только на «confidence 0.7»: численная уверенность модели плохо калибрована и не является бизнес-правилом.

Уточнение обязательно, если выполнено хотя бы одно условие:

- отсутствует требуемая цель, предмет, направление или способ;
- есть две и более допустимые интерпретации с разными state transitions;
- действие зависит от неизвестного игроку выбора, который нельзя сделать от его имени;
- transcript противоречит текущему состоянию;
- действие затрагивает согласие другого персонажа/игрока;
- parser не может построить schema-valid command.

До ответа игрока **не выполняются бросок и изменение состояния**. Уточнение должно быть конкретным: «Ты пытаешься обезоружить стражника или ударить его мечом?», а не «Поясни действие».

## Броски и правила

- RNG генерируется сервером и записывается в событие вместе с формулой, modifiers и версией правил.
- UI показывает игрокам исходный бросок и итоговый расчёт.
- Rules engine использует оригинальную простую систему или юридически допустимый SRD; LLM не импровизирует механику.
- Возможен human override, но он также журналируется.
- Повторное подключение клиента не может повторно применить ход: command имеет idempotency key и expected state version.

Новый event commit проверяет версию состояния после любых медленных AI/STT операций. Иначе два почти одновременных действия могут примениться к устаревшему состоянию.

## Разделение группы

Это не только UI-функция, а модель доступа.

Каждое событие и память имеют:

- `campaign_id`;
- `branch_id` или `location_id`;
- `visibility_scope` — public, party, subgroup, player, GM;
- `occurred_at` и `sequence_no`;
- список знающих персонажей, когда знание отличается от физического события.

При разделении:

1. создаются отдельные branch state и scene summary;
2. участник получает только разрешённый контекст своей ветки;
3. каждая ветка имеет собственный image prompt/reference set и текущую иллюстрацию;
4. global chronology синхронизирует время, но не раскрывает секреты;
5. при встрече веток правила явно определяют, какие знания становятся общими.

Критический тест: закрытое событие ветки A ни напрямую, ни через summary, retrieval, TTS, image prompt или recap не попадает игрокам ветки B.

## Иллюстрации

Генерировать изображение после каждого хода дорого и замедляет темп. Trigger должен быть семантическим:

- значимая смена окружения;
- первое появление важного NPC/объекта;
- кульминационное событие;
- явный запрос хоста в пределах квоты.

Для визуальной устойчивости нужны style bible, character reference, scene ID, persistent descriptors и негативные ограничения. Генерация идёт асинхронно: сначала появляется narration и placeholder, затем новая сцена. Ошибка изображения не откатывает игровой ход.

Для партнёрского IP художники должны утверждать style bible и референсы. AI не должен копировать голоса, лица или работы конкретного художника без отдельного разрешения.

## Text-to-speech

- TTS озвучивает narration и отдельные NPC, но текст появляется сразу.
- Игрок может прервать озвучивание и всегда видит transcript.
- Разные голоса — настройка, не источник канона.
- Voice cloning участников/актёров не входит в MVP.
- Включаются captions, volume controls и режим без звука.

## Клиентская стратегия

### MVP

Responsive web/PWA с одной кодовой базой для телефона и desktop:

- на телефоне: активная сцена, персонаж, action button, dice, inventory, push-to-talk;
- на desktop: те же действия плюс расширенный лог и участники;
- WebRTC audio room;
- восстановление после background/screen lock;
- installable PWA, если платформа поддерживает.

### После проверки

Нативные оболочки добавляются после проверки store policy, платежей и retention. Для России Google Play billing остаётся ограниченным [S037], поэтому web checkout и RuStore важнее раннего native-IAP.

## Что не входит в MVP

- открытый marketplace пользовательских миров;
- публичный matchmaking;
- бесконечные кампании;
- tactical grid/map editor;
- видео всех участников;
- несколько игровых систем;
- unrestricted 18+;
- voice cloning;
- spectator production suite;
- автономное обучение модели на пользовательских сессиях.

## Технические acceptance criteria пилота

| Область | Проверяемое условие |
|---|---|
| Канон | 0 необъяснимых расхождений HP/inventory/location в replay suite |
| Privacy | 0 утечек между ветками в adversarial split-party тестах |
| Ambiguity | 100% schema-invalid или многозначных state-changing команд уточняются до commit |
| Dice | Каждый бросок имеет воспроизводимую формулу, modifiers и event reference |
| Recovery | Переподключение не дублирует действие и восстанавливает актуальную сцену |
| Session | 3–5 игроков могут закончить 60–120-минутный сценарий |
| Accessibility | Клавиатура, captions, labels, видимый focus, режим без TTS |
| Latency | p50/p95 измеряются отдельно для STT, adjudication, narration, TTS и image |
| Cost | Считается на завершённый participant-hour, а не на зарегистрированного пользователя |

## Тест длинной памяти до обещания кампаний

Синтетический replay на сотни/тысячи событий должен проверять:

- сохранность предметов, ранений, статусов и обещаний;
- корректную chronology после параллельных веток;
- отсутствие resurrection удалённых/погибших сущностей;
- ссылки на первичные события для каждого важного факта;
- качество retrieval фактов из начала, середины и конца истории;
- отсутствие leakage между private scopes;
- восстановление после смены модели и пересборки summary.

Только после этого «долгая кампания без деградации» может стать публичным обещанием.