Тема 5. Защита финального проекта

Финальная тема курса посвящена не придумыванию новых идей, а сборке, проверке и защите уже найденного игрового ядра. К этому моменту у проекта должен быть выбранный путь разработки, сформулированная ключевая фишка, первый playable slice, результаты защиты фишки и список доработок. Теперь задача меняется: студент должен превратить рабочее ядро в завершенный учебный продукт. Итог курса — не большая книга правил, не энциклопедия мира и не черновик “когда-нибудь будущей системы”. Итогом становится quickstart-пакет настольно-ролевой игры: компактный набор материалов, по которому другой человек может провести стартовую сессию или короткий ваншот.

Финальная защита отвечает на главный вопрос всего курса: стала ли идея играбельной системой? На предыдущих этапах студент доказывал, что у проекта есть фишка. Теперь нужно доказать больше: что вокруг этой фишки собраны правила, персонажи, последствия, листы, сценарная структура и объяснение, достаточные для проведения игры.

Финальный проект в этом курсе не должен имитировать коммерческий core rulebook на 300 страниц. Для учебного формата это неверная цель. Большой объем может скрывать слабую систему: много лора, длинные списки способностей, десятки таблиц и сложная терминология создают впечатление масштаба, но не доказывают, что игра работает. В версии курса на 64 часа итоговый проект должен быть компактным. Лучше сделать маленькую игру, в которую можно сыграть, чем огромную систему, которую невозможно проверить.

Финальный проект — это игра малого формата, рассчитанная на одну стартовую сессию или короткий ваншот. Она должна иметь понятную фишку, базовые правила, рабочий лист персонажа, инструменты ведущего, стартовую ситуацию и примеры применения правил. В исходном алгоритме разработки НРИ финальная часть логично приводит к двум важным элементам: примерам применения правил и ваншоту. Это показательно: система не считается завершенной, пока не ясно, как ею пользоваться за столом и в какой ситуации она раскрывается. Иными словами, финальный проект должен быть не только написан, но и запускаем.

Quickstart — это краткая версия игры, которая позволяет начать играть без чтения полного рулбука. В учебном курсе это идеальный формат: он заставляет автора выбирать главное, объяснять правила ясно и доказывать работоспособность системы через практику. Quickstart-пакет должен быть достаточно коротким, чтобы его можно было прочитать перед игрой, и достаточно полным, чтобы не требовать постоянных устных пояснений автора.

Рекомендуемый объем — 8–12 страниц без учета приложений, если они нужны. Это не жесткое ограничение, но полезный ориентир. Если студенту требуется 30 страниц, чтобы объяснить базовую игру, скорее всего, система пока перегружена. Если достаточно двух страниц, возможно, не хватает примеров, последствий и инструментов ведущего.

В quickstart-пакет входят:

1. Краткое описание игры. О чем игра, кто такие игроки, какую роль занимает ведущий, сколько длится сессия, какой опыт обещает проект.
2. Ключевая фишка. Фишка должна быть сформулирована ясно и сразу. Читатель должен понять, ради чего существует эта игра.
3. Базовый игровой цикл. Что происходит во время партии: как начинается сцена, что делают игроки, когда включаются правила, как определяется исход, как последствия двигают игру дальше.
4. Правила персонажей. Как создается персонаж или как выбирается готовый персонаж. Какие параметры важны. Что на листе персонажа действительно используется.
5. Правила проверок или процедур. Как игра работает с неопределенностью, риском, конфликтом, выбором, ресурсами или нарративными последствиями.
6. Последствия. Что происходит после успеха, частичного успеха, провала, сделки, потери ресурса или другого ключевого исхода.
7. Лист персонажа. Он должен быть не приложением “для красоты”, а интерфейсом системы.
8. Лист ведущего или GM cheat sheet. Краткая памятка, которая помогает провести игру: как ставить сцены, как создавать угрозы, как использовать фишку, как двигать темп.
9. Стартовый ваншот. Ситуация, в которой игра быстро показывает себя. Ваншот не должен быть длинным литературным сценарием. Он должен быть игровым двигателем.
10. Примеры применения правил. Минимум несколько примеров: как проходит проверка, как выбирается цена, как работает последствие, как ведущий запускает сцену.
11. Отчет о плейтестах. Краткий аналитический текст: что проверялось, что произошло, какие изменения были внесены.

После защиты ключевой фишки у студента обычно появляется соблазн расширять проект во все стороны. Если фишка наконец заработала, хочется добавить больше мира, больше правил, больше персонажей, больше возможностей. Это естественно, но на финальном этапе особенно важно удерживать фокус. Финальная сборка не означает “добавить все, что можно”. Она означает “добавить только то, без чего нельзя провести игру”. На предыдущем этапе студент доказал ядро. Теперь нужно построить вокруг него минимальную рабочую оболочку.

Например, если фишка игры — общий запас кислорода, который тратится на успехи, финальная сборка должна ответить на практические вопросы: Как начинается экспедиция? Сколько кислорода есть у группы? Кто решает, когда его тратить? Что происходит, когда кислород заканчивается? Какие действия требуют проверки? Как ведущий создает ситуации, где кислорода не хватает на все? Как выглядит персонаж в такой игре? Какая стартовая сцена быстро показывает цену успеха?

Если фишка игры — доставка писем между мирами и выбор между правдой и милосердием, финальная сборка должна ответить на другие вопросы: Как создается письмо? Кто отправитель и адресат? Что значит передать письмо точно? Что значит исказить письмо? Какие последствия получает курьер? Как меняется доверие? Как ведущий создает доставку без очевидно правильного решения? Как игрок понимает, что его выбор важен? Финальная сборка всегда должна возвращаться к фишке. Если новый элемент не помогает запустить, объяснить или усилить фишку, его лучше не включать.

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

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

Примеры — обязательная часть финального проекта. Без них правила часто остаются формально понятными, но практически неясными. Пример должен показывать не “литературную красоту” мира, а работу системы. Если есть проверка, нужен пример проверки. Если есть цена успеха, нужен пример цены. Если есть частичный успех, нужен пример частичного успеха. Если есть сделка, нужен пример сделки. Если есть общий ресурс, нужен пример его траты. Если есть нарративная процедура, нужен пример сцены, где она запускается. Плохой пример: “Игрок бросает кубик и узнает результат”. Хороший пример: “Мира хочет вскрыть аварийный шлюз до прихода бури. Ведущий говорит, что это рискованное действие: шлюз можно открыть, но потребуется потратить кислород. Игрок бросает проверку и получает частичный успех. Шлюз открывается, но группа выбирает цену: потерять 2 единицы кислорода сейчас или оставить одного персонажа с поврежденным скафандром до конца сцены”. Такой пример показывает сразу несколько вещей: ситуацию, действие, риск, бросок, исход, цену и выбор.

Для нарративной игры пример может выглядеть иначе: “Курьер приносит письмо женщине, которая десять лет ждала вестей от сына. В письме сказано, что сын жив, но не хочет возвращаться. Игрок может передать письмо точно, смягчить формулировку или скрыть часть сообщения. Точная передача сохраняет доверие гильдии, но разрушает надежду адресата. Искажение письма дает адресату покой, но создает долг перед отправителем. Игрок выбирает смягчить письмо, и ведущий отмечает трещину в доверии гильдии”. Здесь пример показывает, что центральная сцена строится не вокруг броска, а вокруг выбора и последствия.

Лист персонажа — один из самых честных способов проверить, о чем игра на самом деле. Автор может говорить, что игра про память, доверие или моральный выбор, но если лист персонажа состоит только из силы, ловкости, брони, урона и оружия, игрок получит другой сигнал. Лист персонажа должен быть связан с фишкой. Если игра про память, на листе должны быть воспоминания, утраты, забытые имена, чужие истории или то, что можно стереть ради силы. Если игра про доверие, на листе должны быть связи, долги, обещания, уровень доверия, предательства или совместные ресурсы. Если игра про охоту на чудовищ ценой превращения, на листе должны быть признаки чудовищности, человеческие связи, шрамы, запреты, черты добычи. Если игра про экспедицию и кислород, на листе должны быть роль в группе, личная цель, слабость, способность, влияние на общий ресурс и, возможно, отношение к другим участникам. В исходном алгоритме разработки системы НРИ лист персонажа описан как способ удобно разместить важные показатели и подсказки, а также как инструмент, который помогает визуализировать саму систему. Это важная мысль: чарник не просто обслуживает готовые правила, он показывает, какие правила действительно нужны. На финальной защите студент должен быть готов объяснить каждое важное поле листа персонажа. Если поле не используется в игре, его нужно убрать. Если фишка не отражена в листе, лист нужно пересобрать.

В настольно-ролевой игре система работает не только через игроков, но и через ведущего. Поэтому финальный проект должен включать не только правила для персонажей, но и инструменты для проведения. Лист ведущего или GM cheat sheet нужен для того, чтобы другой человек мог понять, как запускать сцены, поддерживать темп и проявлять фишку игры. Ведущему нужно знать: Как начинается сцена? Как выбрать угрозу? Когда требовать проверку? Когда не требовать проверку? Как задавать цену? Как использовать провал? Как вводить последствия? Как поддерживать центральный конфликт? Как завершать сцену? Как переходить к следующей? Если игра идет через механику, лист ведущего должен помогать применять механику. Например: таблица осложнений, уровни угрозы, правила траты ресурса, подсказки по сложности, список возможных цен. Если игра идет через нарратив, лист ведущего должен помогать создавать нужный тип сцен. Например: вопросы к персонажам, шаблон моральной дилеммы, список признаков нарастающего страха, способы вернуть в игру доверие, память, долг или запрет. Ведущий не должен быть вынужден угадывать авторский замысел. Если игра требует от ведущего слишком много импровизации без инструментов, это слабость документации.

Стартовый ваншот — обязательная часть финального проекта. Он показывает, в какой ситуации система раскрывается лучше всего. Ваншот не должен быть рассказом с заранее определенными сценами и финалом. В НРИ игроки должны иметь пространство действия. Поэтому хороший ваншот — это не “сюжет, который нужно пройти”, а конфликтная машина, которая запускает правила и заставляет фишку проявиться. В исходном алгоритме разработки НРИ ваншот предлагается строить через две сюжетные ветки: основную и фоновую. Основная ближе к персонажам и может завершиться быстрее. Фоновая развивается независимо от игроков и может стать основной, если они с ней столкнутся. Также выделяются стартовая ситуация, важные NPC, локации, факты, предметы и идеальная сцена, которая показывает стиль игры.

Для финального проекта это можно упростить, но логика остается полезной. Ваншот должен включать: Стартовую ситуацию. Где находятся персонажи, почему они уже вовлечены, что требует решения прямо сейчас. Центральный конфликт. Что невозможно оставить как есть. Личные крючки. Почему персонажам не все равно. Основные силы или стороны конфликта. Не обязательно “враги”. Это могут быть отправитель и адресат, община и ведьма, экспедиция и ресурс, долг и желание, правда и милосердие. Локации или сцены. Куда игроки могут пойти, где происходят ключевые выборы. NPC или фигуры давления. Те, кто требует, просит, мешает, соблазняет, обвиняет или предлагает цену. Идеальную сцену фишки. Сцену, где игра показывает себя лучше всего. Если после этой сцены фишка не видна, ваншот нужно менять. Возможные последствия. Не один финал, а набор направлений: что может измениться в зависимости от решений игроков. Хороший ваншот не обязан быть длинным. Но он обязан быть точным.

Финальный проект должен пройти плейтест. В версии курса на 64 часа достаточно минимум двух плейтестов за весь проект: один на этапе защиты фишки и один ближе к финальной сборке. Если есть возможность, один из них лучше провести на внешней группе, то есть не только с однокурсниками, которые уже понимают контекст курса. Финальный плейтест отличается от проверки фишки. На защите фишки студент проверял центральное ядро. Теперь он проверяет, можно ли провести игру как цельный quickstart. В финальном плейтесте нужно смотреть: Понятно ли игрокам, кто они? Достаточно ли быстро начинается игра? Не перегружено ли объяснение правил? Работает ли лист персонажа? Понимает ли ведущий, как ставить сцены? Возникает ли заявленная фишка? Работают ли последствия? Не ломается ли темп? Хватает ли ваншота для демонстрации системы? Можно ли провести игру без постоянных пояснений автора? Важно фиксировать не только отзывы, но и наблюдения. Игроки могут сказать, что им понравился мир, но это не доказывает, что система работает. Нужно смотреть, какие решения они принимали, когда обращались к правилам, где теряли интерес, где спорили, где начинали играть именно в заявленную фишку.