Другой подход к Resolution Types
Дорогие друзья, Дракончик продолжает экспериментировать с форматом пересказа. Мы прочитали англоязычную статью и делимся с вами ее пересказом, но ссылка на оригинал прилагается.
Автор считает, что традиционный подход к Resolution Types устарел и предлагает свой.
rpg-news.ru/2023/06/05/5-resolution-types/
Обязательно пишите в комментариях, что вы думаете о таком формате, нам важно ваше мнение!
31 комментарий
людимеханики». Этак можно сделать из статьи вывод, что игроки в «мидскульные» игры не сталкиваются ни с одним из описанных механизмов разрешения.Из банального приходит что-то типа завершения битвы одним броском — например, обрушить потолок на противника, при этом это все еще task resolution — удастся ли обвалить.
Хотя да, сцена разрешается. Но, в таком случае, обособление подхода Scene Resolution мне кажется ненужным.
А Scene resolution это про масштаб. Мало где применимо с пользой, ИМХО.
Ну или компоновать подходы не плоским списком, а матрицей, как ДнДшные мировозрения)
То есть когда у нас детальное разрешение сцены по отдельным заявкам — это Task Resoluton. Как только сцена превратилась в целостную единицу (потому что она малозначима, как в примере выше, или потому что механика концентрируется на обработке всего сразу) — внезапно она стала неотличима от Conflict Resolution. То есть это оказывается всего лишь другим языком описания, без сущностной разницы.
Вся разница — в одной шкале, важен только масштаб.
C. vs T. — это противопоставление разных подходов. Причина действия против непосредственно действия. Широта применения вообще не при делах, об этом явно указано в исходном посыле, чтобы не путали.
А то, что в новой статье, это иная классификация — по широте применения. Она вообще не пересекается с C. vs T. в его оригинальном виде — это другое измерение, другая величина.
Что противостояние «цели участников-успешность действия» сформулировано в иных терминах не делает его иным, как я понимаю. То есть совершенно любая сцена (для примера) может быть сформулирована и в тех, и в других терминах. Расширительно их понимая — собственно, ещё в самом начале появления игр с Conflict Resolution приходилось вводить «виртуальные стороны конфликта» вроде пола, который хочет провалиться (фактически, выразителя мнения участника — обычно ведущего — который хочет предложить другой вариант развития событий). То есть, с одной стороны, за любой осмысленно сформулированной задачей (если это не «бросок на завязывание шнурков») на самом деле стоит некоторый предлагаемый вариант развития событий — когда PC ловит в прицел снайперской винтовки лоб президента Напримерии, бросок определяет не столько успешность выстрела, сколько в каком направлении развернётся игра дальше: в преследуемого беглеца или в члена
скорпионниканового режима. С другой стороны, любой конфликт с целями сторон подразумевает задачи, через которые стороны их достигают.Вот автор, как я понимаю, говорит что реальная разница, которая измерима и не сводима к стилю изложения, это именно блочность разрешения. Как только блок становится таким крупным, что разрешение сводится к одной проверке, TR перестаёт отличаться от CR, и вопрос только в том, как это удобнее излагать.
Это как с движением, например. Оно относительно — то есть двигаться может только одно тело относительно другого. Потому вопрос о том, движется ли Земля вокруг Солнца, Солнце вокруг Земли или они оба вокруг некоторой третьей точки (центра галактики, к примеру), сам по себе лишён смысла: можно говорить о том, какое описание проще и удобнее, а результаты в любом случае должны быть одинаковы. Автор статьи, как я понимаю, говорит именно о том, что язык описания (подходы в смысле C\T) это именно что «лирика» и вопрос удобства взглядов, а определяющий момент — базовый блок.
Можно попробовать посмотреть, когда это будет неверно, и насколько экзотической должна быть ситуация. Уже вне мнения автора статьи — мне лично кажется, что в большинстве случаев да, подобный переход не выкидывает ничего важного.
То есть про это есть в старой цитате, которая про scale, но вот это самое «confusing» оно, сдаётся, не случайное, и не факт, что в глобальном смысле заблуждение. Потому что задача без варианта развития событий за ней и вариант развития событий без какого-то варианта внутримировых задач за ним — это, кажется, в среднем случае неудачный момент.
Что и в примере есть. В фикшене описание заявки может быть одинаковым — «открываю дверь, чтобы спрятаться». Task Resolution — удалось или нет открыть дверь — в Conflict resolution — удалось спрятаться или нет. Нюансы.
Классический пример от Бейкера:
Упражнение 1: успех\неудача без вопроса цели как сколько-то важного. Мне вот так навскидку в голову приходит только какая-то детальная «симуляция завхоза». Какая-нибудь там сцена разбивания лагеря в тропичеком лесу, где надо сделать кучу пунктов, которые скажутся в описаниях — а противомосктные сетки развёрнуты? А проверно, что всё сложено на возвышении, на случай ливня? Причём источник удовольствия — именно сами детали, погружение, а не последствия (потому что если последствия важны, то это именно что конфликт и выбор итога: не будем ли мы играть потом в экспедицию, потерявшую важные припасы или там с больным после укусов москитов). В усреднённом же случае, кажется, отсутствие конфликта за проверкой\задачей говорит, что это не задача, а элемент описания. Бросок, который можно пропускать.
Упражение 2. Представить себе задачу, где конфликт важен, а способ реализации и задача за ним не важна совершенно. Тут мне в голову приходит навскидку только чисто проходной эпизод, детали в котором принципиально ни на что не влияют. Еретик Мокус и его неуловимый культик, спасаясь от инквизиторши Беладонны, пытаются найти убежище у мутанта Шоколада. Из внешних соображений ясно, что Шоколад потом никогда не появится в игре — например, потому что через две сцены всё вокруг подвергнут экстерминатусу. Потому важно только, нашёл Мокус убежище или нет, а описывал игрок сцену как попытку убеждения по-доброму, жуткое варп-колдовство, взятку или что ещё — совершенно неважно. В общем же случае, если у нас чистый конфликт, а никакие введённые детали игрового мира (возникающие в результате описания именно что задачи, внутримирового события) никак и ни на что не влияют, то мы, вроде, не используем именно что один из ключевых моментов НРИ — что введённые там факты игрового мира оказываются равнозначны с писаными правилами. То есть когда у нас учаастник настолько оторвался от игрового мира, что говорит «да неважно, что там, я не буду тратить время на факты», пресловутое общее воображемое пространство деградирует до схематического режиссёрского замысла. В прошлом случае чистое описание, тут — полное его отсутствие. Тоже плохая ситуация, которой по-доброму бы надо избегать.
Может, конечно, я упражение сделал плохо — это действительно навскидку, без обдумывания. Но, кажется, если у нас подходы дошли до крайности, когда один действительно можно противопоставить другому, то дело довольно плохо: в большинстве случаев у нас плохой в игровом смысле эпизод.
ДнД или Дневник Авантюриста, например. Механическая сущность — скилл. И механика говорит, удалось ли совершить действие. Но не говорит, удалось ли достичь цели. В механике, кажется, даже нет целеполагания. Т.е. «хочу вскрыть замок сундука, чтобы найти сокровища» — может быть ситуация, когда замок успешно вскрыт, а сокровищ там нет (например, потому что накидка по таблице лута дала такой результат, или потому что в тексте приключения было сказано, что этот сундук пуст).
В Fate, (у которого тоже торчат уши мидскула), в правилах много нюансов четко обговаривается. Что сводится к мысли, что важнее цель действия, чем само действие. Исходы не просто бинарные, а с нюансами)
Вы кидаете кубики, только когда на пути к цели встаёт интересное препятствие. Если препятствие неинтересное, то и кидать незачем: вы просто достигаете цели.
Провал
Если результат вашего броска меньше сопротивления — это провал.
Провал провалу рознь. Возможно, вы не получаете то, что хотели. Или получаете, но дорогой ценой. А может вас ждут некие отрицательные игромеханические последствия. Иногда провал приводит к нескольким из этих проблем — цену конкретного броска определяет ведущий (см. ниже).
Ничья
Если вы выкинули столько же, сколько противник, — это ничья.
Вы получаете меньше, чем хотели, либо всё, но за малую цену.
Успех
Если вы выкинули на 1 или 2 больше, чем противник, — это успех.
Вы получаете то, что хотели, и вам это ничего не стоит.
Стильный успех
Если обошли противника на 3 или больше — это стильный успех.
Вы получаете то, что хотели, и даже немного больше.
Ходы PbtA вцелом строятся вокруг сюжетных поворотам. Там важно, что ты делаешь, но это важно как метод достижения цели.
То, что ты пишешь, говорит, как в книгах описаны навыки, например, в том же SW. Но в игромеханике, вроде, нет особо ни целеполагания, ни задач — там скорее области применения. Названия навыков в SW поощряют думать о задачах, да, но вот глубокой сущностной разницы (как, насколько я понимаю, говорит автор исходной статьи) толком нет. То есть когда мы выбрали некоторый масштаб, который будет разрешаться в исходной проверке, то именно механика SW точно так же спокойно применяется к разрешению конфликтов, с чисто косметическими правками.
То есть вот у нас есть, например, центурион, который отдаёт приказания развёртывающейся манипуле. Механически это проверка навыка Battle, а выбранный ведущим масштаб — сцена, то есть мы решили, что не будем использовать правила по Mass Battles на полную катушку для этого эпизода, а обойдёмся одной проверкой навыка.
В этом случае, собственно, разница будет больше задаваться тем, как формулирует заявку говорящий. Он может формулировать это в терминах задач, подразумевая планы: «Хочу, чтобы легионеры развернули строй поперёк ложбины между холмами!» (чтобы варварский отряд не видел нас, пока не налетит), а может в терминах ставок и целей — «Хочу тактического преимущества в грядущем бою, хочу поймать преследующих варваров врасплох!» (для чего мы развернёмся за холмом). И то, и другое не требует модификации именно игромеханики — оно требует подхода к подаче заявок. При этом, конечно, факт, что авторы SW ориентировались на подачу заявок первым способом — но этот вопрос, похоже, мало связан с чисто механическими решениями.
Про манипулы.
ИМХО, есть разница в двух случаях:
Игрок говорит — «хочу развернуть манипулы от забора до обеда».
Task Resolution — в примитивном случае не важен контекст происходящего. Механика говорит — кидай вот это, и либо получится, либо нет. На что это повлияет и повлияет ли вообще механика ответ не дает. Чисто про то, удалось ли действие. Возможно игрок хотел своими действиями прикрыть тылы, для защиты от коварного врага. Возможно хотел устроить ловушку для того же коварного врага. Возможно это вообще парад в честь коронации — для механики не важно.
Игрок говорит — «хочу задержать коварного врага, чтобы союзникам хватило время захватить макгафин, для этого развертываю манипулы» или «развертываю манипулы, чтобы произвести впечатление на иностранных послов, собравшихся на коронацию» или «развертываю манипулы, чтобы, воспользоваться неожиданностью и усталостью врага и устранить большую часть нападающих». Цели совершенно разные, хотя метод достижения один. И механика скажет, удалось ли достичь цели, какой ценой, как именно изменилась ситуация по результатам броска.
(Conflict Resolution)
В случае «условного D&D» — да, тут я согласен.
В «чистом» conflict resolution исход «твоя принцесса в другом замке» может наступить только при провале, при успехе — не может. Ну или бросок на спасение принцессы не будет позволен, пока не будет разрешён конфликт с определением её местонахождения.
В task resolution ситуация иная — шадоураннеры всё сделали правильно, но перепутали офисы — возможный результат, если выбор того, в какой офис вламываемся — в руках игроков. Можно сказать, conflict resolution отбирает у игроков возможность сделать ошибку выбора пути к цели — а значит, сокращает пространство их свободы, с некоторой стороны
(Тут можно уйти в тред про навыки игрока против способностей персонажа ответов так на 150)
С другой стороны, можно сказать, что в реальной игропрактике это скорее шкала, чем бинарная оппозиция, и даже я бы рискнул выдвинуть мысль, что task resolution можно считать в разрешение конфликтов в некотором смысле вложенным — когда у нас у всех конфликтов предельно тактические цели — «зачем — чтобы сейф был открыт — зачем — чтобы взять лежащее там — зачем — потому что я рассчитываю, что там компрометирующие бумаги» — если мы остановимся на первом «зачем», то получим task resolution, если дойдём до конца — то окажемся на территории conflict resolution
P.S. только сейчас понял, что пример с conflict resolution малого масштаба — — типичная проверка какого-нибудь финта в мидскуле, господин журден всегда говорил прозой
Хотя возможно я неверно понял (или помню) изначальный смысл противопоставления «Task vs Conflict Resolution» и он вовсе не в уровнях абстракции.
И теперь мне кажется, что автор «новой классификации» ошибается точно так же. Потому что по его классификации выходит именно scale.
Если что — я так понимаю, что источник противопоставления task vs conflict находится тут: lumpley.com/hardcore.html По крайней мере найденные срачи ссылаются именно сюда и цитата тоже отсюда.
Исходя из текста оригинала получается вот так. От более точного к более абстрактному.
Что в целом логично — не во всех играх дозволяется механически разрешать возникшие препятствия на разных уровнях. Грубо говоря, где-то можно кинуть кубы за всю сцену и описать последствия (механика из коробки может работать со Scene Resolution), а где-то требуется сделать декомпозицию и разрешать сцену на уровне отдельных задач (Scene разбивается на Situation, а те в свою очередь дробятся на Task, и только тогда игровая механика начинает работать).
На просторах интернета можно встретить два понимания дихотомии task vs. conflict resolution: (1) исходное, сформулированное 20 лет назад на форумах Forge и основанное на понятии «конфликта интересов»; и (2) более позднее, растиражированное теми, кто пропустил два самых главных слова в исходном определении, и проводящее границу по тому, насколько крупную последовательность внутриигровых событий определяет данная механика.
Автор статьи ничего не слышал о первом подходе и пытается починить второй (не первая такая попытка на моей памяти). В принципе, достойная задача, особенно если отказаться при этом от ярлыков task и confict (а то в лучшем случае получится как-то так). При этом он как бы переизобрёл первый подход и зачем-то искусственно соединил его со вторым в единую классификацию.