Как правильно разрабатывать гибкую клиент серверную архитектуру и делать клиент серверные игры на Godot?
Привет Хабр.
Я решил прыгнуть чуть выше головы и сделать опенсорный виртуальный игровой стол (тот что для настольных роелвых игр, похожий на roll20), но случилось очивидное, самая слабая часть моих знаний используется тут везде, а именно - сети и сетевое взаимодействие. В базе я конечно разбираюсь, но вот нюансы от меня ускользают.
Подробнее про приложение для контекста:
1. Основная идея взята с maptool от rptools, roll20 и foundry vtt. Последние две представляют собой браузерное приложение - что плохо для слабых систем, а первое - морально устарело и абсолютно не интуитивно
2. Из первого пункта вытекает что предполагается два сценария использования - как локальный сервер и как выделенный сервер. В первом случае данные об игровых активах берутся из хранилища пользователя, а во втором непосредственна из хранилища сервера.
3. Само приложение разделено на 3 (условных) части: Обозреватель, Редактор и Игра в реальном времени. Обозреватель - позволяет смотреть активы (персонажей, игровые правила, игровые предметы и т.д.) и искать по ним при помощи филтров или строкового запроса. Редактор - позволяет создавать разметку для записей и собственно нужные записи по разметке. Так например пользователь может создать разметку для "item" у которого будут поля: "name", "damage" и "type", а потом уже создавать записи по этой разметке. И третье это непосредственно игра где используются активы из первых двух пунктов. Например персонаж получил в приключении "Палку", и записывает ее себе в инвентарь, а оно уже подхватывает активы.
Проблематика и концепты:
Суть в том что я не имею ни малейшего понятия как все это связать воедино, так что бы это не было похоже на рваное полотно.
Например с выделеным сервером можно предположить стек:
1. Flask как сервер аутентификации и запросов к базе данных активов
2. MongoDB как базу данных для активов
3. Redis как средство кеширования для частых запросов например
4. Godot как игровой сервер из-за простоты синхранизации действий
И все бы ничего, но есть же еще необходимость собрать локальную систему, а все это очивидно в приложение Godot не уложишь. Прийдется отказываться совершенно точно от Flask и Redis, а монго разворачивать локально для пользователя попахивает безумием.
А так-же я плох конкретно в сетевой части, и например не совсем представляю каким образом поднимать игровой сервер реального времени при старте игры, а точнее как отправлять клиенты на него. К примеру игрок вызывает /start_game и по идее должен получить какой то адрес запущенного игрового сервера или типа того.
Просьба:
Подскажите люди добрые любые идеи или пути по которым мне стоит пойти, статьи которые стоит почитать. Я вижу как возможность тут только полный отказ от концепции библиотеки на локальном сервере, или кешированную в sqllite библиотеку, или в крайнем случае полный отказ от локально сервера, а с перенаправлением на игровые серверы вообще нет идей.
По игровым технологиям тут нечего добавить. Все выглядит вполне себе норм.
По поводу Mongo. Я-бы предложил ее заменить на что-то другое. Монга хороша для проектов
где изначально не известна схема документа и надо грузить все что есть и как есть.
При этом через некоторое время есть риск получить просто свалку документов где никто
не знает схему данных. Или будет несколько параллельно живущих вариантов схем что
само по себе не лучше.
Если вы точно знаете схему (вы разрабатываете игру и весь игровой мир, инвентарь и локации)
то вы точно знаете что у вас будет где лежать. Вообще для игр лучше брать любую key-value
для которой есть API/ABI. Они все подходят.
Вся магия заключается в том что разметки элементов не известны. Пользователь может захотеть сделать систему например для игры "Call of cthulhu 7e" где большую роль играет механика рассудка и удачи, а может например "DnD 5e" в которой значительнйы упор сделан на пракачку. Соответственно будут использованы разные макросы и разные расчеты. MongoDB я выбрал по этой причине. А насчет key-value баз данных , у меня был с ними не очень хороший опыт несколько раз, и они начинали сильно страдать от тысячи или 10 тысяч записей. Поэтому этот вариант был отклонен. Возможно я не прав и существуют хорошие минималистичные и производительные решения, но я таких не нашел.
и они начинали сильно страдать от тысячи или 10 тысяч записей.
Я в это не верю. Обычно key-value dbms стоят на "острие атаки" перформанса. Ситуацию
с 10 тыс записей надо расследовать и понять что было причиной.
Исключение может быть в том случае когда вы их неправильно используете. Например
пытаетесь делать joins, aggregations. Уж для этого они точно не создавались. Key-Value
- это очень короткие и точечные транзакции.
Простой
