Выбираем правильную библиотеку для мультиплеера

Разработчики Unity оценили самые популярные на сегодняшний день фреймворки сетевого кода для многопользовательских игр и поделились результатами.

Не существует идеального универсального решения для всех видов игр. Например, FPS, запущенная на выделенном игровом сервере с защитой от читов, такая как Apex Legends, будет иметь совершенно другие требования к сетевому коду, чем MOBA, работающая как P2P с детерминированным откатом для предотвращения читерства, например Heroes Strike.

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

Unity предлагает два разных решения: UNet для GameObjects, который в настоящее время находится в режиме поддержки, и DOTS-netcode для ECS и находится в предварительной версии.

В родмепе на 2021 компания подтвердила планы по разработке решения для сетки. И пока работают над этим решением, они предлагают разработчикам оценить различные альтернативы.

Оценивали по следующим критериям:

Стабильность/поддержка. Оценивалось по трём осям - вероятность ошибок или сбоев, время отклика для исправления проблем или помощи в отладке проблемы и вероятность критических изменений в API.
Простота использования. По отзывам пользователей о том, насколько легко начать работу и выполнять общие задачи. Сюда входят примеры использования, документация, руководства и простые API-интерфейсы для создания прототипов.
Производительность. Смотрели на сборки мусора/выделения памяти, минимальные накладные расходы на пинг, производительность вычислений и, в идеале, возможность многопоточности.
Масштабируемость. Как и в случае с производительностью, оценили способность решения поддерживать большее количество подключённых клиентов без значительного ущерба для производительности.
Функциональность. Сосредоточились на функциях среднего уровня, таких как репликация объектов и переменных, RPC, управление сценой и т. д. Также искали возможности более высокого уровня, такие как прогнозирование и компенсация задержек.
Стоимость. Учитывалась как стоимость библиотек/решений, так и возможные скрытые затраты.