Очень ждем:

Самый сок:



Баннеры:


Паллан



Ведьмак. Исток Хаоса






Тайный Лабиринт

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.



Art of Rulings

Сообщений 1 страница 7 из 7

1

Глава 1: Искусство Суждений

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-1-искусство-суждений/

Перевод: Angon

Оригинал: The Art of Rulings

Написал Джастин Александер в марте 2011

Перевел Ангон в июне 2018

В комментариях к Новостям из Усыпальницы Луан Фьена {Update from the Crypt of Luan Phien} некто По {Poe} задал мне вопрос:

Любопытно, полагаетесь ли вы при создании карт только на умения {expertise} игроков? Или вы используете какие-то проверки навыков {skill checks}, чтобы отразить умения персонажей разбираться в происходящем в необычных, вроде этого, случаях с картой?

В случае с той конкретной картой игроки раскусили принципы работы усыпальницы, используя в первую очередь свои собственные умения. Но вопрос По заставил меня задуматься о том, как Ведущие {GMs} принимают суждения {make rulings} при ведении ролевой игры.

Начнем с  того, что я предпочитаю использовать системы правил, предлагающие обширную игромеханическую {mechanical} поддержку суждений Ведущего. Некоторые отдают предпочтение полному произволу Ведущего {GM fiat}, но мне нравится наличие игромеханической основы для принятия суждений, поскольку:

Она дает мне возможность принимать суждения с долей неопределенности.
(Вместо того, чтобы сказать “это определенно происходит” или “этого определенно не происходит”, я могу сказать “это выглядит возможным, давай посмотрим, произойдет ли это”.)
Она позволяет различным качествам персонажей {character capacity} оказывать осмысленное влияние на происходящие события.
Ей можно руководствоваться в тех случаях, когда я не уверен, какое суждение принять.
Игромеханический исход {mechanical outcome} предоставляет мне возможность для импровизации {improv opportunity} и подчас подстрекает меня к созданию того, чего я иначе не создал бы.
Она обеспечивает последовательное {consistency} принятие сходных суждений в разное время.
И так далее. В общем, плохо разработанные правила становятся для Ведущего бессмысленной клеткой {straitjackets}. Хорошие правила, с другой стороны, способствуют новым формам игры и расширяют ее возможности.

Помимо вышесказанного, мой, как Ведущего, подход к принятию суждений по существу заключается в следующем:

Пассивное восприятие {passive observation} персонажем окружающего мира происходит автоматически.
Умения игрока приводят в действие {activates} умения персонажа.
Умения игрока могут превзойти {trump} умения персонажа.
Пассивное восприятие происходит автоматически
К пассивному восприятию относятся как очевидные каждому вещи (например, зависший посередине комнаты огромный шар огня {ball of flame}), так и некоторые игромеханические способы определить, заметили ли персонажи что-то неочевидное. В OD&D к таким способам относятся “проверки на неожиданность” {surprise tests}, а в D&D Третьей Редакции — проверки Слуха {Listen}, Внимательности {Spot} и Знания {Knowledge} (хотя эти навыки могут использоваться и не-автоматическими способами).

Почему я отношу сюда навыки Знания {Knowledge  skills}? Представьте, что персонажи входят в комнату, на стене которой нарисован большой геральдический щит. Узнают ли персонажи древний герб Негута Третьего, короля Иркатии {King Negut III of Yrkathia}? Если узнают, то игроки не должны спрашивать, что они знают об этом гербе — они просто узнают его.

А теперь мы переходим к сути вопроса, то есть к тому моменту, когда игрок заявляет “Я хочу совершить Х” и вы должны принять суждение о том, как определить исход этого Х.

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

Рассмотрим простой пример:

Игрок: Я проверяю сундук на ловушки.

Ведущий: Сделай проверку Обыска {Search}.

Для большинства из нас это может выглядеть само собой разумеющимся. С другой стороны, я видел игры, в которых Ведущие требовали проверки Обыска в ответ на “Я открываю сундук”. Подобное можно услышать и от игроков, утверждающих что-нибудь вроде “Мой персонаж — воровка {rogue} 12 уровня. Она лучше меня знает, что не стоит открывать сундук, не проверив его сперва на ловушки!”

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

Однако в целом я бы хотел указать на то, что неотъемлемой частью ролевой игры является, по определению, отыгрыш вашего персонажа {playing your role} — то есть принятие тех решений, которые принял бы ваш персонаж. Я утверждаю, что когда вы передаете значимые выборы игромеханике вместо того, чтобы принимать их самостоятельно, вы прекращаете отыгрывать персонажа и играть в ролевую игру {roleplaying}.

Конечно, на другом конце спектра находится разного рода докапывание до мелочей {pixel-bitching}, при котором вам никогда не позволят передать игромеханике разрешение {resolution} действия вашего персонажа, и обыск сундука станет унылым перечислением подробностей:

Игрок: Я проверяю сундук на ловушки.

Ведущий: Каким образом?

Игрок: Я проверяю, нет ли под сундуком нажимной плиты {pressure plate}.

Ведущий: Каким образом?

Игрок: Я провожу пальцами по периметру в поисках каких-нибудь граней. Затем я разливаю немного воды вокруг, чтобы посмотреть не потечет ли она в какие-нибудь углубления. А потом я очень осторожно приподнимаю один из углов сундука ровно настолько, чтобы я мог просунуть под него кусочек пергамента и понять, не заденет ли он какой-нибудь взведенной пружины {spring-loaded trigger}, поднимающейся вместе с сундуком.

(Или, если вы играете с Ведущим-ублюдком {GM bastardy}: “ — Я проверяю, нет ли под сундуком нажимной плиты. — Ты поднимаешь сундук, чтобы посмотреть, и нажимная плита срабатывает!”)

Безусловно, есть доля искусства в том, чтобы найти “золотую середину” {“sweet spot”}, когда стоит приводить в действие умения персонажа. Но в девяноста девяти случаях из ста это довольно очевидно. Если сомневаетесь, ищите значимые выборы. Или, скорее, никогда не предполагайте, что персонаж делает что-то требующее совершения значимого выбора, если игрок не совершил этот выбор.

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

Продолжая наш пример с обыском сундука, допустим, что в этом сундуке есть скрытый отсек, получить доступ к которому можно вынув днище сундука. Мы решили, что обнаружение скрытого отсека требует проверки Обыска со сложностью 17 {DC 17}. Игрок говорит:

“Я обыскиваю сундук.”
“Я проверяю, нет ли скрытых отсеков в днище сундука.”
“Я выбиваю днище сундука своим топором!”
“Я проверяю сундук на ловушки перед тем, как его открыть.”
“Я проверяю, нет ли скрытых отсеков в крышке сундука.”
Первый вариант — стандартный. Действие разрешается с помощью игромеханики, а именно проверкой Обыска с указанной сложностью обнаружения скрытого отсека. При успехе игрок может получить ряд различных ответов (от “ага, там скрытый отсек” до “ты замечаешь, что снаружи сундук выглядит на несколько дюймов глубже, чем внутри”).

Второй вариант более конкретный (и как раз совпадает с тем, что можно найти). В таких случаях я склонен давать что-нибудь вроде ситуативного бонуса {circumstance bonus} +2 к Обыску. Если в сундуке можно найти что-то еще, я могу разрешить обнаружить это той же проверкой Обыска (но поскольку вы намеренно ищете другое, в этом случае к проверке будет применяться штраф {penalty}).

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

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

В качестве другого примера рассмотрим коридор с ямой-ловушкой {pit trap}. Яма-ловушка срабатывает в 50% случаев, если кто-то наступит на нее, и требует проверки Обыска со сложностью 17, чтобы ее найти. Игрок говорит:

“Я ищу ловушки в коридоре.”
“Я осторожно иду по коридору, простукивая пол перед собой десятифутовым шестом {10-foot pole}.”
“Я призываю небесного барсука {celestial badger} и приказываю ему пройти по коридору передо мной.”
“Я разливаю воду из бурдюка {waterskin} на пол и смотрю, не утекает ли она в какие-нибудь стыки или трещины.”
Первый вариант — это, опять же, прямолинейная проверка Обыска. Второй и третий варианты минуют игромеханику Обыска и, вместо этого, дают пятидесятипроцентный шанс, что шест или призванное существо заставят ловушку сработать.

Четвертый вариант, с другой стороны, может быть обработан разными способами. Легко можно рассудить, что такой прием обнаружит ловушку автоматически (особенно если игрок уточнил, какой именно участок коридора он проверяет). Я бы скорее дал изрядный бонус (скажем, +10) к проверке Обыска за использование подходящего приема.

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

Усыпальница Луан Фьена — пример с прошедшей игры
Давайте рассмотрим это на конкретном примере рисования карты Усыпальницы Луан Фьена, разделенного на секции подземелья, в котором каждая секция периодически вращается независимо от других и тем самым меняет планировку подземелья.

В качестве крайнего случая, мы можем вообразить игрока, заявляющего “Я делаю проверку Знания подземелий {Knowledge (dungeoneering)}, чтобы нарисовать карту подземелья”. На что я ответил бы “Нет”. (У игрока не получилось достичь необходимой для задействования умений его персонажа конкретики.)

В случае этой конкретной игры карта подземелья была нарисована практически полностью с помощью умений игроков. Они просто наблюдали какие комнаты с какими соединяются и медленно постигали возможные конфигурации подземелья. (Единственным исключением, уже в заключительной стадии, был осмотр коридоров в поисках стыков между стенами, которые подтвердили бы предположения о границах между секциями.)

Но я могу придумать несколько способов, которыми они могли бы задействовать навыки своих персонажей:

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

0

2

Глава 2: Намерение и Способ

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-2-намерение-и-способ/

Перевод: Ангон

Оригинал: Art of Rulings – Part 2: Intention and Method

Написал Джастин Александер в октябре 2015

Перевел Ангон в июне 2018

Игрок заявляет: “Я хочу совершить Х”.

В этот момент Ведущий должен принять суждение. В этот момент он должен решить, каким будет результат того, что персонаж игрока совершит Х. И на самом базовом уровне в этом и заключается вся ролевая игра: каждый отдельный сеанс {session} игры может, в сущности, быть определен как последовательность подобных взаимодействий.

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

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

Игрок заявляет свое намерение {intention}.
Предпринятое действие разрешается.
Исход {outcome} действия излагается {narrated}.
На первый взгляд это кажется довольно простым. Игрок заявляет, что он хочет ударить кого-то мечом. Вы делаете бросок атаки {attack roll} чтобы определить, удалось ли ему это. Разрешив ситуацию с помощью игромеханики, вы говорите, попал он или нет.

Однако на практике все может быть намного сложнее, и по ходу дела вы обнаружите немало подвохов.

Ты уверен, что хочешь это сделать?

Это уже стало чем-то вроде клише:

Игрок: Я спрыгиваю на землю.

Ведущий: Ты уверен, что хочешь это сделать?

Дело тут в том, что если ваши игроки собираются совершить что-то очевидно самоубийственное с вашей, Ведущего, точки зрения, значит у вас, вероятно, возникло какое-то недопонимание. Простой пример:

Игрок: Я спрыгиваю на землю.

Ведущий: Хорошо, ты падаешь 200 футов, получаешь 20к6 единиц урона {20d6 points of damage} и умираешь.

Игрок: Что? Я думал, здание всего 20 футов высотой!

Тем не менее, я не большой сторонник уклончивого подхода “ты уверен, что хочешь это сделать?” Хотя в некоторых случаях этим можно предостеречь игрока от неудачного образа действий, едва ли получится разобраться с исходным недоразумением.

В общем случае предпочтительнее объяснить игроку, что по-вашему стоит на кону, чтобы убедится, на одной ли вы с ним волне. Например:

Игрок: Я спрыгиваю на землю.

Ведущий: Здание 200 футов высотой. Если ты спрыгнешь, ты получишь 20к6 единиц урона.

Игрок: А, и верно. Ладно, тогда попытаюсь сделать что-нибудь другое.

Хотя недопонимание также легко может быть и со стороны Ведущего:

Игрок: Я спрыгиваю на землю.

Ведущий: Ты уверен, что хочешь это сделать?

Игрок: А в чем дело? Там внизу лава или что-то вроде?

Ведущий: Нет, но здание высотой 200 футов. Ты получишь 20к6 единиц урона, если спрыгнешь.

Игрок: Я собираюсь сотворить заклинание Падение пера {feather fall}. Я просто хочу, чтобы принцесса решила, что я совершил самоубийство.

Ведущий: Ясно, продолжай.

Это относится не только к смертельно опасным ситуациям. Например, если вы ведете детектив {mystery scenario} и один из игроков заявляет “Я осматриваю ковер”, но вы не понимаете, зачем он хочет осмотреть ковер, просто спросите его.

Игрок: Я осматриваю ковер.

Ведущий: Что ты надеешься увидеть?

Игрок: Ты говорил, что вчера в два часа ночи шел дождь. Если убийца пробрался через это окно после двух ночи, на ковре должна была остаться грязь.

Ведущий (который знает, что убийство произошло в четыре утра): Ага. Выглядит так, как будто кто-то постарался тут все очистить, но ты находишь немного грязи на плинтусе около окна.

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

Отсюда следует более общий принцип:

Если вы не понимаете, чего игроки стараются достичь данным действием,
выясните это перед тем, как вынести суждение относительно этого действия.

Намерение — это не начало действия
Отсюда также следует и то, что намерение — это не начало действия {initiation}.

Увлекшись игрой, мы подчас описываем свои заявки как происходящие в настоящем времени действия: “Я спрыгиваю с крыши!” или “Я пронзаю его мечом!”.

Несомненно, возможно трактовать такие заявки как необратимые {irrevocable} (и некоторые неопытные Ведущие так и делают), но как мы только что увидели, это нередко приводит к неудовлетворительным результатам. Лучше понимать такие заявки в том смысле, который в них на самом деле вкладывается: “Я намереваюсь спрыгнуть с крыши” или “Я хочу пронзить его своим мечом”.

Вместе с тем, очевидно существует точка невозврата, после которой игрок не может “взять назад” {“take back”} заявленное действие. Это происходит в тот момент, когда мы начинаем разрешать действие, которое он намеревался совершить. В этот переломный момент действие действительно началось.

Не следует также путать намерение с исходом. Например, если игрок заявляет “Я хочу пронзить его мечом насквозь!”, совершенно необязательно, что именно это произойдет. Более того, необязательно, что это произойдет даже при успешном броске атаки. Если игрок преуспел на броске атаки (и персонаж попал по цели), удар может только сорвать с полурослика {halfling} куртку, открыв мифрильную кольчугу {shirt of mithril} под ней. (Или, как вариант, результат броска на урон {damage roll} может быть недостаточно высок и не соответствовать тому исходу, при котором враг насквозь пронзен мечом. К этому мы еще вернемся.)

Разумеется, на практике разделение между намерением, началом действия, разрешением действия и исходом зачастую стирается. Если игрок за игровым столом заявляет что-нибудь вроде “Я говорю леди Гвендолин {Lady Gwendolyn}, что она самая прекрасная девушка из всех мною виденных”, то это просто происходит. Подобным образом, заявка “Я прохожу через комнату” обычно приводит к автоматическому результату: намерение, начало действия и его разрешение происходят одновременно, а исход — практически одновременно, поскольку сразу после этого будет сказано что-нибудь вроде “Ты теперь на другой стороне комнаты”.

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

Одноэтапные и многоэтапные намерения
Стоит также отметить, что одноэтапные {single-step} намерения обычно довольно очевидны. Заявка “Я хочу пронзить его мечом” не требует никаких пояснений.

Но не все, что выглядит как одноэтапное намерение, на самом деле является таковым. Например, если игрок заявляет “Я хочу запрыгнуть на груду ящиков {crates}”, то одноэтапное намерение заключается в “оказаться на груде ящиков”. Вроде все просто. Но на самом деле целью игрока при запрыгивании на груду ящиков может быть более удобная позиция для стрельбы по плохим парням. Если позиция на груде ящиков действительно более удобная, то все отлично. Если же это не так, то может пройти еще целый ход {full round} перед тем, как обнаружится недопонимание. (И к этому моменту, конечно, уже слишком поздно его устранять.)

В конечном счете, мы возвращаемся к нашему общему принципу (понимать, зачем игроки пытаются совершить что-либо, перед тем, как выносить суждение относительно этого действия). Однако из сказанного выше следует, что вам необходимо понимать цели игроков не только на на микроуровне {micro-level}, но и на макроуровне {macro-level} (И, по правде сказать, недопонимания на макроуровне могут нанести намного больше ущерба игре, поскольку до того, как они станут понятны, на достижение цели может оказаться затрачено очень много средств.)

Понимание применяемого игроком способа
Более того, понимания намерения недостаточно. Вам также нужно понимать, какой способ применяется для достижения данного намерения.

Опять же, на практике намерение и способ подчас смешиваются, обычно поскольку играющие естественным образом переходят сразу к способу. “Я хочу пронзить его мечом!” — это способ, за которым прячется более общее намерение “Я хочу навредить ему!” (И, по правде говоря, я собираюсь в дальнейшем рассматривать намерение и способ как одно и то же, поскольку большую часть времени так оно и есть).

Однако время от времени отсутствие способа может быть проблемой. Обычно так происходит на макро-уровне, и, по-моему, чаще всего это всплывает при социальных взаимодействиях {social interactions}: “Я хочу соблазнить принцессу” или “Я убеждаю его помочь нам войсками” — это заявления о намерениях, в которых, очевидным образом отсутствует способ достижения этих намерений. Можно представить себе заявки вроде: “Я хочу оказаться по другую сторону стены” или “Я хочу, чтобы он умер!”

Если мы предполагаем, что умения персонажа приводятся в действие умениями игрока, то можно посмотреть на эту проблему и с другой стороны: такая заявка игрока недостаточно конкретна для того, чтобы были задействованы умения его персонажа.

По счастью, эта проблема довольно легко решается: “Каким образом ты это делаешь?” {“How do you do that?”}

Обычно этого достаточно. Но иногда вам могут попасться игроки, которые хотят просто “закидать это игромеханикой” {“throw a mechanic at it”}. Это чревато проблемами, поскольку (а) вам придется постоянно требовать от них дополнительных подробностей, и (б) они нередко верят, что “Я использую Дипломатию, чтобы соблазнить ее” или “Я использую Знание Подземелий {Dungeoneering}, чтобы оказаться по другую сторону” — это осмысленные ответы на подобный вопрос. В таком случае вам просто нужно начать напирать на конкретные подробности: “Как ты приветствуешь ее? Что ты ей говоришь? Когда она говорит то-то и то-то, как ты отвечаешь?”

Следует отметить, что это одна из причин, по которой я говорю об Искусстве {ART} суждений, а не о Науке {SCIENCE} суждений. Существует золотая середина, в которой способ был описан достаточно подробно для того, чтобы умения игрока привели в действие умения персонажа. Что считать этой золотой серединой, зависит от вас, от ваших игроков, от используемой системы правил и от непосредственной ситуации, сложившейся на сеансе игры.

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

Для большинства групп прямой вопрос “Кто это сделал?”, вероятно, будет слишком широким. (Можно представить себе, что Ведущий просто скажет игроку проверить навык Детектива, чтобы выяснить ответ на такой вопрос, но, скорее всего, в 99,99% случаев это не сработает.)  В противоположность этому, заявка “Я хочу осмотреть тело, чтобы определить время смерти” почти наверняка достаточно конкретна. (Можно представить себе Ведущего, который, перед тем как дать возможность выяснить ответ, потребует от игрока уточнить, что он проверяет синюшность {lividity} трупа, но это столь же маловероятно.)

Однако между этими крайностями есть много места для личных предпочтений. И это не является линейной шкалой. Например, достаточно ли конкретна заявка “Я обыскиваю комнату в поисках улик”? Это определенное действие, которое в большинстве систем очевидным образом соотносится с проверкой навыка. Но, может, вам хочется знать, что именно он пытается найти или каким образом он это ищет? С другой стороны, что насчет заявки “Я  хочу выяснить, каким образом он был убит”? Она более конкретная в том, что касается намерения, но менее определенная, когда дело доходит до способа. Осматривает ли персонаж тело? Обыскивает ли комнату в поисках следов {physical traces}? Проверяет ли записи с камер видеонаблюдения {security footage}?

Нахождение золотой середины
Здесь нет “правильного” ответа, но вы интуитивно почувствуете, что вам подходит.

Я бы посоветовал Ведущим установить относительно низкие требования {threshold} к  конкретности заявки, достаточной для принятия суждений. Если игрок хочет дать вам более конкретную заявку — если можно принять более подробные решения, которые он считает значимыми для данной ситуации или для его персонажа — тогда игрок волен принять эти решения.

То есть если ИП находит в подземелье сундук, типичной реакцией игрока может быть “Я обыскиваю его в поисках ловушек.” На что Ведущий может ответить “Хорошо, это достаточно конкретно. Бросай на Обыск.” Но позднее может найтись другой сундук, который игрок сочтет куда более подозрительным, так что он скажет “Я начинаю очень осторожно проверять, нет ли нажимных плит на полу вокруг и под сундуком” или “Я тщательно осматриваю сундук снаружи перед тем, как коснуться его.” И Ведущий может ответить на такие заявки, включив эти дополнительные подробности в принимаемое суждение. (Умения игрока превосходят умения персонажа.)

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

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

Эта “точка невозврата” {“point of no return”} довольно очевидна для взмаха меча: вы не можете решить, что делаете что-то другое, после того как увидели, что провалили бросок атаки. Но в других ситуациях все может быть несколько запутаннее. Например, если вы играете с картой поля боя {battlemap} и кто-нибудь говорит “Я хожу в эту клетку {square}. Нет, погодите, на самом деле я хотел сходить в вот эту клетку.”, нормально ли это? Возможно.

Но что если он уже “завершил” свое движение и начал обсуждать намерение относительно следующего действия, и только после этого понял, что ему стоило бы сходить в другую клетку, чтобы его следующее действие сработало наилучшим образом? Или если он заявит “На самом деле я бы предпочел остаться в укрытии.” после того, как его персонаж вышел в коридор, и огр {ogre} использовал подготовленное действие, чтобы выстрелить по нему?

Мое общее практическое правило {rule of thumb} в таких случаях состоит в том, что если

(а) в результате действия была получена новая информация, или

(б) кто-либо еще начал совершать действие,

то точка невозврата уже пройдена.

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

0

3

Глава 3: Круговорот описания и игромеханики

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-3-круговорот-описания-и-игром/

Перевод: Ангон

Оригинал: Art of Rulings – Part 3: The Fiction-Mechanics Cycle

Написал Джастин Александер в октябре 2015

Перевел Ангон в июне 2018

Banksy - World Leaders at Dice

Что касается заявления намерения, стоит учитывать различие между заявками {declaration}, начинающимися с игромеханики {mechanics-first}, и заявками, начинающимися с описания {fiction-first}.

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

Ведущий: Во внутреннем дворе {courtyard} полно стражи.

Игрок: Могу я прокрасться по периметру внутреннего двора? Держась в тени?

Ведущий: Да. Пройди-ка проверку Скрытности {Stealth check}.

Начинающаяся с игромеханики заявка, с другой стороны, указывает на игромеханику, которую игроку хочется использовать. Например:

Ведущий: Во внутреннем дворе полно стражи.

Игрок: Могу я пройти проверку Скрытности, чтобы пробраться мимо них?

Ведущий: Да. (после проверки) У тебя получается прокрасться по периметру внутреннего двора, держась в тени.

По моему опыту, начинающаяся с игромеханики заявка обычно приводит к тому, что описание {fictional description} действия дается Ведущим (обыкновенно как часть изложения исхода после разрешения проверки), но это не обязательно. Легко можно представить себе и такой вариант:

Ведущий: Во внутреннем дворе полно стражи.

Игрок: Могу я пройти проверку Скрытности, чтобы пробраться мимо них? Может прокрасться по периметру внутреннего двора?

Ведущий: Конечно. Там густая тень. Так что кидай.

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

Напротив, допустим кто-нибудь использует диссоциированную игромеханику {dissociated mechanic}, например тратит Единицу Удачи {Luck Point}, чтобы перебросить кубик. Его персонаж не представляет, что такое Единица Удачи, так что использование Единицы Удачи — неизбежно чисто игромеханическое решение, и любая заявка использовать Единицу Удачи, само собой, будет начинаться с игромеханики.

(Один из важнейших недостатков диссоциированной игромеханики — что она препятствует или мешает начинающимся с описания заявкам, а заявки, начинающиеся с диссоциированной игромеханики, не позволяют отыгрывать персонажа {roleplaying}.)

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

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

Игрок: Я пытаюсь прокрасться по периметру внутреннего двора и делаю проверку Скрытности, чтобы пробраться мимо них.

внешне выглядит похоже на начинающуюся с описания, поскольку “описательная часть” {“fiction bit”} находится в первой половине предложения. Но по сути она тождественна заявке:

Игрок: Я делаю проверку Скрытности, чтобы пробраться мимо них, крадясь по периметру внутреннего двора.

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

Единственно верный подход
Так какой из этих подходов “верен”?

Оба.

Иногда встречаются пуристы, полагающие что только один их этих подходов к ролевым играм является единственно-верным. Сторонники начинать с описания {fiction-first purists} обычно говорят о том, что это способствует вживанию {immersive}, или о том, что начинать с игромеханики — это не “настоящий отыгрыш”. Сторонники начинать с игромеханики {mechanics-first purists} говорят про краткость и ясность игромеханических заявок, или расстраиваются, почему сторонники начинать с описания “забывают, что ролевая игра — это все же игра”.

Но хотя личные вкусы игрока и предпочтения игровой группы безусловно влияют на то, как в ходе игры заявляются намерения, правда в том, что почти любая реальная игра состоит как из заявок, начинающихся с описания, так из заявок, начинающихся с игромеханики. Каждый ход боя тратить кучу времени на выяснение, означает ли такое описание взмаха мечом отчаянную атаку, обычную или защитную {full attack, a standard action, or fighting defensively} — та еще морока {pain in the ass}. А ролевая игра, состоящая исключительно из полностью игромеханических взаимодействий, будет чертовски пресной {bland as hell}.

Что до утверждения, будто начинающиеся с игромеханики заявки — это не “настоящий” отыгрыш, выкиньте это из головы {fuhgeddaboutit}. За исключением отдельных диссоциированных механик вроде Единиц Удачи или Вмешательства Ведущего {GM Intrusions}, принятие игромеханических решений в ролевой игре является отыгрышем. А если под “отыгрывать” просто имеется в виду “говорить атмосферно {immersively} и/или от лица персонажа {in character}”, то стоит отметить, что начинающиеся с игромеханики заявки — необходимое условие при подходе с  “фортуной в начале” {fortune-at-the-beginning}, который нередко используется ради создания богатых и многообещающих возможностей для отыгрыша-актерства {roleplaying-as-acting}. (К этому мы еще вернемся.)

В заключение хочу отметить, что большинство из виденных мною проблем, которые связывают с начинающимися с игромеханики заявками, на самом деле возникают вследствие отсутствующего способа. Если игрок заявляет “Я хочу использовать Дипломатию, чтобы поговорить с леди Вероникой {Lady Veronica}”, проблема не в том, что игрок упомянул название конкретного навыка, а в том, что он не объяснил, как именно он собирается этот навык использовать. Подобным образом, если игрок заявляет “Я хочу атаковать орка”, правильным ответом будет “Чем ты его атакуешь?” {“What are you attacking with?”}

Ограниченные игромеханикой заявки
Термины “начинающаяся с игромеханики” и “начинающаяся с описания” подразумевают, что вторая часть выражения следует по пятам за первой. Вы начинаете с игромеханики, а потом переходите к описанию. Или вы начинаете с описания, а потом переходите к игромеханике. Вы используете игромеханическую модель игрового мира, а потом описываете происходящее в игровом мире согласно модели. Или вы описываете происходящее в игровом мире, а потом моделируете это игромеханически. Это взаимосвязанный круговорот {linked cycle}.

Начинающиеся с игромеханики заявки являются частью этого взаимосвязанного круговорота, и поэтому их не стоит путать с другим стилем игры, который я называю “ограниченным игромеханикой” {mechanics-only}. При ограниченном игромеханикой подходе связь между игромеханикой и описанием игрового мира нарушена, и исключительно игромеханика определяет ход игры. 

Прочтя это описание, вы могли подумать о чем-то вроде:

Игрок: Я атакую орка. 22 на попадание.

Ведущий: Попал.

Игрок: 18 урона.

Ведущий: Орк атакует тебя. Бросай на защиту.

Игрок: 12.

Ведущий: Орк промахнулся.

Но хотя это может быть примером ограниченной игромеханикой игры, это не обязательно так, и это не то, о чем я говорю. По правде говоря, оказалось довольно сложно объяснить суть ограниченного игромеханикой подхода так, чтобы это было понятно, поскольку на первый взгляд он кажется очень похожим на виды игры, от которых на самом деле совершенно отличается. Это особенно справедливо в тех нередких случаях, когда ограниченная игромеханикой игра сочетается с богатыми и подробными описаниями происходящего в игровом мире … просто эти описания никак не связаны с игромеханикой. (Интересно отметить, что больше всего сложностей с пониманием отличий ограниченного игромеханикой стиля игры возникает у тех, кто сам играет таким образом, во многом потому, что они не понимают, что их игры чем-то отличаются от других.)

Star Wars: Imperial Asssault - Fantasy Flight Games

Возможно будет понятнее, если я укажу на распространенность ограниченной игромеханикой игры в настолках {board games}. При игре в Arkham Horror, Imperial Assault или что-то подобное играющие подчас описывают элементы повествования или даже стараются говорить от лица персонажей. Но ничего из этого не имеет обратной связи с игромеханикой; это просто импровизированный слой {improvisational layer}, который не смешивается с игрой, как масло не смешивается с водой.

Например, рассмотрим игру Risk. Ваша армия из Якутии {Yakutsk} вторгается в Сибирь {Siberia}. Вы произносите воодушевляющую речь перед вашими войсками, а затем описываете, как разделяете свою армию и осуществляете гениальный обходной маневр … и ничего их этого не оказывает никакого влияния на результат. И дело не в том, что в игре нет игромеханики, учитывающей боевой дух {morale}, а боевая игромеханика слишком абстрактна для моделирования движения каждого отдельного отряда — дело в том, что импровизация (хотя и, вне всякого сомнения, увлекательная) принципиально отделена от собственно игрового процесса {gameplay}. Они оба происходят одновременно и в одном и том же месте, но никак не связаны друг с другом. (Или, в лучшем случае, связаны не напрямую.)

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

Например, рассмотрим ролевую игру, в которой есть боевой маневр {combat maneuver} Подсечка {Leg Sweep}. Он разработан намеренно и исключительно для моделирования приема, заключающегося в подсекании ног противника. Теперь представьте, что вы сражаетесь с Колышущимся увальнем {Undulating Hulk}: у него нет ног, но для ограниченного игромеханикой игрока это не имеет значения. Нигде в правилах не сказано, что вы не можете применить Подсечку против Колышущегося увальня, так что вы вправе это сделать.

Возможно, вы полагаете, что в данном примере Ведущий решил, что определенная игромеханика (маневр Подсечки) достаточно точно отражает то, что ИП хотел сделать с Колышущимся увальнем (задержать его на Малое Действие {Minor Action} или что-нибудь вроде), и потому счел возможным принять суждение, основываясь на этой игромеханике. Но это не то, что происходит в ограниченной игромеханикой игре.

Представьте себе заклинание {spell}, которое прекращает биение сердца жертвы и, таким образом, убивает ее. Если только перечень возможных целей этого заклинания явным образом не ограничен игромеханически, ограниченный игромеханикой Ведущий разрешит сотворение этого заклинания на вампира, несмотря на то, что его сердце уже не бьется, и даже на неупокоенного скелета {animated skeleton}, вообще лишенного сердца, на которое могло бы подействовать заклинание.

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

В конечном итоге, в ограниченной игромеханикой ролевой игре ассоциированная игромеханика {associated mechanics} превращается в диссоциированную безо всякой на то необходимости. Как я говорил в прошлом, я не возражаю против существования в НРИ диссоциированной игромеханики, но только если эта игромеханика приносит какие-нибудь преимущества, недостижимые другими способами. Ограниченный игромеханикой подход не имеет никаких заметных преимуществ. Нельзя даже сказать, что сторонники этого подхода выплескивают ребенка вместе с водой — они просто выплескивают ребенка.

Сложно сказать, насколько распространен ограниченный игромеханикой стиль игры. Я практически не встречал его “в природе” {“in the wild”}, так сказать, но сетевые обсуждения диссоциированной игромеханики часто привлекают подобных игроков. (Поскольку ограниченные игромеханикой игроки превращают ассоциированную игромеханику в диссоциированную, они никак не могут понять, в чем между ними разница.)

По моим ощущениям, ограниченный игромеханикой подход чаще возникает во время боев, даже среди игроков, которые в других случаях этого подхода не придерживаются. Может быть, это даже внесло немалый вклад в распространенное убеждение, что есть какое-то различие между “боевкой” {“combat”} и “отыгрышем” {“roleplaying”}. (Мне всегда было сложно понять это убеждение, поскольку ситуация, когда на карту поставлены жизнь и смерть, должна быть горнилом развития персонажей, а не местом, в котором о персонажах забывают.)

(Что насчет ограниченного описанием подхода? Это игра {playing} в “словеску” {“let’s pretend”} без какой-либо игромеханической структуры. Этот подход не характерен для ролевых игр, поскольку он по сути своей не нуждается в собственно игре {the game}, но определенную склонность к нему можно увидеть в некоторых разновидностях мухлевания на кубах {dice-fudging}, а также в тех случаях, когда играющие просто игнорируют отдельные разделы игромеханики.)

0

4

Глава 4: Согласие по умолчанию

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-4-согласие-по-умолчанию/

Перевод: Ангон

Оригинал: Art of Rulings – Part 4: Default to Yes

Написал Джастин Александер в ноябре 2015

Перевел Ангон в июле 2018

Мы начали с рассмотрения того, как заявки игроков (или их отсутствие в случае пассивного восприятия) запускает принятие суждения. Затем мы разложили заявку на намерение, способ и начало действия. Теперь мы готовы перейти к самой сути суждения: разрешению {Resolution}.

Разрешение — это перемычка между намерением и исходом. Во многом о нем можно думать как об испытании {test}: намерение персонажа испытывается, а следствием этого испытания является исход действия. Следовательно, в самых общих чертах разрешение определяет, преуспел ли персонаж в осуществлении своего намерения. (Хотя как мы вскоре увидим, это не всегда настолько просто.)

Согласие по умолчанию

Самое простое суждение, которое может принять Ведущий — это “Нет” {“No”}.

Игрок: Я хочу перепрыгнуть через расщелину {chasm}.

Ведущий: Не получится.

Игрок: Я хочу убедить герцогиню поддержать лорда Бекингема {Lord Buckingham}.

Ведущий: Она отказывается слушать.

Игрок: Я расспрашиваю горожан, не слышали ли они чего-нибудь об огре в окрестностях?

Ведущий: Никто ничего не слышал.

Если отвечать “нет”, то все просто: нет осложнений, нет последствий. Все ясно, понятно и совершенно окончательно.

Это делает такой ответ невероятно полезным инструментом. Но также поэтому вам практически никогда не стоит его использовать.

На самом деле вам стоит стремиться к прямо противоположному: к согласию по умолчанию {Default to yes}.

Игрок: Я хочу перепрыгнуть через расщелину.

Ведущий: Хорошо, ты на другой стороне.

Игрок: Я хочу убедить герцогиню поддержать лорда Бекингема.

Ведущий: Она выслушивает твое предложение и соглашается с тем, что оно выгодно.

Игрок: Я расспрашиваю горожан, не слышали ли они чего-нибудь об огре в окрестностях?

Ведущий: Старина Хоб {Old Man Hob} говорит, что в прошлом месяце хуторянин по имени Уиллис {farmer named Willis} клял огра, перебившего его овец.

“Нет” по природе своей останавливает действие и оставляет ситуацию неизменной. С другой стороны, “Да” {“Yes”} безусловно движет действие вперед и создает новую ситуацию, на которую придется отвечать как вам, так и игроку. Теперь, когда персонаж на другой стороне расщелины, что он сделает? Как ответит лорд Бекингем на неожиданную поддержку со стороны герцогини? Попытаются ли ИП выследить предполагаемого Уиллисова огра?

Другая причина соглашаться по умолчанию состоит в том, что, вообще-то, люди преуспевают в большинстве вещей, которые пытаются сделать. Вы собираетесь поехать в центр города {downtown}? Найти какую-то информацию, погуглив? Забронировать билеты на самолет до Каира {Cairo}? Все это скорее всего случится, если вы попытаетесь это сделать.

Да, но…
Однако если соглашаться всегда, то это приведет к проблеме отсутствия вызова {challenge}. Это скучно и предсказуемо. (Кроме того, это не отражает то, как устроен мир: провал {failure} или возможность провала — это часть нашей жизни).

Все это означает, что нам нужно добавить в наш инструментарий {toolkit} новый инструмент: “Да, но…” {Yes, but…}.

Игрок: Я хочу перепрыгнуть через расщелину.

Ведущий: Ты прыгаешь через расщелину, но как только ты приземляешься на другой стороне, пол обрушивается под твоим весом, и ты проваливаешься в бездонную пропасть…

Игрок: Я хочу убедить герцогиню поддержать лорда Бекингема.

Ведущий: Она с интересом выслушивает твое предложение и кажется заинтригованной, но она хочет, чтобы ей была обещана поддержка ее наследственных прав на Восточный Предел {Eastermark}.

Игрок: Я расспрашиваю горожан, не слышали ли они чего-нибудь об огре в окрестностях?

Ведущий: Старина Хоб говорит, что в прошлом месяце хуторянин по имени Уиллис клял огра, перебившего его овец. Но когда ты говоришь с ним, ты замечаешь, что кто-то наблюдает за вами из темного угла таверны…

“Да, но…” обогащает предложенную игроком идею. Такой ответ позволяет добавить к сделанному игроком вкладу свой собственный. Это не отрицающее “нет”, но и не предсказуемое “да”.

Нет, но…
Звучит замечательно, правда?

Но что, если желания игроков противоречат известным фактам игрового мира {game world}? Например, они хотят узнать слухи {rumors} об огре, но вы знаете, что в окрестностях этого города нет никаких огров?

Можно предположить, что это приводит нас обратно к “нет”, но до этого дело еще не дошло. Вообще, “нет” является приемлемым ответом только если намерение прямо противоречит реальности игрового мира. Так что до того, как вернуться к “нет”, стоит остановиться на “Нет, но…” {No, but…}.

Игрок: Могу я найти гильдию волшебников {wizard’s guild}?

Ведущий: Да.

Игрок: Могу я найти гильдию волшебников?

Ведущий: Да, но только если ты отправишься в Грейхок {Greyhawk}, потому что в этом городе гильдии волшебников нет.

Игрок: Есть в этом городе гильдия волшебников?

Ведущий: В этом городе нет, но есть в Грейхоке.

Игрок: Есть в этом городе гильдия волшебников?

Ведущий: В Берлине, в 1982 году? Нет.

Как вы можете видеть, “Нет, но…” во многом то же самое, что и “Да, но…”, просто с другой точки зрения. Четкое различие можно провести тогда, когда выбранный персонажем способ достижения намерения явно не подходит. “Нет, таким образом ты своей цели не достигнешь. Но есть другой подход, которым ты мог бы воспользоваться.”

Диапазон произвола Ведущего
Давайте назовем совокупность этих четырех ответов диапазоном произвола Ведущего {spectrum of GM fiat}:

Да
Да, но…
Нет, но…
Нет
Причина, по которой стоит соглашаться по умолчанию (то есть начинать с верхнего пункта этого диапазона и прорабатывать их по очереди, спускаясь вниз) состоит в том, что каждый сделанный игроками запрос обычно отражает то, что им хочется совершить. Когда игрок говорит “Я хочу совершить Х”, он имеет в виду “Я бы получил удовольствие {fun}, если бы смог совершить Х”. И если у вас нет действительно хорошей причины, не стоит запрещать игрокам совершать то, что им хочется. Сеансу игры, скорее всего, пойдет на пользу, если вы сможете выяснить (и предложить игрокам) подход, с помощью которого они смогут совершить это.

В некоторых случаях они откажутся от этого подхода (“Я не собираюсь идти в Грейхок, до него слишком далеко.”) Это нормально. Это означает, что они предпочитают совершить что-нибудь еще. Но вы дали им значимый выбор {meaningful choice}, а не отобрали его. В конце концов, выбор — это суть ролевых игр.

Banksy - Bomb Hugger

Одна из сильных сторон подхода “Да, но…” в том, что на деле такую систему довольно сложно обмануть:

Игрок: Могу я сделать ядерную бомбу {nuclear bomb}?

Ведущий: Да, но сначала тебе нужно придумать какой-нибудь способ раздобыть обогащенный уран {enriched uranium}. И если правительство узнает, чем ты занимаешься, тебе светят крупные проблемы начиная с попадания в список разыскиваемых террористов {terrorist watch list}.

(Иногда, конечно, может оказаться, что вы имеете дело с раздражающим игроком {troll player}, который постоянно спрашивает, можно ли полететь в галактику Андромеда {Andromeda galaxy}, во время вашей кампании, посвященной Второй Мировой войне. Но если это происходит постоянно, то с вашей проблемой надо разбираться способами, не имеющими никакого отношения к разрешению действий.)

Если вам очень сложно избегать “Нет”, не стоит забывать, что близким родичем “Да, но…” является “Расскажи мне, как ты это делаешь.” По сути это тоже самое, за исключением того, что вы побуждаете игрока самого подумать насчет “но”.

Игрок: Могу я сделать ядерную бомбу?

Ведущий: Хорошо. Расскажи мне, как ты ее делаешь.

Игрок: Ну… Мне нужен источник обогащенного урана. Могу я сделать проверку Связей {Contacts check}, чтобы посмотреть, нет ли у одного из моих старых русских приятелей {old Russian buddies} возможности достать немного на черном рынке?

Последний диалог также указывает в направлении съезда {exit ramp}, уводящего нас от диапазона произвола Ведущего: “Я не уверен. Давайте выясним.”

Это та точка, в которой Ведущий и игрок совместно обращаются к переменчивой фортуне {fickle fortune} (то есть к игромеханике) в поисках ответа. Конечно, роль Ведущего еще не завершена: если разрешение заключается в испытании намерения персонажа, то приходит время Ведущему разработать это испытание.

0

5

Глава 5: Навык и сложность

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-5-навык-и-сложность/

Перевод: Ангон

Оригинал: Art of Rulings – Part 5: Skill and Difficulty

Написал Джастин Александер в ноябре 2015

Перевел Ангон в июле 2018

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

Однако перед тем как мы возьмем в руки кубики, стоит немного поразмыслить над возможным положением дел при провале действия персонажа. Провал должен быть интересным и/или значимым. Если это не так, то вам не стоит кидать кубики. Яснее всего это видно на примере, в котором ответом на провал является простое повторение попытки:

Игрок: Я пытаюсь взломать замок.

Ведущий: У тебя не получилось. Что ты делаешь?

Игрок: Я снова пытаюсь взломать замок.

Ведущий: У тебя не получилось. Что ты делаешь?

Игрок: Я снова пытаюсь взломать замок.

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

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

Ведущие часто допускают ошибку, считая что затрата ресурсов сама по себе значима. Например, время — это самый основной ресурс, который можно потратить. Так что они смотрят на вышеприведенный пример со взломом замка и полагают, что проваленные проверки были значимыми, поскольку они отняли у персонажа время. Однако это потерянное время становится по настоящему значимым только если имеет последствия (такие как появление блуждающих чудовищ {wandering monsters}, приближение крайнего срока {deadline}, дополнительное время на подготовку к бою у ждущих за дверью врагов и т.п.).

Сам ход проверки действия, понятное дело, зависит от используемой вами игровой системы. Я не буду пытаться провести здесь полноценное исследование, но обычно такую проверку можно свести к определению навыка {identifying the skill} и установлению сложности {setting a difficulty}.

Определение навыка
Определить навык, который должен использовать персонаж, довольно просто. У каждого навыка есть описание, в котором определены его параметры. Вам просто нужно выяснить, параметрам какого навыка соответствует предлагаемое действие, и обычно это очевидно.

В некоторых случаях может оказаться, что предлагаемое действие может быть отнесено в область компетенции нескольких различных навыков. Обычно имеет смысл просто разрешить персонажу использовать тот навык, который у него лучше. Исключение стоит сделать, если вы полагаете, что один из навыков меньше подходит для выполняемого задания, чем другой. В разных системах это решается по-разному, но хорошим решением, подходящим в большинстве случаев, будет разрешить проверку менее подходящего навыка с небольшим штрафом. (Другой вариант — при успешной проверке менее подходящего навыка дать бонус к проверке основного навыка {primary skill}. Или, как в 3 редакции D&D, разрешить персонажу безо всякой проверки получить бонус синергии {synergy bonus} за мастерство во вспомогательном навыке {secondary skill}.)

Лично я предпочитаю системы, в которых навыки описаны с небольшим количеством пересечений. Каких-то пересечений избежать не получится, но возможность однозначно определить, какой именно навык используется в данном случае, обычно упрощает и ускоряет разрешение действия, позволяя не колебаться при выяснении подходящего к данной проверке навыка. Особенная морока, когда пересекаются часто используемые “вслепую” навыки вроде Внимательности, проверка которой позволяет заметить сидящих в засаде врагов. Поскольку игрок не знает наверняка, для чего именно делается проверка, он не может напомнить Ведущему, что у него есть другой подходящий навык: чтобы определить, заметил ли персонаж моржа-мозгоеда {brain-eating walrus}, Ведущий проверял навык Обнаружение Клыкастых Животных {Spot Tusked Animal}, но выяснилось, что у персонажа более высокое значение навыка Обнаружение Плотоядных Морских Млекопитающих {Spot Carnivorous Sea Mammals}.

(Такой игры на самом деле нет. Но должна быть.)

Разумеется, не во всех играх есть навыки. Однако когда их нет, в большинстве случаев используются та же самая процедура, только по отношению к атрибутам. (Во многих системах навыки и атрибуты на самом деле одно и то же, просто называются по-разному. Возьмите единственный показатель “насколько я хорош во всем” и, если предпочитаете большую детальность, разделите его на полдюжины атрибутов. Если же вам нужно еще больше детальности, разделите каждый атрибут на полдюжины навыков. Только в тех системах, где навыки свободно сочетаются с несколькими атрибутами, игромеханика на самом деле изменяется. Но я отвлекся.)

Установление сложности
Есть два основных способа установления сложности:

Посмотреть на перечень сложностей и назначить соответствующую или сопоставимую сложность.
Начать со сложности “по умолчанию” и настроить ее, учтя  изменяющие ее факторы.
С некоторыми системами лучше сочетается один из этих подходов. Например, системы D20 склоняются к назначаемой сложности и включают таблицы сложностей, в которых говорится что-нибудь вроде “Сложное задание {Hard task} имеет УС20 {DC 20}” или “Трудновыполнимое задание {Formidable task} имеет УС25”. С другой стороны, “Зов Ктулху” {Call of Cthulhu} склоняется к настраиваемой сложности, поскольку “по умолчанию” целевой показатель {target number} равен значению навыка персонажа, а Ведущий настраивает сложность, применяя к этому значению модификаторы.

Однако вне зависимости от используемой системы правил вы можете использовать любой из этих приемов. (И на деле скорее всего будете использовать и тот, и другой в сочетании.) Например, ведя игру по D&D, вы легко можете начать со сложности УС15 по умолчанию, а затем сказать “Поскольку идет дождь и скалы скользкие, стоит поднять УС до 18”.

Взятие 1 / Взятие 10 / Взятие 20
Что касается сложности, я нахожу полезными три дополнительных показателя. Я буду говорить о них, используя терминологию Третьей Редакции D&D , поскольку первоначально я сформулировал эту идею в рамках данной системы. (Это может немного запутать играющих в Четвертую и Пятую Редакции, поскольку разработчики этих редакций приняли крайне странное решение относительно “пассивных” проверок, и описание игромеханики не соответствует математике этой игромеханики. Придется им смириться с этим, потому что я не собираюсь жонглировать битыми бутылками {jump through the broken hoops} неудачно разработанной игромеханики.)

D&D 3rd Edition - Player's Handbook

Взятие 20: Если вы “берете 20” в D&D, результат рассчитывается так, как если бы выкинули чистую 20 {natural 20} на к20. Другими словами, это наилучший успех, какой только персонаж в состоянии достичь. Взятие 20 используется в ситуациях вроде приведенного выше примера со взломом замка. Поскольку персонаж может пытаться снова и снова, пока не преуспеет, мы можем просто “взять 20” чтобы понять, может ли он вообще преуспеть или нет.

Взятие 10: В D&D, вы можете “взять 10”, если вы действуете в спокойной обстановке. Это средний результат, который может выпасть на кубике. В правилах говорится, что “персонаж может достичь такой степени успеха, если действует в спокойной обстановке и не особенно напрягается”.

Взятие 1: Это понятие в D&D не обозначено как таковое, но оно естественным образом вытекает из игромеханики. Если вы “берете 1” на своем броске, то это худший результат из всех, каких может достичь персонаж. Если сложность задания меньше или равна степени успеха персонажа, “взявшего 1”, значит персонаж автоматически успешно выполняет это задание.

В общем, эти понятия раскладывают задачи на три категории: В чем персонаж преуспеет, даже не стараясь (Взятие 1)? В чем он всегда успешен, если приложит силы (Взятие 10)? И в чем он в конце концов преуспеет, если ему дадут достаточно времени (Взятие 20)?

(Например, представьте, что в комнате что-то спрятано, и требуется проверка Обыска с УС25, чтобы это найти. Персонаж с Обыском +5 всегда найдет этот предмет, если у него будет достаточно времени, чтобы обшарить всю комнату. Персонаж с Обыском +15 найдет этот предмет после быстрого осмотра комнаты. А персонаж с Обыском +25 заметит этот предмет, просто зайдя в комнату.)

Эти понятия вообще полезны для D&D (и других систем), поскольку ускоряют и упрощают разрешение действий. Но они могут быть особенно полезны при установлении сложности. Оцените, насколько умелым должен быть человек, совершающий такие действия, а потом используйте его для сопоставления.

Например, я сделал такие таблицы для Третьей Редакции D&D:

Таблица №1: Профессиональность {SKILLED PROFESSIONALS}

Бонус Навыка {Skill Bonus} Уровень подготовки  {Level of Training}
-1 или хуже Бездарный {Untalented)
+0 Необученный {Untrained}
+1 Знающий азы {Basic Training}
+5 Ученик {Apprentice}
+10 Профессионал {Professional}
+15 Мастер {Master}
+20 Великий мастер {Grand Master}
+25 Легендарный мастер {Mythic Mastery}
Таблица №2: Типичный Уровень Сложности {GENERIC DIFFICULTY CLASS}

УС
{DC} Задание
{Task} Подготовка для взятия 10 {Take 10 Training} Подготовка для взятия 20
{Take 20 Training}
0 Очень простое {Very Easy} Необученный Необученный
5 Простое {Easy} Необученный Необученный
10 Обычное {Average} Необученный Необученный
15 Непростое {Tough} Ученик Необученный
20 Испытывающее {Challenging} Профессионал Необученный
25 Трудновыполнимое {Formidable} Мастер Ученик
30 Эпическое {Heroic} Великий мастер Профессионал
35 Неимоверное {Incredible} Легендарный мастер Мастер
40 Почти невыполнимое {Nearly Impossible} Легендарный мастер Великий мастер
Подготовка для взятия 10: Спросите себя: “Насколько подготовленным нужно быть, чтобы успешно выполнять это задание в рабочем порядке {as a matter of routine}?” Найдите этот уровень подготовки в таблице №1, а затем прибавьте 10, чтобы определить УС проверки (что сделано в таблице №2).

Пример: даже кто-нибудь не обучавшийся гончарному делу в состоянии сделать простую и грубую миску, если показать ему, как работает оборудование, так что изготовление подобной миски должно требовать проверки с УС10 (0+10=10). С другой стороны,  для того, чтобы выполнить сальто назад, необходима некоторая подготовка, так что это может потребовать проверки с УС12 (2+10=12).

Подготовка для взятия 20: Когда имеешь дело с особенно сложными заданиями, вопрос должен звучать как “Какой уровень подготовки необходим, чтобы у человека был хоть какой-то шанс преуспеть в выполнении этой задачи?” Найдите этот уровень подготовки в таблице №1, а затем прибавьте 20 для определения УС задания.

Пример: простой человек не может просто взять скрепку и взломать обычный замок. Необходима подготовка. Так что взлом обычного замка должен быть проверкой с УС25 (5+20=25).

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

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

Infinity - Modiphius Entertainment

Некоторые системы правил, такие как D&D или Нуменера {Numenera} легко поддаются такого рода анализу. Однако другие системы могут сбивать анализирующего их с толку. Особенно это верно в отношении систем, использующих “горсти кубиков” {dice pool}. Например, в использующейся в Infinity RPG системе 2к20 {2d20 System} в основном применяется “горсть кубов” из двух двадцатигранников, которая различными игромеханическими способами может увеличиваться вплоть до максимально возможной горсти в 5к20. Игрок пытается выкинуть на каждом кубике значение, меньшее или равное целевому показателю, зависящему от уровня навыка персонажа, а сложность задания оценивается в количестве успехов, которые нужно выкинуть. Вне зависимости от навыка вашего персонажа, у него нет минимальной гарантии успеха. А вспомогательная игромеханика разработана так, что и максимальный теоретически достижимый успех ничем не ограничен.

Вы, конечно, можете углубиться в математические расчеты и вывести осмысленные рекомендации для систем с горстями кубов вроде этой, но вообще вам лучше бы принять их природу и использовать для установления сложности способ “настройки от умолчания” {adjust-from-default}.

На самом деле, система 2к20 во многом обходит этот вопрос, поскольку не полагается на Ведущего в установлении уровня сложности. Как минимум в 95% случаев Ведущий просто решает, является ли сложность задачи Средней {Average} (1) или Испытывающей {Challenging} (2). (Уровни сложности 3, 4 и 5 тоже существуют, но применяются крайне редко.) Это связано с тем, что в системе намного меньше внимания обращается на простую дихотомию успеха или провала проверки. Вместо этого, внимание сосредоточено на величине успеха {margin of success} персонажа.

И именно об этом мы будем говорить в следующей главе.

0

6

Глава 6: Бросая воображаемый жребий

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-6-бросая-воображаемый-жребий/

Перевод: Ангон

Оригинал: Art of Rulings – Part 6: Fictional Cleromancy

Написал Джастин Александер в ноябре 2015

Перевел Ангон в июле 2018

Banksy - Rat on a Chain

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

На самом деле, когда мы принимаем решение бросить кубик, мы по сути говорим: “У этого действия могут быть разные исходы. Давайте вместе выясним, который из них случится.” Это бросок воображаемого жребия {fictional cleromancy} для определения фортуны. И если мы заявляем, что наш жребии может выпасть только на два возможных исхода, мы ограничиваем действенность этого предсказания судьбы {fortune telling}.

Градация результатов
Простейший способ отойти от простой дихотомии успеха и провала — это назначать задаче один показатель сложности {difficulty number}, но затем толковать результат, основываясь на величине успеха {margin of success} или величине провала {margin of failure}. Простейшая универсальная система исходов может выглядеть как-то так:

Успех

Частичный успех {Partial Success}

Частичный провал {Partial Failure}

Провал

В D&D можно назначить необходимые величины в 5 очков {5 points}. Если вы преуспели при проверке меньше, чем на 5, вы достигаете частичного успеха. Если вы провалили проверку, но ваш результат находится в пределах 5 очков от УС, вы страдаете только от частичного провала. Суть частичного результата в том, что он не дает всех выгод успеха или всех невзгод провала (а также нередко обеспечивает возможность предпринять дополнительные действия, чтобы улучшить свой результат).

Например, персонаж пытается перепрыгнуть через расщелину {chasm}. Ведущий требует проверки Прыжков {Jump check} с УС15. Если игрок выкинет 20 (величина успеха — 5), он легко перескочит расщелину и приземлится на другой стороне. С другой стороны, если он выкинет 16, он достигнет только частичного успеха, и Ведущий может рассудить, что персонаж успешно перепрыгнул расщелину, но неудачно приземлился и упал ничком на другой стороне. В то время как результат 12 (величина провала равна 3) может означать, что персонаж немного не допрыгнул, но сумел ухватиться за уступ {ledge} на дальней стороне расщелины (и теперь может подтянуться). Только если игрок выкинет 10 или меньше (величина провала 5+), персонаж беспомощно рухнет в расщелину.

Очевидно, что этот диапазон довольно легко расширить. (Простой пример: величина успеха 5+ на броске атаки в бою может давать +2 к урону, величина успеха 10+ — +4 к урону и так далее.) В некоторых случаях сама идея “успеха” или “провала” совершенно улетучится — вопрос будет состоять только в том, насколько хорошо (или насколько плохо) у персонажа получилось что-то сделать.

Другой подход к рассмотрению градации успеха — это назначение Ведущим множественной сложности {multiple difficulties} для задачи, у которой есть множество возможных исходов. Я часто использую этот прием для проверок Сбора Сведений {Gather Information}, например:

УС Собранные сведения
10 Несколько месяцев назад “Роберт” {“Robert”} наводил справки насчет каменщиков и плотников, которые могли бы искать работу. Если он и нашел кого-то, никто не знает кого.
15 “Роберт” пытался купить ртуть, и в больших объемах. Он останавливался где-то на северном конце Старого Города {Old City}.
20 “Роберт” останавливался в Разбитом Полумесяце {Broken Moon}, но его никто не видел уже некоторое время.
Стоит отметить, что эти два способа на самом деле — просто разные точки зрения на одно и то же явление.  Эту таблицу Сбора сведений можно с легкостью записать и вот таким образом:

Успех Собранные сведения
на 0+ Несколько месяцев назад “Роберт” наводил справки насчет каменщиков и плотников, которые могли бы искать работу. Если он и нашел кого-то, никто не знает кого.
на 5+ “Роберт” пытался купить ртуть, и в больших объемах. Он останавливался где-то на северном конце Старого Города.
на 10+ “Роберт” останавливался в Разбитом Полумесяце, но его никто не видел уже некоторое время.
Испытание с неизбежным успехом
Теперь, когда стало понятно, что игромеханическое разрешение может выдавать диапазон результатов, можно сделать следующий шаг и осознать, что этот диапазон не обязан включать в себя все варианты. Возможные результаты не обязаны варьироваться от “унизительного провала” {“abject failure”} до “непревзойденного успеха” {“outstanding success”}.

Eclipse Phase - Posthuman Studios

Особенно полезным приемом, на мой взгляд, является “испытание с неизбежным успехом” {simple success test}, как оно называется в Eclipse Phase. Это действие, в котором персонаж так или иначе преуспеет — вопрос только в том, сколько времени это у него займет или насколько полным будет его успех.

Если учесть предыдущее обсуждение Взятия 1, станет видно, что испытания с неизбежным успехом могут возникать чисто математически при различных способах игромеханического разрешения действий. Успех может быть обеспечен вне зависимости от того, что у вас выпадет на кубике, так что единственная цель броска — определение качества успеха. (То же самое относится и к вышеприведенным таблицам Сбора сведений. Результат 9 или менее на проверке навыка означает провал: персонаж ничего не узнает о так называемом “Роберте”. Но если у персонажа модификатор +9 в навыке Сбор сведений, тогда успех ему обеспечен: он непременно узнает что-нибудь о “Роберте”, вопрос только в том, сколько сведений он соберет.)

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

(Предположительно могут быть и проверки, в которых неизбежен провал, а игромеханическая проверка определяет только степень этого провала. Вообще, я подозрительно отношусь к такому подходу, поскольку, кажется, им чаще всего злоупотребляют, загоняя игроков на рельсы {enforce railroads} и тому подобное. Но можно представить себе ситуацию, в которой персонаж намеренно избрал направление действий, которое, как он знает, не может увенчаться успехом. Реальный пример подобного — вошедшая в легенду битва при Фермопилах.)

Провал с продвижением
Другая точка зрения на испытание с неизбежным успехом — это принцип “провала с продвижением” {failing forward}.

В основе своей провал с продвижением практически ничем не отличается от испытания с неизбежным успехом: игромеханический провал описывается как произошедший в мире игры {game world} успех с осложнениями.

(Ключевое различие, если таковое вообще существует, состоит в том, что при испытании с неизбежным успехом Ведущий принимает игромеханическое суждение о невозможности провала перед броском кубика, в то время как провал с продвижением — это толкование игромеханического провала после того, как он случился. Но на деле эта грань весьма размыта.)

Например, Лукас {Lucas} пытается взломать замок на двери архива {file room} и проваливает проверку навыка. Ведущий решает, что несмотря на это у Лукаса получилось открыть дверь… но это заняло слишком много времени, и его заметил ночной сторож {night watchman}. Или у него сломалась отмычка. Или он был заснят на камеру, и потом плохие парни смогут его выследить.

Вообще, существует множество полезных приемов, которые можно освоить, чтобы вырваться из стандартной парадигмы “успеха или провала” {success/failure}. Однако мне стоит предостеречь вас о том, что с термином “провал с продвижением” связаны кое-какие пагубные идеи.

Во-первых, некоторые игроки необычайно идеализируют провал с продвижением и полагают, что этот прием должен использоваться постоянно. Кажется, это происходит вследствие распространенности мнения о том, что провал неизбежно приводит к полному прекращению развития событий {scenario}. Классический пример этого — детективный сюжет {mystery scenario}, застопорившийся из-за того, что игроки не сумели найти улику.

Однако как показано в Правиле Трех Улик {Three Clue Rule}, решение этой проблемы заключается в предоставлении множества путей к успеху. А необходимость обходить созданные в результате твоих провалов преграды заведет тебя туда, куда и не ожидаешь. Если бы ты сумел подкупить стражников, чтобы они пропустили тебя через заднюю дверь, ты бы никогда не полез через стену, не вломился бы через окно и не влюбился бы в принцессу, которую встретил за тем окном. Подчас с провала начинаются самые захватывающие ситуации и самые запоминающиеся сюжеты. Если вы совершенно уберете провалы из ваших игр, это не обогатит, а разорит их. Подобно вождению рельс {railroading}, это ошибочный прием {broken technique}, применяющийся для поспешного исправления другого ошибочного приема.

Кстати о вождении рельс, другая серьезная проблема “провала с продвижением” состоит в том, что он несет с собой значительную смысловую нагрузку, вложенную в него Ведущими, использующими этот прием для удержания ИП на рельсах. (Вообще-то с этим может быть связано и происхождение термина, в котором “продвижение” означает движение по заранее запланированному сценарию {pre-planned plot}.)

Но ни одна из этих проблем не является присущей самому принципу “провала с продвижением”, и этот принцип может быть очень полезным инструментом, который стоит иметь в вашем инструментарии {toolkit}.

0

7

Глава 7: Векторы

источник - https://adventurersleague.wordpress.com/2019/03/10/art-of-rulings-глава-7-векторы/

Перевод: Ангон

Оригинал: Art of Rulings – Part 7: Vectors

Написал Джастин Александер в феврале 2016

Перевел Ангон в июне 2018

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

Разумеется, это не всегда верно. Очевидным примером обратного является бой. По правде говоря, подчас интуитивно понятно, что действия в физическом мире {physical realm} распадаются на отдельные этапы. Вы не можете пройти через запертую дверь, пока не найдете способ ее открыть. Если вы хотите выстрелить из гранатомета {rocket launcher} со снайперского насеста {sniper perch} на вершине утеса {cliff} вам сначала нужно забраться на утес.

Однако эти приемы можно плодотворно использовать в более широком качестве. Не осознавая это, мы лишаем наш игровой опыт {gaming experiences} глубины, которой он мог бы обладать. А в некоторых случаях, к тому же, испытываем трудности с разрешением действий, которые можно было бы рассудить этим довольно незамысловатым способом.

Многоэтапное разрешение действий
Перед тем, как углубиться в вопрос о разработке многоэтапного разрешения Ведущим, давайте сперва рассмотрим, как многоэтапные разрешения могут естественным образом возникать во время игры.

Первая и, возможно, самая незамысловатая причина — это незавершенная заявка {incomplete declaration of method}.  Возвращаясь к одному из примеров выше: игрок заявляет, что хочет залезть на вершину утеса, а когда это действие разрешается, добавляет, что хочет подстрелить кого-то со снайперского насеста на вершине. В этом случае игрок, хотя и намеревался с самого начала выстрелить со снайперского насеста, разделил это намерение на отдельные части, поскольку инстинктивно понимал, что нужно сделать А перед тем, как сделать Б.

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

Из этого следует важное заключение {take-away}: количество этапов в потенциально многоэтапном разрешении может изменяться. В некоторых случаях оно даже может свестись к одному-единственному этапу. Обернем наш пример: допустим, чтобы перебраться через расщелину нужно перепрыгнуть ее, ухватиться за уступ, а потом подтянуться наверх. Но игрок выкидывает необычайный успех {extraordinary success} и вместо этого многоэтапного разрешения перепрыгивает расщелину одним прыжком.

Наконец, существует учет действий {action economy}. Например, многоэтапное разрешение действий часто проявляется в бою, поскольку там существует жесткий предел того, сколько действий можно совершить за один ход: “Я схожу сюда в этом ходу, чтобы я мог добраться вот туда на следующем”.

Star Wars: The Phantom Menace - Decoy in the Throne Room

Рассмотрев эти естественные примеры, можно заметить, что им свойственно разделяться на отдельные этапы по схеме “сначала А, потом Б, потом В”. То есть нужно сделать А перед тем, как сделать Б. Это похоже на заключительную часть фильма Звездные Войны: Пробуждение Силы {Star Wars: The Force Awakens}. Десантный отряд должен успешно совершить гиперпространственное сближение {hyperspace approach} с планетой перед тем, как отключить щиты, и им нужно отключить щиты перед тем, как Сопротивление {Resistance} сможет послать в атаку Икс-винги {X-Wings}.

Но есть и другой вариант, когда нужно выполнить множество требований, чтобы получить возможность совершить следующее действие — нужно сделать А, Б и В перед тем, как можно будет сделать Г. Примерно это произошло в конце фильма  Звездные Войны: Скрытая Угроза {Star Wars: The Phantom Menace}. Амидале {Amidala} нужно арестовать вице-короля {Viceroy}, джедаям {Jedi} — победить Дарта Мола {Darth Maul}, а Энакину {Anakin} — уничтожить управляющий дроидами {droid} корабль перед тем, как Торговую Федерацию {Trade Federation} можно будет вынудить подписать новый мирный договор.

Стоит отметить, что таким образом можно разделить действие на очень много этапов: чтобы достичь вашей цели, нужно выполнить А, Б и В, но чтобы совершить А, нужно сначала сделать Г, Д и Е.

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

Одним из способов ответить на эти вопросы может быть то, что Сердитый ДМ {Angry DM} называет очевидной вехой {visible benchmark}. (В другой своей статье Сердитый ДМ обозначил этот же принцип как “ИПы могут видеть тикающие часы” {PCs Can See The Ticking Clock} — примечание переводчика.) Когда вы завершили выполнение одного этапа в ходе многоэтапного разрешения, должна быть явная веха, отмечающая прогресс в достижении цели. Например, представьте ситуацию, в которой ИП взламывает замок на двери, а Ведущий решает, что это действие стоит разрешить тремя последовательными проверками Взлома {Lockpicking checks}. После того, как первая проверка была пройдена, Ведущий спрашивает игрока “Хочешь ли ты продолжать взламывать замок?”

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

Если вновь обратиться к естественным примерам, можно заметить, что у них есть естественные очевидные вехи. Если вы забрались на утес, вы уже не у его подножия. После того, как вы немного недопрыгнули до другой стороны расщелины, вы уцепились за уступ (и ваши возможности теперь отличаются от тех, что были раньше). Если вы атаковали кого-нибудь в бою, вопрос вполне может звучать как “Хочешь ли ты продолжать атаковать его?”, но если ваша атака была успешной, то вы нанесли вашему противнику урон, а если ваша атака завершилась провалом, вы дали ему дополнительную возможность атаковать вас.

Возвращаясь к бессмысленным примерам, мы можем добавить очевидные вехи и в них тоже. Например, вы можете смоделировать взлом замка на двери тремя проверками, чтобы определить, сколько времени взломщику придется потратить, чтобы открыть дверь, и сопоставить затраты времени с крайним сроком, заданным жестко (из-за угла выходит стражник {guard}) или же гибко (вокруг взломщика кипит бой и каждый потраченный на взлом замка ход — это еще один ход, который его товарищи вынуждены отбиваться от орков {orcs}).

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

На самом деле можно, наверно, обобщить идею “очевидных вех” до “значимых последствий”. Значимые последствия должны быть у каждого этапа многоэтапного разрешения. (И желательно, чтобы последствия были значимыми вне зависимости от того, успешно или нет разрешился этот этап, по той же самой причине, по которой это условие является пропускным пунктом для одноэтапного разрешения действий). А это зачастую возвращает нас к нашему старому другу значимому выбору.

Другими словами, если вы посмотрите на разрешение действия в целом и разломите его {break it apart} в каждой точке, содержащей значимый выбор или значимые последствия… эти разломы окажутся отдельными этапами многоэтапного разрешения действия.

Векторы
Another way of looking at multi-step action resolution is what Technoir refers to as vectors. To paraphrase from the game, you have a clear vector to your objective when:

The player’s description of the action is feasible.
There is a clear path for the action. There are no obstacles the character must surmount first.
The objective is a logical consequence of the action described.
Technoir - Jeremy Keller

A vector is, in short, another name for a method, but imbued with the conceptual idea of a straight line: Look at where the vector is being aimed. If it can’t hit what it’s being aimed at (because there’s an obstacle in the way), then you’ll first need to identify a vector which will put you into a position where you can hit what you’re aiming for.

This process can be almost absurdly obvious when you apply the thinking to a physical objective. For example:

You want to go into a room, but the door is shut.
You want to open the door, but the door is locked.
You want to pick the lock.
LOCK → DOOR → ROOM

But once you understand the basic concept of vectors, the same logic can be fruitfully applied to more abstract situations. They’re great for modeling social encounters, for example:

You want to convince the rep from LVC (Lunar Venture Capitalists) to fund your zero-point energy generator, but you need to convince him it’s profitable.
You want to convince him it’s profitable, but you need to convince him it works first.
You want to use your scientific presentation to show him it works, but he’s busy and is brushing you off.
You want to fast talk him into listening to you.
FAST TALK → PRESENTATION → PROFIT → FUNDING

And although these examples have their vectors drawn backwards from the goal (I want to take my shot at X, where can I see X from?), it can be equally useful to draw vectors from the opposite direction (particularly for GMs designing a multi-step resolution). Take a research test to discover information on the Serpent Crowns of Valusia for example:

A web search doesn’t reveal much, but does tell you that there may be more information in H.L. Menckel’s Beneath the Waves: Arcane Archaeology of the Mediterranean, a rare volume.
Additional research at the local college library indicates that the only known copy of the book was recently purchased at auction by Johnny Marcone.
A networking test reveals that Marcone frequents the Velvet Room.
A seduction roll gets you past the bouncers at the front door.
And so forth.

Смена векторов на ходу
One of the major conceptual advantages of this approach is that you can easily hot-swap vectors: Instead of picking the lock, you can seduce the concierge to give you the key. Or pickpocket the master key off the bellhop. Or break the door down.

SEDUCE → DOOR → ROOM

PICKPOCKET → DOOR → ROOM

BREAK → DOOR → ROOM

Alternatively, instead of going through the door, you could climb through the window. Or break through the wall. Or teleport inside.

Of course, this also works great with non-physical vectors: You can get the LVC rep to talk to you by fast talking him. Impressing him with your past accomplishments. Seducing him. Using a display of your zero-point energy device to amaze him.

I find this concept of “hot-swapping” incredibly useful: It allows the GM to construct a framework for resolving complex, multi-step sequences without constraining the options of the players. It keeps your adjudication flexible and loose, allowing player creativity to flow through the structure.

Correctly interpreted, it also shows that the distinction between “organic” multi-step actions and GM determined multi-step actions is, in many ways, a purely arbitrary one. The “organic” examples are simply those where the GM and/or the players instinctively see the vectors involved, whereas the “determined” actions are simply those where they need to think about it. Over time, and with practice, more and more of these interactions are likely to become instinctual and second nature.

Слом векторов
In general, a vector should terminate at the point from which the next vector is being launched (i.e., the point at which the action changes direction). If you finish resolving a vector and the next vector is pointing in the exact same direction, you’re generally left with one of those meaningless questions we talked about earlier. (“Do you want to keep picking the lock?”)

Partial successes and failures, however, can often be expressed as broken vectors: You were running towards point X, but you slipped and you fell. Or something blindsided you. Or you smashed into an invisible wall (or other obstacle you were unaware of). In some cases, these broken vectors will create obstacles which will force the creation of new vectors to route around them, but in many cases they’ll be transitory delays after which the character can point themselves back in their original direction.

For example, let’s go back to that locked room:

LOCK → DOOR → ROOM

On a partial success, the character picks the lock to the door but is spotted by a security guard. This inserts a new vector, after which they resume their original trajectory:

LOCK → FAST TALK GUARD → DOOR → ROOM

Broken vectors can also be found in situations of endurance. For example, if a character is trying to hold a door shut while a werewolf pounds on it from the other side, they can end up with a vector that looks like this:

HOLD DOOR → HOLD DOOR → HOLD DOOR → HOLD DOOR

Probably repeating the same check over and over again from one round to the next while their friends desperately try to figure out an escape route.

You can see a similar pattern in what I refer to as operatic actions for purely idiosyncratic reasons (because I perceive a pattern in opera music where emotional crescendos are achieved through a series of cyclical builds in the power of the music). I also see this pattern a lot in anime or manga, where a character has to build up power over time and the longer they can sustain that build the more effective the result. (A more mundane example might be convincing members of the jury.)

However, now that we’ve talked about how to break an action resolution down into multiple parts, let’s do the exact opposite…

0



Рейтинг форумов | Создать форум бесплатно