Искусство рулингов. Часть XIV: Групповые действия
Перевод: Станислав Иванов
Текст Justin Alexander от 25 января 2018 года
На удивление просто напортачить с разрешением групповых действий (И немалую роль в этом здесь играет то, что многие игры используют для этого неполноценные механики. Или же вообще не предлагают механики для разрешения групповой заявки).
Основная проблема лежит в искажении вероятных исходов. Классический пример – когда пять персонажей игроков пытаются прокрасться мимо стражника. ДМ смотрит на стандартную механику для подобных заявок, а затем просит каждого сделать проверку Скрытности – и вроде логика на его стороне.
Пускай каждый из этих персонажей вполне неплох в деле скрытности, так что у каждого из них есть 70% шанс преуспеть. «Раз все они вполне неплохи», - думает Мастер, - «То у них есть вполне реальный шанс прокрасться мимо этого парня». Но в действительности это не так. Так как провал любого из персонажей де факто означает провал для всей партии, и поэтому у них есть 17% шанс успешно прокрасться мимо стражника.
Эта ошибка случается по той причине, что наши мозги не могут интуитивно охватить весь спектр вероятностей. Так что мы объединяем «весьма неплохие шансы», но не можем осознать, что, в общем и целом, ряд последовательных успехов все еще крайне маловероятен.
И все становится только хуже, когда пять персонажей игроков пытаются прокрасться мимо пяти персонажей Мастера. В третьей редакции D&D, например, это становилось проверкой, при которой каждый игрок должен был бросить 5d20 и выбрать наименьший результат, тогда как Мастер бросал 5d20 и брал наибольший. В среднем бросок 5d20-бери-наименьшее давал результат в размере 3. А 5d20-бери-наибольшее – 17. Эта разница в 14 очков означало, что для партии персонажей было практически невозможным прокрасться мимо партии равных им оппонентов.
(Но на самом деле шанс в третьей редакции были еще хуже, так как практически все попытки скрыться требовали проверок Тихого Передвижения и еще проверок Скрытности).
Можно поспорить, что в некотором роде это реалистично: большой группе должно быть сложнее пробраться мимо стражи, нежели отдельному парню, а больше глаз – больше людей, что могут вас заметить. Однако на это я отвечу, что искажение вероятностей достаточно высоко, чтобы создать результат, что был бы одновременно нереалистичным и нежелательным.
В случае со скрытностью эффект искажения достаточно очевиден: раз успех практически невозможен, то любые попытки групповой скрытности быстро покидают вашу игру. И проверка скрытности принимает форму одиночного разведчика, идущего впереди остальной группы. И когда разведчик становится слишком уязвимым для неизбежного провала проверки скрытности, то она вообще исчезает из игры.
Четыре разновидности групповых действий
Когда Мастер имеет дело с групповым действием, то первое, что он должен определить – с каким видом действия он столкнулся. В целом я разделяю из на четыре категории:
(a) Все совершают попытки в индивидуальном порядке, и успехи или провалы считаются индивидуально.
(b) Все стараются преуспеть в одном деле, но пока хотя бы кто-то успешен, все хорошо.
(c) Все работают сообща, чтобы выполнить одно действие.
(d) Все работают сообща/помогают друг другу, но всем все еще нужно преуспеть в этом действии.
Рассмотрим пример с проверкой Лазания:
· Все начинают лезть на стену независимо друг от друга.
· Боб пытается залезть и схватить идол. Затем это делает Нэнси (или же они оба пытаются сделать это одновременно, но пока хотя бы одному из них удается схватить идола, идол считается полученным).
· Кто-то спускает веревку, чтобы помочь залезть остальным (Помощь ограничена количеством людей, что действительно могут помочь кому-либо залезть)
· Все обвязаны одной веревкой, помогая друг другу забраться на гору.
А вот и пример со Скрытностью:
· Каждый пытается пробраться мимо стражника по отдельности.
· Все одновременно пытаются пробраться в комнату с Кнопкой с разных сторон, так что если кто-то будет обнаружен (то есть провалит бросок), то на других это не повлияет (Это звучит надумано, но я не могу придумать ненадуманный пример проверки Скрытности, где один член группы может провалить его, тогда как другие преуспеть).
· Стив отвлекает стражу, демонстрируя им эротический журнал, тогда как Гвен прокрадывается мимо них.
· Арагорн ведет хоббитов через темный лес, стараясь поддерживать всю группу скрытой от бродящих вокруг назгулов.
Тип 1: Одновременно происходящие индивидуальные действия
Все совершают попытки в индивидуальном порядке, и успехи или провалы считаются индивидуально.
На самом деле это не вид группового действия. Это множество отдельных действий, происходящих одновременно, хоть они и идентичны друг с другом. Но, по существу, они ведут к выполнению различных целей.
Определяя результат «групповых» действий этого вида, используйте обычный для подобных заявок процесс.
И вот достаточно простой пример: группе нужно сделать шесть фарфоровых тарелок. Есть шесть персонажей, каждый из которых делает проверку Ремесла, чтобы сделать одну фарфоровую тарелку. Если все они преуспевают, то каждый из них отдельно от остальных сделал тарелку и, в результате, они произвели шесть фарфоровых тарелок.
И хоть подобные действия совсем не являются групповыми, это все еще тип разрешения групповых действий, к которому склоняется большинство Мастеров. Я думаю, что по сути это комбинация множества систем (особенно тех, с которых начинали ДМы), что не включали в себя отдельных механик для других видов групповых действий, и факт в том, что зачастую это простейший способ определения результата (Весьма просто сказать «Все сделайте проверку Атлетики». И достаточно просто использовать механику разрешения отдельных действия, так как, в общем, это простейшая из механик, являющаяся базовой для любой ролевой игры).
Моя идея здесь в том, что вместо того, чтобы по умолчанию использовать эту механику, большей части Мастеров пошло бы на пользу воспринимать ее как крайнее средство, когда дело доходит до разрешения групповых действий. Другими словами, убедитесь, что перед вами не групповое действие, прежде чем перейти к одновременным, но индивидуальным проверкам.
Однако если вам нужно некое стандартное правило по тому, когда «нормально» использовать первый тип механик, то ищите те ситуации, где провал одного персонажа вызовет провала у ДРУГИХ персонажей. Так что это нормально, если все лезут на стену отдельно друг от друга, так как один персонаж, отставший от других, не означает, что остальные тоже задержались (Хотя последствия все еще могут быть роковыми).
Тип 2: Независимое групповое усилие
Все занимаются одним делом, но лишь один из них должен преуспеть
Используйте эту форму группового действия, когда персонажи нацелены на выполнение одной-единственной цели, но каждый из них действует отдельно от других.
Разрешая независимое групповое усилие, вы на самом деле все еще используете обычный процесс разрешения индивидуальных действий. Но пока хотя бы один из персонажей преуспевает, попытка в целом успешна.
Вы также можете воспринимать этот подход как «считается лишь наилучший результат».
Вернемся к нашему предыдущему примеру: группе нужно сделать одну фарфоровую тарелку. Каждый из шести персонажей делает проверку Ремесла, чтобы произвести одну тарелку. И пока хотя бы один из них успешен в проверке (то есть делает тарелку), то группа как целое имеет ту самую вещь, что им нужна. Если важно качество тарелки, то используемая ими тарелка будет наилучшей из тех, что им удалось создать (то есть от наивысшего значения проверки).
Недостаток этого метода в том, что он приводит к искажениям другого вида. Это ситуация, в которой все в группе будут говорить вам: «Я ищу ловушки в коридоре» (либо последовательно, либо одновременно), что чрезвычайно повысит их шансы на успех.
И опять же можно поспорить, что это искажение звучит реалистично (больше глаз – выше шанс, что кто-то найдет решение для проблемы). Да и лично я реже сталкиваюсь с проблемами от такого вида искажений, так как (а) успех реже приводит к более «плоскому» игровому опыту (из-за отброшенных за ненадобностью стратегий) и (б) я думаю, что ДМу на самом деле очень сложно ошибиться в деле успешности персонажей игроков.
Однако, если это необходимо или желаемо, данному искажению можно противостоять через последствия или же риск последствий за участие в проверке. Зачастую это принимают форму чего-то плохого, случающегося при проваленной проверке; ну или проверке с весьма большой степенью провала (А вы уверены, что хотите обыскивать коридор, если плохой бросок может привести к срабатыванию ловушки? Материалы для изготовления фарфоровой тарелки дороги, так что имеет ли смысл для Сэлли – что плоха в Ремесле – принимать в групповой занятии гончарным делом?).
Можно также рассмотреть возможность варианта, при котором достаточно высокая степень успеха одного персонажа нивелирует (или же снижает эффект) последствий провала другого члена группы (Например, Элисса провалила свою проверку Поиска на 5, но Раасти преуспел на 10, так что он отталкивает ее в сторону за мгновение до того, как она рвет растяжку).
Тип 3: Совместное действие
Все работают сообща, чтобы выполнить одно действие.
Это, например, когда несколько персонажей работают сообща, чтобы починить машину. Или же создать гравитационную пушку. Или же изучают тайну в Мискатоникском Университете.
Отличие этого подхода в том, что есть лишь одна задача, в которой группа старается преуспеть и все они работают на одну-единственную попытку это сделать. Говоря о механике, у нас есть ряд весьма распространенных подходов.
Помощь. Один персонаж «берет на себя ответственность» в этой попытке (Обычно это наиболее умелый в требуемом деле персонаж, однако это необязательно и зависит от обстоятельств). Другие персонажи, что помогают ему, дают ему бонус на проверку. Эта помощь может потребовать успешной проверки навыка у каждого конкретного персонажа, и это необязательно тот же самый навык, что у «ответственного» персонажа (и далеко необязательно тот же уровень сложности).
Тип бонуса может быть различным. Например, в третьей редакции D&D, это жестко задано в виде действия «Помочь Другому» и предоставляет +2 бонус. В системе с пулом дайсов вы можете дать ответственному дополнительный дайс. Cypher System имеет ряд различных бонусов, зависящих от соотношения навыков и вида предоставленной помощи.
Общая степень успеха. Альтернативный подход состоит в том, чтобы использовать общую степень успеха, созданную на основе действий всей группы, и сравнивать ее с уровнем сложности (Это наиболее распространенный подход в системах в пулами дайсов, где вы считаете успехи, так как посчитать успехи из различных источников и сравнить их с заданным числом достаточно просто). Этот подход может быть быстрее (так как все проверки навыка совершаются одновременно) и более подходящим в случаях, когда нет ярко выраженного «ответственного лица». Недостаток подхода состоит в том, что значения сложности для совместных действий не синхронизируются со значениями сложности у индивидуальных действий, что лишает систему простоты и иногда может вызвать проблемы с согласованностью.
Но у каждого из этих подходов могут быть ограничения на то, сколько именно персонажей может единовременно помогать в конкретном деле (вы можете запихнуть лишь некоторое количество людей под капот гоночного автомобиля).
Тип 4: «Выезжать на чужих плечах»
Все работают сообща/помогают друг другу, но всем все еще нужно преуспеть в этом действии.
Отличие типа 4 от типа 1 может быть достаточно неясным: все лезут на стену отдельно и это явно тип 1. Но, если вся команда работает сообщая, используя страховку и все такое прочее, в какой момент это становится проверкой типа 4?
Мне кажется, что, если вы сомневаетесь, берите по умолчанию как раз тип 4. Я сам не всегда хорош в этом, но по всем уже перечисленным ранее причинам, я думаю, что это лучший способ.
Базовый вариант: один персонаж берет ответственность за проверку, а остальные «выезжают» на его успехе или провале (Если он успешен, то и все успешны. Если же нет, то и все нет).
В GUMSHOE ответственный персонаж получает штраф, зависящий от числа персонажей, которых он «подвозит». Однако эти персонажи могут потратить одно очко из своего пула навыка (обычно, однако далеко не всегда, это тот же навык, что и у ответственного персонажа), чтобы избавиться от этого штрафа.
Когда я подстраивал эту систему под D20, то «подвозимые» персонажи должны были преуспеть в проверке с половинной от заданной для ответственного персонажа сложностью. Последний мог снизить уровень сложности для своих союзников, повысив его для себя.
Простой вариант: пусть каждый персонаж сделает проверку навыка. Если хотя бы половина преуспеет, то и вся группа успешна.
Сложный вариант: все, кто преуспел в проверке, предоставляет бонус тем, кто иначе бы провалился. Если коллективный бонус преуспевших достаточен, чтобы преодолеть провалы, то попытка в целом успешна.
Финальные размышления
Я описал несколько различных вариантов для определения результатов различных же групповых действий. Однако для любой вашей системы вам нужна лишь одна из них для каждого вида групповой активности. Конечно, в некоторых случаях, система изначально имеет механики для этого. Но если вам нужно добавить механическую структуру для чего-либо группового, вам, как я надеюсь, будет весьма просто взять один из описанных мною вариантов и подстроить его под используемую вами систему.
Практика показал мне, что, вообще говоря, ДМ должен определить, может ли групповая проверка вообще состоятся и какая из механик должна быть использована для определения ее результатов. Например, когда я впервые ввел «подвозящую» механику в свои D&D игры, я позволил игрокам решать, должна ли их попытка Скрытности быть «нормальной проверкой» или же «подвозящей проверкой». И я столкнулся с тем, что игроки весьма регулярно использовали лишь базовый вариант разрешения проверки, а еще они постоянно возмущались, когда ответственный персонаж проваливал свою попытку, и хотели вернуться к отдельным проверкам.
Основываясь на этом, я рекомендую вам относиться к групповым проверкам также как и любым другим: определяйте то, как это действие должно быть разрешено, и объявите об этом своим игрокам.
«Ну ладно, это будет «подвозящая проверка». Кто будет ответственным?»
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.