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

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

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



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

В продолжение некогда поднятой в нашем блоге темы игрового искусственного интеллекта поговорим о том, насколько применимо к нему машинное обучение и в каком виде. Своим опытом и выбранными на его основе решениями поделился эксперт по вопросам ИИ в Apex Game Tools Якоб Расмуссен.



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

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

NB! Значительная часть статьи — это копипаста из конфы проекта без особой обработки. Это сделано специально, чтобы показать настоящие воркфлоу и рабочие материалы, а не их вылизанные для публичного доступа версии.

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

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

В мобильных играх много разных интерфейсов, включая HUD и огромное количество экранов для меты. UX-дизайнеры их проектируют, UI-дизайнеры отрисовывают, а чтобы всё это оказалось в движке существуют специально обученные люди — технические UI-дизайнеры. Ну или по-простому верстальщики. Частично их работа заключается в том, чтобы кропотливо из PSD-макета перенести все в префаб, чиселку за чиселкой. Еще они занимаются UI-анимациями, заливают спрайты, делают верстку адаптивной, расставляют ключи локализаций и так далее.

И мы поставили себе несколько целей:

• ускорить работу верстальщика и избавить его от рутины;
• оптимизировать взаимодействие между отделами UI-дизайна и разработки;
• внести в UI единообразие: создать гайдлайны и сформировать на их основе Unity-ассеты;
• обеспечить расширяемость и универсальность UI, реюзабельность ассетов, устойчивость к правкам, и легкую оптимизацию.

Вот как это происходило.

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

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

Бонусом в конце — несколько ссылок по теме.

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

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

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