Игровой сервер на Rust для пошаговой игры, как лучше реализовать?

Всем привет, недавно начал изучать Rust, и хочется параллельно практиковаться.
Решил попробовать сделать простенькую пошаговую игру с мультиплеером, с сервером на Rust и Клиентом на Unity(C#).
До этого опыта в мультиплеерных решениях вообще не было, максимум web-api простенькое сделать мог на шарпе.

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

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

Хотелось бы получить пару ответов на эти вопросы:

  1. Какую сетевую библиотеку на Rust было бы лучше всего использовать?(К примеру я видел tokio, но я не знаю хорош ли его async io для сетевой игры на подобии шахмат, где игроки быстро делают ходы по очереди)
  2. Типом соединения должен же быть сокет ? или как правильно ? Я как то делал всякие чаты на вэбсокетах, как должно всё быть в игровых серверах не шарю ...
  3. Какой протокол лучше использовать?(tcp для меня вроде самый адекватный вариант, но мало ли есть какие то подводные камни)
  4. Как лучше сделать обмен сообщениями между клиентом и сервером ? К примеру я хочу, что бы вся игра было только на сервере, а с клиентов поступает только ввод, как лучше сделать общение между ними ? Самое первое, что мне пришло в голову, это json или xml, но по сокету же идёт массив байтов, типа придется каждый раз сериализовать всё, а это всё время, задержки, или всё таки это нормальный вариант ?
  • Вопрос задан
  • 596 просмотров
Пригласить эксперта
Ответы на вопрос 1
@wladwm
1. Токио - безальтернативно практически.
2. Нет, сессию с клиентом как раз лучше абстрагировать от сокетов. Клиентское ПО должно иметь возможность погасить tcp-сессию, а потом переоткрыть ее. И это все должно происходить без потери собственно сессии.
3. Совсем необязательно. Протокол можно и на udp реализовать. http/3 например вполне себе udp-based.
4. Сериализация-десериализация тут в любом случае имеет место. Думаю в данном случае json/xml нормальный вариант. Как альтернатива - посмотреть можно и на protobuf, тут все точно будет быстрее сериализорваться-распаковываться чем в json.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы