Случайный совет Мастеру: числа, которые мы произносим
С одной точки зрения ролевую игру можно описать как упорядоченный обмен информацией между игроками. В особенности — числовой информацией.
Мастер: Сделай бросок атаки.
Игрок: 17.
Мастер: Ты попал.
Игрок: Наношу 18 единиц урона.
Мастер: Орк замертво падает к твоим ногам!
Игрок получает число — складывает свой навык атаки с результатом броска d20 — и сообщает его Мастеру. Мастер выполняет с ним математическую операцию: сравнивает число с Классом Защиты (Armor Class, AC) орка. Результат заставляет его запросить у игрока ещё одно число. Игрок получает его, бросив урон оружия, и сообщает Мастеру. Тот снова выполняет операцию — сравнивает урон с оставшимися у орка хитами (hit points) — и определяет исход: орк погибает.
Всё кажется простым и интуитивно понятным. В данном случае так оно в основном и есть.
Но оказывается, что способы обработки и передачи числовой информации за столом способны сильно повлиять на игру. Например:
Мастер: КЗ орка — 17. Сделай бросок атаки.
Игрок: Попал. 18 единиц урона.
Мастер: Орк замертво падает к твоим ногам!
Передав игроку часть информации — и связанную с ней математическую операцию, — Мастер заметно повысил эффективность общения. Если бы орк не погиб или рядом находились другие такие же орки, выгода со временем возрастала бы: Мастеру не пришлось бы вновь и вновь сообщать игроку это число.
Разумеется, эффективность — далеко не единственная цель ролевой игры. Есть сколько угодно причин, по которым Мастер может захотеть скрыть Класс Защиты орка от игроков — в силу общего принципа или особых обстоятельств. Я не утверждаю, будто остальные соображения в каком-то смысле «неправильны». Я лишь отмечаю, что, выбирая их, Мастер жертвует эффективностью.
Однако во многих случаях Мастер даже не осознаёт, что делает выбор. Зачастую не существует и причин, оправдывающих неэффективность: Мастер просто не задумывается о потоке информации и его влиянии на игру.
Долгое время я тоже этого не понимал. Люди жаловались мне, что такая-то система ужасно сложна и играть в неё — сплошная головная боль, а я недоумевал, потому что мой опыт с игрой был совсем иным. Можно было бы похлопать себя по плечу и решить: «Видимо, я просто умнее». Но игроки также говорили мне: «Я уже играл в такую-то систему и терпеть её не мог, а у тебя всё наконец обрело смысл. Не могу дождаться следующей игры». И я чесал затылок, ведь не делал ничего особенного, объясняя правила.
Разница заключалась в потоке информации. Его передача за игровым столом бывает не только неэффективной, но также запутанной и обременительной.
Eclipse Phase
Обычно мы представляем игровую механику в виде числовых значений и способов их получения или изменения. Но на практике во многих механических разрешениях участвуют сразу несколько сидящих за столом людей. Если представить разрешение как мяч, его часто приходится перебрасывать туда и обратно. Или можно представить танец: если мы — все игроки за столом — не согласуем действия, выполняя процедуру, то начнём наступать друг другу на ноги.
Эффективная передача информации — пример владения системой. По мере того как группа набирается совместного опыта в конкретной НРИ, она часто интуитивно находит подходящие модели поведения. Но так бывает не всегда. В остальных случаях полезно сознательно задуматься:
- какие числа мы произносим;
- кто должен их произносить;
- как именно мы их произносим.
Приведу простой пример из Eclipse Phase.
Eclipse Phase использует процентную систему. Вы изменяете значение навыка в соответствии со сложностью и добиваетесь успеха, если на процентных костях выпадает меньше получившегося числа. Кроме того, величина успеха равна выпавшему на костях числу. Если вы получили 30 или больше и преуспели, результат считается отличным успехом; если 60 или больше — исключительным.
Вот как часто выглядит знакомство новых игроков с Eclipse Phase, особенно если они вообще впервые видят процентную систему с броском ниже целевого значения:
Мастер: Сделай проверку Навигации (Navigation).
Игрок: У меня 47.
Мастер: А чему равен навык?
Игрок: 50.
Мастер: Отлично. Это успех. Более того, отличный успех, потому что выпало больше 30. Происходит следующее…
Игроки не знают, какие числа мне сообщать, поэтому приходится вытягивать эти числа из них, чтобы выполнить необходимую операцию: определить успех или провал и степень успеха. По мере освоения системы разговор меняется:
Мастер: Сделай проверку Навигации.
Игрок: У меня отличный успех.
Мастер: Отлично. Происходит следующее…
Игроки способны ответить так, потому что изучили механику и теперь знают: результат 47 при навыке 50 означает отличный успех. (Разговор напоминает атаку игрока по орку в D&D, когда КЗ 17 уже известен, верно? Игроку не нужно передавать мне сведения для выполнения механической операции, потому что он способен выполнить её сам. Более того, многие любят процентные системы с броском ниже целевого значения именно потому, что они делают подобную эффективность интуитивной и почти автоматической.)
Но тут возникает проблема: как вы помните, в Eclipse Phase есть уровни сложности, изменяющие целевое число. Простая эффективность нарушается, и мы часто приходим к такому разговору:
Мастер: Сделай проверку Навигации.
Игрок: У меня отличный успех.
Мастер: Вообще-то здесь есть модификатор сложности. Что выпало?
Игрок: 47.
Мастер: А чему равен навык?
Игрок: 50.
Мастер: Тогда на самом деле ты провалился. Происходит следующее…
Это создаёт за столом всевозможное трение: процедура неэффективна и часто сбивает с толку. При этом либо исход вообще не меняется — и тогда мы без всякой причины сбили драматическое напряжение проверки, — либо игрок расстроен тем, что событие, которое, как он думал, шло одним путём, внезапно пошло другим.
Так происходит потому, что мне как Мастеру нужно выполнить операцию — применить скрытую сложность, — но я не получаю необходимого числа. Игрок научился бросать мяч в определённое место — «у меня отличный успех», — но меня часто там нет, и мяч с болезненным стуком падает на пол.
В конце концов я понял, что на самом деле мне нужна от игрока формула «XX из YY», где XX — результат броска, а YY — значение навыка. Такой мяч я мог поймать и без труда доставить куда потребуется.
Мастер: Сделай проверку Навигации.
Игрок: У меня 47 из 55.
Мастер: Отличный успех! Происходит следующее…
И я осознал, что могу просто прямо попросить игроков отвечать именно так. Не нужно ждать, пока они сами догадаются. Даже совершенно новые игроки почти мгновенно попадали в ритм системы.
Продвинутый уровень D&D
Проводя больше времени с системой, вы часто будете находить необычные углы, требующие иного потока информации. Иногда правила поведения за вашим столом можно слегка подправить с учётом особых случаев. Но обычно важнее научиться вовремя показывать игрокам, что сейчас всем нужно работать с информацией иначе, а игрокам — освоить систему настолько, чтобы быстро понимать новые, порой пересекающиеся обстоятельства.
Вернёмся, например, к D&D.
Если я как Мастер обрушиваю орду орков на одного персонажа, то нередко бросаю все их атаки разом, затем весь урон от успешных атак, складываю его и сообщаю игроку одно итоговое число. Логично вести сумму лежащих передо мной чисел по мере их появления, а не диктовать игроку длинную последовательность и заставлять одновременно воспринимать её на слух и самостоятельно всё складывать.
И, конечно, это прекрасно работает… пока у персонажа не появляется снижение урона (damage reduction). Теперь уже игрок должен выполнить механическую операцию — вычесть снижение урона из каждого попадания, — но не располагает необходимыми сведениями.
Даже персонажи с несколькими атаками по разным причинам обычно разрешают их по одной, поэтому обратная ситуация — игрок объединяет урон, а Мастеру нужно применить снижение — возникает редко. Но у двух персонажей в моей кампании третьей редакции есть оружие, наносящее дополнительный стихийный урон. Они усвоили, что иногда мне нужно знать этот урон отдельно, поскольку существа часто обладают сопротивлением или иммунитетом к урону огнём либо электричеством.
Впервые столкнувшись с трудностью, игроки начали всегда сообщать стихийный урон отдельно. Но это была ненужная неэффективность, и мы быстро поняли, что проще мне самому предупреждать, когда стихийный урон следует выделить.
Примеры простые, но, надеюсь, показывают, что такое мастерство не работает по принципу «всё или ничего». Почти всегда можно научиться новым приёмам.
Feng Shui
Рассмотрим ещё одну систему. Её механические операции довольно просты, но могут оказаться дьявольски трудными, если не передавать информацию туда и обратно достаточно чётко.
В Feng Shui 2 механика костей даёт «отклонение» (swerve): вы вычитаете результат на отрицательной кости d6 из результата на положительной кости d6 и получаете значение на колоколообразной кривой от −5 до +5. (На самом деле шестёрки «взрываются» и перебрасываются, поэтому края кривой размазываются, но в основном всё работает именно так.)
Для атаки нужно сделать две вещи. Сначала проверить попадание:
Отклонение + Навык атаки − Защита цели
При попадании рассчитывается урон:
Величина успеха + Урон оружия − Стойкость цели
На странице эти два уравнения не выглядят чем-то особенно экзотическим. Но на практике я видел, как отдельные игроки и целые группы безнадёжно в них запутывались. Обычно возникают две главные проблемы:
-
Нападающий чувствует, что должен полностью завершить один этап процесса, а потом сообщить результат… но не может, потому что ни один этап не завершить без сведений, которыми располагает защищающийся.
-
Завершив первый этап, игрок хочет сообщить простой итог — успех или провал, «я попал». Но если не перенести величину успеха в уравнение урона, рассчитать урон невозможно.
Во втором случае часто происходит следующее:
Мастер: Защита цели — 17.
Игрок: (считает) Так, я попал!
Мастер: Значит, урон равен величине успеха плюс урон оружия. Какой была величина успеха?
Игрок: Э-э… чёрт. Я забыл. Три? Может быть, четыре? Подожди… (снова считает)
В подобных ситуациях происходит ещё одна интересная вещь: игроки не любят путаться и раздражаться, поэтому пытаются найти ситуативный обход проблемы. Например, в Feng Shui 2 я часто слышу примерно такое: «Ну… я знаю Защиту этого парня, потому что атаковал его в прошлом раунде. Поэтому просто снова атакую его — так проще».
Важно понять: игроки хотят решить проблему не меньше вашего. Но подобное ситуативное псевдорешение часто лишь переносит раздражение в другое место. Игроки научились делать механическое разрешение более гладким, но теперь чувствуют, что система вынуждает их выбирать действия, которых они вовсе не хотели. Безумный, гипертрофированный гонконгский боевик Feng Shui 2 оказывается подорван тем, что герои снова и снова атакуют одного и того же парня.
Предположим, вы оказались в такой ситуации. Как её исправить?
- Определите последовательность выполнения механических операций.
- Определите, кто располагает сведениями, необходимыми для каждой операции.
- Решите, как на каждом этапе передавать сведения нужному человеку.
Например, у кого находится каждая часть информации, используемой для разрешения атаки в Feng Shui 2?
- Результат броска отклонения. (Нападающий.)
- Навык атаки. (Нападающий.)
- Защита цели. (Защищающийся.)
- Величина успеха. (Тот, кто рассчитал результат броска атаки.)
- Урон оружия. (Нападающий.)
- Стойкость цели. (Защищающийся.)
- Полученные пункты ран. (Защищающийся.)
Если снова посмотреть на уравнения выше, последовательность разрешения и числа, которые нужно произносить, определить довольно легко:
-
Нападающий бросает отклонение и прибавляет Навык атаки. В игре это называется Результатом действия (Action Result). Нападающий сообщает число защищающемуся.
-
Защищающийся вычитает свою Защиту из Результата действия. Получается величина успеха, которую игра называет Исходом (Outcome). Защищающийся сообщает Исход нападающему.
-
Нападающий прибавляет Исход к Урону оружия. Игра называет результат Разгромом (Smackdown). Нападающий сообщает Разгром защищающемуся.
-
Защищающийся вычитает свою Стойкость из Разгрома. Получается количество полученных им пунктов ран (Wound Points).
Как видите, Робин Д. Лоуз — умный парень: он выделил значимые порции информации в системе и дал им отдельные названия — Результат действия, Исход, Разгром. Другие игры не обязательно сделают это за вас. К сожалению, даже книга правил Feng Shui 2 не объясняет отдельно, как следует передавать сведения туда и обратно. Но вы сможете сходным образом разложить механические процессы любой системы.
Групповая поддержка в GUMSHOE и не только
В завершение поговорим о механическом взаимодействии, в котором одновременно участвуют несколько игроков. Разумеется, из-за этого согласовать «танец» информации ещё сложнее.
В системе GUMSHOE, которую используют такие игры, как Ashen Stars и Trail of Cthulhu, некоторые групповые проверки разрешаются механикой поддержки (piggybacking):
- Один персонаж назначается ведущим (Lead).
- Сложность проверки равна базовой сложности +2 за каждого дополнительного персонажа, который присоединяется к проверке ведущего.
- Каждый присоединившийся может потратить 1 пункт навыка, чтобы отменить добавленные им +2 к сложности.
Механика очень полезна, например, когда Арагорн ведёт хоббитов по дикой местности, стараясь не попасться назгулам. Чем больше неопытных хоббитов, тем труднее Арагорну, но успех по-прежнему должен определяться его умением вести группу.
Много лет назад я адаптировал эту структуру поддержки к системам d20 следующим образом:
- Один персонаж становится ведущим.
- Остальные могут присоединиться к проверке навыка ведущего, выполнив собственную проверку с Классом Сложности (Difficulty Class, DC), равным половине КС проверки ведущего. Если ведущий проходит проверку КС 30, присоединившиеся должны пройти проверку КС 15.
- Ведущий может снизить КС поддержки на 1 за каждый штраф −2, который принимает к собственной проверке.
- Решение присоединиться нужно принять до проверки ведущего.
На бумаге система выглядела разумно. Но за столом она не работала: казалась сложной и привередливой, и игрокам не нравилось ею пользоваться.
Я отказался от неё на пару лет, затем вернулся и понял, что неправильно выстроил последовательность механики. Один из элементов действительно содержал небольшую ошибку игрового дизайна, но в конечном счёте даже она сводилась к порядку разрешения.
Изначально механика разрешалась так:
- Мастер объявляет, что, например, требуется проверка Скрытности (Stealth).
- Игроки решают, хотят ли использовать механику поддержки.
- Мастер одобряет её.
- Игроки выбирают ведущего.
- Остальные решают, хотят ли присоединиться.
- Ведущий решает, хочет ли снизить КС поддержки.
- Ведущий выполняет проверку.
- Если ведущий преуспел, остальные выполняют проверки поддержки. Логика состояла в том, что при провале ведущего проверки поддержки не нужны. Но на практике игроки видели результат ведущего и пытались отказаться от участия, если он оказывался плохим.
На самом деле последовательность разрешения должна была выглядеть так:
- Мастер объявляет, что требуется групповая проверка с поддержкой.
- Игроки выбирают ведущего.
- Остальные выполняют проверки поддержки. Если кто-то провалился, наибольшая величина провала среди всех поддерживающих повышает КС проверки ведущего на +1 за каждые два пункта величины провала.
- Ведущий выполняет проверку.
Уже по числу этапов видно, насколько проще и эффективнее стал процесс разрешения. Единственное настоящее изменение механики, однако, состоит в том, что корректировка КС поддержки превратилась из решения до проверок поддержки в следствие этих проверок.
Главный вывод: хотя передаваемая за столом механическая информация часто выражается числами, она может включать и другие элементы — например, кто становится ведущим при групповой проверке. Их тоже можно сделать более эффективными, упорядочив и формализовав.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.