Концепции

История, персонаж, адаптация, вводная

НИМС строится вокруг трех основных сущностей: история, персонаж и событие.

Персонаж - это некоторый субъект в мире игры.

Мы сознательно выделяем понятие игрок в отдельную сущность, так как считаем, что на этапе работы над вводными у мастера должна быть возможность абстрагироваться от конкретных игроков.

История - это законченная сюжетная единица. В истории принимают участие сколько-то персонажей.

История состоит из событий. У каждого события указано время наступления события и список персонажей, принявших участие в событии. Событие это единство места, времени и персонажей, соответствует явлению в классической драматургии.

Примечание

Пример

История: Колобок

Персонажи: бабка, дед, Колобок, заяц, медведь, волк, лиса

Событие 1: бабка с дедом испекли Колобка. Участники: бабка, дед, Колобок

...

Событие х: Колобок встретил волка, спел песенку и убежал. Участники: Колобок, волк

...

Каждый персонаж, участвовавший в событии имеет своё видение произошедшего. Адаптацией называется видение персонажа - участника события.

Примечание

Пример

Событие: Колобок встретил волка

Адаптация Колобка: Катился я по лесу и вдруг увидел перед собой что-то большое, серое и зубатое. Оно меня уже заметило и мне ничего не оставалось как подкатиться поближе. ...

Адаптация волка: Я увидел на дорожке странный предмет, который показался мне съедобным. ...

Вводная это документ, выдаваемый игроку, содержащий сведения о персонаже для погружения в мир ролевой игры. Цикл преобразования данных история-событие-адаптация-вводные проиллюстрирован на рисунке.

_images/nims-main.jpg

Рис. 1 Схема работы НИМС

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

Досье персонажа и досье игрока

Досье персонажа - набор фактов о персонаже, имеющих существенное значение в процессе подготовки к РИ.

Досье игрока - набор фактов об игроке, имеющих существенное значение в процессе подготовки к РИ.

Для всех персонажей можно (и нужно) завести досье. Досье нужно для указания данных персонажа, важных в рамках вашего мира, как то: пол, семья, возраст, способности, профессии и т.д. Без досье мы знаем о персонаже только его имя. Структура досье описывается на подвкладке Конструктор досье. На этой подвкладке вы определяете какие поля досье вам нужны, а потом заполняете их для каждого персонажа.

Аналогично выполняется работа с досье игрока.

Типы полей:

Текст - поле для хранения текстовых данных. Пример: биография персонажа.

Строка - поле хранит одну строку. Пример: личный девиз.

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

Число - числовое значение. Пример: возраст персонажа.

Галочка - поле хранит значение да/нет. Пример: является ли персонаж хакером.

Множественный выбор - поле содержащее перечисление значений из которых может быть выбрано несколько или ни одного. Значения множественного выбора указываются через запятую. Пример: список заклинаний, которые знает персонажа - файрбол, волшебная стрела, замедление, ускорение.

Досье играет очень большую роль. На его основе работают Фильтр и Группы. Так же информация из досье может быть выведена во вводные.

Примечание

Пример

Можно указать в досье бабки, что она пекарь 1го разряда и ей 65 лет.

Инвентарь персонажа

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

Примечание

Пример

В инвентаре Фродо на начало игры указывается кольцо всевластия.

Отношения

Отношения это информация как персонажи относятся друг к другу. Реализовано с помощью текстового описания. Персонаж может иметь отношение как к знакомым персонажам, так и к не знакомцам. Отношение может быть как однонаправленным, так и взаимным.

Примечание

Пример

Рядовой налётчик банды Сальери может иметь своё отношение к дону Сальери и отношение к дону Морелло по слухам от других налётчиков. Дон Сальери может знать, что у него есть такой налётчик. А дон Морелло может быть совершенно не в курсе о всех налётчиках семьи Сальери.

Хронология

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

Фильтр

Фильтр персонажей/игроков - логическое условие, определяющее правило формирования подмножества персонажей/игроков. Фильтр предназначен для поиска персонажей/игроков по досье и определения состава групп. Фильтр формируется на основе досье персонажа/игрока и на статистических данных о персонаже.

Примечание

Пример

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

Примечание

Пример

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

Подробнее про типы данных столбцов можно прочитать в разделе Досье персонажа и досье игрока.

Как выполняется фильтрация:

  1. Фильтрация строк и текстов происходит по наличию искомой строки в строке или тексте.
  2. Фильтрация по полям с единственным выбором происходит по выбору из предложенного списка значений. Можно использовать множественный выбор.
  3. Фильтрация для значений вида да/нет аналогична фильтрации по полям с единственным выбором.
  4. Фильтрация по числовым значениям требует указания числа и вида проверки: Не важно, Больше, Равно, Меньше.
  5. Фильтрация по полям с множественным выбором происходит по выбору из предложенного списка значений и вида проверки: Не важно, Включает всё, Равно, Включает любой.

Группы

Под группой мы подразумеваем некоторое количество персонажей/игроков, объединённых общим признаком. Группа может включать несколько персонажей/игроков, может быть пустой, может включать всех. Признак вхождения персонажа/игрока в группу описывается фильтром.

Примечание

Пример

В досье имеются данные о принадлежности персонажа к мафиозной семье. Мы создаем группу Семья Сальери. Фильтр этой группы “персонаж из семьи Сальери”. Аналогично создаётся группа для семьи Морелло.

Данный подход исключает ручное включение/переключение персонажа между группами. Изменяя досье персонажа вы автоматически выводите персонажа из одних групп и включаете в другие.

Примечание

Пример

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

С группой персонажа/игрока ассоциированы дополнительные данные, именуемые досье группы. Структура досье группы не редактируема и состоит из мастерского описания группы, текста для персонажа и нужно ли выводить данные о группе во вводные. Подробнее смотрите в разделе Группы.

Карта сюжета

При работе над РИ возникает необходимость в получении общей оценки ситуации. Для этого была сделана карта сюжета. Карта сюжета это схема, на которую выносятся активные группы и ресурсы и прописываются связи между ними.

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

Связи описывают конфликты и интересы групп. Связи являются направленными. Исходить связь может только из группы, а входить и в группу и в ресурс. Группы добавляются из списка существующих групп. Ресурсы заводятся прямо на карте сюжета. Карта сюжета собирается вручную. Подробнее смотрите в разделе Карта сюжета.

Примечание

Семья Сальери враждует с семьёй Морелло и наоборот.

Примечание

Семья Морелло владеет бизнесом, прикрывающим угоны автомобилей. Семья Сальери хочет забрать контроль над этим бизнесом у Морелло.

Примечание

Семья Морелло работает с бандой бутлегеров и доверяет им. Бутлегеры же в тайне сотрудничают с семьёй Сальери.

Активность персонажа

При работе над НИМС возник вопрос “А можем ли мы как-то интегрировать шестерёнку ролей?”. Как оказалось шестерёнка это отдельная сущность и к имеющимся в НИМСе данным плохо применимая. Вместо этого мы реализовали другой инструмент - отметки об активности. У каждого персонажа можно указать тип активности персонажа в истории. Мы зафиксировали следующие виды активности:

  1. Актив - персонаж мотивирован этой историей на активные действия. Пример: Фродо, Дон Кихот.
  2. Спутник - персонаж идет в след за кем-то, но ему самому цель вторична. Пример: Сэм и Санчо Панса.
  3. Защита - персонаж защищается от преследователей. Пример: шпион в облаве, убийца в детективной истории. Если их не найдут, им нечего будет делать.
  4. Пассив - персонаж, владеющий информацией или артефактами в истории, являющийся свидетелем, но не преследующий никаких целей.

Примечание

Персонаж может одновременно иметь несколько активностей в одной истории.

Примечание

Персонаж может иметь разные виды активности в разных историях.

Примечание

Пример

Дед в Колобке пассивен - он не пытается догнать и вернуть Колобка. Дед в Репке активен - он активно хочет выдернуть репку.

Графическое и статистическое отображение активностей позволит оценить степень и качество загруженности персонажа, то есть выполнить ту задачу, которую обычно решают с помощью шестеренки.

Социальная сеть

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

Поддерживаются следующие типы социальных сетей.

  1. Социальные связи - сеть связей между персонажами. Узлы: персонажи. Ребро: совместное участие персонажей в некотором событии. Если два персонажа участвовали в одном событии значит между ними сформировалась социальная связь. С одной стороны это допущение достаточно грубое, потому что не учитывает множество нюансов, но в то же время в большом количестве случаев этого достаточно. Например, группа офицеров пошла в ресторан. Все офицеры друг друга знают, все офицеры помнят о произошедшем в ресторане. Другой пример, муж вернулся из командировки, любовник прятался в шкафу, жена попросила мужа вынести мусор, пока мужа не было любовник убежал. Жена и любовник в курсе друг о друге, жена и муж в курсе друг о друге, любовник в курсе о муже, муж не в курсе о любовнике. Получается, что социальная связь муж-любовник однонаправленная, а эта информация не указывается на схеме. Указание этой информации сильно усложнит процесс разработки событий, поэтому повторюсь - в большинстве случаев факт участия персонажей в одном событии достаточен для фиксации социальной связи. Мощность связи показывает насколько сильна социальная связь между персонажами. Мощность связи определяется количеством историй в событиях которых персонажи пересекались. Например, два пассажира плыли неделю на теплоходе, взаимодействовали в 10 событиях, но только в этой истории. Мощность связи между ними 1. Два мафиози были в 4 переделках, каждая по 5 событий. Мощность связи между ними 4. Мощность связи отражена толщиной ребра.
  2. Персонаж-участие-история - сеть связей персонажей и историй. Узлы: персонажи и истории. Связь между узлами: участие персонажа в истории. Даже если вы не внесли персонажа ни в одно событие в истории, но добавили его в историю, считается, что он участник истории. Мощность узла определяется количеством персонажей в историй. Мощность узла отражена размером узла.
  3. Персонаж-активность-история - сеть связей персонажей и историй на основе данных об активности. Узлы: персонажи и истории. Связь между узлами: активность персонажа в истории (см. Активность персонажа). Например, если указано, что персонаж играет активную роль, то персонажа и историю будет соединять красная линия. Если у персонажа не проставлено никакой активности в истории, то и связи у персонажа с историей не будет.

Диаграммы и статистика

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

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

Диаграммы досье собираются на основе данных досье. С их помощью можно посмотреть соотношение блоков на игре и опять же следить за перекосами в балансе сил.

Анализ загруженности игроков

Анализируя загруженность игроков мы стремимся к тому, чтобы узнать насколько игрок загружен и впоследствии скорректировать соответствующий ему объём нагрузки. Все игроки разные, желания у них разные, возможности у них разные, возможности мастеров тоже не безграничны. Поэтому анализ загруженности весьма индивидуальный процесс и систематизировать мы его не можем, но можем высказать несколько рекомендаций.

  1. Посмотрите на общие диаграммы по базе и обратите внимание на большие отклонения. Если у персонажа в три раза больше историй, чем у остальных это должно иметь объяснение. Может он игротехник, а может информатор который всё знает, а может он Арагорн и все хотят поиграть с Арагорном, вот его и поставили во все истории. Если у персонажа очень маленькая вводная, то должна быть причина почему его так обделили. Может он с луны свалился, может он и так во всё влезет, а может про него как-то забыли и не вписали никуда.
  2. Отметьте виды активности персонажа в историях, посмотрите соответствующие статистики в фильтре и на социальной сети. Если персонаж по вашей задумке активен в 15 историях, то убедитесь, что ваш выбор осознан и вы действительно заложили такую нагрузку на игрока.
  3. Благодаря гибкой структуре досье вы можете хранить в нём произвольные данные. Например, ставить или не ставить персонажа в любовную линию, какую нагрузку нужно давать персонажу: функциональную, сюжетную, смешанную или ещё какую-то. Можно внести сюда пожелания игрока. Может он вывозит сложный косплей, поэтому его нагрузка красивая мебель. Впоследствии будет возможность сравнить желаемое с действительным и скорректировать.

База

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

Примечание

Техническая информация

База хранится в формате JSON. При загрузке базы автоматически собирается схема базы (JSON Schema) для проверки корректности информации и выполняется проверка. Если будет обнаружена ошибка, то будет показано сообщение Проверка данных выявила нарушение целостности базы, пожалуйста свяжитесь с разработчиками для устранения проблемы. Если не было ручного вмешательства в базу, значит ошибка была внесена самим НИМСом и мне как разработчику надо будет с этим разбираться. Поэтому в случае появления этого сообщения, даже если при этом у вас открывается база без видимых проблем, свяжитесь, пожалуйста, со мной!!!

Выгрузка

Выгрузка процесс формирования вводных из имеющихся данных по шаблону. Это могут быть файлы docx или файлы в текстовом формате.

Однопользовательская и многопользовательская версия НИМС

Существует две реализации НИМСа: однопользовательская и многопользовательская.

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

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

Пусть у нас есть одна база и несколько пользователей.

Проблема 1. Что делать, если пользователи почти одновременно изменили данные, и новые правки конфликтуют?

Например, два пользователя одновременно стали редактировать текст события. Первый отредактировал что хотел и перешёл на другую вкладку. И вот второй пользователь тоже отредактировал свою часть. Фактически существует три текста: как было, текст пользователя 1 и пользователя 2. Что должно получится в итоге?

Тут возможны разные стратегии. Например, первый побеждает всех, последний побеждает всех, интеллектуальное слияние (если это возможно) и др.

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

Проблема 2. У персонажей, историй и групп есть владельцы и они их правят. Но что делать с адаптациями? Адаптации являются частью истории, но закреплены за персонажем.

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

Какие бывают пользователи?

  1. Администратор - в его задачи входит создание новых пользователей и доступ к критическим действиям над базой. Администратор не всесилен, он не может просто взять и внести изменение в не принадлежащую ему сущность. Но он может переназначать права на сущности которые ему не принадлежат. Администратор так же является автором.
  2. Автор - обычный пользователь, который может править принадлежащие ему сущности.
  3. Редактор - это строго говоря не пользователь, а специальный режим работы. Если администратор назначает пользователя редактором, то пользователь получает эксклюзивный доступ ко всей базе. Он может вносить любые правки, а все остальные не могут ничего делать. При включении данного режима сущности не меняют владельцев. Это позволяет провести вычитку/чистку текста, а потом вернуть всё владельцам без лишних действий.
  4. Игрок - см. раздел Игрок

Права или кто что может?

Админ

  1. Может создавать пользователей
  2. Может удалять пользователей
  3. Не может удалить самого себя
  4. Может менять пользователям пароли
  5. Может назначать права на сущности
  6. Может отбирать права на сущности никому не передавая
  7. Может назначить/разжаловать редактора
  8. Может передать админство другому пользователя
  9. Может переключить правило назначения прав на адаптации - от истории или от персонажа
  10. Страницу Обзор и конструктор досье - редактирует только админ
  11. Может перезалить базу полностью и только он

Предупреждение

Нельзя переименовать пользователя.

Редактор

  1. Получает полный доступ ко всем сущностям. Вновь созданные объекты тоже, без владения.
  2. Назначается/разжалуется админом
  3. Редактор может самостоятельно сложить с себя полномочия
  4. Редактор может переименовывать/удалять все персонажей/истории/группы

Автор

  1. Может создавать истории, персонажей и группы (права на созданные ресурсы принадлежат создателю)
  2. Может передавать свои права другим авторам
  3. Автор не может отобрать у самого себя права никому не передав

Всем

  1. Сохранение базы в файл для автономной работы (не завершено)
  2. Экспорт вводных
  3. Редактирование отношений персонажей не ограничено владельцами
  4. Редактирование карты сюжета не ограничено

Сущности и права на них

Изначально персонажи принадлежат создателям персонажей. Только владелец персонажа может редактировать его досье.

Изначально игроки принадлежат создателям персонажей. Только владелец игрока может редактировать его досье.

Изначально истории принадлежат создателям историй. Только владелец истории может добавлять в нее новые события и персонажей (можно не своих).

Изначально группы принадлежат создателям групп. Только владелец группы может редактировать досье и фильтр группы.

Права на адаптации определяются текущим режимом - наследуются от историй или наследуются от персонажей.

Права на инвентарь наследуются от историй.

Права на сущность могут не принадлежать никому.

Рисование карты сюжета и заполнение отношений выполняется без ограничений. Любой автор в любое время может это делать. Мы решили посмотреть, что из этого получится) Если возникнут проблемы, напишите нам об этом.

Игрок

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

База заявок

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

Примечание

Пример

У нас есть игрок “Арагорн Московский”. Мы заводим соответствующего игрока. Затем создаём ему пароль. Чтобы получить доступ к досье, игрок вводит логин “Арагорн Московский” и свой пароль.

Предупреждение

Важный побочный эффект - если вы переименуете игрока, то у игрока сменится логин.

Игрок видит своё досье и досье сопоставленного персонажа не целиком, а только те элементы досье, которые доступны на чтение или изменение. И соответственно может менять только те пункты, что доступны на изменение.