Искусство рулингов. Часть XII: Скрытые или открытые значения сложности
Текст Justin Alexander от 24 июля 2017 года
Настало время обсудить одну весьма спорную тему: Должен ли ДМ говорить игрокам заданную сложность проверки навыка?
(Я серьезно. Сходите на любой НРИ-форум, задайте этот вопрос и наблюдайте за тем, как длинные ножи приходят в действие в девяти случаях из десяти)
Мой личный подход к открытым и сокрытым значениям сложности состоит в том, что я отношусь к ним скорее как к инструменту, а не идеологии, а их использование для меня – смесь удобства и практичности. Какую информацию внутри игрового мира несет значение сложности и имеют ли персонажи к ней доступ?
- Если уровень сложности отражает нечто, что персонажи игроков могут наблюдать непосредственно, то скажите игрокам значение (Простым примером будет сложность прыжка через расщелину: Персонаж может непосредственно видеть расщелину и примерно представить, насколько это будет для него сложно. Сказав об этом же игроку, вы сделаете это для него настолько же ясным, как и для его персонажа).
2. Если уровень сложности отражает что-то, что персонажи не могут наблюдать, то скройте его от них (Например, они идут через джунгли и хотят узнать, заметили ли они дикарей, прячущихся в листве у них над головами. Знают ли персонажи игроков, насколько те хороши в искусстве скрытности? Нет. Они даже не знают, что они пытаются заметить дикарей. Таким образом они не узнают сложность проверки).
- Если вы хотите слукавить, вы можете предоставить игрокам примерное значение сложности, основанное на том, что именно знают их персонажи, а реальный уровень сложности раскрыть лишь когда они совершат ошибку («Парень стоит голышом посреди поля. Попасть по нему будет очень и очень просто…» «Твой выстрел отразился от силового поля, окружающего его. Все оказалось хитрее, чем ты думал»).
Когда я сомневаюсь, то обычно я склоняюсь к тому, чтобы не говорить игрокам заданную сложность. Однако в некоторых системах я отказываюсь от это позиции в силу практичности. Например, в Call of Cthulhu вы добавляете сложность к рейтингу навыка персонажа и затем пытаетесь бросить число ниже итогового значения. И для меня гораздо проще назвать игрокам модификатор сложности, чтобы они смогли просто сообщить об успехе или провале проверки, чем заставлять их говорить мне о степени их успеха, чтобы я смог сравнить его с уровнем сложности (Хотя ваш подход, естественно, может отличаться).
Вдобавок к явной практичности и простоте игрового процесса, на мой метод влияет еще ряд факторов. Во-первых, игрок воспринимает игровой мир в гораздо меньшей степени, нежели его персонаж: Они практически полностью полагаются на неточные словесные описания, тогда как их персонажи имеют доступ ко всей полноте палитры чувств. И хотя совершенно ясно, что персонаж необязательно могут вычислить шанс своего успеха с математической точностью, но мне кажется, что это все равно приводит к большему количеству логичных результатов, чем ситуация, когда персонажи, например, пытаются перепрыгнуть расщелину, через которую любой разумный человек не стал бы прыгать, стоило бы ему ее увидеть. Открытые значения сложности снижают количество непонимания между Мастером и игрокам, что, в свою очередь, снижает старую проблему «А ты уверен, что хочешь это предпринять?»
Во-вторых, существует немало обстоятельств, при которых игроки могут выяснить уровень сложности (Например, несколько персонажей совершают атаки против фиксированного значения защиты цели). В некоторых случаях подобный опыт может быть наполнен погружением в игровой мир (персонажи постепенно понимают, насколько опытен их противник, прежде чем можно объявить, что он левша). Это также неплохой пример того, что знание уровня сложности далеко не всегда нарушает погружение в игровой мир, и даже поначалу скрытые значения могут быть избавлены от вуали механики спустя некоторое время, просто чтобы ускорить игру. Практично.
Игры с тратой ресурсов
На протяжении последнего десятилетия или около того мы наблюдаем за распространением НРИ, включающих в себя механики, по которым игроки могут тратить очки из ограниченного пула на проверку навыка. GUMSHOE и Cypher System предлагают нам наиболее распространенную форму этой механики, где очки тратятся из пула навыка или характеристики для получения бонуса на проверку. Tales from the Loop отражает иной подход, где существует ряд различных ресурсов, которые могут быть потрачены на переброс проваленных проверок.
И мне кажется, что подобные системы, особенно склоняющиеся к подходу GUMSHOE или Cypher System, требуют особого подхода, когда дело доходит до открытых или закрытых уровней сложности. Слепая трата ограниченных ресурсов на задачи с неясной сложностью не слишком хорошо работает в подобных играх: Игроки зачастую раздражаются, а ресурсы тратятся сверх нужного, что вскоре приводит игровую сессию к границам возможного системы и вообще ограничивает эффективное построение сценария.
Однако это, конечно же, не значит, что уровень сложности должен быть абсолютно ВСЕГДА известен на подобных играх. Редкая перчинка в виде неизвестного значения сложности на проверку поиска, например, может быть очень вдохновляющей: Игрок не знает, спрятано ли что-нибудь в комнате или насколько оно может быть ценным, так что он должен сделать сложный выбор того, насколько много усилий он хочет вложить в поиски. Встречаясь с ранее неизвестным существом, игроки должны сделать выбор, сразу ли выстрелить в него или же потрудиться и прицелиться. Это способствует погружению и весьма эффективно.
Но если вся игра покрыта вуалью тайны, то на практике это далеко от эффективности. И затрудняет принятие решений (особенно в играх с тратой ресурсов) и вредит погружению.
Еще один способ взглянуть на это – «порог знания», после преодоления которого ДМ называет уровень сложности. Однако по сути своей этот порог – просто ползунок. И я предлагаю радикально понизить его для игр с тратой ресурсов (особенно если обычно вы держите его достаточно высоким).
Для таких игр я также придумал термин «рутинная проверка», чтобы я все равно мог просить сделать вещи вроде рутинной проверки Внимательности, дабы определить, заметил ли персонаж что-либо до того, как все начнут тратить очки своих ресурсов, гм…безо всякого смысла.
Задачи с неопределенностью
Traveller 2300 включает в себя интересный метод определения результата действия, который я больше нигде не видел. Но его можно с легкостью воспроизвести практически в любой ролевой системе. Для любой задачи с неопределенным исходом, где непосредственный успех или провал может быть не сразу очевиден для персонажа (вроде сбора информации, убеждение кого-либо на нарушение закона или же починка дефектного оборудования):
…как игрок, так и судья делают бросок на успех (судья втайне). Если оба не достигли успеха, то судья рассказывает неправду. Если один успешен, а другой нет, то судья рассказывает полуправду. Если оба успешны, то результат – полная правда. Но при любом исходе судья не обозначает, был ли его ответ или предоставленная информация правдивой, полуправдивой или абсолютно неправдивой.
Результат неправда означает, что персонаж пошел по абсолютно неправильному пути. Полученная информация полностью ложна.
Результат полуправда означает, что персонаж отчасти преуспел в своей попытке быть успешным. Часть информации верна.
Результат полная правда означает, что персонаж ни разу не сбился с пути к успеху. Полученная информация полностью верна.
В силу скрытой природы броска судьи, персонаж до конца не уверен в природе полученной информации. Судья может увидеть, как персонажи сомневаются в абсолютной правдивой информации, принимают часть неправды или же всю отчасти правдивую информацию.
Марк Миллер, ведущий дизайнер Traveller: 2300 так описал данную механику в статье “Traveller: 2300 Designer’s Notes”, вышедшей в журнале Challenge Magazine #27:
Установка детонатора по правилам Traveller: 2300 – это задача с неопределенным исходом. Она классифицируется как простая, так что практически кто угодно может в ней преуспеть. Однако иногда судья проваливает проверку, тогда как игрок в ней преуспевает: и тогда что-то в установке детонатора идет не так (хотя и выглядит все ОК), а потом взрывчатка не детонирует в нужный момент. А еще иногда игрок проваливает проверку (и сразу же понимает, что сделал все неправильно), и тогда он может тут же попробовать исправить свою ошибку. Но порой игрок проваливает проверку и слышит, как судья сообщает ему о подрыве всех принесенных им зарядов, так как судья также провалил свою проверку.
Этот метод на удивление разумно привносит неопределенность в восприятие игроком (и персонажем) игрового мира, даже при принятии всех практических преимуществ проверок со стороны игроков и известных уровней сложности. И я считаю, что он заслуживает того, чтобы стать более известным и широко используемым.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.