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

Про серверную лагкомпенсацию написано много статей, в том числе на русском языке. В этом нет ничего удивительного, ведь эта технология активно используется при создании многопользовательских FPS еще с конца 90-ых. Например, можно вспомнить мод QuakeWorld, прибегнувший к ней одним из первых.

Используем ее и мы в своем мобильном мультиплеерном шутере Dino Squad.

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

За шестилетнюю историю существования War Robots мы не раз проводили опросы среди игроков касательно наших карт. Какие нравятся, какие нет, почему? Затем анализировали полученные ответы, фидбек ютуберов, отзывы с форумов и из социальных сетей.

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

В этом материале мы собрали правила, которыми руководствуемся при проектировании карт, опираясь на собственный опыт и фидбек наших игроков. И хотя разбор ведется на примере конкретно нашей игры, он может послужить общей памяткой с рекомендациями для левел-дизайнеров по работе с мультиплеерными картами для шутеров.

В марте 2020 года многие компании перевели своих сотрудников на режим дистанционной работы, и Pixonic не стала исключением. По итогам первых двух месяцев можно сделать вывод, что переезд из офиса по домам просадкой в работе не обернулся, и все дедлайны соблюдаются исправно. Отсюда возникает резонный вопрос: самоизоляция когда-нибудь закончится, но раз все так хорошо, может, отказаться от офиса совсем и продолжить работать дистанционно? Тенденция к такому переходу уже существует: например, руководство Twitter разрешило желающим среди своих сотрудников навсегда остаться на удаленке.

До недавнего времени доктрина Pixonic основывалась на том, что все штатные сотрудники работают в офисе. Мы собрали мнения глав отделов и компании об идее продолжения практики удаленной работы после окончания пандемии, и вот что из этого вышло.

Всем привет, меня зовут Евгений Демиденко. Последние несколько лет я занимаюсь разработкой автоматизированной системы тестирования игр в Pixonic. Сегодня я хотел поделиться нашим опытом разработки, поддержки и использования такой системы на проекте War Robots.

Для начала разберемся, что же все-таки мы автоматизируем этой системой.

В первую очередь, это регрессионные UI-тестирования, тестирование core-геймплея и автоматизация бенчмарков. Все три системы в целом дают возможность снизить нагрузку на QA-отдел перед релизами, быть более уверенными в масштабных и глубоких рефакторингах и постоянно поддерживать общую оценку производительности приложения, а также отдельных его частей. Еще одним пунктом хочется отметить автоматизацию рутины, например ― проверку каких-либо гипотез.



Приведу немного цифр. Сейчас для War Robots написано более 600 UI-тестов и порядка 100 core-тестов. Только на этом проекте мы произвели около миллиона запусков наших тестовых сценариев, каждый из которых занимал порядка 80 секунд. Если бы эти сценарии мы проверяли вручную, то потратили бы минимум по пять минут на каждый. Кроме того, мы запустили более 700 тысяч бенчмарков.

Из платформ мы используем Android и iOS ― всего 12 устройств в парке. Разработкой системы и ее поддержкой занимаются два программиста, а написанием и анализом тестов ― один QA-инженер.

Компания Epic Games впервые продемонстрировала возможности игрового движка Unreal Engine 5. Одной из главных целей его создания было достижение исключительной фотореалистичности, сравнимой только с AAA-блокбастерами и самой жизнью.

Unreal Engine 5 поддерживает ПК, Mac, консоли текущего и нового поколения, iOS и Android. Полноценный релиз движка ожидается в следующем году.

В новом движке выделяются две ключевые области:

• Первая ― полностью динамическое глобальное освещение, мгновенно реагирующее на изменение сцены. Теперь нет необходимости ограничиваться игрой со статичным миром ― можно проводить итерации над ним чрезвычайно быстро. Новая система освещения носит название Lumen.
• Вторая ― виртуализированная геометрия. С UE5 художникам не обязательно задумываться о подсчете полигонов или о том, сколько места в памяти системы они займут. Можно использовать ассеты кинематографичного качества в движке напрямую, загружать модели из ZBrush и данные фотограмметрии, не тратя время на оптимизацию уровней детализации или понижение качества для того, чтобы вписаться в нужную частоту кадров. Эта технология получила название Nanite.

Теперь рассмотрим все нововведения на примере игрового демо для PlayStation 5.

Три года назад ведущий геймдизайнер ArenaNet Дженнифер Шойрле завела в Твиттере очень интересный тред на тему «отличных игровых механик, скрытых от глаз игрока с целью достижения определенного эмоционального эффекта, реакции или поведения», где любой геймдизайнер мог поделиться своими внутриигровыми «фишками».

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

• В Hellblade предупреждение перед игрой было тщательно продумано, чтобы заставить игроков поверить, будто в игре срабатывает система permadeath в случае, если игрок умирает слишком часто, хотя на самом деле ее там нет.
• Pacman может огибать углы более резко, чем это делают призраки, тем самым наделяя игрока небольшим преимуществом.
• Во многих шутерах последние очки здоровья стоят больше всей остальной шкалы, чтобы усилить чувство «выживания на грани». С той же целью в System Shock последняя пуля нанесет урон в 4 раза более сильный, чем остальные.
• И, напротив, Shadow of Mordor слегка увеличивает здоровье некоторых врагов, чтобы бои длились дольше.
• В Bioshock и Devil May Cry, находясь за спиной игрока, противники замедляют свою атаку.
• В Xcom, если промахнуться много раз подряд, игрок получит скрытый бонус для последующих выстрелов. Кроме того, если игроки остаются пассивными слишком долго, враги усиливают свою агрессивность.
• Похоже, что в Heartstone есть pity timers ― таймеры жалости. Многие другие игры позорно использовали их в более ранние годы.
• В Resident Evil 4 после слишком большого количества смертей заспавнится меньше врагов, чтобы дать игроку больше шансов пройти трудный для него эпизод.
• В любой гоночной игре реализован адаптивный ИИ, чтобы сделать соревнование более жестким.

Список можно продолжать и продолжать. Это настоящий кладезь подсказок от успешных геймдизайнеров.

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

Привет! На связи Станислав Яблонский, Lead Server Developer из Pixonic.

Когда я только пришел в Pixonic, наши игровые сервера представляли собой приложения на основе Photon Realtime SDK: многофункционального, но весьма тяжелого фреймворка. Решение это, казалось бы, должно было упростить работу с сервером. Так оно и было ― до определенного момента.

Photon Realtime привязывал нас к себе тем, что приходилось использовать его для обмена данными между игроками и сервером, ― а также привязывал к ОС Windows, поскольку может работать только на ней. Это накладывало на нас ограничения как с точки зрения runtime (среды исполнения): нельзя было изменить многие важные настройки виртуальной машины .NET, ― так и операционной системы. Мы привыкли работать с Linux-серверами, а не Windows. Кроме того, они нам обходились дешевле.

Также использование Photon било по производительности как на сервере, так и на клиенте, а при профилировании образовывалась приличная нагрузка на сборщик мусора и большое количество boxing/unboxing.

Короче говоря, решение с Photon Realtime было далеко от оптимального для нас, и давно надо было что-то с этим делать ― но всегда находились более срочные задачи, и до решения проблем с сервером руки банально не доходили.

Так как мне было интересно не только решить проблему, но и лучше разобраться в работе сети, я решил взять инициативу в свои руки и попробовать написать библиотеку самостоятельно. Но, сами понимаете, дома ― дом, на работе ― работа, в результате время на разработку библиотеки находилось только в транспорте. Однако это не помешало довести идею до реализации.

Что из этого вышло ― читайте дальше.

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

Тем не менее, кроссплатформенность сейчас находится на подъеме. Появляется все больше и больше игр, обладающих этим свойством. Fortnite, Call of Duty, Street Fighter ― все они разных жанров, по-разному реализованы, но в той или иной степени обладают функциями кроссплатформенности.

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

Зачем нужно делать игру кроссплатформенной?

Для игроков это здорово: не нужно выбирать, на каком устройстве запускать игру, ― можно беспрепятственно играть с друзьями, не беспокоясь о том, есть ли они в базе игроков.

Для разработчиков игр это тоже здорово, ведь пользовательская база теперь не сегментирована по разным платформам ― вместо этого можно организовать один большой пул игроков и создать более богатый многопользовательский опыт с более полными игровыми сессиями.



Отлично, так давайте портировать нашу игру на несколько платформ!

Конечно, звучит классно, почему бы и нет. Вот только…

Во «Властелине колец», если вы помните, на совете Элронда герои тоже обсуждали, мол, давайте же просто сделаем, что должны, на что Боромир сказал:



А все потому, что Боромир знает: создание полноценной кроссплатформенной игры ― это не так-то просто.

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

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

Всем привет! Меня зовут Василий Мазалов, я работаю старшим видеомонтажером в компании Pixonic. Наш отдел занимается созданием видео-креативов для маркетинга и комьюнити: роликов для страниц в сторы, обзорных видео игровых нововведений и прочего контента.

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

Год назад я наткнулся на следующее видео:


Что мы здесь видим? Парень нацепил на себя костюм захвата движения тела (пока ничего необычного), повесил перед собой iPhone (а вот это уже интересно) и таким образом транслирует анимацию лица и тела персонажа напрямую в режиме реального времени в Unreal Engine, и выглядит результат для столь незамысловатой реализации довольно качественно.

Классная идея, подумал я. Затем закрыл видео. И продолжил дальше работать.

Спустя полгода в открытом доступе оказался обучающий материал о том, как произвести захват анимации лица в Unreal Engine при помощи приложения на iPhone. В то же время я узнал, что в наш арт-отдел приобрели костюм для захвата движения. Посмотрел его совместимость с UE: всё подошло. Оставалось только найти iPhone для дальнейшей работы, но в наше время с этим проблем еще меньше.


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

Начался долгий процесс изучения различной документации.

Что в результате получилось и как мы этого добились, читайте дальше.

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

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

В этой статье я расскажу:

• Что за задача такая, о которой идет речь;
• Подробнее об интегральных изображениях;
• Как использовать интегральные изображения для приближенного решения гравитационной задачи N тел применительно к дискретному полю импульсов (масс-скоростей);
• Какой недостаток имеет это решение и как его исправить;
• И, наконец, как за константное время вычислить центр масс для произвольного региона.

За последние несколько лет в обучении с подкреплением (reinforcement learning, RL) произошли серьезные прорывы: от первого успешного его использования в обучении по сырым пикселям до обучения Open AI роборуки, ― и для дальнейшего прогресса становятся необходимы все более сложные среды, в чем на помощь приходит Unity.

Инструмент Unity ML-Agents ― это новый плагин в игровом движке Unity, позволяющий использовать Unity как конструктор среды для обучения МО-агентов.

От игры в футбол до ходьбы, прыжков со стен и обучения ИИ собаки игре с палкой, Unity ML-Agents Toolkit предоставляет широкий спектр условий для тренировки агентов.

В этой статье мы рассмотрим, как работают МО-агенты Unity, а затем научим одного из таких агентов перепрыгивать через стены.

Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.

Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.

Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.

Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.

Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.

Сейчас я опишу, как там всё устроено.

Для того, чтобы получить реалистичный мир внутри игры, необходимо учитывать взаимодействие различных форм рельефа между собой и с другими моделями. И если видимые линии пересечения между 3D-моделями портят органичность изображения, стоит задуматься над тем, как их устранить. Самый распространенный случай таких линий, который может быть знаком многим, — пересечение билбордов частиц с непрозрачной геометрией.



Другой пример — нарушающие естественность композиции пересечения скал и растительности с поверхностью ландшафта в сценах «на открытом воздухе».



Помимо разнообразных методов сглаживания (SSAA, MSAA, CSAA, FXAA, NFAA, CMAA, DLAA, TAA и др.), которые пусть и смягчают вызывающий внешний вид таких линий пересечений, но не исправляют ситуацию в полной мере, существуют и более действенные приемы. Их мы и рассмотрим.

С 16 по 20 марта 2020 года в Сан-Франциско пройдёт ежегодная конференция разработчиков игр — GDC. Основная миссия мероприятия направлена на обмен опытом, идеями и интересными кейсами различных компаний, вовлечённых в геймдев-индустрию: от небольших инди-студий до AAA-гигантов.

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

Ну а для тех, кто не собирается ехать, но всё равно интересуется происходящим, стоит упомянуть про GDC Vault — платное онлайн-хранилище всех важных докладов участников GDC разных лет, которым пользуемся и мы сами.

UPD. Из-за вспышки коронавируса Covid-19 на конференцию отказались ехать Kojima Productions, Electronic Arts, Sony, Facebook, Unity, Microsoft, Epic Games и Oculus, однако компании заверили, что все материалы тем или иным образом будут опубликованы в сети.

Update 29.02.2020. Конференцию перенесли на лето.

Update 25.03.2020. Список всех онлайн-лекций с GDC-2020 по ссылке.

Теория архитектуры включает в себя множество аспектов и по своей сути является сплавом многочисленных художественных, социальных и психологических техник. Однако, вне зависимости от архитектурного движения или эпохи, одна идея всегда остаётся неизменной: архитектура — разумный способ организации пространства.

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

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

В предыдущей статье мой коллега рассказал о том, как мы использовали двумерный физический движок в нашем мобильном мультиплеерном шутере. А теперь я хочу поделиться тем, как мы выкинули всё, что делали до этого, и начали с нуля ― иными словами, как мы перевели нашу игру из 2D-мира в 3D.

Всем привет, на связи Александр Панов, техлид из Pixonic. В компании я отвечаю за межпроектные решения и околопроектную периферию и сегодня хочу поделиться своим опытом и наработками.

Платформы непрерывной разработки и интеграции, или CI/CD, сейчас используются повсеместно в тех отраслях, где решающую роль играет итеративность и отлаженность технических процессов. В этой статье речь пойдёт о CI/CD для реализации наших Unity-проектов для мобильной геймдев-разработки: с какими проблемами мы столкнулись, как их удалось решить, каких улучшений мы добились и как прописан наш пайплайн сборок билдов.

Сразу договоримся, что в качестве сервера CI мы используем TeamCity от JetBrains, в качестве хранилища Git-репозиториев ― GitHub, для хранения артефактов сборки ― Nexus.

Всем привет! В этой статье мы расскажем про личный опыт работы с физическими движками для мультиплеерного шутера и главным образом сфокусируемся на взаимодействии физики и ECS: на какие грабли мы наступили в процессе работы, чему научились, почему остановились на конкретных решениях.

Как-то раз я случайно увидел, как мой коллега решает джуниорскую задачку разворачивания двусвязного списка на C++. И в тот момент странным мне показалось не то, что он лид и давно перерос подобное, а само решение.

Вернее, не так.

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

• Почему по умолчанию все решают задачу именно так?
• Можно ли сделать лучше?

Практически в любой современной компьютерной игре наличие какого-либо физического движка является обязательным условием. Развевающиеся на ветру флаги и кролики, бомбардируемые шарами, ― всё это требует надлежащего исполнения. И, конечно, пусть не все герои носят плащи… но те, кто носят, действительно нуждаются в наличии адекватной симуляции развевающейся ткани.



И всё же полное физическое моделирование таких взаимодействий часто становится невозможным, поскольку оно на порядки медленнее необходимого для игр в реальном времени. Данная статья предлагает новый метод моделирования, который может ускорить физические симуляции, сделать их в 300-5000 раз быстрее. Цель его состоит в том, чтобы попытаться научить имитации физических сил нейронную сеть.