Всем привет! Меня зовут Василий Мазалов, я работаю старшим видеомонтажером в компании 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 раз быстрее. Цель его состоит в том, чтобы попытаться научить имитации физических сил нейронную сеть.

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



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

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

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

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

Проекты, которые разрабатывались исключительно для продвижения и рекламы какого-нибудь бренда, особенно раньше, часто можно было найти в сторе. Обычно это проекты «на один раз», но бывают и исключения. Все это в общем называется одним словом — advergame. Под катом перевод небольшой ретроспективы рекламных игр: откуда начались и где они сейчас. Список самых крутых бонусом.

Статья о звуке, но адресована скорее не саунд-дизайнерам (которым всё известно), а продюсерам, ПМ-ам игровой индустрии и начинающим разработчикам. Собранные здесь ошибки — это наш собственный опыт из времён, когда War Robots была ещё прототипом в новой для компании нише.

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

TDD в геймдеве применяют довольно редко. Обычно проще нанять тестировщика, чем выделить разработчика для написания тестов — так экономятся и ресурсы, и время. Поэтому каждый успешный пример использования TDD становится интереснее. Под катом перевод материала, где эту технику разработки применили при создании передвижения персонажей в игре ElemenTerra.

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

Часто это сложнее, чем привирать с помощью красивых графиков.

Поэтому я собрал несколько базовых принципов визуализации, которые применяю в работе (список источников в конце). Пригодится, если вы пишете отчеты, готовитесь к презентации или просто хотите донести смысл каких-то цифр. Главное: чтобы сделать хороший график, не нужно быть талантливым художником или виртуозно владеть matplotlib/ggplot2. Поехали.

Горячие клавиши используют все. Банальные Ctrl+C и Ctrl+V, а сколько раз выручал Ctrl+Z? Ну а Alt+F4? А если вспомнить количество негативных отзывов, когда в новых MacBook Pro добавили тачбар и вырезали ряд командных клавиш?

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

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

В помощь геймдизайнерам придумана масса инструментов: форматы ГДД, различные чек-листы, юзерстори, портреты, агенда и так далее. И все равно этого не хватает.

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