Comments 57
Последние лет 6 работаю как Unity Game Developer (точнее Software Engineer, но сути это не меняет). Несколько компаний, в том числе разработка мобильной игры для Iron Maiden, нового центрального AR аттракциона в Universal Studios и т.д. Всё было более менее хорошо и понятно, пока не появился UE5. Поставил "побаловаться" и всё, приехали.
В общем. Если очень коротко, то у меня с самого начала изучения Unreal 5 культурный шок (это будет видно из моего комментария). В движке всё есть и всё работает. Из самого простого и первого, что увидел:
1. Nanite. Технология из 300400 года. Unity даже с DOTS (ECS) на пару порядков медленнее (я пробовал) отрисовывает такое число треугольников - т.е. забудь. Т.е. это не наверстать в ближайшее время, тем более, что Epic эту технологию разрабатывают уже много лет и, вероятно, есть патентная защита.
2. Lumen. Технология из 300401 года. Realtime Global Illumination плюс reflections. Без RTX карты. Unreal 60 раз в секунду делает то, на что у Unity уходит час, чтобы запечь GI для статичных объектов. Т.е. в Unity про динамический GI забудь (точнее можно с RTX, но всё равно медленно и грустно), тем более, если на сцене сотни миллионов треугольников. При этом GI в Unreal настраивается на порядок проще и быстрее и даёт лучше результат, чем статический в Unity (есть нюансы, с тем, что в Unreal это всё таки больше Screen Space GI, но всё же).
3. Blueprints. Отличное решение, которое избавляет от десятков проблем. Из плюсов Unity как раз отсутствие плюсов и C# (собственно, поэтому, многие на Unity и сидят). Но в результате Unity медленный и GC. Про быстрый C++ в Unity забудь, на зато в Unity зачем-то (судя по всему просто по инерции опять повторяют то, что уже давно есть в Unreal) тоже прикрутили BluePrints.
4. Звук. Из коробки всё автоматически работает, при этом учитывается геометрия сцены (за стенкой не слышно). В Unity забудь.
5. Отличная, быстрая физика со встроенное системой разрушения (!!!). Опять просто из коробки. В Unity забудь.
6. Networking запускается "одной галочкой" в редакторе. Из коробки. Феноменально. В Unity мне пришлось покупать asset за $100 и потом оказалось, что он всё равно не делает то, что мне нужно, плюс его нужно прикручивать месяцами и отлаживать. В данный момент про нормальный Networking в Unity забудь. Т.е. про свой нормальный FPS вообще забудь.
7. Движок сам строит сложные colliders для любых mesh (!!!) и при этом делает это очень хорошо. В Unity забудь - расставляй руками унылые боксы и сферы по сцене.
8. На сцене сразу видно, что будет в игре. Поэтому в Unreal один экран. В Unity забудь. Всегда будешь постоянно прыгать между двумя экранами.
9. При нажатии кнопки Play игра запускается мгновенно (!!!). В Unity забудь. Каждый запуск - это ожидание. Частично помогает отключение перекомпиляции, но это совсем не то.
10. Огромные, встроенные в редактор(!!!) бесплатные коллекции отличных assets, включая Mesh, Texture и лучший редактор людей на рынке. В Unity забудь. Вообще, традиция такая, что если Epic покупает компанию, то её Asset для пользователя Unreal становятся или дешевле и бесплатно, при этом выгоднее создателю Asset (меньше комиссия). Если Unity покупает компанию, то просто, чтобы заработать деньги.
11. Отличный редактор материалов. Всё легко просто и понятно. В Unity тоже попытались такой нодовый прикрутить, но получилось как всегда так плохо и уныло, что им очень сложно и "противно" пользоваться.
12. Volumetric облака! Быстрые, красивые, фотореалистичные и опять из коробки.
13. Очень быстрый и реалистичный DOF и Volumetric Light. Опять из коробки. В Unity (ну вы догадались).
14. Отличная ценовая политика Unreal. Unity на его фоне - это просто грабёж (ещё и за пустой, в сравнении с Unreal движок).
15. Meta Humans. Без комментариев.
И так далее.
Вообще, у меня впечатление, что ситуация, примерно, такая. Есть UE - т.е. лучший движок на рынке, который содержит в себе всё, что нужно и даже больше, который бесплатный, быстрый и вообще топ. Он так хорош, что на нём быстро накидали игру на которой зарабатывают "сотню миллионо в день" и вливают их в развитие движка делая его вообще недосягаемым (все эти Nanite, Lumen, Meta Humans и т.д.) Есть Unity. Из плюсов - C# (как посмотреть, но пускай), 2d, webGL, мобильные приложения (наверное, не сравнивал для них). Из минусов всё остальное. Как я понимаю, Unity хоть как-то на плаву, потому, что они очень сильно вливаются в рекламу и рассказывают о своих успехах на каждом углу. Но сейчас, после выхода UE5 компании Unity будет непросто. Когда я сравниваю их, то вижу, что Unity постоянно пытается хоть как-то догнать Unreal и пытается прикрутить то, что в Unreal есть уже давно. При этом, когда прикручивают, то получается плохо (это касается практически любой системы Unity - начиная от анимации и заканчивая редактором материалов). Вообще, Unity в сравнении с UE пустой. В нём ничего нет и если тебе что-то нужно, то приходится писать самому. Типа вот вам медленный и кривой движок, а чего не хватает - доделайте сами. В UE уже всё есть, всё работает быстро, удобно и правильно и нужно это просто настроить под себя.
Компания Unity несколько раз мне работу предлагала (я отказывался). Плюс недавно интервью попросили, заплатили $50 за него. В процессе много спрашивали, устраивает ли меня их монетизация и сколько я готов платить за их сервисы и какую платную подписку предпочитаю. Самый важный вопрос для компании, как я понял. Я им сразу сказал, что есть Unreal у которого всё, что они продают за очень большие деньги есть бесплатно и лучше работает.
Почему так получилось? Возможно, потому, что Unreal это C++ и таким образом происходит отсев скажем так "начинающих" программистов - в компании просто работает больше крепких профессионалов (я бы даже сказал гениев, которые написали Nanite и Lumen) и пока Unity будет на C# так всё и останется - UE топ, Unity - пытается догнать, плохо и неумело его копируя.
Прогноз. Многие разработчики и компании в ближайшие пару лет пересядут с Unity на Unreal Engine и правильно сделают.
Для себя за день набросал небольшую demo на Unreal Engine EA5. Если честно, то пока делал не мог поверить, что всё это работает и что всё так быстро и просто получается. Рассказывать мне, что в Unity на RTX и HDRP и DOTS можно то же самое с такой же сценой за день (да хоть за год) сделать мне не нужно. Нельзя. При этом я для Unreal даже ничего не оптимизировал - все объекты тут отдельные уникальные Mesh (например, 8 "разных" стульев, все кружки, тарелки и так далее) c несколькими 4К текстурами на Mesh даже там, где они вовсе мне нужны. Всё это "крутится" realtime не на самом топовом железе (при этом я в UE ничего не понимаю и, конечно, мог бы сделать всё "быстрее и красивее", если бы у меня уже был опыт).
Отличный комментарий, спасибо
Вот это комментарийще, конечно! Длинно, красочно, развернуто и совершенно мимо (8
Никто не сомневается в преимуществах UE при разработке ПК шутеров, но про перспективы Unity могут поспорить сотни компаний, выпускающие на нём успешные игры, в которые играют миллиарды.
Спасибо, крутой комментарий :) Вот по поводу UE 5 я как раз написал, что тут уже об одинаковой графике не очень уместно говорить, и я слишком мало отзывов видел, чтобы иметь на этот счёт мнение. А к новым технологиям отношение всегда с подозрением. И по большей части пунктов я согласен за исключением нескольких.
По пункту 3. Да, но тут всё не так просто. На блюпринтах насколько я помню объективно можно сделать не всё, особенно скажем то, что касается работы с сетевыми сокетами и прочим. Но говоря про C# и т.п. В целом благодаря CLR в Unity можно писать на совместимых с CLR плюсах если очень хочется, но при умении работать с GC в среднем тот факт, что C# "медленнее" не играет никакой роли. При грамотной стратегии управлении кучей там всё в порядке. Да С++ в Unity в среднем будет немного медленнее из-за маршалинга, но скажем так в большей части проектов это редко является критом.
По пункту 5. Я бы ещё сказал про автолоды, так как в UE они из коробки, а в Unity ставятся плагином. Но скажем так, с точки зрения бизнеса купить плагин за 100$ это не проблема. А разрушаемость в UE по своей алгоритмической части не супер сложная. Я писал когда-то подобные алгоритмы.
По пункту 6. Да нет, я скажу так - забудь про реалтайм репликацию, предикшен и т. п. без Photon. По поводу сети это не совсем так, потому что сокеты и в целом весь стек TCP/IP работает отлично. Я чаще всего без плагинов сижу на своих сетевых реализациях, потому что мне так чисто удобнее. А в случае мобильных игр тебе хватит RUDP коннекта для реалтаймовых функций с низкими задержками и HTTP коннекта для всяких остальных сервисов. Выдача изображений, иконок и т.п.
По пункту 7. Я бы тут сказал не Box, а convex mesh colliders. И тут скорее вопросы к Nvidia, так как таким образом работает PhysX. Но в целом в Unity вроде как заехал хавок, но я с подозрением отношусь ко всему новому в коммерческих проектах, так что пока не смотрел что там.
По пункту 8 и 9 сразу. Я согласен что система сцен у юнити по сравнению с UE - забей. Тут бы я ещё правда указал про то, что насколько я помню в UE сеть можно тестировать без пляски с запуском нескольких редакторов и прочей дичи, а можно в рамках одного инстанса редактора запустить два инстанса игры.
По пункту 10. Согласен, просто я говорил о том, что с точки зрения продакшена (без Nanite и Lumen) графика добивается одинаковая. Ощущение что графика на UE лучше создаётся именно за счёт того, что там изначально ассеты качественнее, постпроцессинг включен и т.п.
По пункту 11. Как человек обожающий рендер - я в целом не люблю нодовые редакторы. А hlsl и glsl везде одинаковые, так что не могу ничего сказать. Я то нодовый редактор Unity запускал пару раз :)
По пунктам 12-13. Это не так важно с точки зрения принятия решения о технологии на проекте, так как в Unity и то, и другое и пачка всего есть на гите. Так как комьюнити больше, то из коробки там меньше, но одни репозитории keijiro на гитхабе https://github.com/keijiro можно очень долго изучать. Тут типа тонкий момент. Меня в первую очередь интересуют базовые технологии, так как благодаря комьюнити на Unity на данный момент больше разнообразие готовых решений. Качество там конечно нужно фильтровать, но тем не менее.
По пункту 14. Тот пункт с которым я совершенно не соглашусь. И тут очень зависит от проекта. 6% роялти в любом случае - это реальный грабёж с точки зрения бизнеса. 300-1500$ в год - это копейки. В контексте аутсорса так особенно, но для него эпики ввели новую модель, как и для небольших проектов. Но роялти всегда дороже. Поэтому я бы не назвал ценовую модель юнити грабительской. Они похожи +-, и я не хотел бы чтобы юнити в обязаловку вешало роялти, скорее это было бы причиной моментальной смены движка.
А по поводу отсева разработчиков. Важно понимать, что я смотрю не только с позиции разработчика, а ещё и с позиции бизнеса. Про отсев и т.п. согласен, вообще что логично С++ разработчики в среднем выше уровнем любых других разработчиков, так как если ты не знаешь низкий уровень работы ПК - то тебе не стоит даже приближаться к коммерческой разработке на плюсах (самостоятельной так точно, только под контролем сеньора грамотного) Потому что С++ тот язык, где нужно достаточно конкретно писать чего ты хочешь от тачки. Но вот по бизнес причинам с одной стороны, и что скорее плюс для разработчиков с другой UE специалисты дороже. И найти их сложнее. И тут чисто по бизнес причинам вопрос в проектах, потому что есть огромный спектр проектов где между движками не будет разницы. Допустим у тебя бюджет проекта 10-50к$. На такие суммы в среднем, если не делать "одну комнату" у тебя не будет возможности выжать всю графику даже из UE. Если у тебя не реализм, а стилизация так вообще. И реализация на юнити, при не особо великой разнице, выйдет просто дешевле. Поэтому для большого спектра задач для меня оба движка одинаковы за исключением мелких нюансов. В контексте бюджетов проектов интересуют лишь базовые технологии, и что можно сделать с ходу. И тут я немного несоглашусь с понятием "из коробки". Пакетами, редакторами, миллионом бесплатных репозиториев, разница между подключением в Unity красивой графики и анреаловской коробки (опять таки не беру нанит и люмен) - 100$ максимум и час времени. А вот по поиску разработчиков, срокам разработки, затратам на разработку UE в среднем будет дороже. Поэтому основной вопрос для меня, как для техдира. А зачем?
Кто-то должен и сказать о плюсах юнити (хоть и не явлюясь его сторонником). На анриле много не работал за деньги.
Удобная система package-й. Да в анриле есть плагины и они появились раньше, но там они не выкачиваются по гиту, да и работать с ними чуть труднее.
Небинарная система хранения данных. Да тут от любого чиха изменения - тоже вылезает в vcs вылезает 100500 изменений, но все же в теории можно работать над одним файлом (но если вы так делаете,то у вас фиговые процессы разработки). Да и исходники контента проще обновлять - нужно изменить настройки у файла, то у тебя изменяется только мета файл, который отлично кушается vcs и видны изменения.
Намного проще работа с контентом путем миграции юнитипекейджей (в анриле с мигрейтом чуть сложнее).
Юнити намного френдли для 2д (вон всяких спрайтов добавляют и как их воротить на сплайнах, 2д сетки, скелетал спрайты - все это без Spline).
Если затронулась тема контента - то в юнити атласы для спрайтов делаются вообще без гемора.
Addressables - универсальная вещь для контроля ваших ассетов и c удобным их деплоем. (Хотя с ChunkDownloader уже что-то похожее на аа выходит).
Более удобная работа с шейдерами, когда нужно залезть чуть глубже просто смешения текстур (сменить освещение, заюзать compute shader). Хотя в анриле есть уже плагины по смене освещения без залезания в дебри сорцов.
В юнити лучше освещение для мобилок - лайтпробы. В анриле зато появляется десктопный forward, но непонятно что там с поддержкой volumetric lightmaps и с приходом lumen - на это могут и забить (
тот случай когда комментарий лучше статьи отвечает на поставленный вопрос (в статье кстати так и нет ответа на вопрос из заголовка)
а если интересуют от простых до 3д мобильных игр, вот что рассматривать ?
я в разработке не новичек.
даже когда то на C++ программил , очень давно .
но теперь я стал ленивый. хочется меньше ковыряться, больше создавать.
Если именно создавать и даже не париться со встроенным Visual Scripting или блюпринтами, то вариантов по сути немного (всё проверено лично):
1) Unity + Built-In Render Pipeline + Post Processing Stack 2 + что-то для волюметрического света и тумана (Aura 2, например) + Game Creator и его модули (докупаются по необходимости) - великолепное высокоуровневое решение для быстрого создания игровой логики. В UE4 аналога нет.
2) Unity + Universal Render Pipeline + Lux URP Essentials + все тот же Game Creator с модулями.
Если не возражаете, задам вопрос :)
Сейчас выбираю движок для 2d игры, много читал про доступные варианты, в том числе про то, что для простых 2d игр ue тянет слишком много либ, чрезмерно перегружая билд и итоговое приложение, что также влияет на конверсию.
На unity достаточно быстро сделал демку игры, UE даже не разбирал практически.
Как считаете, есть ли смысл потратить время и поработать также и с UE, как с более перспективным решением? И является ли он перспективным в контексте 2d вообще?
На всякий - C# или C++ выбор для меня не существеннен, есть опыт коммерческой разработки на обоих, достаточный для реализации простой игры.
Заранее спасибо за ответ :)
Не возражаю, но отвечать могу раз в сутки - карма слита.
Про UE для 2d тем более для мобильных не подскажу - нет опыта. Я больше писал про сетевые First Person Shooter на производительных платформах. В целом, я бы сказал, что и Unity для совсем простых мобильных игр "перегружен" - есть ещё более простые и компактные (по размеру build) решения.
Мой комментарий был не про то, что выбрать - это индивидуально для каждого проекта и автор статьи рассказал про это. Я просто попытался описать свои мысли и первые шаги на UE5 после Unity 2021.1. Плюс, я бы добавил, что субъективно мне UE ближе, понятнее и логичнее. Он более цельный и готовый. Плюс сегодня даёт такую картинку, которую не может дать никто (Nanite, Lumen). Для меня редактор выглядит более "умным" - с ним приятнее работать. В Unity мне постоянно не хватало то одного, то другого. Все системы какие-то кривые, непонятные и неудобные - видно, что оставлен огромный запас на то, чтобы можно было сделать вообще всё и в результате универсальности делать всё избыточно сложно. Например, cinemachine. Хорошая идея. Но столько всего намешано, что местами проще самому с нуля написать, чем преодолевать ограничения. По идее им можно было просто 3 умных камеры написать для разных ситуаций и всё - кинул на сцену и работает. Но нет. Ты будешь её неделю настраивать и всё равно она не заработает на 100% как тебе нужно. И так везде. В системе анимации со всеми этими состояниями и слоями, в раздельных URP и HDRP, в новой Input System, которая такая "монстроподобная" и универсальная, что мне было проще в свои API её завернуть, чем настраивать и т.д.
На UE у меня ощущение, что я просто делаю игру. На Unity - что я пишу движок, чтобы уже на нём сделать нужную мне игру. В UE мне с ходу дают Game Mode и все нужные "заготовки". В Unity - пиши сам, ищи, покупай. В UE5 у меня на первом же запуске своего простейшего проекта в голове крутится "Не верю. Такого не бывает. Это же realtime. Фантастика. Слёзы на глазах". В Unity что-то прекрасное, я могу увидеть только в специальном поекте Adam, в котором запечено всё, что только можно, включая анимацию. Если же открыть стандартную HDRP технологичную (по мнению Unity) сцену, то в голове "Почему так медленно? Что нужно опять отключить, чтобы поднять FPS? Почему даже с HDRP и на RTX всё так грустно и в каком месте говорить Wow!?
Но, так или иначе, я и сам сейчас работаю с Unity и будут это делать ещё какое-то время - как минимум для WebGL проектов - итоговый размер build для Web - 6 MB, почти все Assets лежат на ftp сервере - Addressables. Ambient occlusion (хоть какой-то) есть и на том спасибо. Красота :)
-По поводу "в анриле всё из коробки работает отлично", это справедливо для всего что уже там есть. Но если нужно что-то поменять или добавить, я про расширение редактора. То это забей. Ну т.е. не всегда можно отдельный плагин прикрутить, иногда сам движок нужно менять. Это занятие не из приятных, а если еще на новую версию переходить, то тяжело поддерживать. В юнити многого нет, но там на много проще расширять редактор, и это будет работать и после обновы(за редким исключением).
-Проект делать дольше в анриле. К сожалению у меня нет достаточно инфы, могу лишь предположить что для проекта на анриле, если это не демка, а полноценная игра с графоном и разнообразным геймплеем, нужно ощутимо больше времени и более крутых чуваков в команде, а на юнити можно сделать графон чуть попроще, но быстрее. Т.е. создать клон уровня АА с юнити анрил будет дольше чем с анрила на юнити, но если это ААА, то на юнити возможно придется урезать графон или чуть дольше повозиться с оптимизацией.
-Ждать пока перебилдиться код в анриле нужно вечность. Код движка менять это долго, а потом нужно закомитить чтобы другие разрабы подцепили. Да, там есть hot reload, но он у меня криво работал, частенько вылетал. В юнити с этим на много лучше. Это наверное касается именно для тех кто меняет код, а для тех кто только в редакторе что-то делает, то анрил наверное шустрее.
Но опять же C++ vs C# думаю очевидно C# проще, но C++ быстрее. Писать блюпринтами думаю не серьезно. Быстрее кодом.
-Система контроля версий и анрил, это ад. Можно работать с ассетами только внутри движка. Я не могу нормально посмотреть какие изменения были в том файле того коммита. Ты просто обязан смириться с тем что есть. Да и плагин этот с багами. А нормальные не работают с анрилом. Поменял файл, и весь файл нужно комитить а не только измененный кусок, потому что бинарный. Не понимаю почему не сделают текстовый формат...
-Графон без сомнения шикарен и работает лучше чем юнити, но это на ПК. Когда мы доходим до мобилок, то все эти преимущества сразу исчезают. Приходится писать оптимизированные шейдеры/материалы всё так же как и на юнити.
-Если говорить про то что есть "из коробки": в юнити есть DOTS, а в анриле нет. Хотя и к анрилу можно что-то подобное подключить наверное. Не то чтобы DOTS это что-то незаменимое, но всё же.
Есть еще ML-Agents, а в анриле нет. Так же Unity Simulations, Build Server(хотя тут не уверен может и в анриле есть готовое решение).
-В юнити на много удобнее работать со связями между объектами. К слову в анриле нельзя свойствах объекта указать ссылку на компонент(свой или чужой). Это нужно делать через код, иначе никак. Не то чтобы это критично, тут вопрос к архитектуре движка, но всё же в юнити просто перетащил компонент в нужное поле в инспекторе и радуешься, меньше зависимостей в коде, хотя и этот подход не идеален.
Unreal не идеален, к сожалению. Пользоваться готовыми решениями легко, но редко когда хватает того что там уже есть и очень часто хочется расширить редактор, но из-за того что это сложно, проще просто забить и чуть страдать в замен на плюшки в виде Nanite, Lumen,...
Если проект на ПК и готовы смириться со сложностями выше(или у вас есть специально обученный человек по решению этих проблем), то смело юзайте анрил. Но если мобилки, а еще другие платформы, или игра которая не требует крутого графона, то на юнити будет проще, удобнее и быстрее даже с учетом его минусов.
Новичку сделать демку на анриле наверное будет проще. Но поработав в юнити с разными прикольными/полезными плагинами, анрил покажется не таким удобным.
Я сам после юнити страдал в анриле, потому что там не было всего того что было в юнити(в том числе мои плагины). И эти плюшки в виде быстродействия кода, красивого графона, не пересилили недостатки которые там есть по сравнению с юнити и я бросил анрил. Хотя хочется вернуться, залезть еще разок в исходники анрила и приблизить движок к идеалу :)
Насколько я понял, анриал не про компоненты. Да и перетаскивать компоненты в объект с других объектов это слишком хрупкая архитектура.
Ну там есть компоненты. И это полезная вещь, т.к. можно из разных компонент конструировать какой-то цельный объект.
Проблемы начинаются когда нужно как-то связать 2 компонента.
Приведу пример: я хочу создать такой компонент который я буду кидать на объект и он будет крутиться. Т.е. есть куб, хочу чтоб он крутился и просто кидаю туда компонент RotatorComponent. И всё бы ничего, в таком виде это будет работать, но что если например я захочу менять параметр другого объекта, например цвет лампочки анимировать. В этом случае мне нужен доступ к компоненту Light а не к Actor-у. В текущей архитектуре для решения этой проблемы мне нужно указать ссылку на Actor(да, Акторы можно в поля указывать, а компоненты нельзя), и название компонента в виде строки, а в коде уже найти нужный компонент у Actor-а по названию(либо по типу, но если там несколько компонент внутри, то так не получится), что звучит очень плохо, потому что название можно поменять и всё сломается. Либо нужно создать еще один класс для конкретного объекта "лампочка с анимацией цвета". Хотя проще же просто кинуть компонент, и в любой момент удалить, либо заменить на другой тип анимации, переключение цвета по триггеру и т.д.
По моему такая архитектура лучше чем хардкод с зависимостями, которые сложно потом расширять.
Можно попробовать создать интерфейс, который будет возвращать нужный компонент из актора. Делаешь ссылку на актора, в блюпринте кастуешь его в нужный интерфейс и берешь компонент.
Можно, но не всегда. Доступа к чужим классам иногда нет, а наследоваться не хочется. А еще так можно указать в параметр Актор у которого нет нужного интерфейса, т.е. даешь возможность совершить ошибку.
Я точно не помню какая именно ситуация у меня была, помню что спрашивал в форумах и никто не смог мне помочь, пришлось находить другое решение, менее привлекательное.
Меня печалит что эту схему можно относительно легко реализовать в движке, но этого нет, и кто не хочет может старую архитектуру использовать, т.е. никому хуже не будет.
-Ждать пока перебилдиться код в анриле нужно вечность. Код движка менять это долго, а потом нужно закомитить чтобы другие разрабы подцепили. Да, там есть hot reload, но он у меня криво работал, частенько вылетал. В юнити с этим на много лучше. Это наверное касается именно для тех кто меняет код, а для тех кто только в редакторе что-то делает, то анрил наверное шустрее.
Для комфортное работы в UE нужен нормальный комп. Это сущяя правда. Я пришел к 8 ядернику с M2(и движок и проект на нём). И вот тогда работа стала комфортной. Релизный проект с кучей кода собирается около минуты. hot reload стал использовать реже.
Сам Юнити на писан на С++, если что. Это к абзацу "Почему так получилось?"
Но в целом, соглашусь. Потыкал UE месяц, почти никакой головной боли с контроллером персонажа - тут из коробки тебе и физика, и двойные прыжки, и передвижение по платформам. Порадовало, особенно после того, как я пересмотрел с десяток сторонних персонажей на для Юнити.
Возможно, потому, что Unreal это C++ и таким образом происходит отсев скажем так "начинающих" программистов - в компании просто работает больше крепких профессионалов
Но разве сам движок юнити не на плюсах? Я имею ввиду именно с точки зрения разработки самого движка
В целом статья разумная, но есть пара UE нюансов.
С++ с UB и утечками это не про UE. Я бы вообще не сказал что в рамках UE мы пишем на плюсах. Это свой отдельный UE C слишком сильно он накручен макросами, плюс GC, стандартная библиотека под запретом, new/delete не рекомендуется к использованию(и не нужен)... Ну какой это С++? )
Ну тут я не разбирался так глубоко, так что согласен. И подобное скорее интересно было бы послушать, как грубо говоря "мнение UE разработчика относительно Unity". Так как я пару раз погружался в анреал, но не могу сказать, что в нём разбираюсь прям глубоко. Ну и у меня немного другие критерии оценки технологии.
Вобще-то, в современном C++ (C++11 и новее; вероятно, можно с более старыми стандартами с boost) использовать new и delete в любом случае не рекомендуется, в большенстве случаев. См. C++ Core Guidelines:
(быстрый поиск по "new and delete"; вероятно, есть и другие релевантные пункты)
Имеется в виду, что в большенстве случаев следует использовать умные указатели (smart pointers; std::unique_ptr, std::shared_ptr).
Про другие особенности использования C++ с Unreal Engine ничего сказать не могу.
3. Круто для быстрого прототипирования, мержить — боль и уныние, либо строгое разделение, лучше основа в С++, а выводить крутилки и мелочь в БП.
Хотя уже анонсили скриптовый язык завезти свой, пока ни слуху ни духу, посмотрим.
5. Ну нет, физикс от нвидии пока сильно быстрее, да и хаос еще сильно по другому себя ведёт, очень сырой.
Не понятно зачем в UE нужен "скриптовый" язык. Не могу придумать ни одной задачи где бы он был нужен.
В основном по объективным метрикам C# лучше С++ (я беру настоящие плюсы) - скоростью разработки. Условно на данный момент есть миллиарды проектов, где тонкость возможной настройки с помощью С++ не нужна. Но при этом на С++ из-за необходимой глубины знаний для оптимального написания кода - разработка всегда идёт в среднем медленнее. Плюс помимо прочего С++ специалист - это редкий и крутой специалист, и соответственно дорогой. Я смотрю условно не с точки зрения разработчика. А больше с точки зрения компании принимающей решение о выборе технологии. И тут безусловно есть очень простой критерий. Если хочется сделать проект, в технологическом плане я не вижу отличий, а затраты на разработку, сложность подбора сотрудников и т.п. будет выше, то как бы зачем мне выделять закладывать бюджет, если я не увижу разницы?
Это всё так, если бы у нас не было блюпринтов. Задачи скриптования блюпринты покрывают. Чтоуж там, есть люди, которые чисто на БП делают игры не трогая плюсы. Что на мой взгляд архитектурно не верно, но остается фактом.
Я просто не вижу какую задачу может решать условный текстовый скрипт лучше, чем С++ + БП.
Да, тут можно сказать что макароны на БП - это говно. Вот только скрипты пахнут не лучше. При этом на БП мы имеем уникальные инструменты, которых не может быть на текстовых скриптах. Например отображение в реальном времени всей текущей исполняемой ветки. Что очень круто для отладки BehaviorTree и Анимаций.
Добавлю, что имел дело с UE3 где в качестве основы Unreal Script работает и с UE4. UE4 в разы удобнее. Ну и даже мой любимый Lua нафаршированный инструментами всё равно хуже. А уж если инструменты не подтянуты - вообще всё плохо. Дебаг через print - это не айс для 2021 года.
А, понял, согласен. Я не совсем так понял тезис. Речь не про то, зачем нужен "не С++", а про то, зачем нужен скриптовый язык, если есть блюпринты. Тогда да, понял. Я скорее про всё остальное, когда ты работаешь реально с плюсами. В этом есть своё удобство, что в остальных частях типа сетевых модулей, интеграций различных сервисов и прочего на Unity C#.
1.Меньше страдать от злых и страшных крестов, проще спецов будет найти на скриптовый язык и дешевле.
2. Можно нормально работать командой, мержить.
Есть блюпринты. Да, из коробки они не мерджатся(к слову, нет никаких проблем организовывать работу так, чтобы мерджить не приходилось даже в больших командах), но если очень хочется есть плагины для мерджа:
https://kennethbuijssen.com/projects/merge-assist.html
Ну и не является скрипт заменой плюсов. У них разные задачи. Плюсы - низкий уровень. Скрипты - высокий уровень.
Доводы за скрипты в UE - Это почти всегда "мне нравится писать код".
С геймдевом не сильно знаком, но КМК между низким и высоким уровнем лежит довольно широкий "овраг". Низкоуровневость и управляемость С++ нужна мало где, но при этом для скриптов хотелось бы оптимизаций и компайл-тайм проверок. Для этого, как я понял, любят использовать C#, но он требует довольно объёмный рантайм. Интересно было бы посмотреть на язык с более "человеческим" синтаксисом, транспилиремый в С или С++.
Есть нативизация блюпринтов. Они компилируются в С++ и уже оттуда в нейтив при шиппинге.
Компайлтайм проверки в блюпринтах не нужны, потому что вы просто не можете там написать ничего, что могло бы быть не валидным на этапе компиляции. Они могут ломаться, если например пропала вызываемая функция. Но это вам покажут, оставив вызов и подсветив его при компиляции.
Блюпринты в качестве скриптового языка очень хороши. Я уже упоминал про возможность видеть исполняемую ветку. Это невозможно в тексте.
Или как вам возможность прям в коде прописать delay? Это мега удобная штука, которую(наверно) можно сделать и в текстовых скриптах, но я там её никогда не видел.
Я в автотестах использую delay и это очень сильно упрощает их написание.
А какого поста еще можно ожидать от чувака, у которого в профиле подпись Master of Unity3D? )
Unreal
.
Технологически Край, Сорс, Фростбайт и ещё куча движков весьма интересные, и на них даже делают игры. У них есть свои нюансы и плюсы. В РФ из интересных движков есть тот же Unigine, но я больше смотрю с точки зрения студии. И если UE разработчика или Unity разработчика я найду в текущих условиях рынка, то вот с остальными большие вопросы, что создаёт лишние риски и сложность поддержки решений. Поэтому я рассматриваю в статье только два движка, потому что по реалиям рынка сейчас есть они, и все остальные. Чисто с точки зрения дальнейшей технической поддержки проекта и поиска сотрудников.
Я всё же в первую очередь эксперт в Unity
с этого надо было и начинать…
Но это почти никак не влияет на основной тезис статьи: если проект не требует технологий UE5, то зачем тратить на разработку больше при практически одинаковом(зависит от специалистов) результате?
Ну я "эксперт" по UE и не вижу особой лажи в статье. Вполне грамотные рассуждения.
Вы если критикуете - критикуйте тезисно, а то выглядит как пустой наезд.
Про UE:
Соглашусь, что в UE очень много всего из коробки, сам был удивлен когда решил попробовать этот движок.
Не понравилось:
1) постоянные вылеты движка после того как проедешь по памяти плюсами это несколько напрягает
2) при интеграции с мобилками, мало готовых плагинов для работы с сервисами + высокая сложность их написания(для меня это критично)
Мультиплеер если просто включить флажок, не будет бороться с читерами, код тоже придется написать.
Про Unity:
Про мультиплеер не соглашусь, в Unity есть от офф MLAPI(который они не давно купили) и Mirror бесплатный
В Unity нет всего этого изобилия, но там C#, куча готовых плагинов для моб сервисов и я сам могу писать плагины без проблем.
Итого: Проблем на всех движках хватает )
постоянные вылеты движка после того как проедешь по памяти плюсами это несколько напрягает
О каких вылетах речь? Сталкиваюсь с вылетами, только если пишу сложную логику на плюсах и при этом подгружаю изменения через hot reload. Поэтому простое правило: масштабные изменения - полный релоад.
Ну если у тебя специфика, то чего жаловаться то, это уже твоя проблема, всё что могли в основе дали и так, бесплатно.
Юнити не знаю, но там из коробки вообще сети нет нормальной.
Итого да, у всех свои плюсы и минусы, надо уметь выбирать инструменты под задачи, ну или допиливать инструмент под свои задачи =D
Кто-нибудь видел прилично и современно выглядящую игру на Unity? Вот такой вопрос у меня всегда возникает когда вижу споры Unity vs UE. Обычно Unity в стиме за версту чувствуется, когда графике на скриншотах из 2000-х сопутствуют несоответсвующие этой графике минимальные аппаратные требования. Могу назвать буквально 2-3 игры на юнити, которые мне понравились, но это точно не благодаря графическим заслугам движка.
Ну как минимум Escape From Tarkov. Но дело даже не в этом. Качество графики и т.п. зависит от команд, которые их делают. Потому что в статье вот о том то и речь, что смотреть надо не на игры (есть очень много крутого реализованного за пределами игр), смотреть надо на базовые технологии и различия в них. Потому что остальное в разы больше зависит от пряморукости команды, нежели от конкретного движка :)
Почему на Юнити в разы больше игр среднего качества? Ну на самом деле у этого много чисто исторических причин, а сейчас на мой взгляд несколько иных. Но ни те, ни другие, не связаны с технологиями :)
Для веб проектов я чаще всего беру pixi.js, three.js, playcanvas и react. Что в этом списке забыл реакт? Это длинная история для другой статьи, если кому-то это интересно.
Мне интересно было бы почитать) Еще было бы интересно увидеть статью от разработчика игр о том, как с его точки зрения разрабатывать игру на современных веб-технологиях. Когда веб-разработчики сталкиваются с необходимостью написать браузерную игру, берут привычные им технологии, а потом пишут статью, то обычно получается статья о том, как делать не надо.
Иногда создается впечатление, что подобные статьи прям ориентированы на людей, у которых на руках уже есть бюджет, издатель и готовый диздок со 100% успешной игрой, но они не знают, что выбрать для максимального профита. Все эти "движок - это только инструмент" сводятся к тому, что: мобилы\2д - юнька, 3д - анрил, есть опыт в создании игр - юнька/анрил, нет опыта - анрил/юнька. И на этом весь смысловой посыл сабжа кончается.
Да, практически во всех современных движках графен зависит только от уровня и рук художников, которые на нём работают, да, практически все функции(райкасты, обработка столкновений, триггеры, спавны актёров, математическая библиотека и манипуляции с объектами в трёхмерном пространстве, проигрывание анимаций) есть во всех движках и дают примерно 90% возможностей над созданием геймплея к большинству игр.
Тем не менее, каких-то глубоких рассуждений о дополнительных готовых решениях того или иного движка, а также ограничениях который они же могут дать - нет. В крайэнжине, например, декали не работают на динамических объектах, от слова вообще. Мелочь, но если вы помешаны на импакте от стрельбы, то для какого-нибудь мясного шутера придется извратится.
Про оптимизацию тоже обычно - забей. Многие любят приводить Тарков, как пример успешной 3д игры, сделанной на юнити, хотя у большинства людей именно по Таркову связаны ассоциации с крайне плохой и неадекватной оптимизацией. Почему так? А неважно. У меня есть годот, который с моими мешами и текстурами проигрывает 200+ фпс при разрешении в 2к, есть дефолтная сцена в анриле 4, также с моим мешем и текстурами дает 170+ фпс в 2к на ультра настройках, а есть unigine, который на своей дефолтной сцене с моим мешем дает 70+ фпс. При этом я много где читал, что рендер в годоте сейчас полный отстой и не предназначен для работы в 3д вообще(естественно, без объяснений), все надежды на новую версию, а про униженного наоборот - у них там чуть ли не магия в оптимизации. И никаких фактов на этот счет от технических директоров о том - почему при таком освещении и количестве объектов на сцене такой результат - это охрененно, а тут - полное уг.
Понятное дело, что для такого сравнения нужны несколько человек, каждый из которых имеет определенный опыт работы в конкретном движке, либо человек, который прям всеми занимается потихоньку. Но с другой стороны - а есть ли какой-то смысл сравнения движков от людей, которые нормально знают только один?
Пример не очень хороший, так как в таком контексте 170+, 200+ или 60+ - это неважно при средней частоте развёртки экрана 60. Но я понял смысл. Речь про базовую оптимизацию движка.
Да, конечно же есть смысл обсуждать. Их на мой взгляд три. Первое, начать обсуждение и посмотреть разные мнения. Но есть ещё второй. Движки не важны с точки зрения супер оптимизации, потому что рендер - это рендер, графический конвеер - это графический конвеер, можно не знать вообще ни одного движка, а знать фундаментальные основы устройства работы ГПУ, чем отличается Nvidia от ГПУ Mali и в чём нюансы. Пока мало кто придумал что-то супер новое, а оптимальные шейдеры можно написать. И третье, бизнес причины никуда не деваются. Я сравниваю не с позиции энтузиаста, разработчика игры мечты или чего угодно. Я уже 3 года занимают аутсорс разработкой проектов под заказ. И для меня немаловажным фактором является стоимость разработки. Есть разные процессы разработки, разные масштабы команд и проектов. И разработка - это просто процесс, который в конечном итоге должен принести результат. Можно сколько угодно рассуждать о том, где какой свет и как на мы выиграем аж 3% перфоманса. Но возьмём простую штуку, которую вроде до сих пор не завезли на юнити. В UE4 есть swarm для запекания света. То есть если я захочу сделать большую локацию с хорошим baked illumination запечь её на кластере на анриале можно будет из коробки, а на юнити это будут пляски с бубном. А от того, что игра выдаёт 130 фпс, а не 120, у пользователя ничего не изменится, с его частотой развёртки дисплея в 60 фпс. Самый быстрый не значит самый лучший, этот выбор многокритериальный. Ну и да, из-за специфики аутсорса я работаю с вполне конкретными бюджетами и сроками, и безусловно всё это оцениваю) И в данном случае в разы важнее, что я могу найти крутых разработчиков без потерь качества, которые заметит пользователь. Чем то, что у соурса есть какая-то великая фича.
Скажем почему нет разборов подобных метрик приведённых выше? Да они просто ни о чём не говорят. Нужно слишком много контекста, как и в любом реальном бенчмаркинге. Железо, операционная система, версия драйверов, используемые инструкции для рендера и так далее. Бенчмаркинг штука во-первых сложная, во-вторых чаще всего бесполезная.
Ну на ~10-15 фпс разницы при 100+ фпс естественно никто не заметит. И это прям шикос производительность для трёхмерной игры. А вот отсутствие стабильных 60+ у игры с графеном 2005го года - заметят сразу же, а если там еще и местами фризы будут или артефакты - вообще отгрести можно сходу. Я и сам, честно говоря, не люблю такое. Скорее всего 4й анрил в этом плане и самый технологичный и самый оптимизированный для ТриДэ. Хотя у него тоже есть свой "тарков" в виде пубга, у которого до сих пор жалуются на оптимизацию, но там явно причина не в движке.
Чего не скажешь про сам тарков. Да и кроме таркова я натыкался еще на отчёт других разработчиков, которые делали игру с псевдо-открытым миром(Насколько помню - там вроде Айс Пик Лодж, на ютубе есть). В кратце - они там там чуть ли не семь кругов ада прошли, чтобы доделать продукт. И это в тесном сотрудничестве сапорта юнитеков. Возможно сейчас уже эти проблемы были решены, однако на тот момент Юнити также считался прямым конкурентом эпикам и позиционировал себя, как альтернатива в триДэ, но сюрпризы такие уже в себе имел. Я помню даже игру одну смотрел, которую один человек сделал - рыбалка 3д и там у меня обыкновенная локация внутри леса рядом с озером выдавала 12 фпса на минималках. Хотя этот же ноутбук спокойно тянул 30-40 фпс в варфейс. Получается, что для мелких 3д игр юньки и тогда было достаточно, а вот на что-то большое и громоздкое - уже нет. Но про это никто не говорил, все аргументы как и сейчас упирались во вкусовщину, публишинг, количество проектов на движке и сообщество. Про Cryengine даже особо писать не стоит - он сам уже знаменит не только хорошим графонием.
Ну и да - пример со swarmom как-раз именно то, на что я изначально намекал. Также вон в Unigine есть API для работы с террейном в реальном времени - свой тераморфинг, + фичи с водой, волнами, каустикой, объёмные многослойные облака. Вот только если я делаю стратегию или изометрию, зачем мне облака. Если я ориентируюсь на коридорный шутер с подгрузкой разных уровней - зачем мне swarm. Но с другой стороны, если люди планируют свой выживач с вертикальным геймплеем, где нужно будет выкапывать огромные норы в земле, строить там жилища и прятаться от агрессивных караванов на поверхности - для них есть готовое решение тераморфинга в Unity? А в Анриле? Я вот лично хз. Если нет, то сколько времени им понадобиться на самостоятельную его разработку в юньке/анриле. Я вот рассматриваю инструменты именно в таком ключе.
Меня тоже удивило то, что обычно не рассматривают никаких движков, кроме этих. Но самое веселое не это: а есть ли какой-то набор тестов, что-бы хоть как-то объективно оценить производительность? С разным освещением/сложностью материалов? Так же интересно глянуть тесты движков разных OpenSource проектов, типа OpenMW/0AD/DarkPalces/etc.
Вообще, рендер в годот не так уж и плох на данный момент. А утверждения о том, что он не очень идут от того, что скоро гредет вулкан и в сравнении с ним нынешний рендер естественно сильно хуже.
Что же касается оптимизации годот и юнити. Где-то лучше один, а где-то другой. Только недавно видел на ютубе ролик, в котором человек экспериментировал с тем, какое количество коллизий объектов одновременно сможет вывезти годот с его нынешней физикой. И, к сожалению, значение в несколько раз ниже чем у юнити.
Да, это не оптимизация конкретно рендера. Но тем не менее, этот пример показывает, что юнити все таки не так уж и плох. Хотя я все равно продолжу пользоваться годот :)
Я понимаю, что пост не претендует на объективность и все такое. Но блин, на мой взгляд название максимально вводит в заблуждение.
На рынке, особенно в инди секторе, существует достаточно большое количество разных движков, имеющих высокую популярность.
Если обратить внимание на статистику GMTK Game jam о том, на каких движках джемеры писали свои игры, то можно увидеть, что UE и вовсе совсем не популярен в инди секторе, в отличие от Godot, Game Maker и т.д.
Суть статьи сводится к сравнению двух движков в контексте проекта уровня ААА, где на первом месте стоит графика. И естественно, что такая статья имеет место быть и многим будет полезна. Но, чтобы она нашла своего читателя, необходимо отобразить суть статьи в ее названии.
Если игра планирует использование ортографической проекции + свет, то точно не UE. Там всё плохо и как я понял, так и будет.
Какой игровой движок выбрать?