Анатомия игры
Во-первых: эта статья входит в мой продолжающийся курс «Настоящее сценарное мастерство». Если вы не читали его с самого начала, наверстайте упущенное с помощью оглавления курса «Настоящее сценарное мастерство».
Во-вторых: курс основан на целом ряде предположений о роли игрового дизайна в приключениях и кампаниях для настольных ролевых игр. Я уже изложил их и больше защищать не стану. Если курс не для вас, просто тихонько выйдите.
В-третьих: курс использует множество терминов, которые я придумал, присвоил и заставил подчиниться. Слова означают то, что я велю им означать, а споры никуда вас не приведут.
В-четвёртых и наконец: это второй урок стремительной экскурсии из трёх частей по основам концептуального игрового дизайна. Я много перескакиваю с темы на тему, и часть этой хрени останется непонятной, пока всё не закончится. Если появились вопросы, просто наберитесь терпения. В конце концов всё обретёт смысл.
В-пятых: закончив чтение, загляните в «Вопросы и Злой: продолжение “Анатомии игры”», где я отвечаю на вопросы и комментарии читателей об этой статье.
Все оговорки сделаны. А теперь начинаем представление…
Все вернулись? Отлично. Садитесь и заткнитесь, я начинаю.
В прошлый раз я учил вас Проектировать целенаправленно. То есть велел решить, какой, чёрт возьми, игровой опыт вы проектируете, прежде чем действительно что-либо проектировать. И сказал, что у этого есть два следствия. Во-первых, хорошие проектировщики сценариев — которыми вы надеетесь стать — начинают с Формулировок Замысла (Design Statements), описывающих как минимум исходную ситуацию сценария, цели игроков, возможные исходы и главное испытание сценария.
Этот урок посвящён тому, почему именно эти вещи. Следующий — последней из них во всех мучительных подробностях.
Во-вторых, игровой опыт — окончательный критерий всего, что вы делаете. Каждый ваш элемент должен служить игровой цели, и ни одна игровая потребность не может остаться неудовлетворённой. Если в игре есть хрень без игровой цели — выбросьте её. Если в игре дыра — заполните. Если не можете этого сделать — выбрасывайте всю игру, потому что работать она не будет. Вы провалились.
Проектирование Сценариев — не математика, и готового процесса здесь нет. Это творческое решение задач. Вы формулируете цель проектирования, определяете потребности и находите лучшие способы их удовлетворить.
Всё понятно? Отлично.
Сегодняшняя тема: что делает игру игрой?
Сценарий — это игра
Время признаний… Я небрежно обращался с терминами. Намеренно. Пытался размыть некоторые границы в вашей тупой голове. Я использовал слова «столкновение», «приключение», «кампания», «игра» и «сценарий» как взаимозаменяемые. Потому что всё это одна и та же чёртова вещь. В сущности. Можно выдвинуть слабенький довод, будто столкновения в список не входят, но не тратьте ни своё, ни моё время. Это мелочная техническая придирка, а без неё вы будете проектировать столкновения лучше.
Проектирование Сценариев посвящено сборке настоящей игры из различных игровых элементов. Пока не приходит Проектировщик Сценария, игра остаётся лишь кучей правил, параметров, игровых конструкций и подобной хрени. Кучей игровых ингредиентов. Работа Проектировщика — завершить сборку. Превратить ингредиенты в игру.
Это значит, что хотя Проектировщик Сценария не создаёт игровые механики — и не должен, — именно он собирает всю игру воедино. А значит, обязан понимать всё это дело с игровым дизайном. У вас может быть лучшая в мире система правил, лучшие параметры чудовищ и лучшая система создания персонажей, но если вы не умеете собрать из них хороший игровой опыт, весело не будет никому. И наоборот: даже со скучными правилами, дерьмовыми параметрами и практически отсутствующим созданием персонажей можно получить отличную игру, если знать, что делает игры отличными.
Короче говоря, проектирование сценария — это игровой дизайн. Игровой дизайн — не правила, параметры, баланс и математика. Это умение собрать имеющиеся детали во что-то великолепное.
Настольные ролевые игры — особенные снежинки
Как и современные любители настольных ролевых игр. До тошноты особенные.
Ха-ха, шучу. У нас здесь весело.
Но если серьёзно, каждый игровой формат и жанр отличается от остальных. Каждый уникален. Компьютерные экстракционные шутеры сильно отличаются от евроигр с размещением рабочих, а и те и другие — от бейсбола. Вот это новость, правда? Но всё это игры. И общего у них больше, чем можно подумать. Если познакомитесь со всеми и ещё с чем-нибудь, станете лучшим разработчиком.
Кстати, я не шучу. Играйте во все доступные жанры и форматы. Даже в те, которые считаете плохими. Даже в те, которые, по вашему мнению, технически вообще не игры. Например, спорт и Candy Land. Мне постоянно, мать его, говорят, что Candy Land — не игра. Любимый пример. Но ни один умник пока не сумел объяснить, почему она всё-таки игра и чему у неё можно научиться. Потому что это игра. Понимание того, как такое возможно, показывает жизненно важную грань игрового дизайна, которую вы обязаны постичь.
Но я отвлёкся…
На самом деле я хочу сказать вот что: смотреть на множество разных игр полезно, но вы также обязаны понимать, что делает особенными ваш формат и жанр и как это меняет уравнения игрового дизайна. В ходе всей этой истории с проектированием сценариев я буду говорить вещи, которые технически применимы не ко всем видам игрового дизайна. А уточнять мне лень. Поэтому вам придётся по контексту понимать, когда слова игровой дизайн означают весь существующий игровой дизайн, когда — дизайн настольных ролевых игр, а когда — всего лишь дизайн приключенческих фэнтезийных настольных ролевых игр.
Контекстные подсказки, детишки. Пользуйтесь ими.
Что делает игру игрой?
Вы не разработчик движка
На протяжении курса я буду повторять это снова и снова…
Вы не разработчик системы. Ваша работа — не создавать игровые механики, а собирать имеющиеся системы и компоненты в отличные игры. Поэтому не лезьте не в своё дело и доверяйте своей игре. Да, даже если ваша игра — D&D 5e. Хотите делать правила, хаки и прочую хрень? Вперёд, если считаете себя достаточно компетентными. Но к проектированию сценариев это не относится и лучше проектировать их не поможет.
Великий Проектировщик способен сделать отличный сценарий из чего угодно. Часть этого умения — научиться работать в рамках системы и распознавать неподходящие для неё сценарии. В таком случае, если творческое решение средствами проектирования сценария не находится, вы принимаете зрелое решение заняться чем-нибудь другим. Вы не избиваете правила до полусмерти и не пришиваете к ним перекрученные, изуродованные конечности, лишь бы заставить делать то, чего они никогда не могли.
Если вашему сценарию необходимы несуществующие правила, проблема в плохом сценарии, а не в плохой системе.
Хватит страдать фигнёй… Что делает игру игрой? Что нужно играм — а значит, и сценариям, — чтобы считаться играми? Всё сводится к четырём вещам: Целям, Правилам, Испытанию и Контексту.
Кстати, последняя из них — причина моей речи о форматах и жанрах. Контекст не создаст и не разрушит бейсбол, но способен создать или разрушить настольную ролевую игру.
Чтобы создать игру, вы обязаны предоставить эти четыре вещи: Цели, Правила, Испытание и Контекст. Есть ли в игровом дизайне что-нибудь ещё? Да, безусловно. Но всё прочее скорее определяет разницу между хорошими и плохими играми. А эти четыре вещи — минимальные требования к тому, чтобы вообще считаться игрой.
Весь остаток урока посвящён каждой из них. А весь следующий урок — той, которую труднее всего сделать правильно.
Почему это не Формулировка Замысла?
Возможно, вы задаётесь вопросом, почему эти четыре вещи — Цели, Правила, Испытание и Контекст — не являются четырьмя частями Формулировки Замысла. Две являются — есть пересечение, — но если проектирование сценария есть игровой дизайн, а играм как минимум необходимы эти четыре вещи, разве начинать не следует с них?
Отличный гипотетический вопрос, я! Так рад, что спросил.
Во-первых, помните: вы — Проектировщик Сценария — не единственная рука на штурвале. На самом деле ваша рука последняя. К моменту, когда вы приступаете к работе, основные механики игры — Правила — уже существуют. И Формулировка Замысла действительно признаёт этот факт посредством тихого намёка.
Когда вы говорите…
Деревня находится под властью дракона. Герои прибывают…
…перед этим стоит невидимое первое предложение примерно такого содержания: «В этом приключении для пятой редакции Dungeons & Dragons». Правила учтены.
Выбранные система и жанр также задают базовый Контекст игры. Начальная ситуация и исходы помогают этот Контекст сузить. Вы продолжите работать над ним на протяжении всего проектирования. Но смысл станет яснее, когда мы подробнее поговорим о Контексте.
Вот почему Формулировка Замысла выглядит именно так и почему она на самом деле посвящена Целям, Правилам, Испытанию и Контексту, хотя и не говорит о них напрямую.
Двигаемся дальше.
Победная цель
Каждой игре нужна Цель. Нет Цели — нет игры. Всё просто.
Цель — настоящая, осязаемая, внутриигровая вещь, к которой стремятся игроки. Это окончание предложения: «Чтобы победить, игроки должны…» То, что настольные ролевые игры открыты, обладают повествованием, моделируют миры и дают игрокам агентность, не освобождает игру от необходимости иметь Цель.
Каждый проектируемый вами сценарий — каждое столкновение, приключение, арка и кампания — должен иметь одну или несколько явных внутриигровых Целей. Чёртова точка.
Не путайте Цели с Мотивациями и Наградами. И Мотивации с Наградами тоже не путайте. Множество придурков именно так и поступает. Веселиться — не Цель. Совместно рассказать историю — тоже. Это Мотивации игроков. Причины, по которым они играют, но не способы победить. Желание персонажа накопить богатство или служить добру — тоже не Цель. Мотивации персонажей дают контекстные причины преследовать Цели, но сами Целями не являются. Очки опыта, уровни, модные новые заклинания и магические предметы — тоже не Цели. Это игровые Награды.
Цели приходят из игры, а не от игроков или персонажей. Это важная часть. Игроки приносят за стол свои мотивации и могут придумывать внутриигровые мотивации как часть контекстной основы отыгрыша, но Цели приходят из игры, потому что являются её частью. Игрокам необязательно понимать, почему играть и побеждать в ролевых играх весело. Но если они не знают Цели, то не могут по-настоящему играть.
Не волнуйтесь… Позднее я уделю Целям гораздо больше времени. Наверное, целых два или три отдельных урока. Они действительно важны.
Правила игры
Цели, выбранные игроками
Я знаю, некоторые из вас уже печатают гневные комментарии, потому что решили, будто моя речь о Целях означает, что игрокам нельзя выбирать собственные. Расправьте скомканное бельё и успокойте сиськи; я этого не говорил. Я не утверждаю, что нельзя позволить игрокам выбирать из нескольких внутриигровых Целей или бросить их в мир и дать преследовать любую желаемую Цель. Не утверждаю, что группа не может заранее решить, чему будет посвящена кампания. Не утверждаю, что нельзя иметь туманные, неопределённые Цели вроде накопления богатства или славы. Не утверждаю, что нельзя вести кампанию с приключением недели и без общей Цели. Не утверждаю, что нельзя вести кампанию, где каждый персонаж преследует самостоятельно выбранную личную Цель.
Всё это совершенно допустимо. За исключением той части, где вы бросаете игроков в мир и позволяете делать что угодно. Так нельзя. То есть можно. Но нельзя. Я вернусь к этому позже, когда вы будете готовы к взрослому разговору о том, что Санта-Клауса, Пасхального кролика и Субъектности Игроков (Player Agency) не существует.
Но это история для другого раза. Я лишь прошу не паниковать, выдумывая следствия, которых я не подразумевал.
У каждой игры есть Правила. Они определяют, как игроки взаимодействуют с игрой. Говорят, что можно делать, чего нельзя и как определяются результаты.
Ролевые игры очень открыты. По крайней мере, в теории должны быть открытыми. Поэтому Правила настольных ролевых игр должны позволять игрокам пытаться совершить любое взаимодействие, которое они способны вообразить возможным в контекстной реальности игры. И в основном они позволяют. Разумеется, если вы признаёте Мастера — и его суждение — частью Правил. Но открытость ролевых игр и существование Мастера не освобождают игру от необходимости в Правилах, а игроков — от обязанности им подчиняться.
Вы — Проектировщик Сценария — Правила не пишете. Для этого существует игровая система. Проектируя сценарии, вы обязаны работать в рамках этих правил. А значит, должны их понимать — по-настоящему, мать его, понимать — и принимать ограничения. Даже те, которые нигде не записаны.
Например, важнейшее правило настольных ролевых игр — Цикл «Заявить — Определить — Описать» (Declare-Determine-Describe), как я назвал его в «Настоящем мастерстве ведения игры». В сущности, это официальное название штуки, где Мастер описывает увиденное, услышанное и воспринятое персонажами, затем игроки описывают действия персонажей, а потом Мастер определяет и описывает результат.
Да, это правило. Эквивалент цикла «Разворот — Поддержка — Взятие карты — Основная фаза — Бой — Основная фаза — Очистка» из Magic: the Gathering. Или как там он теперь выглядит. Проектировщик Сценария обязан понимать работу игры на таком фундаментальном уровне и удостовериться, что сценарий с ней совместим.
Предположим, например, вы хотите создать сценарий, где персонажи вступают в армию — или командуют ею — и сражаются с вторгшейся ордой диких, злых, варварских орков-мародёров. Как вас ограничивает Цикл «Заявить — Определить — Описать»? Например, он технически не позволяет дать игрокам прямой, подобный власти небесных богов контроль над армейскими подразделениями и устроить варгейм.
Правильный армейский сценарий начинается с предположения, что игроки знают лишь то, что способны воспринять их персонажи. Знают увиденное и услышанное, а также сведения из донесений разведчиков, дозорных и офицеров. Игроки ограничены личными действиями персонажей. Персонажи могут отдавать приказы — выкрикивая их или передавая через гонцов и офицеров, — но не обязаны немедленно узнавать результаты. После начала битвы игроки могут не знать, что происходит за пределами ближайшего окружения.
Я знаю, массовые сражения в ролевых играх так почти никто не ведёт — и если в вашей игре есть система массового боя, следует использовать её, — но в D&D 5e войну следовало бы вести именно так.
Подумайте также, как много видеоигр передаёт сведения через заставки. Иногда они даже показывают события, при которых персонажей игрока не было, лишь чтобы дать Контекст, установить Цель или сделать что-нибудь подобное. Для видеоигры это совершенно нормально, но технически выходит за рамки правил настольных ролевых игр. Игроки не могут знать того, что не способны воспринимать персонажи. Поэтому, если вам нужно показать злодейство антагониста, поместите сведения туда, где персонажи смогут их воспринять.
Не слишком ли я здесь пурист? Безусловно. И заметьте, я не утверждаю, что правило, позволяющее персонажам напрямую управлять союзными NPC или двигать армии и корабли как в стратегической игре, неправильно или плохо. Если в системе такое правило есть — пользуйтесь. Но если нет, правильный подход к проектированию сценария — всегда и во всём ограничивать восприятие точкой зрения персонажей. А Настоящий Проектировщик понимает все правила и их следствия, а не только хрень о параметрах боевых столкновений и разрешении проверок Силы (Strength checks) или чего-нибудь такого.
Предварительная проработка правил
Вы не разработчик движка. Я уже говорил? Вы — Проектировщик Сценария — не занимаетесь правилами и механиками. Вы работаете с тем, что есть. И знаете правила вдоль, поперёк, с лица и с изнанки. Но хотя проектирование правил не ваша обязанность, вы за них отвечаете. Даже сильнее, чем бедный, обременённый Мастер, пытающийся провести ваш дурацкий сценарий как можно правильнее, эффективнее и успешнее. Поэтому одна из ваших обязанностей — выполнить как можно больше Предварительной Проработки Правил (Rules Preprocessing).
Что это значит?
Допустим, в игре есть запертая дверь. Как достаточно умный Проектировщик, вы понимаете, что игроки любыми средствами захотят пройти сквозь неё. Вы также должны быть достаточно умны, чтобы понимать, как именно они попытаются это сделать. Предсказание Поведения Игроков — ещё одна ваша обязанность. Но это урок для другого раза.
Например, вы должны знать, что большинство игроков попробует выбить дверь или вскрыть замок. Всё просто, верно?
Как Проектировщик Сценария — и местный Эксперт по Правилам — вы снабжаете Мастера всеми мелкими механическими деталями для разрешения этих действий. Указываете применимые навыки или характеристики, целевые значения бросков и последствия успеха, провала, критического успеха, критического провала или любой другой глупой возможности, предусмотренной правилами вашей системы.
Это и есть Предварительная Проработка Правил. Вы предсказываете механики, которые могут понадобиться, и вооружаете Мастера всем необходимым для беспроблемного разрешения. Вы не оставляете на усмотрение Мастера ничего, что могли предвидеть. Суждение Мастера предназначено для хрени, которую вы предвидеть не сумели. И вы не пожимаете плечами со словами: «Ну, Мастер знает, как установить КС проверки взлома замка и как работают правила выбивания дверей».
Кому-то из вас эта хрень покажется совершенно очевидной. Но за ней стоит чрезвычайно важный концептуальный философский принцип, который будет очень важен в следующем и множестве будущих уроков. Не поймёте его — будете ныть и жаловаться мне на Субъектность Игроков. Которая, кстати, шутка. Субъектность Игроков — Санта-Клаус Проектирования Сценариев. Весёлая фантазия, делающая множество людей счастливыми, но на самом деле её не существует, а понимание лжи и поддержание иллюзии — часть взрослой жизни. Я уже говорил? Говорю снова. Повторение, детишки; так вы учитесь.
Простите… отвлёкся…
У всей этой штуки с Предварительной Проработкой есть крайне важная концептуальная основа: когда вы перечисляете механические правила разрешения предвиденных действий игроков, вы не определяете возможные действия игроков. Не указываете, как они могут или должны справляться с игровой ситуацией. Вы лишь предсказываете самые вероятные действия и вооружаете Мастера всем необходимым, чтобы разрешить их с наименьшими усилиями.
Это одна из причин, по которым Испытания Навыков (Skill Challenges) в 4e — и другие похожие механики — были и остаются совершенно сломанными. Их подавали — и строили — как перечни возможных взаимодействий, а не как прогнозы вероятных взаимодействий. Но сегодня мы не об этом.
Кстати, раз уж речь зашла об историях для другого дня: на следующем уроке я сломаю вам мозг, сказав полную противоположность сегодняшним словам. Посмотрим, сколько человек заработает аневризму от парадокса, которого на самом деле нет. Будет весело.
Двигаемся дальше…
Принимаем Испытание
Бросок костей — не Испытание
Сейчас я в тысячный чёртов раз напомню, что необходимость выбросить определённое число на пластиковом математическом камне — не Испытание. Да, присутствует неопределённость, но игрок не прилагает усилий и не проявляет мастерства. Результаты всего лишь случайны. При прочих равных фраза «Игрок должен пройти какую-то проверку с КС X…» Испытания не создаёт.
Но теперь вы продвинутые ученики и всё это знаете. Позвольте поразить вас тем, чего я никогда раньше не говорил. Произнося: «Бросок костей — не Испытание», — на самом деле я говорю: «Технически бросок костей — не Испытание». Вы ведь понимаете, что значит технически? Это значит, что утверждение корректно, но не всегда верно.
Пожуйте эту мысль. А потом идите подберите носки.
Игра должна предоставить игрокам одно или несколько внутриигровых Испытаний, и я предельно тщательно выбираю здесь слова. Каждое слово в предложении важно и находится на своём месте. Даже слово Испытание выбрано намеренно. Я мог бы облегчить себе жизнь словом вроде Препятствие или каким-нибудь ещё. Хотел бы. Слово Испытание основательно ломает мозг многим из вас, придурков. Но здесь оно правильное.
Испытание — всё, что игроки должны выполнить или преодолеть на пути к Цели. Если Цель — сокровище, то Испытание — спящий на нём дракон. Игры без Испытаний — не игры. Кроме случаев, когда всё-таки игры, но эта хрень выходит за рамки курса. Испытания заставляют игроков потрудиться ради Цели и потому превращают её достижение в ощущаемую победу.
Не путайте слово Испытание со словом Трудное и не приравнивайте Испытание к Сложности. Нечто является Испытанием — и испытывает игроков, — если для преодоления требуется хоть какое-нибудь усилие или умение и присутствует хоть какая-нибудь неопределённость. Даже если считаете Испытание сверхлёгким и думаете, что 99 игроков из 10 пройдут его не заметив, оно остаётся Испытанием. Просто не трудным.
Кроме того, заметьте: Показатели Опасности не обязательно связаны с Испытанием или Сложностью. Не по-настоящему. Показатели Опасности (Challenge Ratings) — в том виде, в каком существуют во всяких Dungeons & Dragons и Pathfinder, — на самом деле не определяют, насколько трудное Испытание представляет чудовище. Классы Сложности (Difficulty Classes) тоже не о Сложности или Испытании. То, что задача с КС 15 считается Трудной или какой-нибудь ещё, не имеет ничего общего с тем, является ли она трудным Испытанием. Более того, сама задача вообще не Испытание. Кроме случаев, когда является. И именно ваша обязанность — обязанность Проектировщика — понимать, что действия и задачи не являются Испытаниями и сами по себе не испытывают игроков, а затем решать, как это исправить. Кстати, это не недостаток устройства игры. Разработчики не сделали что-то неправильно; просто так работают игры и Проектирование Сценариев.
Вся эта хрень — и тот факт, что ваши глаза, вероятно, уже смотрят в разные стороны, — причина посвятить Испытанию весь следующий урок.
Сегодня я лишь хочу, чтобы вы поняли: игры должны предоставлять одно или несколько внутриигровых Испытаний. В большинстве игр есть одно-два главных Испытания и куча второстепенных. Самый очевидный пример — подземелье с битвой против босса в конце, но это примерно детский первый Вариант Структуры Испытаний. Когда будете готовы, я покажу, как сделать намного больше. Но готовы вы будете ещё нескоро.
Есть ещё одна вещь, которую вам нужно понять сегодня: настольные ролевые игры чертовски ограничены в видах доступных Испытаний. На самом деле они способны создавать лишь те Испытания, где игроки должны принять правильное — или лучшее, или просто хорошее — решение в определённой ситуации. Они ведь не могут проверять мышечную память, физические способности, скорость реакции или что-то подобное. Более того, из-за повествовательной природы ролевых игр и странного течения внутриигрового времени даже множество Испытаний, основанных на выборе, во многих играх попросту не работают.
Но, опять же, следующий урок — как и большая часть остатка курса — посвящён Испытаниям, поэтому сегодня больше долбить этой хренью не стану. Однако попрошу вас кое о чём подумать до следующего урока.
Снова рассмотрите упомянутое выше Испытание с Запертой Дверью. Кстати, мы будем говорить о нём много. Мой Discord-сервер сторонников уже сыт по горло Испытанием с Запертой Дверью, потому что я столько о нём талдычил, но оно действительно идеально показывает, что значит создавать Испытания для настольных ролевых игр. Я твёрдо убеждён: если вы не понимаете, как запертая дверь сама по себе может быть Испытанием — и как вы, Проектировщик Сценария, можете сделать её Испытанием или не сделать, — вам не стать Проектировщиком.
Вот о чём я хочу, чтобы вы подумали до следующего раза. Именно подумали. Просто пожуйте эту хрень. Не публикуйте ответ, не комментируйте, не начинайте обсуждение — просто подумайте. Самостоятельно. И дайте подумать остальным. Закройте пальцы и шумовое отверстие. Понятно?
Настольные ролевые игры главным образом Испытывают игроков необходимостью принять правильное — или лучшее, или всего лишь хорошее — решение в определённой ситуации. Это предполагает, что в ситуациях должны существовать неправильные — или худшие, или всего лишь плохие — варианты. Что это говорит о создании самого по себе Испытания с Запертой Дверью? При правильной обработке Запертая Дверь является Испытанием, при неправильной — нет. В этом и состоит Испытание Проектирования Сценария.
И заметьте: само по себе означает без учёта чудовища за дверью или чего-либо ещё внешнего по отношению к самой двери.
Всё в Контексте
Контекст — секретный соус, отличающий ролевые игры от большинства остальных.
Обратите внимание: я не сказал «Каждая игра должна содержать…», как в начале всех предыдущих разделов. Потому что хотя Контекст присутствует во многих играх — хотя бы в какой-то степени, — обязательным он не является. Игра может быть игрой без Контекста. У бейсбола Контекста нет. Цель бейсбола — набрать больше пробежек, чем другая команда. Испытания включают отбивание мяча, бег по базам, игру в поле, подачу и необходимость не уснуть до конца целого чёртового бейсбольного матча. Почему это Цель? Почему это Испытания? Потому что. Больше никакого Контекста нет.
Уже поняли, что такое Контекст? Нет. Приведу ещё один пример.
Рассмотрим настольную игру Century: Spice Road. В Century вы берёте на себя роль торговца пряностями и пытаетесь стать самым богатым и лучшим торговцем. Вот только настоящая Цель — набрать больше победных очков, чем остальные. Испытания состоят в сборе цветных жетонов, розыгрыше карт ради обмена одних жетонов на другие и обмене определённых комбинаций жетонов на карты с победными очками. Контекст — просто слой краски. Он никак не помогает играть. Если вы настоящий профессиональный торговец пряностями, никакого преимущества перед остальными за столом у вас не будет.
Контекст — основа, через которую игроки понимают свои Цели и встречающиеся Испытания. В играх вроде бейсбола и Century она не важна. Осмысление действий через темы игры никак вам не помогает. Но в настольных ролевых играх Контекст жизненно важен для игрового опыта. Ролевой процесс — это принятие лучших решений в Контексте фэнтезийного мира. Более того, понимание того, как Цели, Испытания и ваши решения вписываются в Контекст игры, помогает преодолевать Испытания и предсказывать последствия выбора. Например, знание того, что орки по природе жестокие дикари и не склонны поддаваться очарованию, входит в расчёты при выборе способа справиться с орком в рамках Испытания. Точно так же знание, что магические предметы — ограниченный ресурс, который нелегко заменить, влияет на готовность расходовать одноразовые предметы ради преодоления Испытаний.
Более того, понимание Контекста открывает бесконечно больше игровых возможностей. В D&D вы не ограничены обменом жетонов на лежащие на столе карты. Можно попытаться совершить любое действие, вписывающееся в Контекст игры. Можно срубить дерево и сделать таран, чтобы пробить дверь, потому что именно так работают деревья, топоры и двери.
Это добавляет новые слои ко всей истории с Проектированием Сценариев. Недостаточно создать Цели и Испытания. Нужно хотя бы в некоторой степени задуматься, почему именно такие Цели и почему такие Испытания, а также что они — и действия игроков — значат для Фантазии и Повествования игры. Поэтому я считаю и Фантазию, и Повествование частью работы Проектировщика, но они не являются его единственной работой. В конце концов Контекст — всего лишь одна из четырёх ножек, держащих стол, на котором стоит ролевая игра.
Поняли? Настольная? Ролевая игра?
Наверное, я никогда не посвящу Контексту отдельный урок, но буду часто ссылаться на него на протяжении курса. Примерно так он и работает. Это фильтр, сквозь который вы рассматриваете процесс Проектирования Сценария.
На этом всё
Я понимаю, что это был не столько урок, сколько четыре туманных эссе о четырёх основных ингредиентах, делающих игры — и сценарии — играми. Вообще-то это два эссе, один неопределённый взмах рукой и записка: «Я должен вам одно эссе об Испытании; целую, Злой». Но вы не можете сказать, что я не предупреждал. К счастью, на протяжении всего курса мы будем обсуждать, исследовать и снова анализировать эти идеи ещё и ещё и ещё. Здесь я даже поверхности не поцарапал.
Настоящего заключения предложить не могу, но могу подвести итог…
Как Проектировщик Сценария вы обязаны знать, что делает игры играми — и что делает их хорошими, — потому что ваша работа состоит в сборке разрозненных игровых деталей в настоящие, пригодные для игры — и, будем надеяться, хорошие — игры.
Каждая игра должна предоставить игрокам одну или несколько внутриигровых Целей. Цель — то, чего игроки пытаются достичь. Не путайте Цели с Мотивациями или Наградами, а Мотивации — с Наградами.
Каждой игре нужны Правила. Они определяют, как игроки взаимодействуют с игрой. Проектировщики Сценариев не пишут правила, но должны знать правила своей игры на уровне эксперта. И записанные, и незаписанные. Одно жизненно важное незаписанное правило проектирования ролевых сценариев гласит: знания игроков об игровой ситуации и их возможные взаимодействия с игрой должны ограничиваться тем, что способны воспринять их персонажи и какие индивидуальные действия те способны совершить.
Проектировщики должны предсказывать вероятные способы взаимодействия игроков с разными ситуациями и снабжать Мастера механиками, необходимыми для их разрешения. Они не полагаются на суждение Мастера или знание правил в вопросах, которые способны предвидеть.
Каждая игра должна предоставить одно или несколько внутриигровых Испытаний. Испытания — ситуации, которые игроки должны преодолеть усилием и умением ради достижения Цели игры. Настольные ролевые игры почти исключительно испытывают игроков необходимостью принимать лучшие решения в ситуациях, где те оказались.
Игровой опыт настольной ролевой игры сильно зависит от Контекста. Цели, Испытания и внутриигровые действия должны быть понятны в Контекстной Основе игры. То есть они должны работать с учётом того, что игра представляет воображаемый мир, где аватары игроков — живые, дышащие люди, а также разворачивающееся повествование.
Вот и всё — грубая структурная анатомия игры. В следующий раз вы получите обещанное эссе об Испытании.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.