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

Как собрать НРИ в завершенный quickstart-пакет и доказать, что в нее можно играть

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

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

Что значит «финальный проект» в рамках этого курса

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

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

Quickstart-пакет как форма итоговой работы

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

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

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

Краткое описание игры. О чем игра, кто такие игроки, какую роль занимает ведущий, сколько длится сессия, какой опыт обещает проект.
Ключевая фишка. Фишка должна быть сформулирована ясно и сразу. Читатель должен понять, ради чего существует эта игра.
Базовый игровой цикл. Что происходит во время партии: как начинается сцена, что делают игроки, когда включаются правила, как определяется исход, как последствия двигают игру дальше.
Правила персонажей. Как создается персонаж или как выбирается готовый персонаж. Какие параметры важны. Что на листе персонажа действительно используется.
Правила проверок или процедур. Как игра работает с неопределенностью, риском, конфликтом, выбором, ресурсами или нарративными последствиями.
Последствия. Что происходит после успеха, частичного успеха, провала, сделки, потери ресурса или другого ключевого исхода.
Лист персонажа. Он должен быть не приложением «для красоты», а интерфейсом системы.
Лист ведущего или GM cheat sheet. Краткая памятка, которая помогает провести игру: как ставить сцены, как создавать угрозы, как использовать фишку, как двигать темп.
Стартовый ваншот. Ситуация, в которой игра быстро показывает себя. Ваншот не должен быть длинным литературным сценарием. Он должен быть игровым двигателем.
Примеры применения правил. Минимум несколько примеров: как проходит проверка, как выбирается цена, как работает последствие, как ведущий запускает сцену.
Отчет о плейтестах. Краткий аналитический текст: что проверялось, что произошло, какие изменения были внесены.

От фишки к полной сборке

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

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

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

Правила должны быть написаны как интерфейс

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

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

Примеры в тексте правил

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

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

Лист персонажа как доказательство системы

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

Лист ведущего и процедуры сцены

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

Ваншот как демонстрация игры

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

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

Плейтест финального проекта

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

Отчет о плейтестах

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

Подготовка к финальной защите

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

Короткий питч игры. Одно-два предложения. Кто игроки, что они делают, в чем фишка.
Выбранный путь. Через механику или через нарратив. Почему этот путь был выбран.
Ключевая фишка. Как она сформулирована и как изменилась после промежуточной защиты.
Демонстрация системы. Показ базового цикла: сцена → действие → проверка или процедура → исход → последствие.
Лист персонажа. Краткое объяснение, почему на нем именно эти поля.
Инструменты ведущего. Как ведущий запускает сцены и поддерживает фишку.
Ваншот. Какая стартовая ситуация показывает игру.
Плейтесты и итерации. Что проверялось, что не работало, что было изменено.
Финальный вывод. Почему проект достиг состояния playable quickstart. Защита должна быть не рассказом обо всем мире, а доказательством работоспособности системы.

Что показывать на защите

Студент должен принести не только презентацию, но и проектные материалы. Минимальный набор: quickstart-рулбук; лист персонажа; лист ведущего или памятка; стартовый ваншот; отчет о плейтестах; короткая презентация; при необходимости — карточки, жетоны, таблицы, кубики, примеры компонентов. Если есть время, полезно показать короткую демонстрацию одной сцены или одного хода системы. Это может быть не полноценная игра, а миниатюрный пример: игрок хочет сделать действие, система предлагает выбор, происходит проверка, затем возникает последствие. На защите особенно хорошо работают конкретные демонстрации: «Вот как игрок тратит кислород». «Вот как письмо меняется при передаче». «Вот как страх повышает шанс выжить, но уменьшает контроль». «Вот как шрам становится не штрафом, а новой сюжетной возможностью». «Вот как ведущий заполняет счетчик угрозы». Чем меньше абстрактных обещаний и больше видимых процедур, тем сильнее защита.

Критерии оценки финального проекта

Финальный проект оценивается по нескольким критериям.

Связность системы. Все основные элементы должны работать на одну игру. Фишка, действия, проверки, последствия, лист персонажа и ваншот не должны существовать отдельно друг от друга.
Ясность фишки. Фишка должна быть понятна из текста и видна в правилах.
Операциональность. По материалам можно провести игру. Читателю не нужно постоянно обращаться к автору за устными пояснениями.
Качество игрового выбора. Игроки должны сталкиваться с решениями, риском, ценой или конфликтом, соответствующими проектному обещанию.
Работа последствий. Результаты действий должны менять состояние сцены, персонажей, отношений, ресурсов или мира.
Качество листа персонажа. Лист должен быть удобным и отражать важные элементы системы.
Инструменты ведущего. Ведущий должен понимать, как создавать сцены, угрозы и последствия.
Качество ваншота. Стартовый сценарий должен быстро запускать игру и показывать ее фишку.
Итеративность. Должно быть видно, что проект менялся после плейтестов.
Ясность документации. Текст правил должен быть читаемым, структурированным и снабженным примерами. В более общей логике курса эти критерии соответствуют требованиям к хорошей НРИ-системе: связность элементов, связь с сеттингом и действиями, интересность решений, понятные проверки, последствия, чарник, примеры и ваншот.

Типичные ошибки финального этапа

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

Финальная самопроверка проекта

Перед сдачей студенту полезно пройтись по контрольным вопросам. Можно ли объяснить игру за одну минуту? Понятно ли, кто такие игроки? Понятно ли, что они делают чаще всего? Видна ли ключевая фишка в правилах? Есть ли базовый игровой цикл? Понятно ли, когда включается проверка или процедура? Есть ли последствия у успеха и провала? Отражает ли лист персонажа фишку игры? Может ли ведущий провести сцену по памятке? Показывает ли ваншот лучшее качество системы? Есть ли примеры применения правил? Проводился ли плейтест? Понятно ли, что изменилось после плейтеста? Можно ли сыграть в игру без автора? Если на последний вопрос ответ «нет», проект еще не завершен как quickstart.

Самостоятельная работа

Финальная самостоятельная работа — сборка и подготовка защиты. Студент должен подготовить: Quickstart-рулбук на 8–12 страниц. Лист персонажа в финальной или почти финальной версии. Лист ведущего / GM cheat sheet. Стартовый ваншот. Минимум 3 примера применения правил. Отчет о плейтестах и изменениях. Короткую презентацию защиты. В заметке об адаптации не нужно проектировать полноценную цифровую игру. Достаточно ответить на несколько вопросов: Какая часть системы могла бы стать цифровым прототипом? Что можно автоматизировать? Что можно визуализировать? Какие элементы могли бы выиграть от VR? Что, наоборот, лучше работает именно за столом? Какие риски возникнут при переносе НРИ в цифровой формат? Эта часть важна не как отдельный проект, а как связь курса с программой гейм-дизайна и виртуальной реальности.