Skip to content

GOOD_GAME_PASSPORT.md

Latest commit

 

History

History
1104 lines (806 loc) · 82.2 KB

GOOD_GAME_PASSPORT.md

File metadata and controls

1104 lines (806 loc) · 82.2 KB
Raw

Паспорт хорошей игры IMBA

ID: IMBA-GOOD-GAME-PASSPORT-v1
Статус: ARCHIVE UMBRELLA / DO NOT EXTEND AS MONOLITH
Назначение: историческая сводка замысла и общих ворот качества IMBA.
Не является: игровым контентом, рекламным обещанием, автоматической сертификацией текущей сборки или универсальным рецептом успеха.

Новые требования ведутся в независимых модулях. Актуальная карта находится в PASSPORT_INDEX.md. Для визуала нормативным источником является VISUAL_PASSPORT.md; этот монолит больше не расширяется визуальными деталями.

Этот паспорт отвечает на вопрос «что требуется хорошей игре?» через проверяемые обязательства. Исследовательское обоснование находится в GOOD_GAME_RESEARCH.md. Специализированный PROGRESSION_PASSPORT.md подчиняется этому документу: он уточняет прогрессию, но не может отменять честность, доступность, причинность или право на выход.

Нормативные слова:

  • ДОЛЖНО — обязательное условие;
  • СЛЕДУЕТ — сильное правило, отступление требует записанной причины и теста;
  • МОЖЕТ — допустимый вариант;
  • ЗАПРЕЩЕНО — красная линия, которую нельзя компенсировать другими достоинствами.

1. Определение качества

IMBA считается хорошей игрой для своей целевой аудитории, если она:

  1. надёжно создаёт заявленное переживание;
  2. даёт понятные, осмысленные и правдивые действия;
  3. позволяет научиться, сделать собственный выбор и увидеть его цену;
  4. сохраняет целостность механики, визуального языка, темпа и мира;
  5. убирает барьеры, не являющиеся смыслом испытания;
  6. уважает время, внимание и право игрока остановиться;
  7. подтверждает эти свойства повторными тестами с целевыми игроками.

Ни время в игре, ни число возвращений, ни сложность, ни объём контента, ни красота интерфейса отдельно не доказывают качество.

2. Обещание IMBA

2.1 Игровая фантазия

Я вручную строю невозможную силу, вижу доказуемую цену каждого шага, читаю сопротивление живого Мира и постепенно учусь отвечать ему собственным способом.

2.2 Целевой игрок

Первая версия создаётся для игрока, которому интересны:

  • системные и тактические решения;
  • необычная математическая фантазия;
  • медленное обязательное подтверждение вместо автоматического потока;
  • изучение причинности и поведения противостоящего Мира;
  • короткие законченные дуги с долгим следом.

IMBA НЕ ДОЛЖНА притворяться универсальной экшен-игрой. Она МОЖЕТ оставаться нишевой и сложной, но вход, управление и причинность ДОЛЖНЫ быть доступны без знания Lean и внутренней архитектуры.

2.3 Целевые качества опыта

Приоритеты:

  1. причинная ясность — я понимаю, какое действие и закон изменили состояние;
  2. любопытство — я хочу проверить следующую гипотезу о Мире;
  3. мастерство — моё чтение системы становится лучше;
  4. автономия — я выбираю способ ответа, риск и долгий путь;
  5. напряжение обязательства — подтверждение имеет вес;
  6. живой контакт — Мир имеет жизнь, память и различимый ответ;
  7. значимый след — завершённая дуга остаётся в Хронике.
  8. авторство волшебства — надимба собирается игроком, а не выдаётся готовой.

Визуальное погружение СЛЕДУЕТ использовать в поддержку этих качеств. Социальное взаимодействие не является требованием первой версии.

3. Восемь ворот качества

Игра проходит паспорт только при прохождении всех восьми ворот. Среднее арифметическое не используется: потеря состояния, обман или блокирующий интерфейс не компенсируются глубиной либо стилем.

G1. Замысел

ДОЛЖНО быть записано:

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

Каждая крупная функция ДОЛЖНА связываться хотя бы с одним целевым качеством опыта. Функция без такой связи удаляется, упрощается или получает отдельное обоснование.

Проверка: команда может провести цепь правило → динамика → переживание → наблюдаемый признак.

G2. Работоспособность и доверие

Игра ДОЛЖНА:

  • запускаться и доходить до первого действия на поддерживаемой конфигурации;
  • немедленно признавать ввод визуально;
  • показывать ожидание авторитетного ответа, если он не мгновенный;
  • применять один авторитетный результат ровно один раз;
  • сохранять подтверждённое состояние на заявленных границах;
  • восстанавливаться после обновления, повторного открытия или понятной ошибки;
  • никогда не оставлять игрока в неизвестном полусостоянии;
  • воспроизводить наблюдаемую сессию из seed + журнала действий;
  • удерживать основную игровую сцену в одном видимом экране на поддерживаемых размерах.

Для IMBA Lean ДОЛЖЕН оставаться единственным авторитетом правил, которые влияют на исход. Python МОЖЕТ управлять seed, журналом и процессом. UI МОЖЕТ принимать ввод и визуализировать, но НЕ ДОЛЖЕН тайно пересчитывать допустимость, урон, прогрессию или победу.

Блокирующие дефекты: краш критического пути, потеря подтверждённого состояния, двойное действие, рассинхронизация UI и ядра, недоступное единственное действие, выход сцены за экран.

G3. Понятность и причинная обратная связь

В любой момент игрок ДОЛЖЕН суметь найти:

  • текущее состояние игрока и Мира;
  • единственное следующее обязательное действие либо набор доступных решений;
  • ближайшую цель;
  • цену необратимого подтверждения;
  • результат последнего действия;
  • причину, по которой результат допустили или отклонили.

Каждый переход ДОЛЖЕН представляться как:

ДО → ДЕЙСТВИЕ → Δ → ПОСЛЕ → СЛЕДУЮЩАЯ ВОЗМОЖНОСТЬ.

Математическая визуализация ДОЛЖНА показывать публичное вычисление, а не изображать скрытые «мысли». Она СЛЕДУЕТ за игровым смыслом: сначала читается ответ, затем по желанию разбирается доказательная трасса.

Сигналы урона, лечения, барьера, перераспределения, шрама и перегрузки ДОЛЖНЫ различаться минимум по двум каналам из форма / движение / текст / число / звук / цвет. Один цвет недостаточен.

Проверка: после перехода игрок своими словами связывает собственное действие, закон и изменение обеих сторон.

G4. Агентность и осмысленный выбор

Вне явно обозначенного учебного примера значимое решение ДОЛЖНО иметь:

  • не менее двух допустимых вариантов;
  • различимую до выбора цену или риск;
  • разное влияние на состояние, информацию, позицию или будущие возможности;
  • отсутствие заведомо доминирующего ответа во всех контекстах;
  • результат, который не отменяется скрытой подстройкой.

Ритуальный ввод МОЖЕТ не иметь альтернативы, если он создаёт обещанное чувство обязательства. Но не более трёх одинаковых вводов подряд МОГУТ пройти без новой информации, нового риска, выбора, выразительного ответа или рубежа.

Клик по игровому полю как реакция ДОЛЖЕН менять допустимое игровое намерение, а не служить декоративным эффектом. До клика игрок видит возможную область реакции; после — выбранную точку/зону и её цену; затем отдельно подтверждает необратимое действие, если того требует закон шага.

Проверка: при одинаковом состоянии разные осмысленные решения приводят к объяснимо разным продолжениям.

G5. Обучение, вызов и мастерство

Каждый новый закон ДОЛЖЕН проходить цикл:

ПОКАЗАТЬ → БЕЗОПАСНО ПОПРОБОВАТЬ → ПРОВЕРИТЬ В НОВОМ КОНТЕКСТЕ → ОБЪЯСНИТЬ ОШИБКУ → СОЧЕТАТЬ.

Игра ДОЛЖНА:

  • сделать первый осмысленный ввод заметным без внешней инструкции;
  • учить действие в той же форме, в которой оно позже используется;
  • вводить обозначение Lean вместе с игровым смыслом, а не раньше него;
  • давать после поражения новую гипотезу, а не только уменьшение числа;
  • повышать сложность через комбинацию известных законов и новые решения;
  • сохранять пространство для мастерства, не отменённое постоянными бонусами;
  • отделять основную интеллектуальную сложность от барьеров скорости, зрения и моторики.

Скрытая DDA, меняющая объявленный бросок, урон или правило, ЗАПРЕЩЕНА. Директор МОЖЕТ адаптировать только будущую композицию и темп событий по объяснимому состоянию Мира.

Проверка: опытный игрок принимает иные решения, чем новый, и может объяснить выученную закономерность.

G6. Глубина, темп и прогрессия

Короткая петля ДОЛЖНА соединяться с целью сессии и долгим следом:

действие → решение → ответ → локальный рубеж → дуга сессии → Хроника.

Прогрессия ДОЛЖНА:

  • сообщать рост до того, как число станет единственным содержанием;
  • открывать преимущественно новые способы действия и знания;
  • превращать случайное событие в ситуацию для решения;
  • чередовать нарастание, пик и передышку;
  • оставлять естественные точки остановки;
  • сохранять поражение как знание, но не как бесконечную бесплатную силу.

Детальные требования определяет PROGRESSION_PASSPORT.md.

Проверка: игрок может назвать цель текущего действия, сессии и Хроники; следующая попытка отличается возможностью или пониманием, а не только масштабом чисел.

G7. Целостность живого Мира

На основной сцене ДОЛЖНЫ одновременно присутствовать две стороны:

  • слева — Игрок: жизнь/устойчивость, стопка, напряжение, защита и активное намерение;
  • справа — Мир: жизнь, щит, нагрузка, резерв, память и текущая форма компенсации.

Любой удар ДОЛЖЕН показать путь:

намерение атакующего → контакт → реакция защищающегося → признанный урон/поглощение → новое состояние жизни.

Мир НЕ ДОЛЖЕН быть полосой HP с разными названиями одного эффекта. Единый класс COMPENSATION ДОЛЖЕН проявляться множеством форм, различающихся:

  • условием возникновения;
  • визуальным ригом и движением;
  • формулой изменения состояния;
  • требуемой реакцией игрока;
  • долгим следом в памяти Мира и Хронике игрока.

Случайность ДОЛЖНА быть seeded, журналируемой, защищённой от монотонных серий и ограниченной допустимым состоянием. Сильное событие ДОЛЖНО иметь предвестник минимум за одно осмысленное решение.

Проверка: без чтения журнала игрок различает формы ответа и объясняет, что изменилось в жизни Мира.

G8. Доступность, уважение и доказанность

Доступность

Первая поддерживаемая версия ДОЛЖНА обеспечивать:

  • контраст важного стандартного текста/элемента не ниже 4.5:1, крупного — 3:1;
  • отсутствие критической информации только в цвете;
  • полный критический путь с клавиатуры;
  • видимый и логичный фокус;
  • масштабирование текста без потери действия или выхода сцены за экран;
  • настройку уменьшенного движения и отключение несущественных вспышек;
  • паузу или отсутствие реального лимита там, где скорость не является ядром испытания;
  • понятные ошибки и безопасное восстановление;
  • описание доступных настроек до начала сложной дуги.

Если добавится обязательный звук, его смысл ДОЛЖЕН дублироваться визуально. Если добавится обязательная речь, она ДОЛЖНА иметь субтитры.

Уважение

ЗАПРЕЩЕНЫ:

  • daily rewards, streaks и наказание за перерыв;
  • энергия или ресурс, требующий реального ожидания;
  • FOMO, ложная срочность и искусственный дефицит;
  • скрытые вероятности значимых исходов;
  • унизительные названия доступности или сложности;
  • бесконечный обязательный повтор уже освоенного действия;
  • потеря подтверждённого прогресса из-за выхода;
  • метрика «часы в игре» как самостоятельная цель;
  • интерфейс, который мешает отказаться, сохранить или завершить сессию.

Доказанность

Паспорт НЕ МОЖЕТ считаться пройденным только внутренним обзором. Требуются тесты с целевыми игроками, сохранённые наблюдения и решение по каждой гипотезе.

4. Архитектура игрового опыта IMBA

Каждая полная дуга СЛЕДУЕТ одной причинной структуре:

НАМЕРЕНИЕ ИГРОКА
  → накопить тик
  → открыть конструктор заклинания
  → собрать человеческую фразу надимбы
  → получить точную Lean-проекцию
  → подтвердить собственную конфигурацию
  → проявить Imba + 1 либо принять объяснимое последствие ошибки
  → встретить перебитие Природы
  → прочитать четырёхосевое состояние
  → выбрать и подтвердить защиту/реакцию на поле
  → принять остаточный урон или сдаться
  → перенести напряжение и память
  → получить право первого удара
  → увидеть реакцию и изменение жизни Мира
  → оставить след в Хронике
  → выбрать новую гипотезу/Протокол

Для каждого звена ДОЛЖНЫ существовать:

  • входное состояние;
  • допустимое действие;
  • авторитетное правило;
  • мгновенный сигнал принятия;
  • итог и причина;
  • влияние на следующую возможность;
  • событие локального журнала.

Звено без результата, информации, выразительности или позиции к цели считается кандидатом на удаление.

5. Сюжетный канон: Волшебник Изумрудного Мира

5.1 Позиция переосмысления

Сюжет использует public-domain мотивы книги Л. Фрэнка Баума 1900 года: дорогу, дом, разум, сердце, смелость, изумрудный город и разоблачение внешнего величия. IMBA ДОЛЖНА создавать собственные:

  • текст и диалоги;
  • персонажей и их отношения;
  • устройство Изумрудного Мира;
  • визуальные образы;
  • последовательность событий;
  • механику волшебства и финальный выбор.

ЗАПРЕЩЕНО копировать прозу, диалоги, уникальные сцены, персонажей или визуальные решения конкретной поздней адаптации. Рабочее название и терминология до отдельной проверки остаются внутренними.

5.2 Главный тезис

Мир называет свои законы не-магическими. Ворон обнаруживает обратное: каждый устойчивый закон Мира сложен из допустимых магических переходов. Настоящий маг появляется не тогда, когда принимает предложенное чудо, а когда сам строит допустимое заклинание и отвечает за его цену.

Природа — не абсолютный злодей. Она является живой силой непрерывности: перебивает конструкцию, когда та больше не может быть честно продолжена. Мир — не декорация, а второй участник, который лечится, защищается, перегружается, помнит и меняет форму ответа.

5.3 Пять актов

  1. Заклятие и дорога. Ворон идёт к Изумрудному замку, чтобы Волшебник снял заклятие. Заклятие удерживает его между состояниями и одновременно даёт способность колдовать. Каждый доказанный переход превращает один фрагмент заклятия в шаг по зелёной дороге.
  2. Конфликт первой главы. На четвёртом шаге по дороге Ворон видит, что Мир, отрицавший магию, полностью составлен из неё. Он принимает вторую форму WORLD_MAGUS; сюжетная вставка впервые ставит Ворона и Волшебника друг против друга как двух действующих магов.
  3. Живой Мир. Природа перебивает линию; Ворон понимает, что полного непробития нет, но форму и цену ответа можно выбирать. Язык источник → намерение → путь расширяется без отмены уже выученных законов.
  4. Изумрудный порог. Великий образ Волшебника оказывается интерфейсом, который скрывал математику и насылал беды. Дорога приводит к полноценному бою, где публичная трасса и собственные конфигурации Ворона становятся оружием.
  5. Возвращение или хранение. Хроника открывает финальный выбор: вернуться Домой, остаться хранителем непрерывности или освободить язык заклинаний для нового Мира. Выбор ДОЛЖЕН следовать из истории действий, а не из последней кнопки.

5.3.1 Сцена 00: Ворон и его прежняя Тень

До первого игрового действия открывается не географическое место, а чистое информационное поле. Слева находится проявленный цифровой Ворон, справа — его прежняя форма ТЕНЬ: не человек, не двойник и не злодей, а возможность без тела, существовавшая до входа в Мир.

Пролог ДОЛЖЕН:

  • состоять из четырёх коротких диалоговых шагов и одной кнопки ДАЛЕЕ;
  • объяснить, что форма Ворона является заклятием, а Тень — сохранённой связью;
  • связать способность колдовать с границей, пропускающей магию в обе стороны;
  • завершиться намерением идти к Волшебнику по зелёной дороге;
  • блокировать фоновые игровые действия, но оставаться доступным для повторного просмотра через СЦЕНА 00;
  • после сброса Мира снова считаться начальной сценой нового прохождения.

Сценарные звуковые точки уже имеют стабильные идентификаторы PROLOGUE_FIELD / SHADOW_VOICE / CURSE_PULSE / WORLD_GATE. Пока файлов нет, они являются немыми заглушками и НЕ МОГУТ задержать переход. Будущая речь всегда дублируется полным видимым текстом.

Главное меню является явной границей сессии и содержит три действия:

  • ПРОДОЛЖИТЬ возвращает к сохранённому состоянию без сброса;
  • НОВАЯ ИГРА создаёт новый Мир и обязательно запускает СЦЕНУ 00;
  • СЦЕНА 00 повторяет пролог, не меняя текущее состояние прохождения.

Меню и пролог имеют звуковые швы MENU_OPEN / MENU_SELECT, но до появления аудиоассетов остаются полностью немыми и не задерживают ввод.

5.3.1.1 Бюджет веб-сцены

Производительность является входным ограничением, а не этапом полировки. Каждый новый визуальный слой ДОЛЖЕН до интеграции получить бюджет по весу, памяти, числу одновременно движущихся элементов и частоте обновления.

  • в runtime загружаются WebP/AVIF-копии нужного экранного размера; мастер-PNG хранятся вне public;
  • один сюжетный экран стремится удерживать суммарный вес первоначально нужных изображений ниже 500 KB, а отдельное изображение — ниже 250 KB;
  • непрерывно анимируются не более трёх декоративных элементов на сцену;
  • движение ограничивается transform / opacity, а тяжёлые blur-фильтры и покадровые layout-пересчёты запрещены;
  • prefers-reduced-motion отключает декоративное движение без потери смысла;
  • интерфейс не полагается на браузерный масштаб и остаётся одним экраном на профиле Steam Deck 1280×800;
  • регрессия включает production build, SSR-проверку, HTTP smoke-test и замер публичного веса ассетов.

5.3.2 Исполняемый рубеж первой главы

Рубеж НЕ ДОЛЖЕН быть произвольным UI-флагом. Источник истины — Lean-проекция сертификата:

road = min(certificate, 12)
worldTruthKnown = (4 ≤ road)
ravenForm = if worldTruthKnown then WORLD_MAGUS else CURSED_WALKER
chapterConflict = (road = 4)

Сцена КОНФЛИКТ ДОЛЖНА показать Ворона слева, Волшебника справа и неоновую точку соприкосновения между ними. Её математическая подпись — не декоративная «магическая формула», а смысл поворота: World = Σ допустимых магических переходов. После сцены вторая форма сохраняется; повторное открытие сцены на каждом следующем шаге запрещено.

5.3.3 Тень как будущий источник заклинаний высшего порядка

После знакомства Тень остаётся действующим персонажем и позднее МОЖЕТ открывать лексемы SUPER / META / BETA / SHMATA / MATA / QUASI / ULTRA / NANO / PENNO. Комические и чрезмерные имена являются частью голоса игры, но каждая лексема ДОЛЖНА иметь строгий смысл в типизированном AST: усиление, рекурсию, ветвление, композицию, смену масштаба, перенос инварианта или объявленную цену.

Тень НЕ выдаёт готовую «суперсилу». Она расширяет алфавит конструктора только после доказанного рубежа мастерства. Чем выше порядок заклинания, тем больше совместимых частей, сохранённых инвариантов и явной цены должен удержать игрок. Неудачная высшая композиция даёт объяснимый HOLD, а не случайный провал и не скрытый штраф.

5.4 Четыре человеческих мотива

РАЗУМ / СЕРДЦЕ / СМЕЛОСТЬ / ДОМ МОГУТ проецироваться на четыре оси живой памяти, но не как линейные шкалы «получено/не получено». Игрок уже способен на каждое качество; игра раскрывает, как и когда он им пользуется.

  • Разум — чтение закона и предсказание;
  • Сердце — цена, сохранение и связь;
  • Смелость — добровольно принятый риск;
  • Дом — память, граница сессии и причина вернуться.

5.5 Storylets

Сюжет ДОЛЖЕН собираться из авторских storylets с явными:

  • preconditions: Хроника, ранг, состояние обеих сторон, семейство заклинания, напряжение, предыдущие сцены;
  • content: короткая сцена, реплика или изменение среды;
  • effects: флаги знания, доступный словарь, новая интерпретация, но не скрытый пересчёт исхода;
  • id/seed/order: данные для точного replay.

Процедура МОЖЕТ выбирать между допустимыми storylets, но НЕ ДОЛЖНА генерировать непроверенную прозу в runtime или переписывать Lean-состояние.

5.6 Магические дефекты Мира

Контролируемые игровые аномалии МОГУТ использовать классы ошибок как магию:

  • разрыв типа — части заклинания нельзя скомпоновать;
  • потеря связности — переход достигает цели, но разрушает сохраняемое отношение;
  • ложный шаг — путь выглядит допустимым, но не проходит интерфейс I;
  • зацикленное эхо — композиция возвращается в прежнее состояние без эффекта;
  • утечка тика — объявленная цена превышает доступный бюджет;
  • устаревший реликт — атака или реакция ссылается не на текущую голову истории.

Каждая такая аномалия ДОЛЖНА быть воспроизводимой по состоянию/seed, иметь явный нарушенный инвариант, давать HOLD без скрытой порчи состояния и учить игрока исправлению формулы. Настоящий программный дефект, зависание, потеря данных или расхождение UI с Lean ЗАПРЕЩЕНО оправдывать «магией Мира»: это технический баг и блокер качества.

6. Процедурный конструктор заклинания надимбы

6.1 Новый закон подтверждения

Фраза «Подтвердите конфигурацию надимбы» означает самостоятельное создание, а не принятие предложенного результата.

Обязательный переход:

ТИК НАКОПЛЕН → ОТКРЫТЬ КОНСТРУКТОР → СОБРАТЬ ЗАКЛИНАНИЕ → ПРОСМОТРЕТЬ ПРОЕКЦИЮ → ПОДТВЕРДИТЬ → LEAN ADMIT/HOLD.

До подтверждения ранг, сертификат и стопка удерживаются. UI НЕ ДОЛЖЕН заранее выбирать рецепт, отмечать один вариант как рекомендуемый или иметь кнопку, которая подтверждает конфигурацию по умолчанию.

Заклинание не равно магии

ЗАКЛИНАНИЕ — дискретно собранная игроком форма: фраза, AST, интерфейсный переход, ограничения и доказательство допустимости. МАГИЯ — живое изменение состояния Мира, которое возникает только после допуска этой формы.

Визуальный порядок обязателен:

ПРЯМОУГОЛЬНАЯ ФОРМА ЗАКЛИНАНИЯ
  → ПЕЧАТЬ LEAN / APPEND
  → НЕПРЕРЫВНЫЙ НЕОНОВЫЙ ПОТОК МАГИИ
  → НАБЛЮДАЕМЫЙ ЭФФЕКТ В МИРЕ

Заклинание показывается геометрией книги, узлами и чёткой типографикой. Магия показывается органическим свечением, потоком, деформацией и касанием объектов. HOLD не может породить магический поток. Звуковые заглушки также разделены: SPELL_SEAL относится к форме, MAGIC_BLOOM — к возникшему эффекту.

6.2 Формальное основание: интерфейсный морфизм

Центральное определение магии IMBA:

Заклинание — доказательственно несущий интерфейсный морфизм.

Пусть A и B — игровые домены со множествами состояний S_A и S_B; I : S_A → S_B → Prop — интерфейс допустимого перехода; R_A и R_B — выбранные отношения структуры. Тогда:

Mor_I(A,B; R_A,R_B) =
  { f : S_A → S_B |
      (∀ x, I x (f x)) ∧
      (∀ x y, R_A x y → R_B (f x) (f y)) }

То есть кандидат является заклинанием только тогда, когда:

  1. отображает состояние источника в состояние цели;
  2. каждый его переход разрешён текущим интерфейсом;
  3. выбранная связь или структура не теряется после отображения.

Для игровых заклинаний, определённых не на всех состояниях, ДОЛЖНА использоваться частичная форма с явной предпосылкой:

pre  : S_A → Prop
cast : (x : S_A) → pre x → S_B

Невыполненная pre не является исключением или случайной неудачей: она даёт объяснимый HOLD без изменения авторитетного состояния.

Полный контракт заклинания

Одного сохранения отношения недостаточно: постоянное или пустое отображение способно формально сохранять слабую структуру, ничего не давая игре. Поэтому Spell ДОЛЖЕН дополнительно содержать:

source      : Domain
target      : Domain
pre         : S_A → Prop
map         : (x : S_A) → pre x → S_B
interface   : S_A → S_B → Prop
preserves   : ∀ x y (hx : pre x) (hy : pre y),
                R_A x y → R_B (map x hx) (map y hy)
goal        : S_B → Prop
cost        : S_A → S_B → Cost
effect      : S_A → S_B → EffectSignature

Lean ДОЛЖЕН проверять не только admissible и preserves, но также:

  • goal (map x hx) — достигнуто ли заявленное намерение при свидетельстве hx : pre x;
  • cost — находится ли цена в объявленных границах;
  • effect — отличается ли результат от пустого ритуала и какой наблюдаемый след он создаёт.

Связь с пятью частями конструктора

Часть фразы Формальное значение
Источник объект/домен A и допустимое входное состояние
Намерение целевой объект B и предикат goal
Путь кандидат отображения f : S_A → S_B
Голос интерфейс допустимости I и его текущая модуляция Миром
Печать сохраняемое отношение/инвариант и свидетельство preserves

Цена и наблюдаемый эффект выводятся из всей собранной морфологии, а не являются декоративными числами отдельной карточки.

Пример надимбы

A = (rank = r, certificate = C, identity = q)
B = (rank = r+1, certificate = C+1, identity = q)
f(r,C,q) = (r+1,C+1,q)

I = ShadowBoundary допускает ровно один ожидающий тик
R = identity неизменна ∧ C является префиксом C′
goal = rank′ = rank + 1

Даже если f сохраняет внутреннюю структуру, Природа МОЖЕТ честно остановить его, когда (x,f(x)) ∉ I_Nature. Это не случайное разрушение правильного ответа: морфизм структурно корректен, но больше не проходит через интерфейс текущего Мира. Причина ДОЛЖНА быть показана игроку именно в таком разделении.

Композиция заклинаний

Сложное заклинание является цепью:

A ─f→ B ─g→ C

Композиция g ∘ f ДОЛЖНА допускаться только если:

  • выходной домен f совпадает со входным доменом g;
  • интерфейсы I и J имеют доказанное правило композиции в итоговый K;
  • отношение, сохранённое f, достаточно для предпосылки и сохранения g;
  • суммарная цена и эффект находятся в границах;
  • порядок частей не нарушает сертифицированную непрерывность.

Именно композиция создаёт большую процедурную вариативность: генератор предлагает совместимые элементы пути, но игрок является автором цепи, а Lean доказывает её допустимость.

Частные игровые случаи

Механика Морфизм Сохраняемый закон
Создание надимбы (r,C) → (r+1,C+1) identity и сертифицированный префикс
Защита Impact₄D → Absorbed × Damage absorbed + damage = impact, damage > 0
Память сессии Memory → Memory′ identity и монотонный след истории
Инициатива баланса TensionState → BalanceIntent одноразовая ёмкость min(12, ticks + tension + reflection)
Реакция Мира (PlayerVitals × WorldVitals) → (…)′ нулевой урон и восстановление только более слабой стороны
Поворот осей A → A автоморфизм выбранной осевой структуры

Категориальная граница

Термин Mor НЕ ДОЛЖЕН автоматически объявлять всю систему категорией. Категория возникает только после доказательства:

  1. допустимого тождественного морфизма для каждого объекта;
  2. замкнутости допустимых морфизмов относительно композиции;
  3. ассоциативности композиции;
  4. левого и правого законов тождества.

До этих доказательств магия честно называется типизированной сетью или quiver допустимых переходов. Отдельные доказанные подмножества МОГУТ образовывать категории заклинаний.

Рекомендуемый Lean-каркас:

structure InterfaceMorphism
    (A B : Type)
    (I : A → B → Prop)
    (R_A : A → A → Prop)
    (R_B : B → B → Prop) where
  toFun      : A → B
  admissible : ∀ x, I x (toFun x)
  preserves  : ∀ {x y}, R_A x y → R_B (toFun x) (toFun y)

Runtime-реализация СЛЕДУЕТ более общей частичной форме с pre, goal, cost и effect. Показанный каркас фиксирует ядро идеи, но не считается полным игровым контрактом.

6.3 Человеческий язык и точная семантика

Первая полная грамматика:

ИСТОЧНИК → НАМЕРЕНИЕ → ПУТЬ → ГОЛОС → ПЕЧАТЬ

Пример видимой фразы:

Собери волю → подними невозможное → проведи дорогой → верни эхом → скрепи городом.

Под ней показывается точный, но вторичный слой:

Spell {
  source = WILL
  intent = ASCEND
  path   = ROAD
  voice  = ECHO
  seal   = CITY
}

force = 7 / need 6
coherence = 5 / need 5
resonance = 2 / need 2
cost = tension + 1

Каждый видимый термин ДОЛЖЕН соответствовать одному типизированному Lean-конструктору. UI передаёт только идентификаторы конструкторов. Свободный текст игрока НЕ ДОЛЖЕН исполняться как код.

6.4 Большая, но читаемая вариативность

Реализованный вертикальный срез

Текущая авторитетная грамматика содержит четыре термина в каждой базовой позиции, но один термин каждого типа детерминированно закрывается законом слоя:

Позиция Полный словарь Что видит игрок
Источник WILL / SHADOW / MEMORY / SPARK 3 из 4
Намерение RELEASE / REVEAL / BIND / INVERT 3 из 4
Путь ROAD / ECHO / RIFT / ORBIT 3 из 4
Форма, со ступени II BLADE / VEIL / PRISM 3 из 3

lexiconVariant = hash(seed, cycle, tick, rank, certificate) mod 4 выбирается только Lean. Поэтому один закон даёт 3 × 3 × 3 = 27 базовых формул, а после открытия Формы — 27 × 3 = 81. Одинаковые входы всегда дают одинаковый набор. Игрок начинает с пустой формулы, может привязать или снять любую руну; UI не вставляет первый вариант автоматически.

Это первая рабочая мера вариативности, а не конечный размер языка. Расширение ниже остаётся целевой планкой полной версии.

Базовый словарь первой полной версии ДОЛЖЕН иметь минимум 8 терминов на каждую из пяти позиций: не менее 8⁵ = 32 768 синтаксических рецептов до применения контекстных ограничений.

Один конкретный закон слоя СЛЕДУЕТ показывать как пять рядов по четыре контекстно допустимых термина: 4⁵ = 1 024 локальных рецепта без вывода 1 024 кнопок. Игрок выбирает ровно по одной читаемой карточке в каждом ряду.

Число рецептов НЕ является критерием готовности. Генератор отдельно ДОЛЖЕН сообщать:

  • syntacticCount — число собираемых фраз;
  • semanticCount — число разных векторов force/coherence/resonance/cost/memory;
  • viableCount — число допустимых рецептов текущего закона;
  • strategyFamilies — число разных полезных компромиссов;
  • dominanceShare — долю состояний, где один термин или семейство оказывается лучшим.

Синонимы МОГУТ разнообразить рассказ, но НЕ ДОЛЖНЫ учитываться как новая механическая стратегия.

6.5 Процедурный закон слоя

Lean ДОЛЖЕН детерминированно получать закон из:

seed + cycle + pendingTick + currentRank + certificate
+ player/world vitals + Chronicle + recent spell signatures

Закон задаёт:

  • требуемые силу и связность;
  • резонанс или семейство резонансов;
  • допустимую цену;
  • влияние памяти;
  • процедурно выбранные предложения словаря;
  • минимум три допустимых рецепта не менее чем из двух стратегических семейств;
  • предвестник того, какую часть закона изменит следующий Мир.

Генератор создаёт условия и материал, а не готовое решение. Все предложения, требования и результат ДОЛЖНЫ воспроизводиться из seed и журнала.

6.6 Результаты конфигурации

Lean возвращает один из трёх классов:

  1. УСТОЙЧИВО / APPEND. pre, интерфейс, сохранение, цель и бюджет соблюдены; проявляется Imba + 1.
  2. НАПРЯЖЁННО / APPEND WITH COST. Жёсткие инварианты и цель соблюдены, но мягкий бюджет достигнут через объявленный долг; надимба проявляется, а цена явно меняет напряжение, память или нагрузку Мира.
  3. РАЗРУШЕНО / HOLD. Не выполнены pre, интерфейс, сохранение либо цель; ранг и сертификат не меняются, а отказ раскладывается по этим четырём проверкам. Попытка увеличивает видимое напряжение конфигурации; после заранее известного предела Природа может перебить линию.

Случайный процент успеха после правильно собранного рецепта ЗАПРЕЩЁН. Случайность МОЖЕТ процедурно менять закон до выбора, но не подменять признанное соответствие после подтверждения.

6.7 Окно конструктора

Конструктор вызывается отдельным модальным окном внутри полноэкранной игры, а не системным popup и не новой вкладкой. Он ДОЛЖЕН:

  • помещаться в текущий viewport без прокрутки всей игры;
  • иметь пять последовательно читаемых рядов;
  • сразу собирать выбранные части в одну крупную фразу;
  • показывать A → B, интерфейс I и сохраняемый закон человеческими словами;
  • показывать живые шкалы силы, связности, резонанса, цены и памяти;
  • раскрывать Lean-формулу отдельным вторичным слоем;
  • позволять клавиатурный выбор, возврат и замену любой части;
  • иметь отдельные действия ПРОВЕРИТЬ и ПОДТВЕРДИТЬ;
  • запрещать подтверждение неполной фразы;
  • после HOLD сохранять выборы и подсвечивать конкретные несовпадения без ответа «просто неверно».

Визуальная метафора: изумрудная книга/чертёж заклинания, где фразы соединяются светящимися связями, а под ними проявляется математический граф. Декор НЕ ДОЛЖЕН скрывать текст, фокус или итог.

6.8 Прогрессия языка

Игрок СЛЕДУЕТ осваивать не всё пространство сразу:

  • сначала три позиции и по два термина;
  • затем добавляются Печать и Цена/Память;
  • Хроника открывает новые термины и объясняет их закономерности;
  • Протоколы меняют доступную информацию или способ сборки, а не дают автоматический правильный рецепт;
  • сохранённые «формулы» МОГУТ быть шаблонами, но новый закон требует осмысленной адаптации.

Первый рабочий вертикальный срез использует три ступени сложности и одну мета-ступень. Источником порогов является только Lean:

Ступень Условие Что становится обязательным Новый вопрос игрока
I · Основа certificate < 4 Источник + Намерение + Путь «Хватает ли моей формуле силы, связности и резонанса?»
II · Форма certificate ≥ 4 Основа + отдельная Форма «Как заклинание войдёт в Мир: лезвием или покровом?»
III · Синергия certificate ≥ 8 Форма и один совпавший рецепт синергии «Какие части усиливают друг друга как единая мысль?»
META · Мастерство masteryMarks ≥ 3 удачная синергия усиливается вдвое «Как применить знание прошлых сессий к новому закону?»

Ступень НЕ добавляет пассивное +damage. Она добавляет новый обязательный тип решения. Мета-ступень сохраняется между сессиями через Хронику, но усиливает только созданную игроком синергию и потому не может заменить сборку.

Рабочие синергии первого словаря:

Синергия Рецепт Бонус до META Смысл
EDGEWAY / Лезвие дороги BLADE + ROAD +1F +1C +1R форма разреза продолжает направление пути
UMBRA / Сцепление с Тенью VEIL + SHADOW +1F +1C +1R источник и форма образуют одну теневую границу
REVELATION / Эхо откровения REVEAL + ECHO + любая проявленная форма +0F +1C +2R намерение раскрытия возвращается усиленным смыслом
REMEMBRANCE / Память покрова MEMORY + ECHO + VEIL +0F +2C +2R прежняя форма возвращается в защищающем контуре
NOVA / Изумрудная нова SPARK + ORBIT + PRISM +2F +0C +2R искра замыкается орбитой и преломляется в Мир
RIFTBLADE / Лезвие разлома INVERT + RIFT + BLADE +2F +1C +0R давление обращается и получает режущую границу

На META 1 численный вклад совпавшей синергии удваивается. UI ДОЛЖЕН показывать название, значок, рецепт и точный вклад до подтверждения. Неактивная синергия показывается как отсутствующая связь, а не как случайный процент неудачи.

Автосборка, best spell, обязательный рекомендованный рецепт и покупка готового ответа ЗАПРЕЩЕНЫ.

6.9 Формальные свойства будущей реализации

Lean ДОЛЖЕН доказать или исчерпывающе проверить:

  1. каждый сгенерированный закон имеет не менее трёх допустимых рецептов;
  2. HOLD не меняет ранг, сертификат и проявленную стопку;
  3. APPEND повышает ранг ровно на один и расширяет сертификат ровно на один;
  4. одно подтверждение создаёт не более одной фишки;
  5. одинаковый seed, state и AST дают одинаковый результат;
  6. UI-ярлык не влияет на семантику конструктора;
  7. цена не становится отрицательной и не переполняет состояние;
  8. скрытая Природа не меняет уже объявленный закон после подтверждения;
  9. сохранённый шаблон не обходится без повторной проверки текущего закона;
  10. генератор не выдаёт единственный рецепт как скрытый пароль.
  11. admissible и preserves являются разными проверками и имеют разные причины HOLD;
  12. композиция разрешена только для совместимых доменов и интерфейсов;
  13. пустой сохраняющий морфизм не проходит без заявленного goal/effect;
  14. категориальные свойства не заявляются до отдельных доказательств identity/composition laws.

6.10 Проверка реального разнообразия

До плейтеста требуется пакетная симуляция минимум 10 000 детерминированных законов. Она ДОЛЖНА искать:

  • неразрешимые законы;
  • законы с одним решением;
  • термины, которые никогда не полезны;
  • семейства, доминирующие независимо от состояния;
  • разные фразы с полностью одинаковым исходом;
  • слишком частые или слишком редкие narrative storylets;
  • длинные серии одного и того же резонанса или визуального рига.

Численные границы баланса фиксируются до прогона и пересматриваются только с записанной причиной.

7. Три уровня интерфейса

7.1 Игровой смысл — всегда первый

Основная сцена ДОЛЖНА за один взгляд сообщать:

  • кто действует;
  • что поставлено на карту;
  • куда можно отреагировать;
  • что произошло с Игроком и Миром;
  • какое действие ожидается дальше.

7.2 Математическая сцена — по действию

При нажатии поле МОЖЕТ временно становиться визуализацией вычисления. Она ДОЛЖНА:

  • использовать только фактические входы и выходы перехода;
  • показывать формулу, подстановку, guard и APPEND/HOLD;
  • оставаться связанной с объектами Игрока и Мира;
  • иметь сокращённый читаемый итог;
  • не блокировать следующий ввод после завершения.

7.3 Аудит — по запросу

Полная трасса, seed, epoch, head, сертификат и журнал ДОЛЖНЫ быть доступны для проверки, но НЕ ДОЛЖНЫ конкурировать с основным действием за внимание новичка.

7.4 Визуальный алфавит контакта

Контакт и реакция ДОЛЖНЫ считываться раньше поясняющего текста. Каждый факт кодируется одновременно значком + направлением + числом + коротким названием; цвет является дополнительным каналом и никогда не несёт смысл в одиночку.

Минимальный алфавит вертикального среза:

Факт Знак Обязательная визуальная роль
инициатива Игрока ⚖ ограниченная ёмкость возникает между Вороном и Миром
прямой урон ▼ число потери рядом с жизнью цели
восстановление ✚ число возврата жизни
барьер ⬡ число поглощения или новой защиты
нагрузка ⌁ цена реакции Мира
перераспределение ⇌ перенос потока между резервом, щитом и жизнью
синергия ⟐ / ◈ / ✺ связь выбранных частей заклинания

Один класс COMPENSATION МОЖЕТ иметь множество форм, но форма всегда получает собственный знак, силуэт рига, движение и строку изменения vitals. Текстовая причина остаётся доступной; значок сокращает поиск, но не заменяет объяснение.

7.5 Визуальная грамматика конструирования

Правило и его изображение являются одной системой. Каждый тип заклинания имеет собственную неизменную визуальную обязанность:

Правило Что оно решает Что обязано измениться на поле
Источник из какого состояния берётся сила материал, цветовой акцент и силуэт ядра
Намерение что игрок хочет сделать направление и временной характер движения
Путь как переход проходит через Мир траектория: дорога, эхо, разлом или орбита
Форма какая граница удерживает эффект внешний контур: лезвие, покров или призма
Синергия какие части образовали новое целое отдельный соединяющий знак и импульс связи
F/C/R выдерживает ли формула закон состояние печати: устойчиво, на грани или распад

Во время сборки поле показывает не готовую карточку, а растущую печать и цепь узлов. Пустой узел обозначает нерешённый вопрос; заполненный — выбор игрока; текущий — следующий необходимый тип. Повторное нажатие снимает руну.

Предварительная оценка UI является только читаемой проекцией объявленных Lean порогов и баллов. Финальный вердикт, цена и изменение состояния всегда приходят из Lean. После подтверждения выбранные Источник, Намерение, Путь, Форма и Синергия продолжают жить в эффекте: его силуэт, движение и траектория не могут схлопываться в один универсальный неоновый всплеск.

Критический смысл ДОЛЖЕН дублироваться формой, знаком и текстом, а не только цветом. Анимация ведёт взгляд по причинной цепи выбор → связь → проверка → эффект; режим prefers-reduced-motion сохраняет ту же причинность без необязательного движения.

8. Бюджет внимания и один экран

В каждый момент ДОЛЖЕН быть один визуальный приоритет первого уровня. Остальные данные группируются как:

  1. сейчас: действие и непосредственная ставка;
  2. сразу после: изменение Игрока и Мира;
  3. почти: ближайший рубеж;
  4. глубже: математическая трасса и Хроника.

На поддерживаемом desktop viewport:

  • документ и основная сцена НЕ ДОЛЖНЫ иметь вертикальную или горизонтальную прокрутку во время боя;
  • панели МОГУТ уплотняться, переходить в сворачиваемые слои или увеличиваться по запросу;
  • масштабирование НЕ ДОЛЖНО скрывать единственное действие;
  • активная реакция на поле ДОЛЖНА оставаться внутри видимой квадратной области;
  • состояние обеих сторон ДОЛЖНО оставаться читаемым одновременно.

9. Измерение опыта

9.1 Что измерять

Основные конструкты PXI для IMBA:

  • простота управления;
  • обратная связь прогресса;
  • ясность целей и правил;
  • вызов;
  • мастерство;
  • любопытство;
  • автономия;
  • смысл;
  • аудиовизуальная привлекательность.

Погружение измеряется как вторичный эффект. Шкала используется целиком и без переписывания вопросов. Одна оценка не превращается в «общий балл хорошести».

Наблюдаемые признаки:

  • найден ли первый ввод;
  • замечено ли изменение обеих сторон;
  • прочитана ли цена до подтверждения;
  • меняется ли стратегия после поражения;
  • используются ли разные реакции в разных состояниях;
  • открывается ли полная трасса добровольно;
  • где игрок хочет остановиться;
  • выбирает ли он ещё одну попытку при явной возможности закончить.
  • может ли он прочитать собранное заклинание как намерение;
  • понимает ли он, какой термин изменил математический результат;
  • создаёт ли второй закон новый рецепт, а не повтор первого решения;
  • ощущает ли он авторство или угадывание скрытого пароля.

Последний пункт — сигнал интереса, но не самостоятельная цель оптимизации.

9.2 Локальный журнал

До отдельного согласия внешняя аналитика ЗАПРЕЩЕНА. Локально СЛЕДУЕТ записывать:

session_started
goal_seen
action_offered
spell_builder_opened
spell_term_selected
spell_previewed
spell_confirmed
spell_appended
spell_held
spell_family_changed
field_reaction_selected
action_confirmed
action_rejected
result_seen
cause_opened
world_vital_changed
player_vital_changed
strategy_changed
milestone_reached
session_saved
session_finished
session_exited
error_recovered

Каждая запись ДОЛЖНА иметь локальные seed, cycle, epoch, тип действия и версию правил. Персональные данные и удалённая отправка не требуются.

10. Программа плейтеста

Этап 0 — внутренний аудит

  • пройти все ворота по сборке;
  • проверить критический путь автоматически;
  • провести клавиатурный и визуальный аудит;
  • зафиксировать гипотезы, а не исправдывать заранее известные проблемы.

Этап 1 — формативный тест

Состав: 5 новых целевых игроков и 3 возвращающихся. Малой выборки достаточно для поиска повторяющихся проблем, но не для статистического доказательства.

Сценарий нового игрока:

  1. начать без объяснения автора;
  2. накопить первый тик и открыть конструктор;
  3. самостоятельно собрать и подтвердить первое заклинание надимбы;
  4. встретить Природу;
  5. сделать реакцию на поле и защититься;
  6. закончить одну дугу до ответа Мира;
  7. увидеть Хронику и возможность продолжить или выйти;
  8. ответить на короткое интервью и PXI.

Модератор сначала наблюдает молча. Think-aloud применяется отдельным проходом, если вопрос касается понимания, потому что проговаривание меняет естественный темп.

Этап 2 — исправление RITE

Ясная и безопасная проблема МОЖЕТ исправляться между участниками. Изменение фиксируется вместе с номером сборки; результаты до и после не смешиваются как одна выборка.

Приоритет исправлений:

  1. блокер и потеря доверия;
  2. непонимание действия или результата;
  3. ложный/пустой выбор;
  4. несправедливый вызов;
  5. темп;
  6. баланс чисел;
  7. косметика.

Этап 3 — валидация

После стабилизации СЛЕДУЕТ провести тест на 12–20 целевых игроках с заранее записанными критериями. Цель — подтвердить конкретную версию и опыт, а не доказать универсальную привлекательность.

Этап 4 — регрессия

Каждая новая механика ДОЛЖНА повторно проверить:

  • причинность;
  • доступность полного пути;
  • воспроизводимость;
  • один экран;
  • красные линии;
  • уже подтверждённые точки обучения.

11. Критерии принятия вертикального среза

Это стартовые продуктовые гипотезы, а не научные константы.

Обязательные нулевые допуски

  • 0 крашей на критическом пути;
  • 0 потерь подтверждённого состояния;
  • 0 молча проигнорированных вводов;
  • 0 расхождений между показанным итогом и авторитетным ответом;
  • 0 недоступных с клавиатуры обязательных действий;
  • 0 выходов основной боевой сцены за поддерживаемый viewport;
  • 0 случаев, где критический смысл передан только цветом;
  • 0 тёмных паттернов из раздела G8.

Ранний тест на пяти новых игроках

  • минимум 4 из 5 находят первый осмысленный ввод без подсказки;
  • минимум 4 из 5 после первой дуги называют ближайшую цель;
  • минимум 4 из 5 без подсказки собирают полную фразу и до подтверждения объясняют её намерение;
  • минимум 4 из 5 после Lean-проекции указывают, какая часть рецепта изменила итог;
  • минимум 4 из 5 связывают последний признанный урон с действием и реакцией;
  • минимум 4 из 5 до подтверждения называют различие между двумя предложенными реакциями;
  • минимум 4 из 5 различают Игрока и Мир и замечают изменение их жизни;
  • все участники могут сохранить/закончить сессию без угрозы потери серии;
  • ни один участник не застревает без понятного способа продолжить или восстановиться.

Если критерий не пройден, проблема считается гипотезой дизайна или интерфейса, а не ошибкой игрока.

Критерии глубины после двух сессий

  • игрок может назвать хотя бы одну выученную причинную связь;
  • игрок хотя бы раз меняет реакцию из-за состояния Мира;
  • поражение приводит к новой сформулированной гипотезе;
  • Протокол влияет на выбор, а не только на число;
  • повторная дуга содержит новый контекст до четвёртого одинакового ввода;
  • игрок может объяснить, что навсегда осталось в Хронике.

12. Паспорт функции

До реализации каждой крупной функции заполняется карточка:

Название:
Целевой игрок/момент:
Какое качество опыта поддерживает:
Игровое обещание:
Новый осмысленный выбор:
Цена/риск:
Входное состояние:
Авторитетное правило Lean:
Немедленная обратная связь:
Изменение Игрока:
Изменение Мира:
Долгий след:
Доступность:
Риск тёмного паттерна:
Гипотеза плейтеста:
Критерий решения:
Автоматические проверки:

Если поля «новый осмысленный выбор», «качество опыта» и «гипотеза плейтеста» пусты, функция не готова к производству.

13. Пакет доказательств релиз-кандидата

Релиз-кандидат ДОЛЖЕН иметь:

  • версию обещания и целевой аудитории;
  • карту полной игровой дуги;
  • список поддерживаемых viewport и способов ввода;
  • результаты автоматических проверок;
  • replay минимум одной полной дуги;
  • отчёт expressive range генератора заклинаний;
  • проверку разрешимости процедурных законов;
  • реестр storylets, их предусловий и покрытия;
  • accessibility checklist;
  • журнал найденных блокеров и их решений;
  • протокол последнего формативного и валидационного плейтеста;
  • результаты PXI по конструктам, без искусственного общего балла;
  • список известных ограничений;
  • аудит красных линий;
  • решение PASS / CONDITIONAL / FAIL по каждым воротам.

CONDITIONAL допустим для экспериментальной сборки, если условие явно видно команде и не затрагивает безопасность, данные, обман или обязательную доступность. Публичный релиз не МОЖЕТ объявляться соответствующим паспорту при FAIL.

14. Definition of Done хорошей игры

IMBA НЕ считается соответствующей этому паспорту, пока одновременно не выполнено:

  • обещание опыта сформулировано и связано с механиками;
  • критический путь работоспособен, воспроизводим и восстанавливаем;
  • игрок видит Игрока слева, живой Мир справа и причинность их обмена;
  • поле принимает осмысленную реакцию и показывает её цену;
  • игрок сам собирает надимбу в читаемом конструкторе, а Lean проверяет её типизированную семантику;
  • процедурность создаёт несколько жизнеспособных решений и не подменяет выбор готовым рецептом;
  • изумрудный сюжет причинно следует Хронике и решениям, оставаясь оригинальным авторским текстом;
  • математическая сцена объясняет реальный переход, не скрывая игровой итог;
  • обучение приводит к различимому росту мастерства;
  • выборы меняют продолжение и не имеют одной вечной доминирующей стратегии;
  • прогрессия открывает возможности и знание, а не только числа;
  • основной бой помещается в один экран;
  • обязательный путь доступен с клавиатуры, не полагается только на цвет и поддерживает уменьшенное движение;
  • игра имеет честную точку сохранения и выхода;
  • красные линии пройдены без исключений;
  • целевые игроки подтвердили замысел поведением и отчётом;
  • пакет доказательств сохранён рядом с версией сборки.

Паспорт пересматривается после каждого содержательного плейтеста. Изменения целевого обещания, красных линий или границы полномочий Lean требуют явного решения владельца игры и новой версии паспорта.