Обратите внимание на заголовок. Мы будем говорить о том, как писать модули. Не о том, как их разрабатывать. О тексте. Конкурс модулей от «Восточных земель» показал, что у многих возникают сложности именно с текстом.
Я не могу научить вас писать. Существует только один надёжный способ овладеть этим навыком: очень много читать и очень много писать.
Чему, однако, я могу вас научить — это некоторым схемам и приёмам, которые облегчают работу над текстом. Тому, как структурировать текст. Тому, как его оформлять.
Речь пойдёт о location-based модулях, то есть таких, которые составлены главным образом через описание локаций и их содержимого (например, любое классическое подземелье с описанием отдельных комнат). С моей точки зрения, хороший модуль, помимо прочих достоинств, должен служить инструкцией по проведению игры, и вместе с тем — снабжать ведущего достаточным количеством ярких образов, чтобы разбудить его фантазию. То есть, хороший модуль — это одновременно и технический, и художественный текст. Впрочем, как и большая часть ролевой литературы.
Приведённые здесь рекомендации призваны служить основой, которую вы можете изменять и адаптировать к нуждам конкретного модуля. В первую очередь, описанная структура рассчитана на модули небольшого и среднего размера. Для больших форматов вроде мегаподземелья потребуется внести в неё определённые изменения.
Здесь и далее слова «модуль» и «приключение» используются как взаимозаменяемые.
Общая структура текста
Во время знакомства с модулем читатель выстраивает мысленную модель: представление о том, как устроен модуль и из чего он состоит. Насколько легко пройдёт этот процесс, зависит от того, насколько удобно и последовательно составлен весь текст.
Я стараюсь разбивать информацию на смысловые блоки примерно в таком порядке:
1
Техническая информация. В файле с модулем должно присутствовать:
— указание на то, какая система правил используется,
— ссылка на дополнительные источники, если без них нельзя обойтись (например, на дополнения к книге правил),
— и та техническая информация, которую требует система — например, средний уровень партии.
Зачастую эти сведения можно поместить прямо на обложку. Если нет — дайте их коротким абзацем где-то в самом начале.
2
Первое, что необходимо читателю — понять, о чём вообще пойдёт речь в приключении. Хорошо, если у вас есть какая-то аннотация, однако её функция — привлечь внимание читателя к модулю, заставить его скачать и открыть файл. Для полноценного знакомства необходим более подробный рассказ.
В самое начало можно поместить авторское предисловие, особенно если оно необходимо для понимания контекста, в котором написан модуль, или способно придать ему какой-то особенный окрас. Не следует делать предисловие слишком длинным: полстраницы — достаточно. Читатель пришёл сюда не для того, чтобы поимённо знакомиться со всеми вашими тараканами.
Рассказ о сути модуля — то есть, можно сказать, экспозиция — чаще всего выглядит как история того места или того конфликта, которые будут подробно описаны далее, а чаще всего — и того, и другого, поскольку практически в любом модуле обязательно присутствует какой-то конфликт. Даже если это конфликт вида «в подземелье лежит золото, которое нужно персонажам, но чтобы до него добраться, надо преодолеть разные опасности».
Есть и другой вариант: хроника, timeline. Фактически, то же самое — только вместо художественного изложения приводится список ключевых дат с кратким описанием событий.
Другие способы рассказать о сути приключения менее универсальны, и — на мой взгляд — не так полезны.
3
После экспозиции стоит переходить к информации для игроков.
Чаще всего в какой-то отдельной вводной для игроков нет необходимости — ведущий даст её сам, опираясь на экспозицию; однако бывают случаи, когда это оправдано. Как правило, необходимость в наличии вводной зависит от наличия у приключения конкретной завязки, т.е. одного-единственного повода пойти приключаться именно сюда: например, героям выдали особый квест или партия нашла уникальный предмет.
Зато дополнительная информация — список легенд или слухов, или просто та часть сведений, которая должна быть известна игрокам заранее — зачастую очень полезна и тоже размещается именно в этом блоке.
4
Кроме информации для игроков, существует общая информация для ведущего. Это сведения, которые ведущий должен знать непосредственно до того, как начнёт водить модуль. Один из основных принципов последовательного текста: общее перед частным!
В первую очередь это касается каких-то особых механик, которые используются в модуле. Например, если в приключении есть какой-то счётчик, необходимо рассказать о нём именно здесь. Сюда же — вещи вроде таблиц случайных встреч, которые также используются во всём модуле.
В некоторых случаях в этот блок может входить описание персонажей и фракций. Обычно такие компоненты приключения раскрываются через локации и таблицы случайных встреч, но в случае, когда они действуют проактивно, ведущему может быть необходимо знать о них заранее.
В принципе, общую информацию для ведущего и информацию для игроков можно менять местами. Порядок расположения этих блоков текста зависит в первую очередь от того, присутствует ли в одном из них нечто связанное с содержанием другого блока. Но! Лучше всего, если таблица случайных столкновений и другая подобная информация будет идти непосредственно перед картой и описанием локаций, и при этом — входить в общий блок сведений для ведущего. При таком расположении их будет проще всего отыскать.
5
Наконец-то настало время главного — карты. Поскольку мы говорим о location-based модулях, карта служит настоящим фундаментом вашего приключения.
Даже если вы выкладываете карту отдельным файлом в архиве (или отдельным листом вместе с брошюрой), советую вставить её ещё раз в общий текст. Причина заключается всё в том же построении мысленной модели: даже если читатель не запомнит карту с первого раза, у него появится какой-то общий образ, на который можно будет ориентироваться при знакомстве с описанием конкретных локаций. При этом карта на отдельном листе или в файле тоже полезна: с ней легко сверяться в процессе чтения.
6
Наконец, переходим к основному: описанию локаций. Локации могут быть самыми разными: комнаты подземелья, городские здания, черты местности. Грубо говоря, любая точка на карте, которой вы присвоили номер и дали отдельное описание, в нашем случае является локацией.
Если есть какие-то черты, общие для местности, которая объединяет ваши локации; для здания, подземелья, города — первым делом стоит дать их описание. Чаще всего такие черты есть: двери, высота потолка, каменная кладка, строительные материалы, архитектурный стиль… Какие из них важны для ведущего — зависит от жанра приключения, и раз уж вы взялись писать модуль, то должны в этом разбираться.
Общее перед частным.
Как должно выглядеть описание отдельной локации? Этому посвящён целый раздел ниже.
7
Однако на описании всех локаций модуль не заканчивается. Ряд сведений, которые обычно попадают в описание локации, стоит вынести отдельно — чтобы можно было сгруппировать их на сей раз по типу.
Например, если в вашем приключении множество разных монстров — стоит сделать отдельный бестиарий; множество NPC с собственными мотивами и интересами — сделать их список или даже таблицу взаимоотношений; отдельные фракции — тоже описать их здесь.
Не злоупотребляйте: эти приложения служат для удобства поиска. Нет особого смысла в бестиарии, если в вашем приключении всего три разных типа монстров; можно ограничиться указанием их характеристик в таблице случайных столкновений и тех локациях, где они расположены.
Наконец, сюда попадает всё то, чему не нашлось места в прошлых блоках. Обратите внимание: после полного описания локаций уже не должно быть необходимой для проведения модуля информации. Только дополнительные сведения и различные удобства вроде отдельного бестиария. Только в самом крайнем случае стоит лишь ссылаться на какие-то предметы из приложений вместо того, чтобы давать их описание сразу.
***
Подытожим. Общая структура location-based модуля, которую я рекомендую, имеет примерно следующий вид:
— Техническая информация, и (опционально) предисловие.
— Экспозиция (предыстория, описание конфликта).
— Информация для игроков (вводная, слухи).
— Общая информация для ведущего (особые механики, таблица столкновений, всё, что необходимо знать заранее).
— Карта.
— Описание локаций.
— Приложения.
И хотя эта схема является довольно универсальной, отступать от неё можно — если вы понимаете, зачем. Всегда задавайте себе вопрос: в каком порядке ведущему необходима информация. Ответ на него определит расположение смысловых блоков.
Описание локаций
Во время знакомства с отдельной локацией происходит то же самое, что и с целым модулем, только на другом уровне: читатель составляет мысленную модель. Мысленная модель необходима даже в том случае, если ведущий составляет конспект приключения, а не читает модуль непосредственно во время игры; она помогает определить, что необходимо выписать, а без чего можно обойтись.
Хорошо составленное описание локаций даже важнее общей структуры модуля — потому что с модулем ведущий так или иначе знакомится отдельно, а описание локаций всегда использует уже в процессе игры.
Здесь действует всё тот же принцип: общее перед частным. Однако в любой локации может располагаться огромное количество самых разнообразных вещей. В каком порядке их распределить?
Для себя я выработал следующую иерархию.
— Общее описание локации. Первым делом необходимо дать список всех важных элементов, не снабжая их подробным описанием. Важным считается общий облик локации, всё, что рассчитано на взаимодействие, и всё, что бросается в глаза. Обратите внимание: здесь обязательно должны быть упомянуты ловушки, засады, противники и прочие непосредственные угрозы! По этой же причине общее описание не может служить текстом для зачитывания вслух: оно содержит в том числе скрытую от игроков информацию.
— Поочерёдное описание перечисленных ранее компонентов. Желательно — в порядке значимости. Враги в комнате намного важнее груды гнилых мешков в углу!
Примерный порядок здесь такой: обстановка, угрозы активные (враги), угрозы пассивные (ловушки), точки интереса (алтари, фонтаны, рычаги, сундуки).
Эти два раздела составляют единый текст; общее описание идёт первым абзацем, а затем отдельными абзацами — уточняющая информация.
При этом уже после общего текста локации я выношу отдельными блоками:
— Подробное описание NPC, если требуется. Как описывать NPC, расскажет последний раздел этой статьи. Далеко не все NPC нуждаются в подробном описании. Иногда всю необходимую информацию можно уместить в общем тексте.
— Статблоки врагов. В общем тексте — внешность врагов, их тактика и прочие «описательные» детали. Характеристики лучше вынести отдельно и выделить при помощи врезки или форматирования — так их будет проще найти, и они не будут вклиниваться в текст.
— Описание волшебных предметов. Лучше всего — в отдельной врезке.
— Советы для ведущего или другие авторские заметки. Тоже в отдельной врезке.
Последовательность этих блоков может различаться в зависимости от конкретных нужд. Я расставляю приоритеты примерно в перечисленном порядке. Скорее всего, ведущему в первую очередь понадобится описание NPC и/или характеристики монстров, а затем уже всё остальное.
Используйте цветовое кодирование! Делайте разный фон для врезок с разной информацией: например, светло-зелёный для статблоков, чёрный с белым шрифтом — для описания волшебных вещей, и светло-серый — для советов и заметок. Таким образом читателю будет проще найти нужную информацию.
 |
| Кликните для увеличения |
Вы, как автор модуля, должны понимать, что именно нужно узнать ведущему в первую очередь, какие подробности важны, а какими можно пренебречь. Представьте, что ведёте игру сами и описываете локацию игрокам. А затем представьте, что вы — один из этих игроков. О чём вы спросите ведущего в первую очередь? Какие детали локации вас заинтересуют? Какие моменты можно будет безболезненно вычеркнуть?
***
Примерная структура описания локации:
ГЛАВНЫЙ ТЕКСТОВЫЙ БЛОК:
— Общее описание, где перечисляются ключевые элементы.
— Подробное поочерёдное описание каждого элемента в отдельности.
ДОПОЛНИТЕЛЬНЫЕ БЛОКИ И ВРЕЗКИ:
— Описание NPC.
— Статблоки врагов.
— Волшебные предметы.
— Любые дополнительные заметки, советы и т.д.
Описание NPC
С одной стороны, описание персонажа должно быть достаточно кратким, чтобы ведущий мог быстро его прочесть и сразу запомнить. У него просто слишком много персонажей, чтобы заучивать подробное досье и вживаться в каждый образ по методу Станиславского.
С другой стороны, описание персонажа должно быть достаточно подробным, чтобы ведущий понял, чего хочет этот NPC, какими чертами личности обладает и как будет взаимодействовать с персонажами игроков.
Таким образом, описание NPC — одна из самых сложных задач, которые ложатся на плечи автора модуля. Не могу похвастаться тем, что нашёл для неё универсальное решение, однако я выработал для себя несколько принципов, которые могут вам пригодиться.
Блок с описанием персонажа ведущего выглядит примерно так:
— Общее описание NPC. Внешность, род занятий, характер, манеризмы. Не делайте его слишком длинным. Хороший автор способен передать суть персонажа при помощи пары строчек. Подхватить и развить предоставленный образ — дело ведущего.
Как добиться такой краткости? Используйте клише и стереотипы. Одного слова «дварф» достаточно, чтобы вызвать целую цепочку ассоциаций. Добавьте к нему пару ярких мазков: допустим, у нас не просто дварф, а любвеобильный пошляк-дварф. С таким образом легко работать. А вот подробное досье только помешает быстро вычленить ключевые черты характера.
— Приветствие (опционально, в редких случаях). Я заметил, что многие ведущие теряются, когда нужно начать диалог от лица того или иного NPC. По большей части, это касается OSR и встреч с персонажами в подземельях. Можно включить в описание фразу, с которой персонаж скорее всего начнёт диалог. Стоит только заметить, что не всегда это возможно — начало диалога может отличаться в зависимости от обстоятельств. Диалога вообще может не быть!
Если у вас не получается обойтись одним приветствием, и вы хотите перечислить в тексте сразу несколько… Не надо. Ведущему придётся прочесть их и отсеять неподходящие, а это — лишняя когнитивная нагрузка. Овчинка не стоит выделки. Можете дать одну-единственную фразу — отлично. Не выходит — значит, не надо.
Разумеется, подобная фраза не должна сводиться к простому «Привет!». Как минимум, она должна давать зацепку для продолжения разговора. В моём «Зуате» древняя ворона спрашивает: «Что вы делаете в моём гнезде, смертные людишки?». Хотя вопрос риторический, игроки могут начать с ответа на него — или задать встречный вопрос. Уже намного лучше, чем «Здрасьте».
И, конечно, далеко не каждому персонажу это вообще нужно — только тем, кто действительно может создать какие-то затруднения.
— Взаимодействие. Описание того, КАК персонаж может взаимодействовать с игроками; что может им предложить, что ответит на их просьбы, как отреагирует на определённые поступки. Эти вещи контекстозависимы и чаще всего связаны с другими компонентами модуля; другими персонажами, предметами и локациями.
Я не случайно назвал категорию «Взаимодействие». Думайте в первую очередь о том, что захочет NPC от игровых персонажей и что захотят персонажи игроков от него. Какую информацию сможет сообщить. Представьте, что пишете инструкцию по обращению с NPC.
Лучше всего подавать такую инструкцию маркированным списком; один пункт — одна особенность или один факт. В этом случае краткость — сестра таланта; хотя очень легко расписать взаимодействие с NPC на двадцать-тридцать пунктов, но ведущий просто не сумеет удержать всё это в голове. Беспощадно сокращайте список, оставляя лишь самое главное.
— Игровая статистика. Здесь всё понятно — характеристики, способности и вещи NPC.
 |
| Пример описания локации с ключевым NPC из моего модуля «Песни мёртвых рыб». Такой объём — уже достаточно много; только важные персонажи заслуживают такого количества текста. Кликните по изображению, чтобы увеличить. |
Быстрая схема описания NPC:
— Общее описание. Простой текст.
— Приветствие (опционально).
— Взаимодействие. Маркированный список.
— Игровые характеристики. Статблок.
***
Другие компоненты модуля тоже могут содержать черты, служащие для описания персонажа. Локация, в которой располагается NPC, способна многое о нём рассказать; это может быть ситуация, в которой очутился персонаж, а может быть его жилище.
Однако в первую очередь такая характеристика — через окружение или через связи — служит для придания образу NPC выпуклости. Всю «техническую» информацию, инструкцию, ведущий должен получить в одном месте. Согласитесь, достаточно неудобно, когда описание внешности и характера персонажа располагается на в одном разделе, а просьба, которая есть у него к героям — через десять страниц в другом.
Мы же не сюжеты пишем, в конце концов…
Заключение
Я большой противник построения текста по одинаковому шаблону. Гибкость — большое преимущество для любого автора, которое позволяет справляться с самыми сложными задачами.
Поэтому воспринимайте это руководство не как высеченные в граните правила, а как набор рекомендаций — или хотя бы повод задуматься о том, как выстраивать информационную иерархию в игровых материалах.
За рамками статьи осталось множество наблюдений — по большей части, о том, как писать НЕ НАДО. Не уверен, что смогу собрать их в какую-то стройную систему. В любом случае, когда-нибудь будет повод написать продолжение.
***
Эта статья написана при поддержке моих патронов: Vladislav Petrov, Anton Belov, Anton Palikhov, Dmitrii Tretiakov, AndyTheMessengerRobot, Olga Shott, Дмитрий Новиков, Wolfus, Ariwch, Андрей Кириллкин, MagaLodonov, Anonim, Evgeny Ledovskikh, Глеб Гончаренко, Sergey Pomerantsev.
Немає коментарів:
Дописати коментар