well-executed architecture decisions for game backend on unity
TRANSCRIPT
Удачные архитектурные решения игрового
backend-а для игр на Unity
Константин Черник[email protected]
Обо мне и о том, кто сегодня в зале
План выступления
• Возможности нашего серверного решения
• Взгляд на технологии• Наиболее удачные решения• Вопросы
Возможности серверного решения
Основные возможности
• Сокетный транспорт на protobuf• Использование Rest api• Поддержка разных версий протоколов• Симулятор сообщений для клиента и сервера• Переиспользование модулей разными проектами без
изменения кода• Нагрузочное тестирование• Backend могут делать unity разработчики
Решение не идеальное, но рассказать есть о чём!
Взгляд на технологии
Технологии
LinqTPLOWin & Katana Task parallel library Language-Integrated
Query
Проблема Protobuf на iOs
Protobuf имеет проблему на iOs из-за кодогенерации.
Мы решили эту проблему, за инструкциями обращайтесь ко мне[email protected]
Наиболее удачные решения
1.Сообщение в инспекторе
• Все полученные и отправленные сообщения можно сохранить в инспекторе
• Можно менять поля не меняя код• Можно создавать сообщения, сохранять их и
использовать в будущем• Можно создавать целые сценарии взаимодействия• Просто реализовать (SerializeField)
1.Сообщение в инспекторе
2.Транспортная организация
• Поведение транспорта полностью инкапсулирован в GameObject
• 2 вида транспорта, локальный и соккетный
• Лёгкая эмуляция поведения клиента и сервера
• Удобные контейнеры для сообщений
2.Соккетный транспорт
• input_history_container – история сообщений от сервера
• output_history_container – история сообщений от клиента
• output_instant_object – моментальная посылка сообщения на сервер перетаскиванием объекта в дети
2.Локальный транспорт
• input_history_container и output_history_container – повторяют соккетное поведение
• input_instant_object – моментальная отправка сообщения на клиент перетаскиванием настроенного GameObject-а в дети
• predefined_input_container – настройка сценариев ответов “сервера”на клиентские запросы
2.Транспортная организация
2.История сообщений
3.Версионность протоколов
• Проблема версионности• Возможные пути решения• Что такое протокол в контексте
нашего серверного решения• Подход к версионности, который
выбрали мы
3.Версионность протоколов
• Каждый протокол в отдельном .proto файле• Версия протокола содержится в namespace
(Protocols.Login.v1) и в имени .proto файла (login.v1.proto)• Сервер может поддерживать разные версии одного
протокола• Клиент может работать с любыми версиями протоколов,
которые поддерживает сервер• Клиент может работать с любым подмножеством
протоколов, поддерживаемым сервером• Протоколы развиваются независимо друг от друга
3.Настройка версий на клиенте
4.Объект сессии
Мотивация появления
4.Объект сессии
• Данные о состоянии пользователя приходят в каждый обработчик
• Интерфейс объекта сессии и компонента сессии полностью повторяют GameObject и Component (добавление, удаление, проверка наличия, получение)
• Данные имеют композитную структуру, удобно добавлять новые и удалять старые компаненты
• Реализован аналог RequireComponent на обработчиках сообщений
4.Плюсы объекта сессии
• Объект сессии понятен unity разработчикам
• Легко добавлять и удалять компоненты
• Все данные о сессии в одном месте
• Композитная структура, легко расширяема
