well-executed architecture decisions for game backend on unity

Удачные архитектурные решения игрового

backend-а для игр на Unity

Константин Черникkanstantsin.chernik@gmail.com

Обо мне и о том, кто сегодня в зале

План выступления

• Возможности нашего серверного решения

• Взгляд на технологии• Наиболее удачные решения• Вопросы

Возможности серверного решения

Основные возможности

• Сокетный транспорт на protobuf• Использование Rest api• Поддержка разных версий протоколов• Симулятор сообщений для клиента и сервера• Переиспользование модулей разными проектами без

изменения кода• Нагрузочное тестирование• Backend могут делать unity разработчики

Решение не идеальное, но рассказать есть о чём!

Взгляд на технологии

Технологии

LinqTPLOWin & Katana Task parallel library Language-Integrated

Query

Проблема Protobuf на iOs

Protobuf имеет проблему на iOs из-за кодогенерации.

Мы решили эту проблему, за инструкциями обращайтесь ко мне.kanstantsin.chernik@gmail.com

Наиболее удачные решения

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 разработчикам

• Легко добавлять и удалять компоненты

• Все данные о сессии в одном месте

• Композитная структура, легко расширяема

Заключение

Вопросы?Константин Черник

kanstantsin.chernik@gmail.com