Еще один доклад с Pixonic DevGAMM Talks — на этот раз от наших коллег из PanzerDog. Lead Software Engineer компании Павел Платто разобрал мета-сервер игры с сервисно-ориентированной архитектурой, рассказал, какие решения и технологии были выбраны, что и как у них масштабируется, и с какими трудностями пришлось столкнуться. Текст доклада, слайды и ссылки на другие выступления с митапа, как всегда, под катом.

Продолжаю выкладывать доклады с Pixonic DevGAMM Talks — нашего сентябрьского митапа для разработчиков высоконагруженных систем. Много делились опытом и кейсами, и сегодня публикую расшифровку выступления backend-разработчика из Saber Interactive Романа Рогозина. Он рассказывал про практику применения акторной модели на примере управления игроками и их состояниями (другие доклады можно посмотреть в в конце статьи, список дополняется).

Выкладываю второй доклад с нашего первого митапа, который провели в сентябре. В прошлый раз можно было почитать (и посмотреть) про использование Consul для масштабирования stateful-сервисов от Ивана Бубнова из BIT.GAMES, а сегодня поговорим про CICD. Точнее расскажет об этом наш системный администратор Егор Панов, который отвечает за доступность инфраструктуры и сервисов в Pixonic. Под катом — расшифровка выступления.

22 сентября провели наш первый нестандартный митап для разработчиков высоконагруженных систем. Было очень круто, много позитивного фидбека по докладам и поэтому решил не только их выложить, но и расшифровать для Хабра. Сегодня публикуем выступление Ивана Бубнова, DevOps из компании BIT.GAMES. Он рассказал о внедрении дискавери-сервиса Consul в уже рабочий высоконагруженный проект для возможности быстрого масштабирования и failover`а stateful-сервисов. А также об организации гибкого пространства имен для бэкэнд-приложения и подводных камнях. Теперь слово Ивану.


Я администрирую продакшн-инфраструктуру в студии BIT.GAMES и расскажу историю внедрения консула от Hashicorp в наш проект «Гильдия Героев» — fantasy RPG с асинхронным pvp для мобильных устройств. Выпускаемся на Google Play, App Store, Samsung, Amazon. DAU около 100 000, online от 10 до 13 тысяч. Игру делаем на Unity, поэтому клиент пишем на С# и используем свой собственный скриптовый язык BHL для игровой логики. Серверную часть пишем на Golang (перешли на него с PHP). Дальше — схематичная архитектура нашего проекта.

Хочу поделиться механизмами, которые мы используем на сервере для визуальной отладки игровой логики и способами изменения состояний матча в реальном времени.

В предыдущих статьях подробно рассказывали (список сразу под катом) о том, как устроена ECS в нашем новом проекте в разработке и как выбирали готовые решения. Одним из таких решений был Entitas. Он не устроил нас в первую очередь из-за отсутствия хранения истории состояний, но очень понравился тем, что в Unity визуально и наглядно можно посмотреть всю статистику по использованию сущностей, компонентов, систему пулов, производительность каждой системы и т.д.

Это вдохновило нас на создание своих инструментов на игровом сервере, чтобы смотреть, что происходит в матче с игроками, как они играют, как перформит система в целом. На клиенте у нас тоже есть подобные наработки для визуальной отладки игры, но инструменты в клиенте чуть более простые по сравнению с тем, что мы сделали на сервере.

Я всегда любил и умел торговаться. Со стороны покупателя это своего рода игра на получение максимальной выгоды, а для продавца — способ показать, что он ценит труд и нелегкую жизнь человека, которому делает скидку. Видел, как торгуются за 10 рублей, за 5 и даже жвачку.

Статья же призвана раскрыть определенную точку зрения на ведение переговоров для заключения контрактов с максимально выгодными для вашей компании условиями. За 14 лет эволюции от инженера первой категории до заместителя техдиректора по направлению внутренней и внешней инфраструктуры (а также консалтинга медиа-холдингов, стартапов, криптобирж и соцсетей) мне пришлось договориться о сотнях контрактов с контрагентами. Могу сказать, что подобный опыт применим везде — выбираете ли вы дата-центр, закупаете оборудование или ищите новый автомобиль. Как говорится: смелость города берет, а наглость и деревнями не брезгует.

Мы давно стремимся быть максимально открытыми и делиться опытом, пусть и не всегда идеальным. Это помогает не только находить узкие места у себя в разработке, но и пробовать что-то новое.

И если в текстовом формате мы не первый раз рассказываем истории из разработки, то теперь решили организовать митап в сентябре вместе с друзьями из DevGAMM, где будем на реальных кейсах разбирать архитектуру в глобальном понимании — от системных решений и приложений до архитектурных паттернов и стилей. И в этот раз мы решили уйти от традиционного стиля «митапов», поэтому — всего 222 отобранных приглашенных, актуальные темы и крутой нетворкинг на митапе (А|а)рхитектура.

А для тех, кто заинтересовался — под катом FAQ и подробности.

— А мы покажем казуальный PvP-раннер с препятствиями для тех, кто любит унижения.
— Что?
— Что?

Перед одной из презентаций на PixJam Summer'18.

Зимой мы провели первый внутренний PixJam, в котором ребята из всех отделов креативили и придумывали концепты для новых игр (кстати, один из них уже готовится к софт-ланчу). Собрали тонну позитивных отзывов и фидбека, чтобы сделать его еще лучше, и повторили эксперимент. Расскажу, как он проходил на этот раз и что мы изменили.

В предыдущих статьях цикла (все ссылки в конце статьи) о разработке нового fast paced шутера мы рассмотрели механизмы основной архитектуры игровой логики, базирующейся на ECS, и особенности работы с шутером на клиенте, в частности, реализация системы предсказания локальных действий игрока для повышения отзывчивости игры. В этот раз подробнее остановимся на вопросах клиент-серверного взаимодействия в условиях плохого соединения мобильных сетей и способы повышения качества игры для конечного пользователя. Также вкратце опишу архитектуру игрового сервера.

Рассказывать о новых проектах это, конечно, хорошо, но не всегда всё получается, как мы хотим.

В общем, начали тут вспоминать факапы из прошлого, когда решение одной проблемы прибавляло новых, увлеклись и решили поделиться парочкой. Как забанить невиновных игроков, заддосить собственные сервера, ошибиться в одной букве и словить тонны негатива от пользователей — вот это всё, как мы любим.

В одной из предыдущих статей мы провели обзор технологий, которые используются на нашем новом проекте — fast paced шутере для мобильных устройств. Теперь хочу поделиться, как устроена клиентская часть сетевого кода будущей игры, с какими трудностями мы столкнулись и как их решали.

Все рано или поздно приходят к аналитике за данными. В больших многопользовательских играх (да и синглплеере) без этого уже вообще никуда. Сколько пользователей предпочитают новый режим; где слабые места монетизации; куда смотреть геймдизайнерам, чтобы повысить вовлеченность игроков; и еще миллион вещей — подсчитывается вообще всё. И всё это влияет на решения, которые потом принимают разработчики.

А вот внедряют аналитику все по-разному: кто-то покупает сторонние решения (просто, но негибко), кто-то пишет под себя (долго и дорого), а кто-то пока просто считает несколько базовых метрик силами программистов и не заморачивается.

Поэтому я расскажу об инструменте, который будет полезен для всех. Кто только начинает выстраивать аналитику — сможет «на коленке» создать систему с нуля, а компании с уже готовыми решениями — «бустануть» свой подход.

В прошлой статье я описал технологии и подходы, которые мы используем при разработке нового мобильного fast paced шутера. Т.к. это была обзорная и даже поверхностная статья — сегодня я копну глубже и подробно расскажу, почему мы решили написать собственный ECS-фреймворк и не стали использовать существующие. Будут примеры кода и небольшой бонус в конце.

В мае вместе с CTO Pixonic Сергеем Ждановым (я — слева, он — справа) посетили Google I/O 2018 в Калифорнии. Хотелось посмотреть на тренды, технологии, пообщаться с разработчиками (я еще собирался поучаствовать в Codelabs, а то в прошлый раз не удалось туда попасть). В целом, если сравнивать с прошлым годом, Keynote был не такой впечатляющий, но все равно есть о чем рассказать по итогам конференции.

Не буду повторять, что и так уже все слышали, а расскажу, что заинтересовало меня, как разработчика мобильных игр, и что будет полезно знать другим. Начнем.

Год назад у нас в компании был один проект — мобильный шутер War Robots с относительно медленными, но красочными и напряженными боями. Игра продолжает развиваться, у нее десятки миллионов установок и игроков по всему миру, постоянно выходят апдейты. В какой-то момент мы захотели сделать динамичный шутер на Unity со скоростями, сравнимыми с Overwatch, CS:GO или Quake. Но реализовать задуманное для мобильных платформ (в первую очередь iOS и Android) на основе War Robots при текущих архитектуре и подходах было практически нереально.

Мы понимали, как это сделать в теории — есть много статей, презентаций на YouTube, детально рассказывающих о том, как написать шутер, как работать с сетью, какие возникают проблемы и как их решать. Здесь нет Rocket Science, все эти подходы придумали еще 30 лет назад и за это время они особо не поменялись. НО: у нас не было практики.

Забегая вперед, скажу — нам удалось реализовать задуманное. Мы создали для мобильных платформ динамичный быстрый шутер, который сейчас находится в бета-тестировании и активно дорабатывается. И мне очень хотелось бы всем этим поделиться. Это первая, обзорная статья с перечислением и кратким описанием практически всего того, что мы используем (прошу не путать с другим нашим проектом в разработке, технологии и подходы в котором похожие, но отличаются в деталях).

Я лид команды в Pixonic, где работаю уже год. О старте и развитии одного из наших новых проектов я ранее написал статью на Хабре. По ходу дальнейшего производства, спустя еще полгода, у меня накопилось большое количество интересного опыта, которым хотел опять поделиться. На этот раз речь пойдет о процессе наращивания функционала в мобильном клиенте и поддержании кода в гибком состоянии.

Уверен, подавляющее большинство хотя бы раз запускали какую-нибудь многопользовательскую игру. На старте клиент, как правило, пишет несколько магических сообщений и через несколько секунд (хотя в случае с одним известным десктопным шутером — несколько минут) игрок попадает в главное меню, где есть заветная кнопка «В бой» или типа того. Но процесс запуска состоит из огромного количества этапов, которые происходят очень быстро и без вмешательства игрока:

В предыдущей части мы рассмотрели основные проблемы написания нативных плагинов на Unity под iOS и Android, а также методы их решения для iOS. В этой статье я опишу основные рецепты по решению этих проблем для Android, стараясь сохранить схожую структуру взаимодействия и порядок их рассмотрения.

Когда делаешь на Unity игры для мобильных платформ, рано или поздно придется писать часть функционала на нативном языке платформы, будь то iOS (Objective C или Swift) или Android (Java, Kotlin). Это может быть свой код или интеграция сторонней библиотеки, сама установка может заключаться в копировании файлов или распаковки unitypackage, не суть. Итог этой интеграции всегда один: добавляются библиотеки с нативным кодом (.jar, .aar, .framework, .a, .mm), скрипты на C# (для фасада к нативному коду) и Game Object со специфичным MonoBehavior для отлавливания событий движка и взаимодействия со сценой. А еще часто требуется включать библиотеки зависимостей, которые нужны для работы нативной части.

Весь этот механизм интеграции обычно не вызывает проблем на чистом проекте, в котором еще нет (или мало) интеграций таких сторонних библиотек. Но когда проект разрастается, всплывает много проблем, усложняющих этот процесс, а часто дающих необходимость дополнительных модификаций и адаптирования под проект плагина, что потом выливается в увеличении сложности последующей поддержки и обновления.

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback'ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

Итак, начнём!

Жаль вас расстраивать, коллеги, но мой ответ: никак. Или, как говорилось в одной отечественной рекламе, «сынок, это фантастика». Нет, в природе существуют Tier IV ДЦ и ЦОДы, заключающие и выполняющие SLA, но в этой статье речь пойдет не о них (так как их услуги стоят, простите за каламбур, заоблачных денег), а о провайдерах выделенных физических и виртуальных серверов и сервисов, которыми в настоящее время пользуется большинство простых смертных, в том числе и мы в Pixonic.

Я намеренно не буду приводить названия конкретных компаний, с которыми мне приходилось работать как в Pixonic, так и до него, чтобы донести уже озвученную идею: так или иначе, серьезные «нюансы» обнаруживаются у всех. Возможно, кто-то захочет поспорить, но мое заключение основывается на более чем 8-летнем опыте общения с техподдержкой и менеджментом дата-центров разного уровня по всему миру.