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

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

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

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

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

В недавнем интервью с Джоном Скитом мы пришли к выводу, что профессиональная работа с любой технологией подразумевает умение диагностировать проблемы и понимать, как ваши приложения работают под капотом. Вдогонку к тому разговору, я узнал у Саши goldshtn Гольдштейна, одного из лучших в мире экспертов по производительности .NET, автора книги «Pro .NET Performance», на какие инструменты следует обратить внимание .NET-разработчикам.

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

Привет! На связи Станислав Яблонский, 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 по ссылке.

Введение

Автоматизированное тестирование во всю свою мощь используется многими компаниями. Юнит-тесты, Интеграционные тесты, UI тесты, ручное тестирование и прочие методы. Но почему-то в такой большой области, как GameDev автоматизация тестов сводится к тому, что билды передаются в QA отдел на ручное тестирование. Постараюсь рассказать как разрабатываю игры я, и как пишу для них тесты.

— А где газировка?

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

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

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

Смущённый, я закрыл холодильник и спустился в кубикл к своему коллеге Фрэнку.

— Чувак, в холодильнике нет газировки. Что случилось?

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

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

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

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

1800

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

1842

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

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

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

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

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

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



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

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



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

Battle Prime — первый проект нашей студии. Несмотря на то, что многие члены команды имеют приличный опыт в разработке игр, мы, естественно, сталкивались с разными сложностями во время работы над ним. Они возникали как в процессе работы над движком, так и в процессе разработки самой игры.

В геймдев индустрии огромное количество разработчиков, которые охотно делятся своими историями, наработками, архитектурными решениями — в том или ином виде. Этот опыт, выложенный в публичное пространство в виде статей, презентаций и докладов, является отличным источником идей и вдохновения. Например, доклады команды разработки из Overwatch были для нас очень полезны при работе над движком. Как и сама игра, они очень талантливо сделаны, и я советую посмотреть их всем интересующимся. Доступны в GDC vault и на YouTube.

Это одна из причин, по которой мы также хотим вносить вклад в общее дело — и эта статья одна из первых, посвященная техническим деталям разработки движка Blitz Engine и игры на нем — Battle Prime.

Статья будет поделена на две части:

• ECS: имплементация Entity-Component-System паттерна внутри Blitz Engine. Этот раздел важен для понимания примеров кода в статье, и сам по себе является отдельной интересной темой.
• Неткод и геймплей: все, что касается высокоуровневой сетевой части и ее использования внутри игры — клиент-серверная архитектура, клиентские предсказания, репликация. Одной из важнейших вещей в шутере является стрельба, так что ей будет уделено большее количество времени.

Под катом много мегабайт гифок!

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

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

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