Последствие подтасовок: Не все броски дайсов являются механикой

Текст Justin Alexander от 30 сентября 2019 года

В GM Don’t List #9: Fudging я рассуждал о том, почему Мастера должны избегать подтасовок, и почему, даже вследствие необходимости, они должны считаться одним из провальных моментов их игр, а также опорной точкой для их дальнейшего повышения качества их вождения.

Наиболее распространенная форма подтасовки – это изменение результатов броска дайса (бросок был неудачным, но вы говорите, что он был успешным, ну или наоборот), однако всем известно, что есть и другие способы подтасовать результаты с точки зрения механики (повысить общее число хитов существа, например).

Однако мне кажется, что далеко не все понимают, что не все броски дайсов во время вашей игры – это механика, так что изменение или игнорирование их результатов не будет подтасовкой. Особенно если речь заходит о процедурных генераторах контента. Подобные схемы могут использовать целый ряд техник, основанных на случайностях (вот, например, метод по использованию карт из коллекционных игр для создания приключений), но поскольку мы почти всегда имеет несколько дайсов во время нашей игры в НРИ, то большая часть генераторов полагается на них.

Почему же это не подтасовка?

Если вам сложно понять, почему изменение результатов процедурной генерации контента не является тем же самым, что и подтасовка результатов механической проверки, давайте обратимся к крайностям в моих примерах. Я готовлю сценарий к своей следующей сессии и мне нужно имя для мастерского персонажа. И вот я открываю Random Name Generator на Behind the Name, выбираю случайные фамилии, нажимаю кнопку и получаю:

Ivonne Eógan Masson

И неважно по какой причине (может быть это чисто чувство эстетики, или же потому что масоны уже закрепились в качестве основной силы города и мне кажется интересным, что генератор случайностей неожиданно связал моего персонажа с ними), но я решаю избавиться от второго «s» из «Masson», назвав персонажа Ivonne Eógan Mason.

Подтасовал ли я результаты?

Положа руку на сердце, нет. Ни по одному из адекватных или же функционально оправданных определений этого термина.

Изменилось ли что-нибудь, если бы вместо изменения результата я попросту бы игнорировал его и нажал «Generate a Name!» еще раз? Все еще нет.

Что если я перенесу это взаимодействие из подготовки на живую игру (и мне все еще нужно имя для нового мастерского персонажа, теперь уже на лету, и я случайно генерирую его, а потом изменяю)? Ничего не изменилось.

А если генератор случайных имен включен в книгу правил? И все-таки нет.

Это не подтасовка не только потому, что она сделает идею «подтасовки» настолько широкой, что она станет бессмысленной, но и потому, что воспринимать результаты процедурной генерации как смирительную рубашку или же обязывающий вас к чему-либо договор, — это в корне неверно ее использовать. Использование генератора – это как покрывать дно чашки Петри питательными веществами: столкнувшись с вашим творческим подсознательным, «чашка» начнет собирать все получившиеся случайности и странные совпадения, что затем перейдут к росту и развитию (например, Ivonne Mason – это совершенно другой человек, нежели Lea Colton или Caroline Bone как раз по той причине, что каждое из этих случайных имен создает отдельный друг от друга творческий импульс). Относясь же к результату процедурной генерации как к неприкосновенной цитате из Писания, вы словно стерилизуете свою чашку Петри, губя весь процесс роста.

Все механики – генераторы случайного контента!

«Ага!», — скажете вы. «Но не будут ли все механики определения результата в основе своей генераторами случайных результатов, чьи итоги могут быть творчески интерпретированы Мастером и другими игроками? Не будет ли описание итога действия тем же, что и использование созданной случайным образом банды для превращения их в Бандитов Кровавого Щита?

В основе своей нет. Процесс похож (броски дайсов, интерпретация результатов), но функции у механик определения результата и процедурной генерации контента во многом противоположны: первые используют в целом неконкретный творческий импульс и создают конкретный результат (часто бинарного типа «вышло/не вышло»). Тогда как генератор создает неконкретный творческий импульс и мотивирует ДМа создать нечто конкретное.

В силу похожести вовлеченных в это дело процессов и того, что «конкретика» может быть весьма подвижным мерилом, вы можете использовать процедурную генерацию в качестве механики определения результата (стерилизуя свои чашки Петри), и наоборот. Но так как инструменты были созданы для одного процесса, а вы используете их для другого, результат будет похож на последствия использования микроскопа заместо молотка.

Серые зоны

Однако не нужно думать, что во всем этом нет серых зон, что лежат на границе между генераторами и механиками.

Это ясно видно на примере игр, что берут нечто, традиционно считавшееся генератором случайного контента в других системах, и вместе этого используют их как встроенную механику (или нечто близкое к механике).

Например, персонажи Apocalypse World создаются на основе шаблонов. Например, если вы хотите играть Стрелком, то вы берете его шаблон и следуете его инструкции: «Чтобы создать своего стрелка, выберите имя, внешний вид, характеристики, ходы, экипировку и связь с другим игроком». В каждой из этих категорий есть конкретный список. И вдруг это отличный пример серой зоны: многие люди, привыкшие к иным системам создания персонажей, смотрят на предложенный список имен как нечто, что можно как использовать, так и игнорировать (например, многие из редакций D&D содержали похожие списки элфийских имен; в Over the Edge был список имен с Аль-Амарджа, ну и так далее). Однако Apocalypse World намеренно навязывает сеттинг через нетрадиционные механики, так что я играл за столами, что интерпретировали имена как механическое требование: вы должны были выбрать его из списка имен Стрелка (которые отличались от имен Вожака, тем самым укрепляя реальность сеттинга). И я на самом деле не знаю, каково было намерение самого Винсента Бейкера касательно этого.

Еще одну серую зону можно найти в процедуре по наполнению подземелий из изначальной редакции Dungeons & Dragons. Хоть правила и позволяли некоторую свободу Мастеру в деле распределения сокровищ и монстров, на строчку выше таблицы процедурной генерации, но механика была весьма запутанной и открытой для различных интерпретаций. Особенно это заметно в случае с бродячими монстрами из OD&D: проверка на случайную встречу чаще всего воспринимается современными Мастерами как момент процедурной генерации, тогда как в OD&D это была весьма прямо прописанная механика.

Mythic Game Master Emulator – это еще один интересный пример: чтобы эмулировать роль ДМа, система Mythic добавляет немало сдерживающих структур на основание в виде генераторов случайного контента. Но несмотря на создаваемые ею серые зоны, система все еще четко разделяет результаты механического разрешения действий и результаты эмулятора ДМа. Если вы хотите ясно понять, в чем заключается эта разница, потратьте вечер, играя с Mythic в качестве основы для своей любимой игры – результат может быть весьма занимательным.

Комментарии:

Добавить комментарий