Интеграция ИТ систем¶
Данный документ призван обобщить опыт игр Deus Ex и Магеллан по тому, как удобно и правильно интегрировать бекенд вашей игры и joinrpg. Предназначен для мастеров, у которых на игре есть некая ИТ-система, предоставляющая возможности в рамках игрового мира. В дальнейшем будем называть ее Система.
Привязка всего к персонажу¶
Примечание
Эти принципы мы считаем разумными для всех интеграций
Источником правды о персонажах на начало игры является данные из joinrpg. Это даст мастерам возможность вести всю информацию по игре в одном месте, использовать удобные и привычные инструменты для управления.
В качестве основного ИД мы предлагаем использовать characterId
в joinrpg. Это уникальный между всеми играми int32
ключ, по которому удобно доставать данные. Важно использовать идентификатор, привязанный к персонажу, а не к игроку. Таким образом, вы сможете:
- Выпускать мастерских NPC (персонаж есть, игрока нет)
- Передавать до игры персонажей от игрока игроку (слив игрока)
- На игре менять роль игроку (выпуск второй ролью).
Поля персонажа¶
Для хранения всех данных по персонажу надо использовать поля персонажа. В API это называется CharacterFields
.
Обратите внимание, что дополнительные данные по полям (например, метаданные по вариантам выпадаек) можно хранить в поле ProgrammaticalValue
и загрузить при помощи MetaDataApi_GetFieldsList.
Логин¶
В качестве логина в вашу систему рекомендуем:
- Реализовать поддержку логина =
characterId
. Это удобно для техподдержки. - Использовать «красивый», игровой логин, который берется из какого-то поля персонажа, например
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 проблема мерджа решалась таким образом:
- До игры происходил периодический импорт из joinrpg в Систему, всех персонажей с
IsActive=true
, перетирая данные в системе. - В момент начала игры и после нее персонажи, у которых флаг
InGame
принял значениеtrue
(прошли регистрацию и вышли в игру) записываются в систему ровно один раз и замораживаются там.
Онлайн-импорт должен для снижения нагрузки на Систему и joinrpg:
- Обращаться к joinrpg за id персонажей, которые изменились c момент последней заливки. Retry в случае падения.
- Ставить id в внутреннюю очередь
- Загружать по одному, убирая из очереди. Это можно делать в несколько потоков, но быть готовым в случае ошибки попробовать повторно после паузы.
- Если (1) прилетел персонаж, который уже есть в очереди на обновление, не обновлять его дважды.
Реализацию онлайн-импорта можно посмотреть тут https://github.com/sth-larp/import-server