Случайный совет Мастеру: проверки всем скопом
Томас: Ладно, я обыскиваю комнату.
Мастер: Выполни проверку Поиска (Search check).
Томас: (Бросает кости.) Вот чёрт. На кубике 4, так что результат проверки всего 8.
Мастер: Ты пару минут переворачиваешь комнату вверх дном, но ничего не находишь.
Мария: О! Я тоже хочу проверить!
Стив: И я!
Саманта: У меня 17!
Это проверка всем скопом (dogpiling the check). Такой подход не всегда плох, но, когда он возникает во время игры, зачастую просто кажется каким-то… неправильным. Игроки пытаются схитрить? В смысле, вполне логично, что Мария, Стив и Саманта могут помочь обыскать комнату. Почему же это настолько раздражает?
В действительности здесь три разные проблемы, и полезно разделить их и рассмотреть по отдельности.
Первая — проблема метаигры. Если Томас получил 30 на проверке Поиска, а Мастер сказал: «Ты ничего не нашёл», Мария, Стив и Саманта не встрепенутся со словами: «Я тоже попробую!» Лишь когда плут проваливает бросок и ничего не находит, остальной отряд использует эти метаигровые сведения, чтобы проверку выполнил кто-то другой.
Если вас беспокоит именно это, можно просто выполнять такие проверки тайно. Игроки не знают результата и поэтому не могут использовать его в метаигре.
Однако это не обязательно остановит проверки всем скопом. Неуверенность в том, насколько хорошо справился Томас, может, наоборот, побудить игроков всегда наваливаться на проверку. Результат других проверок действий бывает очевиден сразу: например, Томас либо вскрыл замок и может открыть дверь, либо нет. Тогда остальные персонажи выстраиваются в очередь пробовать следом — это не метаигра, но всё ещё проверка всем скопом.
Так мы переходим ко второй проблеме — проблеме темпа. Действительно ли интересно сидеть и по очереди смотреть, как каждый выполняет одну и ту же проверку? Какая тягомотина! Давайте уже покончим с этим и двинемся дальше! (Особенно если в комнате на самом деле нечего находить и результат проверки Томаса ни на что не влияет.)
Часто эту проблему можно обойти, попросив всех персонажей выполнить проверку одновременно.
Мастер: Вас проводят в величественный бальный зал. На стене висит огромное геральдическое знамя: красный олень встаёт на дыбы на сине-белом клетчатом поле.
Саманта: Я узнаю этот герб?
Мастер: Все выполните проверку Интеллекта (История) (Intelligence (History) check).
Более того, зачастую такую проверку следует предвидеть. Все персонажи видят геральдическое знамя и либо узнают его, либо нет. Активно изучать его не требуется, поэтому нужно сразу попросить всех выполнить проверку. Мы называем их реактивными проверками (reactive checks).
Даже если проверка не реактивная — например, речь идёт об обыске комнаты — и действие предлагает игрок, можно опередить навал: «Кто-нибудь помогает Томасу обыскивать комнату?»
Но третья проблема — проблема баланса.
Допустим, шанс успеха конкретной проверки составляет 70% для первого персонажа и 50% для каждого из четырёх остальных. Вероятно, такая проверка попадает в диапазон интересных и уместных. Но если выполнить её всем скопом — каждый бросает, а успех нужен лишь один, — вероятность в 70% внезапно превращается в 96%. И тогда приходится спросить себя, зачем вообще бросать кости.
Составная вероятность накапливается быстро. Это особенно заметно в системах, где диапазон результатов кости шире диапазона бонусов навыка: с каждым новым броском средний результат быстро меняется так, что навык становится почти совершенно неважен. Например, возьмём проверку с КС (DC) 15, где большинство бонусов навыка находится в пределах от +1 до +5, а бросается d20. Успешная проверка с большей вероятностью достанется игроку, который выбросил на d20 наибольшее число, чем персонажу с наивысшим значением навыка.
ПРОВЕРКИ ВСЕМ СКОПОМ И ГРУППОВЫЕ ДЕЙСТВИЯ
Повторение проваленной проверки всем скопом — не то же самое, что групповое действие (group action), когда несколько персонажей работают вместе. Во многих играх уже есть эффективные механики разрешения групповых действий. Например, в D&D 5-й редакции существуют групповые проверки (group checks), где бросают все, а группа добивается успеха, если успешна хотя бы половина проверок, и действие Помощь (Help action), при котором персонаж с лучшим модификатором выполняет проверку с преимуществом (advantage), если ему помогают остальные. Подробнее о разрешении групповых действий в любой системе читайте в части 14 «Искусства решений».
Неудача должна иметь значение
По иронии, решение проблемы во многом возвращает нас к базовым принципам построения проверки: если вы бросаете кости, неудача должна быть интересной, значимой или и той и другой одновременно.
Поэтому всякий раз, когда персонаж выполняет проверку, провал должен влечь цену или последствие.
И всё же проверки всем скопом раздражают ещё и потому, что позволяют без труда обойти последствие, которое поначалу казалось значимым. Например, провал попытки вскрыть дверной замок важен, потому что теперь персонажам придётся искать другой способ пройти через дверь.
Разумеется, это также показывает, что во многих отношениях проверка всем скопом неотличима от многократного повторения одной и той же проверки одним персонажем.
Начнём с обзора трёх приёмов из статьи «Неудача для начинающего Мастера»:
Без повторных попыток (No Retries). По определению полностью решает проблему. Тот, кто выполнил первую проверку, представлял лучшие усилия группы, и последующие проверки не изменят исход. Например, мы установили, что этот замок вскрыть нельзя и придётся искать другой путь внутрь.
Если группа привыкла использовать нарративное разрешение (narrative resolution), этого может оказаться достаточно. Но нередко люди лишь недоумённо почешут затылки: «Почему Саманта не может обыскать комнату после Томаса или одновременно с ним?»
Чтобы «смягчить» идею запрета повторных попыток, я экспериментирую в D&D со ступенчатой групповой проверкой (gradated group check). По сути, она трактует проверки всем скопом как групповую проверку задним числом. Для успеха групповой проверки должна преуспеть половина участников, поэтому второй персонаж получает шанс вырвать победу из пасти поражения. Но если и он провалит проверку, группа зароет себя глубже и для возвращения к успеху ей понадобятся уже две дополнительные успешные проверки.
Эффективное применение приёма несколько ограничено, но я считаю его отличной мысленной моделью для социальных сцен. Томас явно испортил переговоры с визирем. Сможет ли Саманта вмешаться и всё уладить? Если нет, спасти ситуацию будет очень трудно.
Движение вперёд через неудачу (failing forward). Заранее устраняет проблему, потому что первый персонаж, выполняющий проверку, не может потерпеть неудачу — он может лишь столкнуться с последствием. Томас находит спрятанную драгоценность, но приводит в действие ловушку; вскрывает замок, но ломает отмычки; и так далее. Поскольку первая попытка не провалилась, остальным персонажам незачем наваливаться на проверку.
Часы прогресса (progress clock). Когда ничего другого не помогает, заведите часы неудачи или продвиньте их. Гибкость этого варианта огромна, поэтому к нему легко обращаться всякий раз, когда всё остальное не сработало.
Подведём итог: как только начинается навал, нужно искать дополнительные последствия. Не в качестве наказания, а с мыслью: «Хорошо, вы тратите много времени на этот замок… Что это означает в контексте окружающего мира?»
Осмелитесь ли вы навалиться?
При этом не стоит отбивать у персонажа со вторым по величине значением навыка желание иногда блеснуть. Поэтому можно подумать, какую выгоду даст каждый дополнительный успех проверки:
- при проверке сбора информации каждый успех даёт новый фрагмент сведений, но провал сообщает злодеям, что персонажи задают вопросы;
- при проверке создания магического предмета каждый успех добавляет предмету уникальную особенность, но каждый провал накладывает проклятие.
Такое построение проверки может оказаться сложнее, зато теперь дополнительным успехам противостоит возросший риск провала с каждым новым участником, и группе приходится принимать стратегическое решение.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.