Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 14
Разработчики юнити сделали 1001 фичу, которые, на их взгляд решают любую проблему. Но беда в том, что ни одна из них не работает нормально с любой другой.
Есть 3 разных физических движка.
Есть 5 разных UI систем (каждая из которых умеет полтора землекопа).
Есть ECS/Jobs/DOTS, но в 90% проектов они не используются тк требуют умнейших костылей от разработчиков чтоб реально получить какой-то толк.
Есть асинхронность и корутины, но всё равно приходится использовать UniTask или нечто подобное.
Шейдеры вроде как-то умно компилируются. А в итоге получается uber.shader на 20мб когда внутри используется только стандартный spriteDefault и какой-то additive на частицы.
Не говоря уже о том, как сильно разросся размер билда и сколько там мусора везде лежит в памяти (в тч ОЗУ)
Да и постоянные эти загрузки после каждого изменения кода. Domain reloading. Да, можно всё отключить, поставив теги что мол обновляй вручную поля статические, но раньше почему-то и без этого работало и не надо было ждать по 10с.
Крч что хочу сказать (исключительно субъективно): движок ужасный, но лучший из всех. Тут можно сделать что угодно, но есть нюансы на каждом шагу
"но лучший из всех. " - нет.
У них просто нет единого архитектурного вижна. Каждую систему пишет отдельная команда, которая вообще не общается с соседним отделом
Это следствие попытки усидеть на всех стульях сразу, поддерживая и мобилки, и консоли. Универсальный инструмент всегда будет в чем-то уступать узкоспециализированному
О чем говорить, если полноценное динамическое освещение они обещают добавить только в 7 версии. Я имею ввиду Surface Cache Gi
Да и UI они в последней версии тоже сделали сразу 2 вариантов..
нуу честно сказать некоторые штуки как будто имеют место быть, но в основном претензии выглядят как недостаточное понимание особенностей движка и некоторой теории. Unity это не ноу код конструктор а довольно сложное апи с кучей нюансов которых хотелось бы конечно поменьше и поменьше багов, но в данной статье не все претензии оправданы я считаю. Например деревья поведения зависят от расположения нод бай дизайн, это не только для Unity решения верно, сверху вниз слева направо поэтому это не баг а фича. Для встроенного навмеша (если вы хотите именно его использовать, потому что есть и сторонние пакеты довольно неплохие) например есть динамический навмеш, и если у вас структура уровня меняется в процессе игры вам скорее всего придется перестраивать навмеш динамически. С инпут системой тоже не до конца понятно. Зачем вам эмулировать события инпут системы? у вас нажатие кнопки вызывает какую то логику, ну так и вызывайте ее. Ну то есть существует кто-то ответсвенный за выполнение логики, а триггеры могут быть разные (инпут с клавиатуры или кнопка интерфейса), это неправильное разделение ответственности. Зачем вам корутины когда есть unitask, который в принципе может работать как корутина в главном потоке а может и переключаться на другие треды тогда когда это возможно. С текстом тоже не понял, там 2 разных компонента для ui и для мира, вы точно используете правильный (что то типа TextMeshProUGUI вместо TextMeshPro)? На скрине с мостом если зеленое это коллаидеры то не совсем понятно зачем там на стойка они например, ну и плейн который вы накинули, на нем как будто меш колаидер полностью повторяет геометрию плейна (могу ошибаться) как будто было бы достаточно одного квада. Ну и по поводу обилия разных решений, тут я согласен что хотелось бы каких то стандартных однотипных решений для одинаковых случаев но unity движок с историей, что-то постоянно новое появляется, улучшается, меняется, поэтому и подходы меняются, то как решали проблему 10 лет назад и сейчас конечно может отличаться, но ведь у вас телефон сейчас тоже не кнопочный например, прогресс такая штука, если гуглите смотрите просто на даты публикаций и версии для которых написаны те или иные решения. Я без негатива и не защищаю unity, у них полно проблем, но не все что тут описано на мой взгляд справедливо.
Нормальные деревья поведения имеют явные связи приоритетов, а не полагаются на координаты нод. Если логика скрыта в UI-координатах, ее невозможно дебажить
текстом тоже не понял, там 2 разных компонента для ui и для мира, вы точно используете правильный (что то типа TextMeshProUGUI вместо TextMeshPro)?
Речь о вот этом предупреждении, которое появляется если внутри канваса есть любое текстовое поле. Если выставить каналы как надо, а потом поменять текст в поле - они вернутся и ворнинг снова появится. Нет, TextMeshProUGUI не решает проблему. Впрочем, само существование этого компонента тоже вызывает вопросы с точки зрения архитектуры, спасибо что заметили.
ну и плейн который вы накинули, на нем как будто меш колаидер полностью повторяет геометрию плейна (могу ошибаться) как будто было бы достаточно одного квада
Да, безусловно. Просто плейн лучше заметен на скриншоте чем квад
насчет бехавор. вы просто путаете, fsm и bt. они пытались сделать бeехавор три. дерево поведения. там как раз порядок нодов зависит от позиции в редакторе это нормально. но вот в чем они реально накосячили, то что само название как бы намекает что это дерево! и дерево поведения должно быть именно деревом! а они запилили граф! скорей всего из за этого и уволили этих разработчиков.
del
Если встроенный NavMesh не устраивает, всегда есть A* Pathfinding Project. Родные тулзы юнити обычно годятся только для прототипов, в проде все равно пилишь свое
как-будто группа джунов с анрыла решила перейти на юнити и собрала отчет для начальства, почему им надо еще 4 месяца чтобы добавить тутор перед выпуском
Behavior
blueprint'ы в анриле и прочее визуальное "программирование" максимум для прототипирования подходят, а нормальные программисты избегают. guys, are you OK?
Денис, если Вы считаете, что покровительский тон и переход на личности добавят вам веса в глазах читателей, то, боюсь, Вы ошибаетесь.
Насчёт визуального программирования также спешу разочаровать: оно довольно активно используется, в том числе и в AAA. Например, оно позволяет разделить зону ответственности программиста и технического геймдизайнера и вообще вынести часть работы на последних (как правило, более дешёвых) специалистов. За всю индустрию ручаться, конечно, не буду, но лично наблюдал несколько крупных проектов на UE и с блупринтами.
Ну проблемы с инпутом решает новый Unity Input System. Который правда кривоват в настройке, но зато, можно оперировать действием, в не прямым состоянием инпута. И подвязываешь себе клавиатуру, тачпад и геймпад.
На UGUI с их канвасом забил давно, есть Unity UI Toolkit, более чем достойная альтернатива. У неё правда документация хромает с экзамплами, но я нет-нет стараюсь этот косяк покрыть своими экзамплами, и разбтрами как делать нетривиальные вещи просто.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы Unity, о которых не расскажут в пресс-релизе