Unity *

Привет, Хабр!

Как знают наши постоянные читатели, мы давно и успешно издаем книги по Unity. В рамках проработки темы нас заинтересовал, в частности, инструментарий ML-Agents Toolkit. Сегодня мы предлагаем вашему вниманию перевод статьи из блога Unity о том, как эффективно обучать игровых агентов методом игры «с самим собой»; в частности, статья помогает понять, чем этот метод эффективнее традиционного обучения с подкреплением.



Приятного чтения!

Салют, хабровчане. Совсем немного времени остается до старта курса «Разработчик игр на Unity», в связи с этим мы подготовили для вас еще один интересный перевод.

---

async в Unity уже и так работает без каких-либо плагинов или оборачивающих Task корутин, имитирующих асинхронное поведение проверяя завершение на каждом кадре. Но это все-равно своего рода магия. Давайте же немного углубимся в эту тему.

(Примечание: пока еще я не обладаю идеальным пониманием всех подкапотных тонкостей async/await в C#, по этому я буду стараться дополнять изложенное, по мере углубления моего понимания.)

Эффект тумана войны из Civilization VI — отличный пример простой структуры вычислительного шейдера (compute shader). Если вы всегда хотели узнать об основах программирования таких шейдеров, то этот туториал для вас. Вы сможете понять его даже без знания шейдеров и программирования на C#; более опытные разработчики могут пропустить введение.

Анализ эффекта

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


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

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

Немного коротко обо всем.

Игра Synthety в жанре квест — приключение. Цель игры найти выход с текущей локации на следующую. Для этого необходимо общаться с персонажами, взаимодействовать с окружающими предметами, решать головоломки и прочее. От начала разработки и до релиза игры пролетели около полугода. Игра разрабатывалась на движке Unity на языке C#. В данном посте хотелось бы поделиться советами и подсказками в разработке и релизе игры.

Всем привет, в июне OTUS вновь запускает курс «Разработчик игр на Unity». В преддверии старта курса, мы подготовили перевод интересного материала по теме.

---

Сегодня мы поговорим о том, как делать блендинг меша с террейном (или с другими мешами) в Unity. Это руководство довольно продвинутое, но я постарался разбить его на отдельные этапы. Предполагается, что у вас есть общие навыки работы с Unity и базовое знание С#. Руководство разработано для amplify, но я думаю, что его можно также применить и к Shader Graph. Это мое первое руководство, поэтому надеюсь, что оно получится достаточно понятным. Если вы захотите что-то добавить, дайте знать. Я включил сюда стартовый набор, в котором есть некоторые дополнительные шейдеры для этого проекта, а также базовый комплект для начала работы. Все файлы проекта из сегодняшнего руководства доступны моим патронам за $5, но в ближайшем будущем, они будут доступны всем желающим.

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

Raymarching — это достаточно новая техника, используемая для рендеринга сцен реального времени. Она особенно интересна тем, что полностью вычисляется в шейдере экранного пространства. Другими словами, рендерер не получает доступа к данным мешей и сцена отрисовывается на одном четырёхугольнике, покрывающем всю область видимости камеры. Объекты в сцене задаются аналитическим уравнением, описывающим кратчайшее расстояние между точкой и поверхностью всех объектов сцены (поэтому полностью техника называется полями расстояний Raymarching-а). Оказывается, что даже при наличии только этой информации мы можем создавать поразительно сложные и красивые сцены. Более того, благодаря тому, что мы не используем полигональные меши (и вместо них применяются математические уравнения), здесь, в отличие от традиционного рендерера, можно задавать идеально плавные поверхности.


Snail Иниго Килеза была полностью создана при помощи raymarching. Другие примеры подвергнутых raymarching-у сцен можно найти на Shadertoy.

В этой статье мы сначала расскажем о фундаментальных понятиях и теории raymarching, а затем покажем, как реализовать простейший raymarcher в игровом движке Unity. Далее мы продемонстрируем, как на практике встроить raymarching в настоящую игру на Unity, позволив объектам с raymarching-ом перекрываться обычными GameObjects.

Полный код можно найти в этом репозитории Github.

Краткое вступление

Как правило, для того чтобы добраться до интересующего нас поля сериализованного свойства, мануальная терапия советует нам использовать метод FindPropertyRelative(), в который прокидывается название переменной.

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

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

Внимание. Данная статья подразумевает, что вы уже умеете работать с UnityEditor’ом, хотя бы раз писали кастомные PropertyDrawer’ы и хотя бы в общих чертах понимаете, чем сериализованное свойство отличается от сериализованного объекта.

Меня зовут Тарас Улейский, я Technical Artist в Plarium Kharkiv. Для оптимизации графики нашей Survival RPG на мобильных устройствах мы использовали свои кастомные шейдеры. Они предполагают использование уникальных текстур и карт, которые не похожи на текстуры и карты в других популярных способах шейдинга. В результате 3D-художникам не совсем понятно, как создавать эти текстуры для ассетов в игре. Чтобы сразу можно было увидеть, как 3D-модель будет выглядеть в движке игры на этапе текстурирования, я перенес шейдер в Substance Painter. Материалов по API в Substance Painter на данный момент практически нет, я изучил эту тему самостоятельно, поэтому решил поделиться своими наработками.

Делимся с вами подборкой вебинаров на тему разработки игр. Вы узнаете, как сделать простую консольную игру на PHP, 3D-арканоид на движке Unreal Engine 4, космическую аркаду и AR-приложение на Unity. Заходите под кат – будет интересно.

В этой части на примере мода для Beat Saber мы рассмотрим общие принципы разработки модов для Unity-игр, узнаем, какие есть трудности, а также познакомимся с Harmony — библиотекой для модификации кода игр, которая используется в RimWorld, Battletech, Cities: Skylines и многих других играх.

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

Всем привет! Меня зовут Григорий Дядиченко, и я занимаюсь AR/VR. (Слышны хлопки по залу). В AR/VR я уже больше 4 лёт, хотя занимаюсь не только исключительно ими, а самыми различными проектами под заказ всё это время. Я работал в студиях, я долгое время был фрилансером и даже целый год у меня была своя студия. Сегодня же я хочу рассказать с разных точек зрения и нюансов “почему вам не стоит идти в VR”, как разработчику. Если вас интересует то, с чем вы столкнётесь в виртуальной реальности — добро пожаловать под кат!

Привет! Имея за плечами довольно серьезный опыт разработки игр и приложений, я долгое время боялся браться за RPG. Я имею ввиду полноценную ролевую игру, а не казуальный кликер или айдлер (idle). Итак, я поделюсь с вами историей о том, как по-быстрому за 1 месяц сделать свою RPG, с блэкджеком и всем остальным.

30-го апреля после сытного обеда я сел и почесал голову: завтра намечается 1 мая, а в этот день в Новосибирске традиционно проходит широко известное культурное мероприятие — Монстрация.

Понятное дело, что никакой Монстрации в этот раз не предполагалось, в связи с карантином, а её автор — Артём Лоскутов — предложил всем уйти в онлайн:

«Вирус лишил нас иерархий: теперь нет больших и маленьких монстраций, все оказались в первом ряду своей личной монстрации, где каждый лозунг — главный. Тотальная децентрализация. Монстрация становится Облачной, отражаясь облаком фотографий — своих главных визуальных артефактов, в облаке репортажей, постов, твитов и сториз».

Ну, что же, подумал я: онлайн, так онлайн. Почему бы и нет.

Сегодня мы совершим прыжок в область Spatial Awareness с помощью очков Hololens от Microsoft и поговорим о развитии Windows Mixed Reality (WMR), а также о том, чего стоит ожидать от второго поколения.

Статья рассчитана на тех, кто занимается разработкой под Hololens с использованием среды Unity и Mixed Reality Toolkit (MRTK).

На всякий случай оставим здесь руководство по UWP от Microsoft.

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

Вы руководите командой из нескольких программистов и художников, работающих над портированием красивой VR-игры на PS4 под Oculus Quest. У вас есть на это шесть месяцев. Каким будет ваш первый ход? Давайте попробуем воспользоваться Unity Addressables.

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

Предположу следующее: примерно 70% читателей скажут, что самой большой проблемой при портировании игры на Quest является производительность ЦП/GPU. Я могу ответить на это: скорее всего, вы правы. Повышение производительности — одна из сложнейших областей в VR-игре. Для оптимизаций такого типа необходимо глубокое изучение продукта, а на это требуется время. Иногда дальнейшая оптимизация невозможна, из-за чего обычно приходится избавляться от затратных элементов геймплея и графики. А разочаровывать игроков опасно.

Если вы побродите по форуму DOTS, то можете встретить там подобные посты о том, как автор написал библиотеку, способную рендерить миллион анимированных спрайтов, и всё равно получает только 60fps. Я создал собственный рендерер спрайтов DOTS, который достаточно хорош для нашей игры, но он не способен справиться с миллионом. Мне стало любопытно.

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

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

Вот список типичных проблем:

1. в репозиторий попадают ненужные файлы или наоборот не попадают нужные
2. множество больших файлов раздувает размер репозитория
3. проблема с мерджем yaml файлов Unity
4. в репозиторий добавлен только сам файл или только meta
5. в проекте присутствуют пустые папки
6. сложность автоматической нумерации версий и билдов
7. неудобство использования кода между несколькими проектами

О решение этих проблем, связанных с совместным использованием git и Unity, вы можете прочитать в моем цикле статей.

В этой статье будет описано решение первых трех проблем

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

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

Помните созданный нами класс Position? Вообще-то в Unity уже имеется встроенный класс, выполняющий точно такие же функции, но с немного более качественным управлением — его проще объявлять и обрабатывать. Этот класс называется Vector2Int. Поэтому перед началом мы удалим из MapManager.cs класс Position и заменим каждую переменную Position на переменную Vector2Int.


Это же надо проделать в нескольких местах скрипта DungeonGenerator.cs. Теперь давайте приступим к остальной части алгоритма.