Проектирование для Bleep
Это было примерно в 2010 или 2011 году. Меня попросили возглавить команду разработчиков пятой редакции D&D, но это было еще очень рано. И вот я выступал на одной из конференций. Один геймер спросил меня об одной проблеме с правилами и о том, как она будет решаться. Он настаивал на том, что если это и все остальное не будет объяснено в мучительных подробностях в новой книге правил, то игроки будут искажать правила, и это разрушит игру. Он сильно давил на меня, и в конце концов я в отчаянии сказал: “Я устал разрабатывать для мудаков”.
Мог ли я сформулировать это лучше? Конечно. Конечно. Я не хотел оскорбить. И, чтобы быть ясным, я не хотел сказать, что человек, поднявший этот вопрос, был мудаком. Под мудаками я имел в виду игроков, которых не волнует ни замысел игры, ни удовольствие других игроков за столом - им просто нравится спорить о правилах.
Но если отбросить оскорбительные формулировки, это решение, которое должен принять каждый дизайнер. На каждый стол с отличными игроками, заинтересованными в получении удовольствия, часто находится один игрок, который настаивает на споре по поводу формулировки правила в книге. Этот игрок найдет (или попытается найти) лазейку или противоречие и использует его в своих интересах. Поэтому необходимо решить, для кого вы будете разрабатывать правила - для одного игрока или для всех остальных? И, конечно, для некоторых столов и некоторых игр каждый игрок - это тот самый один игрок.
Я не говорю вам ничего такого, чего бы вы еще не знали. Однако вопрос заключается в том, насколько сильно вы готовы работать, чтобы защитить свои правила от этого единственного игрока.
Как и на многие другие вопросы, которые я здесь поднимаю, здесь нет универсально правильного ответа. Но это вопрос, на который необходимо ответить, а ответив, нужно последовательно применять этот подход.
Писать очень жесткие, очень сбалансированные правила сложно, но это не повод избегать их. В идеальном мире, полагаю, правила всегда были бы защищены от злоупотреблений и идеально “сбалансированы”, к тому же они были бы приятны для чтения, просты для понимания, кратки, поощряли бы творчество и, что самое главное, приносили бы удовольствие. Но мы живем не в идеальном мире.
Немного о балансе
Позвольте мне на минуту отвлечься от слова “сбалансированность”. Это гораздо более сложный вопрос, чем большинство людей, употребляющих это слово. Обычно мы приравниваем сбалансированность к справедливости, а с точки зрения игрока, “справедливость” обычно означает “это справедливо для меня”. Но балансируете ли вы персонажа игрока с другими персонажами за столом? С проблемами, с которыми сталкивается персонаж? Это две совершенно разные вещи.
На самом деле, вопрос баланса, вероятно, слишком велик для этого простого отступления, так что вместо этого позвольте мне проиллюстрировать его историей о балансе, относящейся к написанию правил для недобросовестных игроков.
Давным-давно существовали старые текстовые компьютерные “ролевые игры”, такие как Zork. В этих играх компьютер сообщал вам, что вы видите, и ждал, пока вы введете нужное слово или комбинацию слов. Если была дверь, то для ее открытия нужно было набрать “DOOR”, или, возможно, “OPEN DOOR”. Нельзя было набрать “PULL THE DOOR JUST A BIT AND PEEK THROUGH THE CRACKH”, потому что игра не понимала, что это значит. Она скажет: “I DON’T UNDERSTAND” или что-то в этом роде. Для того чтобы сделать игру управляемой, правила были ограничены очень конкретными, явно детализированными вариантами. Если вы поступали не совсем так, как должны были, игра не работала. Креативность в игре заключалась не в том, чтобы придумывать свои собственные интересные решения проблем, а в том, чтобы найти именно то решение, которое было задумано разработчиком.
Игра была идеально сбалансирована, потому что все в ней было конкретно определено. Напечатайте правильное слово - и у вас все получится, а все остальное - нет. Настольные ролевые игры могут стать жертвой подобного рода, если разработчик слишком беспокоится о том, что его правила не сбалансированы. Во имя баланса можно случайно исключить всю вариативность и многогранность игры, и в итоге получить правила, в которых все настолько определено, что есть только один путь к удовольствию. Персонажи совершают одни и те же действия (потому что в конечном итоге есть только одно “правильное” действие) и сталкиваются с одними и теми же проблемами снова и снова. Игра просто ждет, когда игроки сделают эквивалент “произнесут правильное слово”, чтобы добиться успеха, а затем перейти к следующему столкновению, чтобы снова сделать то же самое.
Это действительно трудно измерить, но иногда удовольствие от ролевых игр достигается благодаря небольшим деталям, которые не совсем сбалансированы. Возможно, именно здесь дизайн игр больше похож на искусство, чем на науку. Но это тема для следующей колонки.
Жесткие и свободные правила
Вернемся к обсуждаемому вопросу. Здесь существует некое соотношение между правилами, которые не позволяют злоупотреблять ими, и правилами, которые способствуют творчеству как со стороны ГМа, так и со стороны игроков или обоих игроков. Для наших целей назовем их “жесткими” правилами, которыми нельзя злоупотреблять, и “свободными” правилами, предназначенными для облегчения и расширения возможностей.
Рассмотрим фэнтезийную игру, в которой есть заклинание “вскипятить жидкость”. Его описание гласит: “Кипятит 1 литр жидкости”. Казалось бы, очень простое для понимания, маломощное заклинание, позволяющее приготовить чай, верно? А может быть, использовать его несколько раз подряд, чтобы согреть ванну. Но что, если игрок хочет вскипятить кровь в сердце оппонента? Это не то, что задумал разработчик, но, в зависимости от набора правил, это может быть законной интерпретацией формулировки правила.
Дизайнер начал с намеренно вольного написания заклинания (ведь вы используете его для приготовления чая, какой тут вред?), но когда игроки недобросовестно интерпретируют правила, вольная формулировка может привести к самым разным проблемам. Поэтому дизайнер пытается ужесточить заклинание и меняет “жидкость” на “воду”. Заклинание стало чуть менее интересным, но проблема решена, верно? Тот же игрок скажет, что больше половины человеческого тела - это вода, поэтому он просто вскипятит воду в легких противника. Внезапно это гонка вооружений. Дизайнер пытается еще больше ужесточить заклинание кипячения, добавляя множество дополнительных деталей, чтобы сохранить его смысл и противостоять всем возможным злоупотреблениям, которые могут придумать игроки. Может быть, это и неплохо, но подумайте о прецеденте. Если вы собираетесь посвятить длинный абзац словоблудию, чтобы тщательно и плотно разработать заклинание, кипящее чай, то что вы будете делать, когда дело дойдет до гораздо более серьезных и широких эффектов?
Если вы собираетесь разработать последовательный дизайн, то вы должны дать каждому заклинанию, каждой способности, каждому оружию, каждому предмету снаряжения… каждому правилу в игре такой же уровень детализации, каждый из которых добавляет ограждения от возможных злоупотреблений. Таким образом, книга правил превращается в увесистый том, в котором подробно описаны все угловые случаи, а защитные перила предохраняют от большинства потенциальных злоупотреблений. Может быть, читать его немного (или много) труднее, но зато он надежен.
Хорошо, но, лишив игру свободы действий, вы лишили ее и обратной стороны интерпретации, то есть большей части увлекательного творчества. Иногда лучшие впечатления от игры возникают, когда ГМ или игрок придумывают идею, совершенно отличную от той, что задумал дизайнер. Именно поэтому мы играем в эти игры, а не в Zork.
(Хотя, не поймите меня неправильно, в свое время “Зорк” был довольно забавным).
Некоторым геймерам не нужно много четко сформулированных, жестких правил. Они хотят иметь возможность принимать решения прямо за столом, чтобы события развивались быстрее, и не нужно было зацикливаться на тексте в книге. Они хотят иметь возможность по-другому относиться к правилам.
Таким образом, уровень интерпретации, возможный в рамках правил, - это спектр, и вам нужно выбрать место на этом спектре - от очень жесткого до очень свободного - для тех правил, над которыми вы работаете. Вы пишете для тех, кто посмотрит на низкоуровневое заклинание кипячения жидкости и подумает: ну, очевидно, это нельзя использовать для кипячения врагов и их убийства - это было бы глупо? Или вы пишете для тех игроков, которые слюной изойдут от желания получить незначительный эффект, который они смогут использовать, чтобы превратить себя в бога?
И вы должны быть откровенны с теми, кто читает ваши правила, в том, каким должен быть общий подход. Если вы пишете свободные правила, вам нужно проинструктировать и игроков, и ГМов относительно ответственности, которая с этим связана. Если же вы пишете жесткие правила, то, вероятно, вам следует поощрять игроков полагаться на книгу правил, чтобы определить, как все работает.
И еще одно предупреждение: избегайте этой ловушки: Не стоит после проведения игровых тестов правил просто заделывать дыры, которые обнаружили в них игроки. Вы можете легко получить ситуацию, когда одни правила будут написаны достаточно жестко, а другие (те, которые не были упомянуты игроками) - гораздо свободнее. В итоге возникает путаница. Игроки и ГМы должны знать, как они должны использовать правила, и это хорошо передается, когда вы последовательны в подходе.
Все сводится к тому, для кого дизайнер писал правила. Уверен, что по рассказу, с которого я начал эту статью, вы догадаетесь, что я предпочитаю более свободные правила, которые поощряют игроков применять их собственное чувство логики и их собственное творчество, потому что именно так мне больше всего нравится играть на самом деле. Я не хочу изучать за столом длинные правила и уж точно не хочу вступать в споры по поводу формулировок. Хотя я очень ценю привлекательность более жестко написанных правил, когда они сделаны хорошо.
Я также скажу, что для разных игр я делаю разный выбор. Например, система Cypher System свободна, но Stealing Stories for the Devil гораздо свободнее. Работа над D&D в свое время предполагала совсем другой выбор. Аудитория для каждой игры немного отличается - хотя я уверен, что многим из тех же людей понравится любая из них или все, если я проделал последовательную работу и объяснил им, чего можно ожидать.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.