Существует много программ для написания сценариев и много поводов, чтобы написать свой сценарий. Но, как и все рабочие инструменты, сценарный софт адаптируется под требования предметной области. По этой причине программа для разработки сценария кино не приспособлена для написания сценария компьютерной игры и наоборот. Моя область ещё более специфична — я разработал программу НИМС (набор инструментов мастера-сюжетника) для создания сценариев ролевых игр живого действия (далее РИ).

Блиц вопросы:

Оно используется? Да, проекту уже два года. За это время на НИМСе сделано больше 20 игр.
Оно платно? Бесплатно — donationware.

В этом посте я расскажу о видах сценарных задач, о специфике написания сценариев для РИ, что умеет НИМС и об особенностях его реализации.

На картинке социальная сеть по сюжетам РИ «Порт-Артур», МГ S&M (кликабельно).

Дисклеймер 1: настольные ролевые игры это самостоятельный вид игр и их я буду упоминать как НРИ.

Классификация задач по написанию сценариев

Много веков сценарий как явление принадлежал исключительно сцене. В конце 19 века появился кинематограф, а в конце 20 — многообразные игры (компьютерные, настольные, живого действия и пр.) И везде есть сценарии. С художественной точки зрения они схожи и подчиняются единым законам сценаристики. Но с точки зрения формы представления информации каждая область применения сценариев ставит свои задачи. Давайте попробуем разобраться в этом.

Задачи по написанию сценариев можно разделить по наличию/отсутствию интерактива со зрителем/пользователем. Кино, сериалы, книги, театр требуют безынтерактивного сценария. Соответственно, зритель никак не может повлиять на ход повествования и в итоге имеется лишь вариант развития событий. В противоположность им существуют интерактивные сценарии, предполагающие влияние зрителя. Это сценарии всевозможных игр.

Интерактивные сценарии можно разделить на закрытые и открытые. Закрытые сценарии требуют описания всех возможных вариантов развития истории. Например, сценарии для компьютерных игр и ролевых книг-игр.

Открытые интерактивные сценарии, в свою очередь, можно условно разделить по степени мастерозависимости. В настольных ролевых играх, например D&D, все действия игроков доводятся до мастера и он ведёт повествование. Эти игры полностью мастерозависимы, и игрок не может сделать ни шага без мастера.

На РИ происходит взаимодействие большого количества игроков в рамках установленных до игры правил и договорённостей. Мастерам нет необходимости следить за каждым шагом, но в их компетенции обычно остаётся разрешение спорных вопросов и латание ошибок правил в процессе игры. Ещё раз подчеркну, что игроки взаимодействуют друг с другом автономно, без вмешательства мастера.

Дисклеймер 2: описанное здесь не догма, скорее типичный вариант, НРИ бывают автономными, РИ бывают авторозависмыми и ещё полный спектр промежуточных вариантов.

Сценарии на ролевых играх живого действия

Разработка РИ имеет определённые требования. В процессе разработки создается модель мира, который населяется персонажами, и прописываются конфликты. Часто для игры необходимо придумать десятки активных персонажей и десятки открытых историй, имеющих способы разрешения.

Перед игрой игроку выдают вводную, описывающую положение его персонажа: предыстория, родственники, друзья, враги, имущество, конфликты, позиции фракций по ключевым вопросам и т.д. Обобщая, во вводную можно поместить любую информацию, которая «может сыграть».

И ещё один дисклеймер: описанное здесь тоже не догма. Есть игры вообще без вводных, или у части игроков вводные есть, а у части нет. Игрок может увидеть свою вводную непосредственно на игре, а может принять участие в её разработке за несколько месяцев до игры с указанием, во что он хочет поиграть и с кем.

Значительную часть вводных составляет предыстория, призванная ответить на вопросы «Почему ...?»: «Почему я ненавижу короля?», «Почему наши дома враждуют?», «Почему нам важно, чтобы ритуал прошёл хорошо?»

Каждый игрок должен получить свою порцию информации и оперировать ею на игре. Бич написания вводных это несостыковки. Любое событие из предыстории пересказывается многократно и с разными акцентами, потому что каждый участник видит ситуацию по-своему. Мало того, что каждый факт необходимо расписать в нескольких вариантах, но и в случае каких-то изменений, все эти изменения необходимо продублировать в каждом из вариантов. Например, если в каком-то эпизоде было задействовано 5 персонажей, то в случае малейшего изменения в этом эпизоде необходимо внести 5 правок, а не одну. Такая ситуация приводит к большому количеству несостыковок.

Проект НИМС предназначен для разработки сценариев РИ, предполагающих наличие множества историй с большим количеством участников. С его помощью информация распределяется между игроками, а процесс написания текстов сопровождается механизмами контроля для устранения несостыковок и выявления «забытых» линий.

Процесс написания вводных

Условие задачи: есть история, в которой задействовано множество персонажей. Необходимо предоставить каждому персонажу ту часть истории, которая ему известна.

Можно решать эту задачу в лоб: Фродо, твоя предыстория такая, Гэндальф, твоя предыстория такая. Проблема, с которой мы столкнёмся — рассинхронизация информации. Например, мы напишем во вводной Фродо «Громко свисти, если увидишь орков». А всем остальным членам Братства кольца забудем это написать, и они не будут знать, что значит свист Фродо. Ещё «лучше», если мы про «свист Фродо» напишем только половине Братства кольца.

Эту проблему можно решить, если ввести ещё один текст — текст оригинала истории, на основе которого мы будем писать адаптированные тексты или тексты-адаптации для каждого персонажа. В тексте оригинала будет указано «Перед тем, как отправляться в путь, Братство кольца договорилось, что при виде орков Фродо будет свистеть». У Фродо будет: «Мы договорились, что при виде орков я буду свистеть». У всех остальных: «Услышав свист Фродо, я бегу его спасать от орков».

Но тут есть следующая проблема. Мы прекрасно знаем, кто входит в Братство кольца. Но в другой ситуации мы можем не знать всех, кто присутствовал в событии. Пример такой ситуации: совет, на котором решали, что делать с кольцом. Мы точно знаем, что там собралось всё Братство Кольца, Элронд и вполне мог быть кто-то ещё (даже если это противоречит первоисточнику). Если на этом совете было принято решение, которое необходимо зафиксировать во вводных, то мы получаем неопределенность — кто еще из 140 персонажей нашей игры был на совете и что-то знает?

Для решения этой задачи мы разбиваем историю на события, где событие это единство времени, места и персонажей. Фиксируем событие: «Совет кольца, время: 3018/10/25 12:00, участники:..., описание события:...» Теперь мы точно знаем, кто был участником события. У каждого участника есть своё видение события, которое мы описываем в адаптации события. Адаптация всей истории для выбранного персонажа состоит из всех адаптаций событий с этим персонажем.

Финальный этап: все адаптации написаны, мы группируем их в текстовые файлы по персонажу. Одной картинкой это выглядит так:

В итоге, мы получаем структурированные данные, которые вдобавок пригодны для визуализации:

1. Мы можем сформировать хронологию событий, как по каждой истории, так и индивидуально для каждого персонажа.
2. Социальная сеть в социологическом смысле. У нас есть множество персонажей, и их факт нахождения в одном событии мы можем интерпретировать как социальную связь между каждым из участников события. Как минимум, они могли видеть друг друга, но в большинстве случаев персонажи активно взаимодействуют между собой.

Пример хронологии событий базы-примера по Властелину Колец (кликабельно):

Пример социальной сети с игры РИ «Mad Mad Max», Mk. Albion (кликабельно):

Отношения персонажей

Таблица отношений персонажей широко применяется в РИ и НРИ. Таблица отношений это квадратная таблица, в которой каждая строка и каждая колонка соответствует персонажу, а в ячейках таблицы мы записываем отношение персонажа А к персонажу Б. Интересный момент: персонажам не обязательно быть знакомыми между собой, чтобы иметь отношение друг к другу. Персонаж из низов может иметь какие-то счеты с боссом мафии, но сам босс мафии может быть совершенно не в курсе этого.

Досье

Досье это список фактов о персонаже. Структуру досье определяет мастер игры, так как важная информация для одной игры является не важной для другой. Например, возраст персонажа может влиять на допуск к полетам на какой-нибудь игре про космос, но во Властелине колец к возрасту нет никакой привязки и от него ничего не зависит.

Досье это, конечно, хорошо, но полезно оно не само по себе, а в сочетании с возможностью искать по нему персонажей. Например, нам в романтическую историю необходимо добавить молодого неженатого дворянина. Настроим фильтр: возраст «до 30», сословие «дворянское», семейное положение «холост», отсортировать по возрастанию возраста.

Группы персонажей

Развивая идею фильтра, мы пришли к группам персонажей. Например, у нас на игре есть группа Тамплиеры, и мы хотим предоставить историю ордена только людям из этой группы. Решение в лоб: Петя, Витя, Боря тамплиеры, мы их включаем в группу, текст для группы выводится во вводные. Потом Витя уходит в ассасины, на его место приходит Гоша, а мы вручную редактируем списки групп. Вместо этого мы можем собрать фильтр по досье: фракция тамплиеры. Только тем персонажам, которые проходят этот фильтр, будет выводиться текст для тамплиеров, и никаких проблем с ручным обновлением данных.

Карта сюжета

Карта сюжета это инструмент проработки межфракционных конфликтов. Инструмент тоже достаточно известный как в РИ так и НРИ. В качестве спецификации я использовал вот эту статью. Вкратце — есть действующие на игре группы-силы, которые как-то относятся друг к другу. Например, добрые хотят уничтожить злых, и наоборот. Есть ресурсы, которые пассивны, но входят в сферу интересов групп. Например, если считать кольцо Всевластья ресурсом, то добрые хотят его уничтожить, злые хотят его захватить, нейтральные хотят его эффективно использовать. На основе карты сюжета мы можем спланировать список конфликтов, которые будут решаться по игре и сделать для них сюжетную подводку.

О реализации

Изначальное требование к системе это автономность. Я хотел, чтобы у мастера ролевой игры была возможность работать с ноутбука там, где плохо со связью. Например, на фудкорте или даже на полигоне. Именно поэтому НИМС сделан как приложение, а не как сервис (большинство систем для РИ со схожим функционалом являются сервисами).

Второе требование — это отсутствие исполняемых файлов и инсталляторов. Потому что они засоряют систему, потому что их выкладывают на файлопомойки с возможностью доустановить всякий ненужный мусор и т.д.

Для того, чтобы это провернуть, необходима виртуальная машина на компьютере пользователя, и она есть — это браузер. Собственно, так НИМС и реализован — архив с автономной веб-страницей, которая открывается в браузере.

Это было моё первое приложение написанное полностью на JavaScript, поэтому я старался свести к минимуму использование библиотек и фреймворков.

Реализация в виде автономной веб-страницы имеет следующие неприятные побочные эффекты:

• нет доступа к файловой системе, поэтому невозможно сделать кнопку «Сохранить» и чтобы все незаметно сохранилось в файл. Вместо этого со страницы скачивается текущая версия базы. Аналогично, при открытии системы показывается не последняя база, а база-пример. Необходимо загружать последнюю рабочую базу в начале работы вручную. Да, это неудобно, но риск потерять данные из-за сбоя localstorage и аналогов ещё хуже.
• невозможность использовать файлы с «нестандартными расширениями» (привет Chrome). Например, нельзя в папку страницы положить docx и по необходимости загрузить его через GET запрос. Аналогично не работает библиотека l20n с её ftl файлами. С сервера — пожалуйста. Первую проблему я решил кодированием docx в base64 и сохранением в js файл. Вторую проблему я решил путём создания велосипеда.
• невозможность вызова исполняемых программ, даже когда очень хочется. Тут необходимо отметить подсистему формирования вводных — вот мы всё написали, нужно это сохранить в файл и отправить игроку по почте или распечатать. Первичное требование было «сохранить вводную в docx» (это не я придумал). Я реализовал это с помощью docxtemplater. Он позволяет генерировать файлы docx по шаблону. Именно для этого мне нужно было по запросу подгружать docx шаблон в страницу в предыдущем пункте.

И, кстати, отсутствие исполняемых файлов и возможный оффлайн приводят к тому, что я не могу использовать внешнюю СУБД. Только что-нибудь в браузере in-memory. Я выбрал путь велосипеда и сделал хранение данных в виде JSON объекта с валидацией JSON Schema при загрузке. JSON объект хранится в обычном текстовом файле, именуемом «базой».

Во всём остальном это обычная SPA.

Вскоре после релиза мне сообщили о проблеме: игр, над которыми работает строго один мастер, меньшинство. Поэтому возможность совместной работы над игрой несколькими мастерами является вопросом жизни и смерти проекта.

Проблема: у нас есть рабочее ядро, но заточенное под автономную работу. Как обеспечить совместную работу нескольких мастеров?

Решение: переделываем ядро для работы с базой под асинхронный режим работы и модифицируем таким образом, чтобы оно могло запускаться на node.js. Оффлайн режим работает как раньше. Серверный режим раздаёт веб-страницу, а все обращения к ядру преобразуются в Remote Procedure Call для исполнения запросов на сервере. То, что раньше было интерфейсом ядра, становится интерфейсом API. Попутно серверный режим расширяет API функциями управления пользователями и разграничения доступа.

В результате и оффлайн и серверное решение используют одно и то же ядро. Схематично это выглядит так:

Материалы

Для пользователей мы подготовили множество материалов:

• Онлайн презентация — краткое описание базовых концепций, для пользователей, не знакомых с НИМС.
• Скринкасты — видеозаписи, где я рассказываю о том, как НИМСом пользоваться.
• Документация — полное описание используемых концепций и реализованного функционала.
• Онлайн демо — выложенная в интернет оффлайн версия. Идёт в комплекте с базой-примером, которая иллюстрирует если не все, то большинство реализованных фич.

Оффлайн версию можно скачать здесь. Проверялась работа в Chrome и Firefox. Должно работать независимо от ОС, но специально это не проверялось.

Что касается исходного кода — проект разделён на клиент, сервер и текстовые ресурсы:

• Клиент включает в себя весь сценарный функционал.
• Текстовые ресурсы это база-пример, презентация, документация, шаблоны выгрузки.
• Сервер это расширение ядра клиента для работы с правами и организации удаленного доступа нескольких пользователей. Эта часть проекта в текущий момент не обнародована.

Заключение

Проект НИМС даёт возможность посмотреть на сценаристику с другой стороны. Сценарии для РИ это незавершённые истории и нет необходимости формировать из них последовательное повествование для зрителя/читателя. В РИ каждый игрок получает свою часть информации и действует исходя из этого, так же как и в реальности. В этом случае задача сценариста состоит не только в том, чтобы рассказать историю, но ещё и распределить историю между действующими лицами.