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 не является базой данных, кубиком или окончательным судьёй состояния. Он выполняет языковые задачи вокруг детерминированного ядра.

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, но внутри это не свободно общающийся «рой агентов»:

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

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

Рынок уже использует 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 пилота#

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

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

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

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