Существует множество программ для написания сценариев и множество причин написать собственный сценарий.
Но, как и все рабочие инструменты, скриптовое программное обеспечение адаптируется к требованиям предметной области.
По этой причине программа разработки сценариев фильмов не подходит для написания сценария компьютерной игры и наоборот. Моя сфера деятельности еще более специфична — я разработал программу под названием NIMS (Storyteller's Toolkit) для создания сценариев ролевых игр с живым действием (LAR).
Блиц-вопросы: Он используется? Да, проекту уже два года.
За это время в НИМС было сделано более 20 игр.
Это платно? Бесплатное ПО.
В этом посте я расскажу о типах сценарных задач, особенностях написания сценариев для РИ, о том, что умеет НИМС, и об особенностях его реализации.
На картинке изображена социальная сеть по мотивам рассказов РИ «Порт-Артур», MG S&M (кликабельно).
Отказ от ответственности 1: настольные ролевые игры — это самостоятельный тип игр, и я буду называть их NRI.
Классификация скриптовых задач
На протяжении многих веков сценарий как явление принадлежал исключительно сцене.В конце 19 века появилось кино, а в конце 20-го - различные игры (компьютерные, настольные, живое действие и т. д.) И повсюду есть сценарии.
С художественной точки зрения они схожи и подчиняются одним и тем же законам сценарного мастерства.
Но с точки зрения формы подачи информации каждая область применения сценариев ставит свои задачи.
Давайте попробуем разобраться в этом.
Задачи по написанию сценария можно разделить по наличию/отсутствию взаимодействия со зрителем/пользователем.
Кино, сериалы, книги, театр требуют неинтерактивный сценарий .
Соответственно, зритель никак не может повлиять на ход истории и, как следствие, остается лишь вариант развития событий.
В отличие от них существуют интерактивные сценарии , предполагая влияние зрителя.
Это сценарии для всевозможных игр.
Интерактивные сценарии можно разделить на закрытые и открытые.
Закрытые сценарии требуют описания всех возможных вариантов развития истории.
Например, сценарии компьютерных игр и книги по ролевым играм.
Открытые интерактивные скрипты , в свою очередь, условно можно разделить по степени мастер-зависимости.
Например, в настольных ролевых играх.
Д&Д , все действия игроков докладывают ведущему и он ведет повествование.
Эти игры полны зависимый от хозяина , и игрок не может сделать ни шагу без мастера.
На РИ большое количество игроков взаимодействуют в рамках правил и соглашений, установленных перед игрой.
Мастерам не обязательно следить за каждым шагом, но обычно в их компетенцию входит решение спорных вопросов и исправление ошибок в правилах во время игры.
Еще раз подчеркну, что игроки взаимодействуют друг с другом.
не в сети , без вмешательства мастера.
Disclaimer 2: то, что здесь описано, не догма, а типичный вариант, NRI могут быть автономными, RI могут быть автозависимыми и полный набор промежуточных вариантов.
Сценарии для ролевых игр с живым действием.
К разработке РИ предъявляются определенные требования.
В процессе разработки создается модель мира, в котором живут персонажи, и прописываются конфликты.
Зачастую для игры необходимо придумать десятки активных персонажей и десятки открытых историй, имеющих способы разрешения.
Перед игрой игроку дается введение с описанием положения его персонажа: предыстория, родственники, друзья, враги, имущество, конфликты, позиции фракций по ключевым вопросам и т. д. Подводя итог, можно поместить любую информацию, которая «может играть» во вступительный текст. И еще одна оговорка: то, что здесь описано, тоже не является догмой.
Есть игры вообще без вступительных примечаний, либо у некоторых игроков вступительные примечания есть, а у некоторых нет. Игрок может увидеть свое введение непосредственно в игру, а может принять участие в ее разработке за несколько месяцев до игры, указав, во что он хочет играть и с кем.
Значительную часть вступления составляет предыстория, призванная ответить на вопросы «Почему.
Э»: «Почему я ненавижу короляЭ», «Почему наши дома враждуютЭ», «Почему это важноЭ» по нашему мнению, ритуал прошел хорошоЭ» Каждый игрок должен получить свою порцию информации и оперировать ею во время игры.
Бич написания вступительных заметок – нестыковки.
Любое событие из предыстории пересказывается многократно и с разными акцентами, ведь каждый участник видит ситуацию по-своему.
Мало того, что каждый факт необходимо описать в нескольких вариантах, так и в случае каких-либо изменений, все эти изменения должны быть продублированы в каждой версии.
Например, если в эпизоде было задействовано 5 персонажей, то при малейшем изменении в этом эпизоде необходимо внести 5 правок, а не одну.
Такая ситуация приводит к большому количеству несоответствий.
Проект NIMS предназначен для разработки сценариев RI, включающих несколько историй с большим количеством участников.
С его помощью информация распределяется между игроками, а процесс написания текстов сопровождается механизмами контроля для устранения несоответствий и выявления «забытых» строк.
Процесс написания вступительной заметки
Проблемное условие: имеется история, в которой задействовано множество персонажей.Необходимо дать каждому персонажу ту часть истории, которую он знает. Вы можете решить эту проблему в лоб: Фродо, твоя предыстория такая, Гэндальф, твоя предыстория такая.
Проблема, с которой мы столкнемся, — это десинхронизация информации.
Например, во введении к Фродо мы напишем: «Громко свисти, если увидишь орков».
И мы забудем написать это всем остальным членам Братства Кольца, и они не узнают, что означает свисток Фродо.
Еще «лучше», если мы напишем о «свистке Фродо» только половине Братства Кольца.
Эту проблему можно решить, если ввести еще один текст – текст оригинального рассказа, на основе которого мы напишем адаптированные тексты или тексты адаптации для каждого персонажа.
В исходном тексте будет написано: «Перед тем как отправиться в путь, Братство Кольца договорилось, что Фродо будет свистеть при виде орков».
Фродо скажет: «Мы договорились, что когда я увижу орков, я свистну».
Для всех остальных: «Услышав свист Фродо, я бегу спасать его от орков».
Но есть следующая проблема.
Мы прекрасно знаем, кто входит в Братство Кольца.
Но в другой ситуации мы можем не знать всех, кто присутствовал на мероприятии.
Пример такой ситуации: совет, на котором решали, что делать с кольцом.
Мы точно знаем, что там собралось всё Братство Кольца, Элронд, и вполне мог быть ещё кто-то (даже если это противоречит первоисточнику).
Если на этом совете было принято решение, которое нужно записать во вступительной записке, то мы получаем неопределенность – кто еще из 140 персонажей нашей игры был на совете и что-то знает? Чтобы решить эту проблему, мы разбиваем историю на события, где событие представляет собой единство времени, места и персонажей.
Записываем событие: «Совет Кольца, время: 3018/10/25 12:00, участники:.
, описание события:.
» Теперь мы точно знаем, кто был участником события.
У каждого участника свое видение мероприятия, которое мы описываем в адаптации мероприятия.
Полная адаптация истории для выбранного персонажа состоит из всех адаптаций событий с участием этого персонажа.
Завершающий этап: все адаптации написаны, группируем их в текстовые файлы по символам.
На одной картинке это выглядит так: 
В результате мы получаем структурированные данные, которые также подходят для визуализации:
- Мы можем создать хронологию событий, как для каждой истории, так и индивидуально для каждого персонажа.
- Социальная сеть в социологическом смысле.
Персонажей у нас много, и факт их пребывания в одном событии мы можем интерпретировать как социальную связь между каждым из участников события.
Как минимум, они могли видеть друг друга, но в большинстве случаев персонажи активно взаимодействуют друг с другом.
Пример социальной сети из игры РИ «Безумный Макс», Мк.
Альбион (кликабельно): 
Отношения персонажей
Диаграмма взаимоотношений персонажей широко используется в RI и NRI. Таблица отношений — это квадратная таблица, в которой каждая строка и каждый столбец соответствует персонажу, а в ячейках таблицы мы записываем отношения персонажа А к персонажу Б.Интересный момент: персонажам не обязательно знать друг друга, чтобы иметь отношения друг с другом.
У персонажа снизу могут быть какие-то счеты с боссом мафии, но сам босс мафии может об этом совершенно не подозревать.
Досье
Досье — это список фактов о персонаже.Структуру досье определяет гейм-мастер, поскольку важная информация для одной игры не важна для другой.
Например, возраст персонажа может влиять на допуск к полетам в какой-нибудь игре про космос, но во «Властелине колец» нет привязки к возрасту и от него ничего не зависит. Досье — это, конечно, хорошо, но оно полезно не само по себе, а в сочетании с возможностью поиска с его помощью персонажей.
Например, в романтическую историю нам нужно добавить молодого неженатого дворянина.
Настроим фильтр: возраст «до 30», сословие «дворянский», семейное положение «холост», отсортировать по возрастанию.
Группы персонажей
Развивая идею фильтра, мы придумали группы персонажей.Например, у нас в игре есть группа Тамплиеров, и мы хотим предоставить историю ордена только людям из этой группы.
Решение простое: Петя, Витя, Боря - тамплиеры, включаем их в группу, текст для группы отображается во вступительном тексте.
Потом Витя становится ассасином, его место занимает Гоша, и мы вручную редактируем списки групп.
Вместо этого мы можем собрать фильтр по досье: Фракция тамплиеров.
Текст для тамплиеров будет отображаться только у тех символов, которые пройдут этот фильтр, и с ручным обновлением данных проблем не возникнет.
Карта участка
Карта-сюжет — это инструмент для проработки межфракционных конфликтов.Инструмент также достаточно известен как в РИ, так и в НРИ.
Я использовал это как спецификацию статья .
Короче говоря, в игре действуют группы-силы, которые так или иначе связаны друг с другом.
Например, добрые хотят уничтожить зло, и наоборот. Есть ресурсы, которые пассивны, но попадают в сферу интересов групп.
Например, если мы считаем Кольцо Всевластия ресурсом, то добрые хотят его уничтожить, злые хотят захватить его, а нейтральные хотят эффективно использовать.
На основе карты сюжета мы можем спланировать список конфликтов, которые будут разрешены в игре, и создать для них краткое содержание сюжета.
О реализации
Первоначальное требование к системе – автономность.Мне хотелось, чтобы мастер ролевых игр мог работать с ноутбука, где плохая связь.
Например, на фуд-корте или даже на тренировочной площадке.
Именно поэтому НИМС сделан как приложение, а не как сервис (большинство систем для РИ со схожим функционалом являются сервисами).
Второе требование — отсутствие исполняемых файлов и установщиков.
Потому что они засоряют систему, потому что кладутся на файловые дампы с возможностью установки всякого ненужного мусора и т.д. Для того чтобы это сделать, нужна виртуальная машина на компьютере пользователя, и она есть – это браузер.
Собственно, так и реализован НИМС — архив с автономной веб-страницей, открывающийся в браузере.
Это было мое первое приложение, полностью написанное на JavaScript, поэтому я старался свести к минимуму использование библиотек и фреймворков.
Реализация его как отдельной веб-страницы имеет следующие неприятные побочные эффекты:
- доступа к файловой системе нет, поэтому невозможно сделать кнопку "Сохранить" и все спокойно сохранить в файл.
Вместо этого со страницы загружается текущая версия базы данных.
Аналогично при открытии системы показывается не последняя база данных, а примерная.
В начале работы необходимо вручную загрузить последнюю рабочую базу данных.
Да, это неудобно, но риск потери данных из-за сбоя localstorage и аналогов еще хуже.
- невозможность использования файлов с «нестандартными расширениями» (привет Chrome).
Например, вы не можете положить docx в папку страницы и при необходимости скачать его через GET-запрос.
Библиотека l20n с ее ftl-файлами аналогично не работает. С сервера - пожалуйста.
Я решил первую проблему, закодировав документ в base64 и сохранив его в js-файл.
Вторую проблему я решил, создав велосипед.
- невозможность вызвать исполняемые программы, даже когда очень этого хочется.
Здесь необходимо отметить подсистему генерации ввода — теперь мы все написали, нужно сохранить в файл и отправить плееру по почте или распечатать.
Основное требование было «сохранить введение в docx» (это не я придумал).
Я реализовал это с помощью docxtemplate. Он позволяет создавать файлы docx с использованием шаблона.
Именно поэтому мне понадобилось загрузить шаблон docx на страницу по запросу в предыдущем пункте.
Просто что-то в браузере в памяти.
Я выбрал велосипедный маршрут и сохранил данные в виде объекта JSON с проверкой схемы JSON при загрузке.
Объект JSON хранится в текстовом файле, называемом «базовым».
Во всем остальном это обычный СПА.
Вскоре после релиза мне сообщили о проблеме: существует меньшинство игр, над которыми работает строго один мастер.
Таким образом, возможность совместной работы нескольких мастеров игры над игрой является вопросом жизни и смерти для проекта.
Проблема: у нас есть рабочее ядро, но оно рассчитано на автономную работу.
Как обеспечить сотрудничество нескольких мастеров? Решение: переделываем ядро для работы с базой данных в асинхронном режиме работы и модифицируем его, чтобы оно могло работать на node.js. Офлайн-режим работает как и раньше.
В режиме сервера распространяется веб-страница, и все вызовы ядра преобразуются в вызовы удаленных процедур для выполнения запросов на сервере.
То, что когда-то было интерфейсом ядра, становится API. Попутно режим сервера расширяет API функциями управления пользователями и контроля доступа.
В результате и автономное, и серверное решения используют одно и то же ядро.
Схематически это выглядит так: 
Материалы
Мы подготовили множество материалов для пользователей:- Онлайн презентация — краткое описание основных понятий для пользователей, незнакомых с НИМС.
- Скринкасты — видео, где я рассказываю о том, как использовать НИМС.
- Документация — полное описание используемых концепций и реализованного функционала.
- Онлайн демо — офлайн-версия, размещенная в Интернете.
В комплекте идет примерная база, которая иллюстрирует если не все, то большинство реализованных возможностей.
Работа тестировалась в Chrome и Firefox. Должно работать независимо от ОС, но это специально не проверялось.
Что касается исходного кода, то проект разделен на клиентские, серверные и текстовые ресурсы:
- Клиент включает в себя все функциональные возможности сценария.
- Текстовые ресурсы Это примерная база, презентация, документация, шаблоны загрузки.
- Сервер представляет собой расширение клиентского ядра для работы с правами и организации удаленного доступа нескольких пользователей.
Эта часть проекта на данный момент не обнародована.
Заключение
Проект НИМС дает возможность взглянуть на сценарное мастерство под другим углом.Сценарии для РИ — это незавершенные истории и нет необходимости формировать из них последовательное повествование для зрителя/читателя.
В РИ каждый игрок получает свою порцию информации и действует на этой основе, как и в реальности.
В этом случае задача сценариста – не только рассказать историю, но и распределить ее между персонажами.
Теги: #Программное обеспечение #скрипты #написание сценариев #ролевые игры с живым действием
-
Хроматометрия
19 Oct, 24 -
Убунту. Русификация Консоли В 2016 Году
19 Oct, 24 -
Яндекс.каталог Крашится Или Взломан?
19 Oct, 24
