Konstantin Chernik, zGames. Creating backend you keep having the same architectural problems again and again: how to organize the transport, how to emulate a client / server, how to develop protocols, how to test the server. These problems are usually solved in the less optimal way, and require a lot of time for architecture premeditation. We would like to shorten this way sharing ideas which we believe are particularly useful.

1. Удачные архитектурные
решения игрового backend-а
для игр на Unity
Константин Черник
kanstantsin.chernik@gmail.com

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

3. План выступления
• Возможности нашего серверного
решения
• Взгляд на технологии
• Наиболее удачные решения
• Вопросы

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

5. Основные возможности
• Сокетный транспорт на protobuf
• Использование Rest api
• Поддержка разных версий протоколов
• Симулятор сообщений для клиента и сервера
• Переиспользование модулей разными проектами
без изменения кода
• Нагрузочное тестирование
• Backend могут делать unity разработчики

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

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

8. Технологии
LinqTPL
OWin &
Katana Task parallel library Language-Integrated
Query

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

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

11. 1.Сообщение в инспекторе
• Все полученные и отправленные сообщения
можно сохранить в инспекторе
• Можно менять поля не меняя код
• Можно создавать сообщения, сохранять их и
использовать в будущем
• Можно создавать целые сценарии
взаимодействия
• Просто реализовать (SerializeField)

12. 1.Сообщение в инспекторе

13. 2.Транспортная организация
• Поведение транспорта полностью
инкапсулирован в GameObject
• 2 вида транспорта, локальный и соккетный
• Лёгкая эмуляция поведения клиента и
сервера
• Удобные контейнеры для сообщений

14. 2.Соккетный транспорт
• input_history_container – история
сообщений от сервера
• output_history_container – история
сообщений от клиента
• output_instant_object – моментальная
посылка сообщения на сервер
перетаскиванием объекта в дети

15. 2.Локальный транспорт
• input_history_container и output_history_container
– повторяют соккетное поведение
• input_instant_object – моментальная отправка
сообщения на клиент перетаскиванием
настроенного GameObject-а в дети
• predefined_input_container – настройка сценариев
ответов “сервера”на клиентские запросы

16. 2.Транспортная организация

17. 2.История сообщений

18. 3.Версионность протоколов
• Проблема версионности
• Возможные пути решения
• Что такое протокол в контексте нашего
серверного решения
• Подход к версионности, который
выбрали мы

19. 3.Версионность протоколов
• Каждый протокол в отдельном .proto файле
• Версия протокола содержится в namespace
(Protocols.Login.v1) и в имени .proto файла (login.v1.proto)
• Сервер может поддерживать разные версии одного
протокола
• Клиент может работать с любыми версиями протоколов,
которые поддерживает сервер
• Клиент может работать с любым подмножеством
протоколов, поддерживаемым сервером
• Протоколы развиваются независимо друг от друга

20. 3.Настройка версий на клиенте

21. 4.Объект сессии
Мотивация появления

22. 4.Объект сессии
• Данные о состоянии пользователя приходят в
каждый обработчик
• Интерфейс объекта сессии и компонента сессии
полностью повторяют GameObject и Component
(добавление, удаление, проверка наличия,
получение)
• Данные имеют композитную структуру, удобно
добавлять новые и удалять старые компаненты
• Реализован аналог RequireComponent на
обработчиках сообщений

23. 4.Плюсы объекта сессии
• Объект сессии понятен unity
разработчикам
• Легко добавлять и удалять компоненты
• Все данные о сессии в одном месте
• Композитная структура, легко
расширяема

24. Заключение
Вопросы?
Константин Черник
kanstantsin.chernik@gmail.com