Unity *

Прочитал как‑то на Хабре заметку «Что делать с детьми летом, если ты айтишник?» Ответил на нее двумя своими заметками (раз и два). А теперь предлагаю взглянуть на поднятую тему немного с другой стороны: с точки зрения «борьбы с цифровым неравенством»? С тем самым, которое проявляется в ограниченном доступе к информации. По мнению некоторых отечественных экспертов, для ее преодоления, якобы, достаточно всего лишь «100% обеспечение образовательных учреждений, учреждений здравоохранения, органов государственной власти и местного самоуправления современными услугами цифровой связи»... Про борьбу с «цифровым неравенством» учреждений здравоохранения и органов госвласти промолчу... А вот про образование скажу — «Хошь, как хошь, а маловато будет!» А что, по‑вашему, уважаемые эксперты, получат «преодолев цифровое неравенство» наши «рядовые» школьники? Складывается стойкое убеждение, что единственное, что они получат — это игромания. Где те ресурсы, которые помогут расширить их знания, разовьют полезные навыки? Где (адаптированные на соответствующий возраст) методические материалы, которые сделают доступными нашим детям хотя бы уже имеющиеся в сети Интернет полезные ресурсы, созданные в других странах?

Привет! В этой статье мы поделимся опытом создания нашей первой игры, несмотря на то, что мы не имели большого опыта в создании игр.

Специфика моей деятельности связана с имитационным моделированием технологических объектов и процессов (как сейчас модно говорить - цифровые двойники, оптимизация, тренажеры для обучения персонала). И конечно в этом деле постоянно сталкиваюсь с задачей сетевого обмена информацией и синхронизацией данных, как при реализации многопользовательского режима так и при организации сетевого обмена между отдельными моделями. И вот наблюдаю интересную картину — некоторые производители цифровых двойников и тренажеров используют стандарты для этого всего (например OPC UA, IEEE 1516, DDS (Data Distribution Service), MQTT, CAPE‑OPEN, xAPI), а некоторые — делают самоделки, причем закрытые. Особенно меня удивляют товарищи, создающие эти самые самоделки, ни с чем не совместимые и абсолютно закрытые, только для того, чтобы потом с этими самоделками являться «единственным поставщиком» скажем так, требуя при этом совместимости со своими велосипедами, да еще и являются организациями, которые сами же и проверяют совместимость стороннего ПО со своими‑же велосипедами. Жуть, в общем.

Серия Grand Theft Auto стала культовой в игровой индустрии, а San Andreas — одной из самых запоминающихся частей для многих игроков. Время проходит, но фанаты всё так же преданы игре. Кто-то достаёт старый и пыльный диск с ностальгией, а некоторые заходят ещё дальше. Сегодня проверим фанатский перенос GTA: San Andreas на движок Unity с помощью статического анализатора PVS-Studio!

В свежей версии 2023.2 TS появилось несколько кроссплатформенных улучшений. Поработали над производительностью (в особенности — над тормозами освещения на мобилках). Нарисовали более красивые атмосферные эффекты для HDRP. Продумали использование VFX Graph. Проапгрейдили UI Toolit, починили баги для VR. Вернулись к понятной схеме названия версий: Не Unity 1234.5 XYZ, а просто Unity 6.

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

Фрустрация + неизвестность + подготовка к госам/диплома + изучение C# = достаточный уровень напряжения и стресса.

[Первая часть]

Генерация скайбокса

В игре используется встроенная система неба HDRP Unity, то есть она генерирует текстуру скайбокса (кубическую карту) в каждом кадре. Это занимает около 0,65 миллисекунды, что не очень много по сравнению со всем остальным, но если игра нацелена на генерацию 60 FPS, то это будет почти 4% от общего бюджета времени на кадр.

Предварительный проход

Теперь мы переходим к самому рендерингу. В C:S2 используется отложенный рендеринг: по сути, это означает, что рендеринг выполняется за несколько фаз и с использованием множества промежуточных render target. Первая фаза — это предварительный проход, создающий попиксельную информацию о глубине, нормалях и (преположительно) о гладкости, записывая их в две текстуры.

Этот проход на удивление затратен, он занимает примерно 8,2 миллисекунды, то есть слишком много, и именно здесь начинает проявляться одна из самых больших проблем рендеринга игры. Но для начала нам нужно поговорить о тех самых зубах.

Одна из самых долгожданных игр для PC Cities: Skylines 2 вышла в конце октября, но получила смешанные отзывы. По моим ощущениям, геймплейно и с точки зрения симуляции игра сделала шаг в правильном направлении, и по крайней мере, теоретически она выглядит более целостной по функциям, чем первая часть. Однако в ней присутствуют существенные изъяны, от проблем с балансом и спорных дизайнерских решений до багов, из-за которых экономическая симуляция игры становится практически бесцельной. Стала ли она достойным преемником оригинала — пока вопрос открытый, но все сходятся в одном: производительность проекта далека от должного уровня.

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

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

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

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

За всю карьеру удалось поработать на множестве игровых проектов в качестве лида. За более чем 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 Хуан Линьетски опубликовал ответ на этот пост.

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

Меня зовут Джо Уинтергрин, я генералист 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.