Интеграция ИТ систем ======================== Данный документ призван обобщить опыт игр Deus Ex и Магеллан по тому, как удобно и правильно интегрировать бекенд вашей игры и joinrpg. Предназначен для мастеров, у которых на игре есть некая ИТ-система, предоставляющая возможности в рамках игрового мира. В дальнейшем будем называть ее Система. Привязка всего к персонажу ----------------------- .. note:: Эти принципы мы считаем разумными для всех интеграций Источником правды о персонажах на начало игры является данные из joinrpg. Это даст мастерам возможность вести всю информацию по игре в одном месте, использовать удобные и привычные инструменты для управления. В качестве основного ИД мы предлагаем использовать ``characterId`` в joinrpg. Это уникальный между всеми играми ``int32`` ключ, по которому удобно доставать данные. Важно использовать идентификатор, привязанный к персонажу, а не к игроку. Таким образом, вы сможете: 1. Выпускать мастерских NPC (персонаж есть, игрока нет) 2. Передавать до игры персонажей от игрока игроку (слив игрока) 3. На игре менять роль игроку (выпуск второй ролью). Поля персонажа ----- Для хранения всех данных по персонажу надо использовать поля персонажа. В API это называется ``CharacterFields``. Обратите внимание, что дополнительные данные по полям (например, метаданные по вариантам выпадаек) можно хранить в поле ``ProgrammaticalValue`` и загрузить при помощи `MetaDataApi_GetFieldsList `_. Логин ----- В качестве логина в вашу систему рекомендуем: 1. Реализовать поддержку логина = ``characterId``. Это удобно для техподдержки. 2. Использовать «красивый», игровой логин, который берется из какого-то поля персонажа, например ``dartvader@empire.local`` Пароль ----- Пароль в вашу систему рекомендуем хранить в поле персонажа типа PIN-код. Он будет создан автоматически (но при желании вы сможете вручную его отредактировать). «В игре» ------- У персонажа есть флаг «В игре» — ``InGame``: - становится ``true``, если игрок прошел регистрацию на игре; - становится ``false``, если игрок был выпущен новой ролью. В идеале он мог бы становится false, если бы Система сообщала joinrpg о смерти персонажа, но такой функционал не был реализован. Для NPC он всегда ``false``, их надо обрабатывать отдельно (`#1034 `_) Использование joinrpg в качестве бекенда ------------ Не рекомендуется использовать joinrpg в качестве непосредственного бекенда для вашего приложения. Мы не гарантируем соблюдения ваших требований по нагрузке и надежности. Правильный вариант, чтобы бекендом для вашего приложения был ваш сервис с вашей базой, который работает независимо от joinrpg. Впрочем, если вы всегда запрашиваете данные `по одному персонажу по его Id `_, количество запросов не превышает сотен в час и вы готовы обеспечить стабильный канал до joinrpg, то это можно использовать как основной вариант. Преимущества: нет проблемы синхронизации. Заливка Excel -------------- .. note:: Подходит только для простых ИТ-систем и маленьких игр. Самый простой способ — написать скрипт, который обрабатывает выгрузку в Excel персонажей (не заявок!). В процессе подготовки он запускается несколько раз и тестируется, каждый раз с полной очисткой БД Системы. В момент финального парада в joinrpg.ru отклоняются заявки не заехавших и скрипт запускается последний раз. Плюсы: - просто, - надежно. Минусы: - невозможно частично переливать данные или обновлять их в реальном времени; - не подходит, если игра большая (формирование Excel займет определенное время). Онлайн-импорт ----------------- .. note:: Мы рекомендуем этот вариант для сложных ИТ-систем Создается компонент, который по определенным правилам переносит данные из 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