Проблема взлома
Я провёл паршивое столкновение, но это была не моя вина. В основном. Мог ли я что-нибудь сделать, чтобы оно вышло не таким дерьмовым? Конечно. Но проблема была по-настоящему зашита в правила системы. В основном. Мог ли я воспользоваться какими-то элементами, чтобы оно вышло не таким дерьмовым? Конечно. Но проблема была по-настоящему вплетена в саму ткань ролевых игр.
И это заставило меня задуматься.
Я хочу рассказать вам о своём паршивом столкновении и о том, как оно помогло мне распознать то, что я называю Проблемой взлома. В основном. Правда в том, что помощь в распознавании Проблемы взлома мне не требовалась. Я всегда смутно чувствовал, что она существует. И вы тоже о ней знаете. Почти наверняка. Моё паршивое столкновение и последующие размышления помогли мне дать Проблеме взлома определение и проанализировать разные способы, которыми ролевые игры пытались с ней справиться — и потерпели неудачу.
Так вот, Проблема взлома — не о взломе систем. Вернее, она о взломе систем.
Я имею в виду, что речь не об изменении правил игры, а о том, как персонажи получают доступ к компьютерным системам без надлежащего разрешения. О компьютерном взломе. В играх. Но будь речь только о компьютерном взломе — в играх, — я не стал бы тратить на это время. Потому что обсуждать стоит только фэнтезийные игры. Я редко вожу игры с компьютерами и никогда о них не пишу. Однако Проблема взлома возникает и в других игровых занятиях: например, в ремесле и исследованиях. На самом деле она скрывается и под большинством социальных столкновений. Она должна быть частью взлома замков и обезвреживания ловушек, но это не так, потому что игровые дизайнеры внедрили неуклюжие, паршивые заплатки, чтобы обойти Проблему взлома.
Некоторые из вас уже слышали часть этой речи. Проповеди. Тирады. Как хотите. Всё потому, что вы состоите в тайной клике сторонников высшего уровня, знаете о моём сверхсекретном разрабатываемом движке для ролевых игр и слышали, как я из-за него ору и бьюсь головой о стол. Ведь теперь, когда я знаю, что Проблема взлома существует и почему она существует, мне придётся её решить.
С великой силой приходит великая ответственность и всё такое дерьмо.
А это просто общее рассуждение о самой проблеме и о том, почему её так трудно было заметить и решить. Заодно оно исправляет кое-что, сказанное мной в одной из самых старых моих статей.
Взлом высшей степени паршивости
Для начала — контекст.
Сейчас я вожу для своей домашней группы игру о заговорах и паранормальных расследованиях в современном мире. Это, вообще-то, не кампания, а временная замена, пока наша основная кампания закрыта на ремонт. По сути, это «Секретные материалы», только следователи работают на частный исследовательский институт, а не на федеральное агентство. Впрочем, занимаются они тем же дерьмом, что Скалдер и Малли. Они уже столкнулись с вендиго сатанинского культа, разобрались с экстрасенсами, даже заполучили экстрасенса в команду, успели забрать предполагаемые обломки предполагаемого НЛО до того, как агенты DARPA отправили их на Склад 51, а теперь разбираются со вспышкой стрекательного гриппа, который, возможно, создали Шмонсанто, Пфайзер Через Игрек или какая-то другая совершенно вымышленная биотехнологическая компания, пока им мешает отбившийся от рук агент CDC.
Вот такая игра.
Во время задания следователям понадобилось связаться с одним человеком. У них были только его имя, несколько людей, с которыми он, возможно, общался, и сведения о том, что он остановился в определённой гостинице. Один из следователей — бывший агент разведки со специализацией в компьютерной разведке. Иными словами, хакер. Он хотел получить доступ к компьютерной системе гостиницы, выяснить номер комнаты этого человека и, возможно, раздобыть контактные данные.
Он мог заняться социальной инженерией или устроить так, чтобы группа отвлекла персонал, пока он добирается до компьютера на стойке регистрации. Но у него был навороченный компьютер и куча высокотехнологичных устройств, и сначала он хотел попробовать удалённое проникновение через гостиничную сеть Wi-Fi. Шансы невелики, зато провал почти ничем не грозит — хороший первый ход.
Разумеется, когда я говорю: «Он мог применить социальную инженерию или получить прямой доступ, но сначала выбрал удалённое проникновение», — на самом деле я имею в виду, что я перечислил варианты, а он выбрал один. Потому что игрок — не хакер. Он в этом дерьме не разбирается. Более того, это временная игра в незнакомой системе, и мне совершенно не хотелось учить его всем правилам полноценного взлома. Не то чтобы в системе вообще были обстоятельные правила взлома. Это реалистичная игра о современности, а не киберпанк. Джейки Мнемоник не подключается к Матрице, не летит сквозь Сеть, не шинкует ICE и не пробивает стены Крепости данных «Протовижен».
Суть в том, что я предлагал варианты, а он принимал лучшие решения, какие мог, исходя из контекста. Это важно. Запомните.
Итак, Дарий — тот самый следователь — обнаруживает, что у гостиницы есть гостевая и служебная сети Wi-Fi. Ещё он находит в бизнес-центре пару принтеров, в которых, скорее всего, сохранены учётные данные обеих сетей. Более того, прошивку этих устройств никто никогда не обновлял, а настройки безопасности по умолчанию не менял. Найдя принтеры в гостевой сети, Дарий входит в панель одного из них со стандартными учётными данными. Так он получает множество идентифицирующих сведений о принтере и прочую важную информацию. Затем он отключает принтер от гостевой сети и подключает его к служебной. Благодаря хорошему Wi-Fi-сканеру и постоянному наблюдению он перехватывает рукопожатие между принтером и сетью. Используя сведения о принтере, извлечённые из него учётные данные и перехваченное зашифрованное рукопожатие, Дарий имитирует принтер и сам подключается к служебной сети Wi-Fi. По сути, его компьютер притворяется принтером. Видите? Оказавшись в сети, он замечает компьютеры сотрудников, потому что никто не отключил их обнаружение, и собирает кое-какие сведения о них. Через уязвимость в протоколах RDP операционной системы — её так и не исправили из-за нерегулярных обновлений и плохо настроенной безопасности — он получает удалённый доступ к компьютеру на стойке регистрации. Потом заходит в гостиничную PMS-систему, ищет человека по имени и находит его контактные данные и номер комнаты.
Вот так просто.
Послушайте, я заранее решил, что это будет не слишком сложно. Я нарочно выбрал гостиницу, не входящую в сеть, со слегка устаревшим оборудованием и плохими процедурами ИТ-безопасности, потому что знал: в группе есть хакер, которому захочется провернуть подобное дерьмо. Но вы бы пришли в ужас, узнав, сколько коммерческих заведений страдают от всех до единой уязвимостей, которыми он воспользовался в моём маленьком столкновении. Эй, компании — поставщики VPN, может, подкинете мне одну из тех рекламных интеграций, которыми осыпаете всех прочих создателей контента?
Там есть и щепотка чуши. Небольшая: мне нравится сохранять правдоподобие — да и помогает то, что действие происходит не в 2025 году, — но я отказываюсь скатываться в полноценный голливудский взлом. Зато у Дария есть передовые технологии Института, некоторые из них основаны на архитектуре чипов не с этой Земли, а ещё он отлично бросал кости, так что победу пришлось ему отдать. Шансы были невелики, но он рискнул и выиграл.
Как бы круто всё это дерьмо ни звучало, мой игрок не хакер, и реальность пришлось слегка погнуть. Правила взлома в системе довольно ограниченны, а я всё равно не хотел задействовать их полностью. Поэтому за столом всё свелось к тому, что я предлагал ему варианты и возможности вроде: «Можно начать со сканирования гостевой сети и поискать в ней уязвимые устройства, через которые получится перейти в служебную сеть», — он отвечал: «Попробую», — а затем следовала куча проверок «Аппаратное обеспечение [Системы безопасности]» (Hardware [Security Systems]) и «Информатика [Взлом]» (Computer Science [Hacking]) со штрафами в одну ступень, бонусами в две ступени и прочим дерьмом.
А за кулисами система… ах да, система. Мы используем правила Alternity Science Fiction Roleplaying Game, изданной в 1998 году компанией TSR, Inc., которая целиком принадлежит Wizards of the Coast, Inc., и сеттинг Dark•Matter Campaign Setting, перенесённый мной во времени в 2015 год.
За кулисами у системы есть вполне стандартный счётчик прогресса (progress tracker). Знаете такие. Игрок должен накопить определённое число очков прогресса (progress points), чтобы завершить задачу; каждая попытка расходует время или ресурсы, а слишком много провалов или один критический провал могут привести к катастрофе. У базовой механики Alternity есть ещё и степени успеха (degrees of success). Поэтому один бросок может принести одно, два или три очка прогресса.
Короче говоря, это стандартное испытание навыков (skill challenge). Вы ведь не думали, что испытания навыков изобрела четвёртая редакция Dungeons & Dragons? И не думали, что счётчики прогресса изобрела Blades in the Dark? Всё, что сделала BitD, — придала им форму пирога. Среди подобных систем Alternity на самом деле неплохо реализовала испытания навыков — там они назывались комплексными проверками навыков (Complex Skill Checks), — но я не собираюсь анализировать или критиковать всю концепцию испытаний навыков либо намекать, что существует особый секретный соус Злого, способный превратить их в действительно хорошую систему. Я говорю конкретно о Проблеме взлома, которая связана с ними лишь косвенно и вообще не обязана включать испытания навыков.
Если честно, главная проблема в том, что испытания навыков якобы должны решать Проблему взлома, но на деле лишь дают ей ещё больше свободы.
Так вот…
Прежде чем продолжить, хочу отметить: это не испортило игровую встречу. Игроки повеселились. Столкновение со взломом заняло лишь несколько минут игрового времени. Хакер взламывал, остальные заглядывали ему через плечо, и на протяжении короткого столкновения все оставались вовлечены. Моё описание определённо помогло. Я даже применил приём с намеренно слегка запутанным техническим жаргоном, чтобы поддерживать внимание.
К слову, один мой друг пытается убедить меня написать цикл о моих приёмах описания, улучшающих игру, о которых вы больше нигде не прочитаете, — например, о намеренно слегка запутанном техническом жаргоне. Хотите статьи о дурацких приёмах описания, которыми ещё никто не делился? Дайте знать.
Признаю, я мог сделать одну мелочь, чтобы распределить участие между игроками. Вообще-то, я попытался, но игроки не подхватили, а столкновение закончилось так быстро, что настаивать не имело смысла. На самом деле тут можно отдельно поговорить о том, что я мог сделать для исправления Проблемы взлома и почему всё это ни хрена не исправляет и не считается. Скорее всего, вскоре я это обсужу: будет повод поорать и поворчать на самых верных, щедрых и активных сторонников. Но…
Я теряю свою лазерную сосредоточенность на сюжете. Перейду к сути и двинусь дальше.
Это столкновение со взломом не было плохим отрезком игры. Оно не испортило встречу, не отняло больше времени, чем заслуживало, и я не потерял внимание игроков. По другую сторону ширмы это был совершенно нормальный отрезок игры. Столкновение-работяга. Оно удерживало интерес, выполнило свою задачу и побрело дальше. Была лишь небольшая упущенная возможность, которую заметил только я и которая бесит меня лишь потому, что я — это я, а всё, что не совершенно, есть провал.
Проблема взлома не разрушает систему. Это не громадная проблема. Такое замечаешь, только если оно случается часто, да и вообще это всего лишь упущенная возможность сделать лучше. Это ужин посреди рабочей недели. Запечённая куриная грудка с брокколи на пару и рисом. Тако из одного из тех наборов Ortega Taco Night с салатом айсберг. Сытно, даже вкусно и вполне питательно, но если есть такое слишком часто, становится тоскливо, а ещё оно занимает место чего-нибудь получше.
Пожалуйста, не забывайте об этой перспективе.
Что же такое Проблема взлома?
На поверхности Проблема взлома — всего лишь отрезок игры, в котором игрок снова и снова бросает одну и ту же проверку, чтобы чего-то добиться. Но это лишь поверхностное объяснение, и пока не копнёшь глубже, оно подталкивает к пресным, паршивым решениям. Так что давайте копнём.
Проблема взлома возникает, когда персонаж должен выполнить продолжительную задачу, требующую специальных знаний или подготовки, которые относятся к очень небольшому числу навыков. Обычно вообще к одному.
Продолжительная задача (protracted task) требует от персонажа нескольких минут, часов или даже дней работы. Это не то, что можно сделать мгновенно. Если вы просто обходите один экран входа — прекрасно, но полноценное проникновение с доступом к системе, обходом защиты, поиском ключевых данных, получением контроля над устройствами и, возможно, заметанием следов не делается за шесть секунд тыканья по клавишам. Точно так же первая помощь после травмы оказывается быстро, а полноценное лечение требует куда больше усилий. Ремесло всегда занимает время. Нельзя просто бросить ингредиенты на верстак и постучать по ним ремесленным молотком. Чтобы сварить зелье или выковать меч, нужны часы или дни.
Специальные знания означают, что у игрока — не у персонажа, а именно у игрока — нет мысленной модели или системы координат для этой задачи. Мой игрок не хакер. Он не знает, как хакеры взламывают. Они печатают — и что-то происходит. Чёрт, я тоже не хакер, но после интернет-исследований при подготовке игры точно попал в какой-нибудь список наблюдения. За моим столом есть игрок, которая не врач, но играет врача и несколько часов поддерживала жизнь критического пациента, пока парамедики пробивались сквозь метель. Насколько мне известно, никто из моих игроков не волшебник и не алхимик, но в игре они постоянно проводят магические ритуалы и варят зелья. Дело в том, что их персонажи — специалисты в вещах, о которых сами игроки буквально ничего не знают. Поэтому у них нет основы, на которой можно строить планы, выбирать подходы или пробовать альтернативы.
Последняя часть — об ограниченном списке навыков — довольно понятна и часто идёт рука об руку со всей этой темой эзотерических знаний. Для ремесла используется навык «Ремесло», для взлома — навык «Взлом», для медицины — навык «Лечение».
Важно понимать: даже если разбить всё это на предельно конкретные поднавыки, мы всё равно прямиком попадём в Проблему взлома. Я мог бы разделить Медицину на Диагностику, Фармакологию, Физиотерапию, Хирургию и тысячу других навыков, но их применение всё равно диктовала бы текущая задача. Получилось бы: «Сначала примени Диагностику, чтобы определить проблему, теперь используй Фармакологию, чтобы подобрать лекарства для контроля состояния, и так далее». А даже если бы навык диктовала не задача — «Хотите применить фармакологический подход или провести хирургическое вмешательство?» — мы тут же упёрлись бы в то, что у игрока, Мастера и автора приключения нет знаний, необходимых, чтобы играть, вести и проектировать такое столкновение.
Итак, у вас есть внутриигровая задача, которая интуитивно требует — и механически выигрывает от — нескольких проверок действий, но при этом сводится к многократным броскам одной и той же проверки: либо потому, что её определяет сама задача, либо потому, что игроку не хватает знаний для выбора иных подходов, либо по обеим причинам сразу.
Это и есть Проблема взлома. И да, я знаю: внутри спрятано серьёзное допущение, о котором я писал много лет назад и для которого предложил простое решение. Я до него доберусь. Решение нехорошее. Просто наименее паршивое из доступных. Точнее, таковым оно не было.
Дело в том, что Проблема взлома куда коварнее, чем кажется. Она заразила множество элементов множества ролевых игр. Где-то она очевидна, как при настоящем взломе. Где-то протекает бессимптомно. А где-то скрывается под паршивыми полосками лейкопластыря торговой марки Band-Aid™.
Возьмём, например, социальные столкновения. В конечном счёте продолжительное социальное столкновение — не разрешаемое одним-единственным броском — обычно состоит из множества реплик игроков и Мастера, но сама игра сводится к многократным броскам местного аналога «Взаимодействия» (Interact), пока собеседник либо не уступит, либо не разозлится и не нападёт. Однако социальное взаимодействие не ощущается как Проблема взлома, потому что у игроков и Мастеров есть мысленная модель разговора, а значит, они могут придумывать бесконечные подходы, просто разыгрывая беседу как беседу. Хотя механика под капотом всё та же: «Продолжай бросать Взаимодействие, пока не преуспеешь или не провалишься».
Слышали когда-нибудь жалобы, что ближний бой бывает довольно скучным, а игра за колдуна (warlock) сводится к постоянному применению потустороннего разряда (eldritch blast)? Что такое ближний бой, если не многократные броски одной и той же проверки ради продвижения к итоговому успеху без какой-либо настоящей основы для описания подходов подробнее, чем: «Пытаюсь убить орка мечом»? Просто это не кажется Проблемой взлома, потому что в бою происходит слишком много всего прочего.
По-хорошему, взлом замков и обезвреживание ловушек тоже должны страдать от Проблемы взлома. Но не страдают, потому что дизайнеры свели их к одному броску. Они сделали это из-за Проблемы взлома, но, на мой взгляд, решение паршивое. Подумайте, что требуется, чтобы провести одну из тех сцен, где нужно вскрыть замок, пока остальные сдерживают чудовищ, или обезвредить ловушку, прежде чем шипастый потолок раздавит всех. Мне приходится говорить: «Это особый замок, одной проверки тут недостаточно». Глупость. Взлом замков и обезвреживание ловушек всегда должны работать именно так.
И это подводит меня к одному из самых распространённых решений Проблемы взлома. К тому самому, которое я лично впарил вам всем пятнадцать лет назад.
Пластырь одного броска™
Много лет назад я говорил вам никогда не использовать несколько бросков для разрешения ситуации, если достаточно одного. Я говорил так из-за Проблемы взлома. Отрезок игры, в котором игрок снова и снова бросает одну проверку, чтобы накопить достаточно прогресса для успеха, — отстой. Но, честно говоря, это недостаточно большой отстой, чтобы такой подход оказался хуже разрешения одним броском.
На самом деле есть несколько очень веских причин применять несколько проверок для продолжительных задач, даже если всё сводится к накоплению прогресса до успеха. Чтобы меньше печатать, я буду называть это подходом прогрессивных проверок (Progressive Check approach). Так мы отличим его от подхода одного броска (Single-Roll approach) к управлению задачами. Договорились? Отлично.
Во-первых, прогрессивные проверки интуитивно понятны. Если задача требует минут, часов или дней работы, не стоит разрешать её так же, как удар в горло. Именно поэтому мне пришлось так старательно убеждать Мастеров не использовать прогрессивные проверки. Они слишком естественны. Само по себе это ещё не отличная причина применять прогрессивные проверки, но начать можно отсюда.
Во-вторых, прогрессивные проверки помогают поддерживать вовлечённость, темп и синхронность. Часто, когда персонаж погружается в продолжительную задачу, остальные в это время занимаются другими делами. Прогрессивные проверки дают повод регулярно возвращаться к персонажу, занятому долгой работой. Вам не приходится говорить: «Ты всё ещё занят задачей; разрешим её, когда пройдёт достаточно времени. А теперь я поиграю со всеми остальными».
Когда я упомянул вовлечённость, вы подумали, что я сейчас заговорю о противоположной проблеме, верно? Но нет: обычно именно усердный исполнитель продолжительной задачи остаётся обделён вниманием, когда вы уже достаточно хороший Мастер, чтобы провернуть всю эту чушь из статьи «Все делают всё одновременно».
Обратите внимание: прогрессивные проверки также позволяют синхронизировать часы всех участников. Если каждая прогрессивная проверка соответствует десяти минутам работы — или одному часу, или одному рабочему дню, — вы точно знаете, сколько времени остальные персонажи должны чем-то заполнить или пропустить между проверками. Короче говоря, прогрессивная проверка закрепляет ваши Часы действий (Action Clock).
Особенно важно это при провале задач. Представьте, что группа находится в городе. Волшебник три дня варит важное зелье, а остальные игроки общаются, заводят связи, тренируются, ищут зацепки, обслуживают снаряжение, ходят по магазинам, продают сокровища, кутят или занимаются чем-то ещё. Если по окончании этих трёх дней волшебник получает один-единственный шанс на успешный бросок, то при провале игрок пожертвовал множеством возможных игровых событий ради одного паршивого броска.
Это подводит нас к другой вещи, которую подход одного броска моделирует с трудом. Как при нём поступать с обязательством выполнить задачу — и отказом от неё? В подходе одного броска возникает странность: персонаж должен посвятить задаче определённое число минут, часов или дней, чтобы заслужить право на проверку. Если он бросает задачу, то все возможности, от которых он до этого отказался, не приносят ему ничего. Более того, когда по той или иной причине — хорошей или плохой — появляется возможность бросить задачу, у игрока нет нормальных оснований для выбора.
Представьте, что настоящий я работает над проектом. Прошло три дня, а прогресса нет. Всё идёт дерьмово. Тут появляется друг с другим предложением. Бросив текущий проект, я получу награду. Может, не такую хорошую, зато гарантированную. Если проект всё равно застрял, а я уже измотан, разумно зафиксировать убытки и выбрать верный вариант. Но если проект идёт отлично и мне кажется, что через день-другой случится прорыв, расчёт меняется, верно?
Прогрессивные проверки также упрощают приостановку задач, которые вообще можно приостановить. Некоторые можно. Вскрытие замка на паузу не поставишь, перерыв в лечении может быть опасен, зато ремесленный проект вполне можно отложить и вернуться к нему позже. В подходе одного броска Мастеру приходится отслеживать, насколько персонаж приблизился к возможности бросить проверку до приостановки задачи. При прогрессивных проверках Мастер и так отслеживает прогресс, поэтому пауза не требует дополнительного учёта.
Прогрессивные проверки позволяют игрокам по ходу работы видеть отдачу от вложений времени и ресурсов. Это здорово, потому что во время игры игроки должны видеть прогресс. Кроме того, так они могут принимать разумные решения: продолжать ли вкладываться в задачу, когда обстоятельства меняются или результат не приходит.
И это возвращает меня к лучшей причине использовать прогрессивные проверки. Начиная продолжительную задачу, вы можете примерно оценить, сколько времени и ресурсов она, вероятно, потребует, но не должны знать это с абсолютной точностью. Так и должно быть. Вы не должны точно знать, сколько займут обыск комнаты или взлом замка. И не должны быть совершенно уверены, что посреди ремесленного проекта не закончатся материалы и не придётся покупать новые.
Прогрессивные проверки работают даже в системах с бинарным разрешением действий. Более того, переменная стоимость во времени и ресурсах становится главным отличием между тем, что делается немедленно, и тем, что требует минут, часов или дней.
Поэтому подход одного броска в действительности не решает Проблему взлома. Это даже не решение в виде полоски лейкопластыря торговой марки Band-Aid™. Это попытка избежать проблемы наполнения ванны, утопив младенца, или как там звучит эта фраза.
Если совсем честно, именно по этим причинам я использую прогрессивные проверки, даже когда они приводят к Проблеме взлома. Уж лучше Проблема взлома, чем отказ от прогрессивных проверок. Она не настолько ужасна — особенно учитывая, как редко возникает, и особенно потому, что я о ней знаю и держу её под контролем. Моё ужасное столкновение со взломом было ужасным только для меня. Игроки провели время вполне нормально. Разреши я его одним броском, удовлетворения было бы куда меньше.
Другие паршивые решения
Я знаю, что у Проблемы взлома есть множество вроде бы очевидных решений, и знаю, что многим из вас захочется написать о них в комментариях. Пожалуйста. Я не стану на вас орать. Чёрт, я хочу, чтобы вы это сделали. Так вы поможете другим обходить Проблему взлома теми же способами, что и я. Но не обманывайте себя: ваши решения тоже паршивы. Обещаю. Единственные решения — паршивые и костыльные. Я не собираюсь разбирать каждое плохое решение Проблемы взлома, но несколько прокомментирую.
Самое распространённое — решение через мини-игру (Minigame Solution). Многие киберпанковые игры используют его для компьютерного взлома. Alternity тоже. Просто делает это довольно дерьмово.
По сути, решение через мини-игру означает создание отдельной подсистемы для разрешения конкретной продолжительной задачи. Появляются специальные правила, снаряжение, способности, действия и варианты. Игрок и Мастер используют эти особые правила и системы, чтобы разыграть маленькую мини-игру и разрешить задачу.
Очевидно, для некоторых игр и задач это имеет смысл. Взлом виртуального интернета был краеугольным камнем киберпанка с тех пор, как Гибсон изобрёл жанр. Но как широкое решение проблемы продолжительных эзотерических задач это не работает. Вы правда хотите, чтобы игрокам пришлось учить кучу мини-игр ради своих персонажей? Большинство игроков не выучит даже общие правила игры. Да и сами вы сколько мини-игр готовы освоить ради ведения? Неужели взлом замков, ремесло и магические ритуалы настолько важны, что заслуживают двадцатиминутной мини-игры со специальными правилами? И настолько ли часто они встречаются, чтобы вам не приходилось каждый раз искать и перечитывать правила?
А что насчёт вещей, для которых дизайнеры мини-игру не создали? Допустим, я хочу провести столкновение о приготовлении блюда, которым нужно впечатлить прибывшего сановника. Или игрок с навыком кулинарии сам решает, что это хороший способ впечатлить сановника. Мне на ходу изобретать кулинарную мини-игру?
Есть и решения, которые требуют правильно строить столкновения или правильно вести игры. Велите авторам приключений не создавать задачи со взломом, в которых нельзя применять другие навыки и решения. Велите Мастерам всегда чередовать продолжительные задачи с другими занятиями ради темпа. У меня припасена очень долгая и очень злая тирада о токсичном — до повреждения мозга — образе мыслей за этими предложениями, но её я оставлю на другой день. Я не верю в решение системных проблем через навязывание условностей авторам приключений и Мастерам. Если что-то сломано на уровне системы, исправляйте на уровне системы. Если в игре есть навык взлома — или ремесла, или вскрытия замков, — его применение само по себе должно быть интересным и увлекательным. Мне не должна требоваться затопленная комната, чтобы сделать вскрытие замка интересным.
В конечном счёте, хотя эти решения и могут уменьшить последствия Проблемы взлома, ни одно из них не затрагивает настоящую суть. Подлинная проблема скрывается не в костях, разрешении действий или вовлечённости. Она в том, как позволить игрокам играть персонажами, которые разбираются в том, в чём не разбираются сами игроки. И в том, как Мастерам вести игру без знаний, которыми обладают персонажи.
Не ожидали, да?
Игровой процесс — это стратегический выбор
Повторяйте за мной: «Бросание костей — не игровой процесс». Игровой процесс — это принятие решений, влияющих на исход игры. Если вы не принимаете решений, меняющих игру, вы не играете.
Как только игрок Дария выбрал подход с удалённым взломом, принимать стратегические решения он закончил. Всё. Он выбрал свой ход, а дальше оставалось лишь долго выяснять, чем всё кончится и чего ему будет стоить. В процессе бросков он выбирал только между продолжением взлома и отказом от него, а без изменения ситуации причин останавливаться не было.
Вот в чём Проблема взлома. Сам по себе выбор между продолжением и отказом — не особенно интересное игровое решение. В отдельных ситуациях он может быть захватывающим, но даже тогда не слишком. Уж точно не так, как смена подхода по мере развития ситуации или испытание разных решений в поисках работающего.
Если во время взлома вы запускаете отслеживание, решение продолжать, пока вас выслеживают, создаёт сильное напряжение. Но всё равно это лишь вопрос того, сколько вы готовы поставить на кон до исчерпания терпимости к риску. А если отслеживание не запускается, вы просто бросаете следующую проверку. Ровно как при ремесле во время простоя, если полоса неудач не пожирает дорогие материалы.
К слову, поэтому социальные взаимодействия не ощущаются как Проблема взлома, хотя механически они ей тождественны. По крайней мере, тождественны в исполнении большинства Мастеров. Разыгрывание беседы — постоянное решение, что сказать дальше, — создаёт настолько обширное пространство возможностей, что вы можете и не заметить, как раз за разом совершаете одну и ту же механическую проверку.
Конечно, хорошие Мастера подстраивают разрешение под ситуацию. Скажете что-то подходящее — получите бонус к следующей проверке Взаимодействия. Скажете что-нибудь оскорбительное — можете автоматически провалиться или получить штраф до конца разговора. Но если извиниться и загладить вину, штраф, возможно, исчезнет.
Всё это работает не благодаря правилам, а потому, что Мастера и игроки понимают, как устроены люди, разговоры и прочее дерьмо. Мастер может изменять каждую отдельную проверку, потому что знает, как работают люди и беседы. А что будет аналогом в игре про взлом, где ни игрок, ни ведущий не хакеры?
Задумайтесь…
Если два специалиста по взлому разыграют столкновение со взломом как Мастер и игрок, оно будет похоже на социальное взаимодействие под руководством отличного Мастера. Мастер станет изменять каждую проверку в зависимости от очень конкретных заявлений игрока, а игрок — менять стратегии и подходы, опираясь на описания Мастера и результаты действий.
И вот она, Настоящая Проблема взлома. Как ролевая игра может позволить двум неспециалистам разыграть требующую специальных знаний задачу так, чтобы это было стратегично, захватывающе и увлекательно? Как ролевая игра может позволить двум неспециалистам разыграть любую подобную задачу, какую только можно представить? Прямо на ходу? И как сделать это без такого уровня абстракции, при котором сами задачи перестают ощущаться чем-либо, кроме абстракций? Как решить Настоящую Проблему взлома, не создав Проблему Burning Wheel? Возможно ли это вообще?
Ура неразрешимым проблемам
На этом обсуждение заканчивается. По крайней мере, пока. Потому что очевидного способа позволить человеку, который не разбирается во взломе, провести для другого такого же человека игру про взлом так, чтобы она ощущалась взломом, на самом деле нет. Во всяком случае, без мини-игр или абстракций. Пока нет. Я верю, что решение где-то существует. Думаю, отчасти оно требует более совершенного набора инструментов для построения сложных продолжительных задач. По сути, лучшего подхода к испытаниям навыков. Но мне также кажется, что для него может потребоваться совершенно иной взгляд на разрешение действий — на самом глубоком уровне базовой механики. Можно ли надстроить такое над чем-нибудь вроде Dungeons & Dragons — совсем другой вопрос. И это ещё не говоря о других, более специализированных, более абстрактных и более инди-ролевых играх, которые просто налепляют на Проблему взлома дополнительные костыли и повязки, так и не приблизившись к Настоящей Проблеме взлома.
А пока я всё же советую последовать моему примеру и относиться к Проблеме взлома чуть спокойнее. Я знаю, что некоторые из вас отвергли идею прогрессивных проверок — самостоятельно или потому, что прочли мои ранние работы и больше к ним не возвращались, хотя с тех пор я несколько раз давал противоположный совет. Непременно помните о Проблеме взлома и не позволяйте ей выходить из-под контроля, но и не погружайтесь в условности, абстракции, мини-игры или подход одного броска только ради того, чтобы всеми силами её избежать.
Вероятно, в будущем я ещё многое об этом скажу. Я совершенно точно и определённо работаю над кое-чем — как над твёрдыми советами, так и над хаками правил, — что собираюсь развить и опубликовать в ближайшие недели и месяцы.
Так что, полагаю, оставайтесь на связи.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.