Проектировать целенаправленно
У меня полно дел и совсем мало времени, так что быстренько пробежимся по оговоркам.
Эта статья входит в мой большой курс по проектированию приключений и кампаний — «Настоящее сценарное мастерство» (True Scenario Designery). Каждый материал опирается на предыдущий. Если вы читаете их не по порядку, исправьте это с помощью удобного оглавления курса.
Курс основан на ряде предположений о роли Игрового Дизайна в приключениях и кампаниях для настольных ролевых игр. Я их уже изложил. Вы вправе с ними не соглашаться и делать всё как хотите, но тогда в этом курсе вы не найдёте ничего полезного и лишь возненавидите его. Никому в моих комментариях это не интересно. Мне тоже. Сделайте всем одолжение и займитесь чем-нибудь другим.
Для этого курса я изобретаю собственный словарь, и слова означают то, что я велю им означать. Не нравятся мои термины? Считаете, что они значат другое? Никому в моих комментариях это не интересно. Мне тоже. Идите докучать кому-нибудь ещё.
Считайте, что я вас предупредил. Я больше не собираюсь спорить о каждой чёртовой вещи, которую говорю.
Проектировать целенаправленно
С возвращением на мой потрясающий мастер-класс по искусству Проектирования Сценариев (Scenario Design) — «Настоящее сценарное мастерство». Да, я знаю, что английское design уже существительное и суффикс -ery ему не нужен. Это называется параллелизмом, тупица. И разве вы не читали предупреждение насчёт споров о моих словах?
Хотел бы я сказать, что со вступительной концептуальной чушью покончено. Но не могу. Если собираетесь развивать навыки Проектировщика Сценариев, вам нужна основа из фундаментальных принципов игрового дизайна и понимание того, как они связаны с проектированием сценариев для настольных ролевых игр. Следующие примерно три урока я буду ломом вколачивать эту хрень вам в череп. В самом общем смысле расскажу, как работают игры и как их делать.
Весёлого тут мало. Я знаю, вам хочется рисовать карты и заселять их чудовищами. Мне тоже. Но — и это тема сегодняшнего урока — если рисовать карты и наполнять подземелья бездумно, не понимая, что и зачем вы делаете, у вас не выйдут лучшие чёртовы приключения, какие вы только способны создать. А ведь цель именно в этом, правда? Никакого больше мусора уровня вполне сносного, работоспособного приключения.
Поскольку это концептуальное введение не особенно весёлое, я изо всех сил постараюсь провести нас через него как можно быстрее. А это, как вы знаете, совсем мне не свойственно. Если сегодня мой тон кажется слегка торопливым, причина в этом. Я просто объясню идеи и пойду дальше. Никакой борьбы, оправданий, споров, выведения, анализа или убеждения. Просто скажу вам, как оно есть.
Груда понятий, которую я хочу разобрать в следующих примерно трёх уроках, образует один гигантский, уродливый, взаимосвязанный гордиев узел. Я попытался собрать родственные идеи вместе и расположить их в логическом порядке, но полностью это невозможно. Поэтому мы будем немного скакать туда-сюда. Сегодня — не так сильно, как в двух следующих материалах. Если что-то покажется непонятным или неясным, просто подождите. Вероятно, всё сложится, когда я вывалю на вас всю кучу игрового дизайна целиком.
Чтобы эту хрень было проще ухватить, я буду в основном опираться на примеры и гипотетические ситуации. Знаю, я напрашиваюсь на неприятности: игроки так увлекаются придирками к примерам, что упускают сами идеи. Пожалуйста, не надо.
Эта хрень уже пожирает отведённый мне объём, поэтому переходим к настоящей теме сегодняшнего дня: целенаправленному проектированию.
Настоящий урок о целенаправленном проектировании начинается здесь
Проектирование Сценариев — или Проектирование Приключений, Проектирование Кампаний либо как вы ещё захотите это назвать — является Игровым Дизайном. Сами по себе настольные ролевые игры вроде Dungeons & Dragons — не игры. Это всего лишь груды разрозненных механик. Когда кто-то вроде вас приходит написать Приключение, Кампанию или что угодно ещё — и не важно, для личного пользования или публикации, создаёте ли вы прекрасный законченный документ, неразборчивые заметки либо просто пару параметров и карт, потому что уже знаете, что будете делать за столом, — написанием Сценария вы завершаете процесс Игрового Дизайна. Вы проектируете игру.
Я знаю, мы уже истоптали эту землю. Не отставайте.
Игровой Дизайн посвящён созданию приносящего удовлетворение игрового опыта. Обещаю: к концу этой серии примерно из трёх уроков вы поймёте анатомию игрового опыта, а пока просто улыбайтесь и кивайте.
Создание приносящего удовлетворение игрового опыта — это не сюжет и не моделирование мира. Игровой опыт настольных ролевых игр включает и то и другое — игнорировать их нельзя, — но они вторичны по отношению к самому игровому опыту.
Создание приносящего удовлетворение игрового опыта — это также не просто подбрасывание ситуаций игрокам ради того, чтобы посмотреть, что произойдёт. Так ролевой игровой опыт тоже отчасти складывается, но и это вторично по отношению к спроектированному вами опыту. Настоящие Проектировщики Сценариев не оставляют всё на волю случая или диких прихотей игроков-идиотов и понимают, что Агентность Игроков (Player Agency) — не про то, чтобы бросить стаю обезьян в песочницу и посмотреть, что в итоге покроется дерьмом.
Да, здесь мы тоже уже бывали. Не отключайтесь.
Следствие таково: вы — Настоящий Проектировщик Сценариев — обязаны уметь превратить что угодно в увлекательный игровой процесс, а всё, что вы включаете в игру, должно поддерживать увлекательный игровой процесс.
На этой идее и основано то, что я называю Целенаправленным Проектированием (Designing on Purpose), а вы, если хочется звучать по-научному и скучно, можете назвать Проектированием, движимым целью (Purpose-Driven Design).
Проще всего объяснить смысл на примере.
Загадка Мермана: урок целенаправленного проектирования
Итак, несколько недель назад на Discord-сервере сторонников Злого произошло вот что…
French Rice Merman — 06.06.2024, 6:06
Допустим, вы ведёте детектив, а игроки приходят к неверному выводу. Вы им об этом сообщаете?
С точки зрения игрового процесса у этого вопроса лишь один правильный ответ. Да. Да, вы обязаны сообщить игрокам, если их вывод неверен. Почему? Потому что в игре игроки должны знать, победили они или проиграли. Так уж оно устроено.
Не додумывайте лишнего. И не читайте слов, которых я не произносил. Я не говорю, что нужно останавливать действие, голосом рассказчика объявлять: «Вы правильно разгадали тайну!» — и включать на пульте победную фанфару из Final Fantasy. Не говорю, что следует прерывать обсуждение теорий словами: «Ребята, хватит, вы облаяли не ту задницу». Я лишь говорю, что после окончания игры — столкновения или приключения с загадкой — игроки должны знать, хорошо они справились или нет.
Ваша работа, госпожа или господин Настоящий Проектировщик Сценариев, — распознавать такие игровые потребности, как «игроки должны иметь возможность оценивать свои успехи, неудачи и продвижение», и строить игру так, чтобы эти потребности удовлетворялись.
В моём модуле The Fall of Silverpine Watch есть побочная детективная история об убийстве, которой игроки могут заняться. Разгадывать её необязательно, но решение облегчает получение одной из двух концовок с Успехом.
В финале модуля я велю Мастеру использовать NPC-спутницу из задания по сопровождению: пусть она спросит игроков, что, по их мнению, произошло, почему появился призрак и всё такое. Ей любопытен их ответ на загадку. Когда игроки дают Окончательный Ответ, Мастер должен выбрать одну из трёх реакций.
Если игроки в основном правы, NPC говорит: «Звучит вполне логично. Мы никогда не узнаем наверняка, что произошло, но, думаю, вы угадали».
Если игроки подобрались близко, но упустили важные детали, NPC говорит: «Не знаю… кажется, вы что-то пропустили. Не всё сходится. Жаль, мы уже никогда не узнаем: нам пора двигаться дальше».
А если игроки ошиблись полностью, NPC говорит: «То, что вы сейчас сказали, — одна из самых безумно идиотских вещей, какие я когда-либо слышала. Ни в одной части вашей бессвязной, путаной речи вы даже близко не подошли к…» Дальше вы знаете. Нет, на самом деле она этого не говорит. Я шучу. Но она действительно говорит: «Я совершенно не верю в эту теорию. Простите. Впрочем, не важно: вы убили призрака, а нам пора идти дальше».
Эта маленькая сцена существует в модуле исключительно потому, что я — сексуальный игровой гений — знаю: игроки должны уйти с пониманием, хорошо они справились или нет. Даже если загадка — всего лишь необязательное дополнительное задание. И я нашёл способ встроить это в приключение. Способ, который подходит сюжету игры — Уна от природы любопытна и добросердечна, всё приключение она задаёт вопросы, — и моделированию мира: Уна не говорит игрокам прямо, правы они или нет, а лишь оценивает, кажется ли ей их теория разумной.
Это и есть Целенаправленное Проектирование. Распознать игровую потребность и построить вокруг неё увлекательный игровой процесс. Учесть принципы Игрового Дизайна в каждом аспекте игры.
Сила цели
Эта хрень нужна не только для удовлетворения базовых потребностей игрового дизайна. Целенаправленное Проектирование позволяет настраивать игровой опыт под любые ваши цели. Например, избегать проблем или даже регулировать сложность игрового процесса.
Допустим, ваша детективная история о призраке — не просто побочная линия. Предположим, Сценарий начинается с того, что призрак умоляет персонажей игроков отомстить за его убийство, чтобы он мог уйти в иной мир. Это цель приключения, в котором можно победить или проиграть. О Целях мы ещё поговорим в другом уроке.
Как Настоящий Проектировщик Сценариев вы знаете: если не проявить осторожность, вся эта история «раскройте убийство, чтобы победить» наверняка превратится в Бесконечное Приключение (Perpetual Adventure). Что такое Бесконечное Приключение? Такое, где игроки могут повторять попытки сколько угодно. Либо в нём нет чёткого состояния поражения, либо игроки не понимают, когда проиграли.
Представьте: персонажи приходят к призраку и говорят: «Мы раскрыли убийство. Тебя убил Юстас Полиглотт из Гильдии лексикографов, и мы свели его в могилу». Но они ошибаются, и призрак не растворяется в эфире. Теперь они могут ещё раз попытаться разгадать загадку, зарезав другого подозреваемого. Потом ещё одного. И ещё. Они могут резать подозреваемых, пока наконец не доберутся до нужного.
Я нарочно довожу пример до абсурда, так что обойдёмся без комментариев. Но проблема настоящая. Бесконечные Приключения ужасны. Зная это, вы такого не создадите. Вы придумаете причину, по которой игроки не смогут разгадывать загадку снова и снова. Например, призрак должен вознестись на небеса до полуночи, иначе навеки окажется прикован к материальному плану — неслышимый и невидимый.
Так Целенаправленное Проектирование предотвращает проблему.
Теперь о регулировании сложности. Представьте, что у игроков лишь одна попытка дать ответ. В полночь они приходят к призраку и говорят: «Это сделал Юстас», после чего призрак либо возносится на небеса, либо навеки остаётся в мучениях. В таком приключении с высокими ставками, где у вас только один шанс, нет ничего изначально неправильного — некоторым игрокам такая хрень очень нравится, — но это беспощадное испытание, способное вызвать раздражение. Игроки никак не смогут оправиться от пропущенной улики, неверного вывода или нераспознанной лжи. Если добавить спутника вроде Уны, который время от времени спрашивает игроков и говорит что-нибудь вроде: «Это не очень-то сходится; вы уверены, что ничего не упустили?», у них появится право на ошибку и возможность всё переосмыслить, прежде чем они окончательно зафиксируют ответ.
Не принимайте механики за цели
Вот предостережение, которое отделит зёрна Настоящих Проектировщиков Сценариев от плевел Простых Строителей Приключений…
Настоящее Проектирование Сценариев — это поиск уникальных, творческих способов удовлетворять игровые потребности. Именно поэтому всё так трудно сделать правильно. Всегда возникает соблазн подобрать универсальные механические решения игровых проблем. Нам нужны решения, которые можно применять снова и снова при каждом появлении одной и той же проблемы. Мы называем это «Созданием Инструментов» (Building Tools).
Рассмотрим решение «Часовая Бомба» (Ticking Time Bomb). Нужны ставки, чтобы каждое решение имело значение, даже простой выбор между выламыванием двери и вскрытием замка? Нужно предотвратить Бесконечные Приключения? Просто добавляйте Часовую Бомбу в каждое приключение. Вы ведь слышали такой совет? Каждому приключению и каждому столкновению нужен таймер.
Проблемы настоящие. Часовые Бомбы — одно из решений. Но лишь одно из многих, слишком конкретное и слишком ограничивающее, чтобы работать в каждом Сценарии. При Проектировании Сценария нужно сосредоточиться на этой проблеме в этом Сценарии и найти для неё уникальное, творческое, идеально подходящее решение. Это трудно, но с практикой становится легче.
Это не значит, что Разработчики Систем (System Designers) не могут помочь. Хороший Разработчик Системы обязан определить вероятные игровые проблемы, которые возникнут из жанра игры, стиля игры и всей подобной хрени. И должен создавать инструменты, решающие эти проблемы — или помогающие Проектировщикам Сценариев их решать, — но не настолько ограниченные и жёсткие, чтобы заставлять Проектировщика втискивать в них свои замыслы. Мой Пул Напряжения (Tension Pool) и Часы Джона Харпера (Clocks) из Blades in the Dark — примеры хороших универсальных инструментов, которые решают распространённые игровые проблемы, не слишком стесняя Проектировщиков Сценариев. Сравните их с решением «Часовая Бомба» или чем-нибудь вроде Испытаний Навыков (Skill Challenges) из четвёртой редакции Dungeons & Dragons.
Заявите о своих намерениях
Сейчас я совершу гигантский логический скачок, а соединять для вас все точки мне некогда. Просто поверьте этому безумному утверждению…
Чтобы правильно Проектировать Целенаправленно, сначала определите Цель, а затем Проектируйте.
Безумие, правда?
Я ещё много раз вернусь к этой мысли на протяжении курса. Она занимает центральное место во всём этом Проектировании, движимом целью. Но сегодня я хочу представить идею Формулировки Замысла (Design Statement), особенно как первого шага в Проектировании Сценария. Прежде чем проектировать Сценарий, нужно знать, что именно вы, чёрт возьми, намерены спроектировать.
Это может казаться очевидным, но очень легко начать с крайне неполной Формулировки Замысла и даже не заметить. В следующем уроке я расскажу об Анатомии Сценария. Тогда эта хрень станет немного понятнее. А пока усвойте: садясь Проектировать Сценарий, вы как минимум должны описать Цель Сценария, его Исходную Точку, Исходы во множественном числе и хотя бы одно Испытание — обычно самое большое.
Что это значит? Что фраза «Игроки должны убить дракона» — до прискорбия неполная Формулировка Замысла. Нужно что-нибудь вроде…
Деревня находится под властью дракона. Герои прибывают туда, и жители умоляют их победить или прогнать дракона. Герои должны вступить с драконом в противоборство. Если они убьют или прогонят его, то спасут деревню. Если им это не удастся, дракон в ярости сожжёт деревню, а затем улетит искать новое поселение для террора.
Для каждого проектируемого Сценария вы обязаны обозначить, как он начинается, какова цель игроков и какими хорошими и плохими исходами всё может закончиться. В нём также должно быть хотя бы одно Испытание. А чтобы сделать всё по-настоящему правильно, больше в Формулировке Замысла ничего не нужно. Чем сильнее вы загромождаете её хренью сверх необходимого минимума, тем меньше пространства оставляете для настоящего проектирования позднее. Хорошая Формулировка Замысла содержит ровно минимум. Ни больше ни меньше.
Незаписанные формулировки замысла
Открою секрет: Формулировки Замысла нужны не только Сценариям. Они нужны всему. Каждый элемент, который вы добавляете в игру, — каждый персонаж, каждое столкновение, каждая награда, каждая сцена, каждый случайный бросок, определяющий, не наткнутся ли персонажи на опасность, пока бездельничают в сельской местности, — всё имеет Формулировку Замысла. Но это не значит, что вы будете писать по абзацу для каждого игрового элемента. Это было бы до идиотизма неэффективно. Для всей мелочёвки Формулировки Замысла останутся незаписанными.
Суть в том, что всё в игре должно находиться там не просто так. Если я ткну пальцем в столкновение с гоблинами в комнате 14Б и спрошу: «Зачем оно здесь?», вам лучше иметь ответ. То же касается случайных столкновений в лесу или городской сцены между двумя вылазками в подземелье.
А значит, отныне, прежде чем добавить в игру что угодно — и я имею в виду вообще, мать его, что угодно, — остановитесь и спросите себя: «Погодите, зачем я вообще это делаю?»
А теперь та часть, от которой у вас сломается мозг…
Игровой дизайн превыше всего — не игровой дизайн прежде всего
Позвольте спросить: почему вы пишете именно то приключение с драконом? Можно написать какое угодно. Почему вы выбрали убийство дракона?
А что насчёт постоялого двора в деревне? Того самого, где дородная хозяйка потеряла сыновей на войне и потому опекает гостей с милой, но невыносимо приторной заботой? Зачем вы её туда поместили? Зачем вообще нужен постоялый двор? И почему им заведует заботливая бабушка?
У каждого вашего решения всегда есть причина. Люди часто проживают дни, делая выбор и толком не понимая зачем. Многие пожмут плечами: «Не знаю. Просто захотелось приключение с драконом?» Или: «Наверное, мне показалось, что из неё выйдет забавный персонаж». Это нормальные ответы. Они относятся к особому виду ответов, который я называю Опорной Целью (Tentpole Purpose).
Я учил вас, что игровой дизайн должен править всем, верно? Но это не значит, что игровой дизайн всегда идёт первым. Это лишь значит, что игровой дизайн важнее всего. Было бы нелепо утверждать, будто каждый Сценарий нужно выбирать исходя из потребностей игры. Игре безразлично, посвящена ли она убийству дракона или расследованию убийства. Как правило. Иногда не безразлично. До этого я ещё доберусь.
В игру можно добавлять что-нибудь по множеству причин. Например, я упоминал Опорные Элементы (Tentpole Elements). Опоры — это элементы, которые вы хотите включить просто потому, что хотите их включить. Часто это центральные элементы, которые кажутся вам классными и вокруг которых хочется построить Кампанию, Приключение или Столкновение: конкретное чудовище, конкретное место, что угодно. Они называются Опорами, потому что обычно это те самые вспышки вдохновения, которые зажигают в вас желание построить игру.
Иногда, однако, придётся строить игру вокруг конкретной Цели. Если ваша кампания посвящена убийству архидьявола Бизлибаба, возможно, понадобится приключение, в котором игроки добудут металл для ковки великого меча Дьяволоубийцы. А если вы создаёте приключение-ограбление, может понадобиться Столкновение о проникновении через чёрный ход баронского поместья. Цели могут быть даже очень абстрактными. Возможно, вы хотите провести приключение, где герои заслуживают уважение жителей королевства. Или приключение об убийстве здоровенного босса. Доброе старое задание «убей кого-нибудь».
И вот здесь, к слову, я предостерегаю: не тратьте ни единой йоты внимания на классификацию целей. Некоторые из вас — я знаю вас по именам — просто не способны не раскладывать по категориям каждую чёртову вещь. И уже пытаются выяснить разницу между созданием приключения вокруг Цели убить босса и Опоры в виде убийства дракона. Не переживайте. Разница есть. Но она не имеет значения.
Иногда у вас будут конкретные Повествовательные Цели или Цели Фантазии (Narrative or Fantasy Purposes). Возможно, нужно строить игру вокруг темы сюжета или его развития: например, вы хотите приключение, подчёркивающее порочную природу сеттинга, либо приключение, раскрывающее мотивы злодея. Или вам кажется, что вашему миру чего-то не хватает. Чёрт, почти вся хрень, которую вы расставляете на карте города, нужна для сохранения Фантазии. В деревне ведь должен быть мясник, верно?
А иногда вами действительно будет двигать какая-нибудь Игровая Цель (Gameplay Purpose). Возможно, вы хотите строить приключение вокруг определённого режима игры — например, Исследования — или конкретной Игровой Потребности: скажем, NPC, с которым игроки могут сверить ответ, чтобы не оказаться с единственной попыткой разгадать загадку и без возможности оправиться от ошибки. Продвигаясь по курсу, вы будете всё лучше разбираться во всей этой хрени про Игровые Цели. Это важно. Важнее всего. Но это не значит, что они всегда идут первыми.
Любая цель допустима, но игровой дизайн правит всем
Вы можете добавить любой элемент в любую игру по любой причине. И для элементов, добавленных ради Повествовательных Целей и Целей Фантазии, на самом деле существуют хорошие игровые обоснования. Я дам их через урок или два. Но всё добавленное должно ещё и приносить пользу с точки зрения игрового процесса. И я не о поддельном интернет-добре и морали. «Это не делает игру хуже» не считается. Хорошо — не просто неплохо. Всё добавленное в игру должно улучшать игровой опыт.
В следующие много месяцев я ещё не раз объясню, что это значит.
Вот почему Проектирование Сценария начинается с Формулировки Замысла. Не важно, почему вы создаёте именно этот Сценарий, но вы обязаны удостовериться, что сможете превратить его в увлекательный игровой опыт. Формулировка Замысла — своего рода проверка на вшивость.
Даже при работе с меньшими элементами важно всё равно пройти проверку на улучшение игрового опыта. Поэтому каждый раз, задав себе вопрос «Зачем я это делаю?», следом спрашивайте: «Получится ли из этого хороший игровой процесс?»
Игровой дизайн превыше всего
Целенаправленное Проектирование — это понимание того, зачем вы делаете всякую хрень, и уверенность, что всё сделанное улучшает игровой опыт. А ещё — способность замечать пробелы в игровом опыте и заполнять их. Понять, что игрокам нужно знать, победили они или проиграли, а значит, в детективный Сценарий необходимо встроить систему оценки. Понять, что какой бы открытой ни была игра с открытым миром, вам всё равно нужно ясно обозначать цели игроков и направлять их к достижению этих целей.
Вы будете добавлять в игры хрень исключительно ради Игровых Целей. Вам когда-нибудь говорили, будто каждое Столкновение должно продвигать сюжет? Полная чушь. Столкновения могут служить множеству целей. Продвигать сюжет они не обязаны. Но обязаны служить Игровой Цели.
Нойте и жалуйтесь сколько угодно, но если вы ведёте современную Dungeons & Dragons, вам придётся время от времени расходовать ресурсы игроков. Иногда для этого нужно добавлять Столкновения просто ради Столкновений. А если делать этого не хочется, вы обязаны распознать оставленную неудовлетворённой Игровую Потребность и найти другой способ её удовлетворить. Нельзя просто пожать плечами и заявить: «Я могу вести как хочу; мне плевать на дни приключений». То есть заявить можно, но на самом деле вы лишь говорите: «Мне лень вести хорошую игру». Тоже мне повод для гордости.
Экономия и элегантность
Лучшие игровые решения — как и лучшие игровые элементы вообще — делают много всего одновременно. Уна из The Fall of Silverpine Watch выставляет игрокам итоговую оценку за умение разгадывать тайны, но этим её роль не исчерпывается. Она участвует в Цели приключения, предоставляет Экспозицию, обучает игровым принципам и служит элементом Фантазии, с которым игроки могут взаимодействовать в мире. Для крошечной немолодой полурослицы она тащит на себе очень многое.
Когда Настоящие Проектировщики Сценариев находят неудовлетворённую игровую потребность — например, «у меня есть загадка, но игроки никак не могут проверить свой ответ», — большинство сначала ищет среди уже существующих игровых элементов тот, который сможет взять эту нагрузку на себя. А закончив Проектирование Сценария, они обычно ищут игровые элементы, которые можно объединить. Потому что в целом Сценарий с меньшим количеством многоцелевых элементов лучше Сценария с множеством одноцелевых. Не нужно изобретать нового NPC, чтобы дать игрокам улику, если с этим прекрасно справится городской мясник.
Конечно, так получается не всегда. И здесь можно перестараться. Один житель деревни способен выдавать задания, давать экспозицию, оценивать результаты, проводить обучение и продавать припасы, но тогда игровой опыт исследования деревни пострадает.
А если я не могу?
Проектирование Сценариев — это выявление игровых потребностей и поиск творческих способов их удовлетворить, верно? Одно из примерно семнадцати моих определений Проектирования Сценариев. Но что, если вы не можете? Что, если, как ни старайтесь, не удаётся найти хороший и разумный способ позволить игрокам проверить ответ на загадку, прежде чем окончательно его зафиксировать? Или хотя бы сообщить им, победили они в приключении или проиграли? Что тогда делать?
Выбрасывайте грёбаное приключение и проектируйте другое, потому что написанное вами не работает. Вот что делать.
Если в игровом процессе дыра и вы не можете её залатать, у вас плохая игра. Предайте её огню и начните заново. Стыдиться здесь нечего. Такое случается. Если вы столкнулись с неразрешимой проблемой, это не делает вас плохим Проектировщиком Сценариев. Подобное бывает со всеми. Кроме меня. Я никогда не выбрасывал неработоспособный Сценарий, ибо совершенен. Но вы не я. Вам приходится соответствовать разумным стандартам обычного, заурядного, смертного проектировщика. Простите.
Значит ли это, что некоторые приключения просто невозможно построить? Да. Именно так. Многое просто не работает за столом. Например, лабиринты в настольных ролевых играх — полный отстой. Я не утверждаю, что ни один проектировщик не сумеет заставить их работать, но весь фокус именно в поиске способа. Если он существует, я его не нашёл.
Точно так же, если игровой элемент не служит Игровой Цели в вашем Сценарии, вы обязаны его вырезать. Может казаться, что он ничему не вредит, но это не так. Помните: какая-то хрень может существовать в мире, не попадая в кадр и не расходуя игровое время. Деревням нужны мясники, но игре не обязательно нужно столкновение с мясником. По диким землям бродят могущественные драконы, но это не значит, что игроки обязаны с ними встретиться.
Но признайте: здесь действует двойной стандарт. Если ваше Опорное Столкновение не работает с точки зрения игрового процесса и исправить его не получается, оно должно уйти. Возможно, придётся переписать весь Сценарий. Но если столкновение существует исключительно ради Игровой Цели — например, бой с крысами, потому что игре нужен бой, а персонажи низкого уровня, — оно может остаться. Всё в порядке. Оно улучшает игру независимо от того, насколько ориентированным на Сюжет или Моделирование вы себя считаете.
Подведём итоги…
Я знаю, что немного скакал туда-сюда, торопился с некоторыми вещами и многое оставил для следующего и дальнейших уроков, поэтому изо всех сил постараюсь аккуратно завершить сегодняшний урок красивым бантиком.
Проектирование Сценариев означает понимание того, что создаёт хороший игровой опыт, и поиск умных, творческих способов его предоставить. Начинается всё с понимания того, что вы хотите добавить в игру и зачем. И требует признать, что всё добавленное должно улучшать игровой опыт.
Поэтому каждый проект важно начинать с определения цели проектирования, а затем описывать игровой опыт, который вы намерены вокруг неё построить. Как минимум эта Формулировка Замысла должна включать исходную точку Сценария, цели игроков, различные возможные исходы и хотя бы одно испытание, которое игрокам предстоит преодолеть. Требования одинаковы и для целой кампании, и для отдельного столкновения. Вы не всегда будете записывать Формулировки Замысла, но в голове они должны существовать всегда.
Игровой опыт — единственный ограничитель вашего проекта. Всё в Сценарии должно служить Игровой Цели, даже если изначально вы добавили элемент ради другой цели. Не можете найти умный, творческий способ этого добиться — вырезайте элемент. Он должен уйти. Точно так же вы обязаны удовлетворить все игровые потребности Сценария. Не можете найти умный, творческий способ это сделать — выбрасывайте проект и создавайте другой.
Если подвести итог итогу: Проектирование Сценариев — это творческое решение задач. Поиск умных, творческих, уникальных способов превратить хрень, о которой вы хотите делать игры, в по-настоящему хорошие игры, а также умных, творческих, уникальных способов закрыть пробелы в игровом процессе тех игр, которые вы хотите создать.
Если подвести итог итогу итога: если вы ждёте контрольного списка, формулы или пошагового руководства, вы выбрали не ту игру. Такая хрень — для Простых Строителей Приключений.
Если вам понравилась эта статья или у вас есть комментарии, присоединяйтесь к дискуссии в канале Telegram или сервере в Discord.