Интеграция ИТ систем

Данный документ призван обобщить опыт игр Deus Ex и Магеллан по тому, как удобно и правильно интегрировать бекенд вашей игры и joinrpg. Предназначен для мастеров, у которых на игре есть некая ИТ-система, предоставляющая возможности в рамках игрового мира. В дальнейшем будем называть ее Система.

Привязка всего к персонажу

Примечание

Эти принципы мы считаем разумными для всех интеграций

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

В качестве основного ИД мы предлагаем использовать characterId в joinrpg. Это уникальный между всеми играми int32 ключ, по которому удобно доставать данные. Важно использовать идентификатор, привязанный к персонажу, а не к игроку. Таким образом, вы сможете:

  1. Выпускать мастерских NPC (персонаж есть, игрока нет)
  2. Передавать до игры персонажей от игрока игроку (слив игрока)
  3. На игре менять роль игроку (выпуск второй ролью).

Поля персонажа

Для хранения всех данных по персонажу надо использовать поля персонажа. В API это называется CharacterFields.

Обратите внимание, что дополнительные данные по полям (например, метаданные по вариантам выпадаек) можно хранить в поле ProgrammaticalValue и загрузить при помощи MetaDataApi_GetFieldsList.

Логин

В качестве логина в вашу систему рекомендуем:

  1. Реализовать поддержку логина = characterId. Это удобно для техподдержки.
  2. Использовать «красивый», игровой логин, который берется из какого-то поля персонажа, например dartvader@empire.local

Пароль

Пароль в вашу систему рекомендуем хранить в поле персонажа. Это удобно посмотреть игроку и просто загрузить в вашу систему. В joinrpg есть автогенерация паролей в виде простых цифровых PIN-кодов, задайте вопрос техподдержке как ее настроить.

«В игре»

У персонажа есть флаг «В игре» — InGame:

  • становится true, если игрок прошел регистрацию на игре;
  • становится false, если игрок был выпущен новой ролью. В идеале он мог бы становится false, если бы Система сообщала joinrpg о смерти персонажа, но такой функционал не был реализован.

Для NPC он всегда false, их надо обрабатывать отдельно (#1034)

Использование joinrpg в качестве бекенда

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

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

Заливка Excel

Примечание

Подходит только для простых ИТ-систем и маленьких игр.

Самый простой способ — написать скрипт, который обрабатывает выгрузку в Excel персонажей (не заявок!). В процессе подготовки он запускается несколько раз и тестируется, каждый раз с полной очисткой БД Системы. В момент финального парада в joinrpg.ru отклоняются заявки не заехавших и скрипт запускается последний раз.

Плюсы:

  • просто,
  • надежно.

Минусы:

  • невозможно частично переливать данные или обновлять их в реальном времени;
  • не подходит, если игра большая (формирование Excel займет определенное время).

Онлайн-импорт

Примечание

Мы рекомендуем этот вариант для сложных ИТ-систем

Создается компонент, который по определенным правилам переносит данные из joinrpg в БД Системы. При этом возникает вопрос одновременных изменений в joinrpg и в Системе, например, пусть в joinrpg указан генокод персонажа. Что, если он одновременно будет изменен мастером в joinrpg и эффектом зелья в рамках Системы? Есть различные решения этой проблемы. Самый простой — если редактируемые в joinrpg реквизиты не могут быть изменены в рамках Системы, но это подходит не для всех. На игре Deus Ex проблема мерджа решалась таким образом:

  1. До игры происходил периодический импорт из joinrpg в Систему, всех персонажей с IsActive=true, перетирая данные в системе.
  2. В момент начала игры и после нее персонажи, у которых флаг InGame принял значение true (прошли регистрацию и вышли в игру) записываются в систему ровно один раз и замораживаются там.

Онлайн-импорт должен для снижения нагрузки на Систему и joinrpg:

  1. Обращаться к joinrpg за id персонажей, которые изменились c момент последней заливки. Retry в случае падения.
  2. Ставить id в внутреннюю очередь
  3. Загружать по одному, убирая из очереди. Это можно делать в несколько потоков, но быть готовым в случае ошибки попробовать повторно после паузы.
  4. Если (1) прилетел персонаж, который уже есть в очереди на обновление, не обновлять его дважды.

Реализацию онлайн-импорта можно посмотреть тут https://github.com/sth-larp/import-server