Unity *

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

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

Значит надо создать какое-нибудь окружающее пространство для услады взора игрока. Для начала поле зрения игрока следует ограничить, ведь заполнять всё пространство от игрока до горизонта моделями затратно как по времени, так и по производительности.

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

За всю карьеру удалось поработать на множестве игровых проектов в качестве лида. За более чем 5 лет удалось насмотреться на разные подходы к созданию проектов.

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

Не волнуйтесь, никаких SOLID и других изотерических практик. Коротко, по делу, подкрепленное использованием на нескольких проектах.

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

Привет, Хабр! Меня зовут Игорь, и я Unity Developer. В этой статье я хотел бы поделиться кейсом, как Test Driven Development помогает мне разрабатывать мою RTS игру.

Недавно анализатор PVS-Studio начал выдавать предупреждения о возможностях оптимизации кода в проектах под Unity Engine. Какие они, эти предупреждения? Как анализатор понимает, какой код стоит оптимизировать? Почему это сделано именно для Unity? Ответы в заметке.

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

Меня зовут Игорь, и я Unity Developer. В этой статье я хотел бы поделиться кастомной архитектурой, которую сделал в процессе разработки своей RTS игры.

Скажу сразу: что основные концепции и принципы уже используются в различных DI фреймворках, таких как Zenject & VContainer. Поэтому чего-то феноменального в этой статье вы не увидите. Но, поскольку я люблю делать свои велосипеды, то в свою архитектуру я привнес парочку интересных вещей, которых нет в других DI фреймворках на Unity. Ну шо, поехали :)

Привет, Хабр! Меня зовут Игорь, и я Unity Developer. В этой статье хотел бы рассказать, как можно делать модульные механики для игровых объектов, за счет разделения данных и логики без ECS.

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

Апдейт: ведущий разработчик Godot Хуан Линьетски опубликовал ответ на этот пост.

Привет! Меня зовут Даниил, я занимаюсь саунд-дизайном (sound design) и пишу музыку. Это первая моя статья и по совместительству пилотная в планируемом цикле; поэтому, вероятно, она будет содержать дополнительную информацию, которую я планирую перенести в отдельную публикацию (если данная серия получит продолжение).

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

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

Примечание: предполагается что читатель знаком с базовыми принципами работы в FMOD и Unity.

Сейчас я планирую рассмотреть наиболее нетривиальные моменты с упором на процесс имплементации аудио. В противном случае статья может незаметно превратиться N-страничный нечитабельный талмуд. Все учебные проекты, о которых будет рассказано, находятся в свободном доступе и выполнены на Unity engine (Asset Store) и Unreal engine (Unreal Engine Marketplace).

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

Наверно, произошло что-то плохое, и теперь вы читаете эту статью. Сочувствую! Давайте начнём по порядку.

Меня зовут Джо Уинтергрин, я генералист Unreal Engine. Можете взглянуть на все мои ресурсы. В статье я приведу полезную информацию для новичков в Unreal, имевших опыт работы с Unity.

С чего начать?

• Прочитайте документацию по Gameplay Framework. Всю целиком! У Unreal есть Gameplay Framework. Прочитайте документацию и освойтесь в ней. Это правильное решение при разработке любого типа игры. Не пропускайте её. Держите её под рукой, чтобы перечитывать.

• Влейтесь в сообщество. Это учетверит вашу скорость обучения. Есть Discord для бывших Unity-разработчиков Алекса Роуза и есть мой Discord.

• Почитайте Epic Online Learning Library. Вот она. Делайте упор на статьи, написанные Epic Games.

• Скачайте последнюю версию Unreal Engine из Epic Games Launcher. На данный момент это 5.3. В общем случае всегда стоит начинать проект на самой новой версии. Кроме того, нет никаких причин больше пользоваться UE4 — UE5 лучше и имеет все возможности UE4.

• Изучите документацию «Unreal Engine for Unity Developers» компании Epic. Это хороший способ начать. Вот она.

• Прочитайте статью целиком. Я знаю, здесь много текста, но не ничего не пропускайте! Всё это очень важная и точная информация! В Интернете много некачественных сведений об Unreal, но не здесь. Здесь всё правильно.

Это вторая статья из серии про использование async/await в Unity. В первой мы разобрали восемь причин отказаться от Coroutine в пользу Async. В данной же статье посмотрим на самые распространённые ошибки при использовании async/await.

Разбор полётов. В чём суть смены модели лицензирования Unity? Чем это грозит? Убьёт ли это инди и, в частности, гиперказуалки? Нужно ли прям сейчас бежать на другой движок?

В Unity есть класс Gradient, который предоставляет удобные средства для управления градиентом в рантайме и редакторе. Но т.к. это класс, а не структура использовать его через Job system и burst нельзя. Это первая проблема. Вторая проблема — это работа с ключами градиента. Получение значений осуществляется через массив, который создаётся в куче. И как следствие напрягает сборщик мусора.

Сейчас я покажу как можно решить эти проблемы. И в качестве бонуса получить увеличение производительности до 8 раз при выполнении метода Evaluate.

Изначально статья была написана в январе 2023

Думаю не стоит лишний раз напоминать о той обстановке, в которой мы живём последний год. Как только всё тогда началось, вновь пошли разговоры про импортозамещение и поддержку отечественного производителя, в том числе и в IT. Было очевидно, что в нашей стране за последние N лет в этом отношении было сделано немного, мягко говоря. Тем не менее, ещё не всё потеряно. :-)

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

Делаю ККИ на Unity. В программировании совсем новичок. Долго отнекивался от использования нейросетей, но решил попробовать и СhatGPT подсказала подходящие решения и помогла быстрее изучать программирование.

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

Для систематизации работы интерфейса предлагается заимствовать опыт из веб разработки.