Текст Justin Alexander от 30 ноября 2015 года

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

В действительности же, когда мы принимает решение кинуть дайсы, то на самом деле мы говорим: «Есть более, чем один возможных исход этого действия. Давайте же вместе мы узнаем, что именно случилось». Это в своем роде бросок жребия, дабы определить нашу удачу. И когда мы говорим, что наш жребий может иметь лишь два возможных исхода, мы ограничиваем эффективность этого предсказания.

Градуируемые результаты

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

-Успех

-Частичный успех

-Частичный провал

-Провал

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

Например, персонаж может пытаться перепрыгнуть расщелину. ДМ просит его сделать проверку Прыжка со сложностью 15. Если игрок выбрасывает 20 (а шаг проверки равен 5), то его персонаж с легкостью перепрыгивает расщелину и приземляется на другой стороне. Если же результат 16, то это лишь частичный успех, и Мастер может решить, что хоть он успешно перепрыгнул через расщелину, персонаж упал ничком на другой стороне. Тем временем, результат в 12 (то есть степень провала равна 3) может привести к тому, что прыжок был слишком коротким, но персонажу удалось схватиться за выступ на другой стороне (и получить возможность вытащить себя наверх). И лишь бросок с результатом 10 или ниже (то есть степень провала 5+) означает, что кто-то беспомощно свалился в расщелину.

Очевидно, что спектр результатов легко расширить (Броски атаки в бою дают нам простейший пример – степень успеха в 5 может дать +2 к урону, степень успеха в 10 уже +4, ну и так далее). В некоторых случаях вся идея «успеха» и «провала» может быть полностью размыта – останется лишь вопрос, насколько хорош (или плох) персонаж в том или ином деле.

Другой взгляд на градуированный успех – это то, что, когда у нас есть набор возможных результатов, ДМ моделирует это заданием множества уровней сложности. Я часто использую этот метод с проверками Сбора Информации. Пример ниже.

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

Проверка простого успеха

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

И тут я представлю технику, которую я весьма ценю – это проверка простого успеха из Eclipse Phase: она подразумевает под собой действие, где мы принимаем тот факт, что персонаж преуспеет в нем. И нас волнует лишь то, как много времени это займет или насколько хорош будет результат.

Если мы вернемся к нашему обсуждению о «Взять 1», то мы увидим, как простые успехи могут математическим образом возникнуть во многих механиках определения результата: успех может быть гарантирован вне зависимости от итогов броска, так что единственная нужда в нем – это определить качество нашего успеха (Вы можете увидеть это в табличках по Сбору Информации из примера выше: результат проверки навыка, равный 9, означает провал – персонажам не удалось собрать ничего на так называемого «Роберта». Но если у персонажа есть +9 на его проверку Сбора Информации, то успех неизбежен: он в любом случает узнает что-либо о «Роберте». Остается лишь понять, как много).

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

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

Движущий провал

Еще один взгляд на проверку простого успеха – это идея движущего провала.

В своей основе она неотличима от простого успеха – провал с точки зрения механики описывается как успех с осложнениями в игровом мире.

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

К примеру, Лукас пытается взломать замок на двери в архив, и проваливает проверку навыка. ДМ решает, что Лукасу все-тки удалось открыть дверь…но это потребовало слишком много времени, и вот его уже заметил ночной сторож. Или его отмычка сломалась. Или же его записали на камеру, и теперь плохие парни смогут найти его спустя какое-то время.

По сути, существует немалое число полезных техник, которые могут помочь вам оторваться от парадигмы успех/провал. Однако вот несколько слов предосторожности касательно идеи «движущего провала», так как она успела повлечь за собой ряд вредоносных теорий.

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

Однако «Правило Трех Улик» демонстрирует, что решение этой проблемы заключается в том, чтобы предложить несколько путей для достижения успеха. Будучи вынужденными искать пути обхода тех заслонов, что были созданы вашими провалами, вы отправитесь в том направлении, о котором могли и не думать: если бы вам удалось подкупить тех стражников, вы никогда бы не забрались на стены замка, не вломились бы через окно и не влюбились бы в принцессу, которую нашли за ним. Зачастую неудача – это лишь отправная точка для самых увлекательных ситуаций и наиболее запоминающихся из историй. Полностью избавив свой стол от провалов, вы не обогатите свои игры, а, наоборот, обедните. Как и рельсы, это неисправная механика, что накладывается как поспешная заплатка поверх другой неисправной механики.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *