> В этом проекте я использовал протокол TCP, конечно лучше писать свою надстроку над UDP, что я и пробовал делать вначале
Об этом глупо даже задумываться, как мне кажется. В играх нам требуется актуальность данных в первую очередь. Мы же не хотим, чтобы у нескольких игроков состояние мира отличалось друг от друга.
UDP хорош для информации, которую нестрашно потерять, голос или видео.
однако quake3 это не мешает работать через udp
В играх нам требуется актуальность данных в первую очередь.

Именно поэтому и используется UDP. Если пакет не пришел вовремя, то он уже неактуален, не имеет смысла пересылать его еще раз.
Поговорив с коллегами могу с вами согласиться, но не во всех случаях. Например при использовании UDP бывали случаи, когда выстрелы снайперов не засчитывались системой, удары урон не всегда наносился.
UDP можно использовать для информации, которая постоянно меняется, например координаты и вектор движения персонажей, но не для сообщений о новом ранге, подтверждении фрага или использовании рычагов, например.
Согласитесь, если информация о новом ранге придет из-за потери пакетов на 100 мс позже, игрок этого даже не заметит. А вот информация о координатах противника фактически должна передаваться в реал-тайме (в том смысле, как это используется в ОСРВ), и тут UDP лучше подходит.
В любом случае, мы говорим о некой сферической ММОГ в вакууме, и давать какие-то оценки на основании задержек из-за потери пакетов — это неблагодарное дело.
В идеале хорошо использовать tcp и udp в связке. Например чат tcp а передвижение и стрельба udp.
MessagePack не пробовали?
Читал в связке потеря udp пакетов увеличивается, если канал перегружен, отбрасываются в первую очередь udp пакеты. Но на самом деле я не думаю что это так критично, многие игры используют протоколы в связке (например wows). MessagePack не пробовал, протобаф идеально подошел.

Так не надо перегружать канал TCP-пакетами, вот и все :-)

При разработке многопользовательского шутера с системами комнат, мы потратили очень много времени для создания своего игрового сервера используя RakNet или Poco. Требуется очень много времени и сил для синхронизации анимации, движения, стрельбы, а главный вопрос в безопасности — где считать физику?

Встроенный инструментарий в движок, это классная вещь как оказалось: репликации, сериализация, разделение кода на клиент / клиент-сервер / сервер и все это из коробки.

По поводу прожорливости, если собрать контент игры и отдельно бинарный файл, то получаем что игра и сервер весят например 30Гб, это как то круто =)

Но если отдельно через движок сделать сборку игры и сервера, то игра все те же 30Гб, а сервер 1.5-2 гб.
По потреблению памяти оно падает с 1.5Гб в зависимости от размера уровня до 200-300Мб.

Для работы с Master Server, использовали связки ASP .NET Web Api + ORM Entity Framework + Postgresql.
Что позволило сделать из сборки сервера, еще и сайт игры, статистику, панель администратора и другие фичи без дублирования кода и в едином окружении. А EF Migration позволяет быстро и легко изменять и обновлять базу данных.

image

Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.