Comments 15
Как же юнити стал убогим под капотом. Вместо доработки кор архитектуры, они продолжают писать нашлепки в виде пакетов и через пару лет успешно их диприкейтить.
По сути нет ни одной причины, почему не написать свой движок (тем более для 2д) или не использовать Godot для чего посложнее.
На самом деле он всегда был убогим, начиная с самого первого релиза.
Вспоминаются самые мемные проблемы:
Раньше GetComponent мог возвращать только компоненты, но не интерфейсы, которые они реализуют. Поэтому для диспатча сообщений использовался SendMessage, который мало того что боксит/анбоксит, так ещё и дёргает сообщение по имени метода (!!!).
Вместо нормального стейтменеджмента и условного AbstractGameApp, предлагается сделать менеджер состояния игры путем написания компонента-синглтона (!) и прилепливания к нему DontDestroyOnLoad (!!). Стейтменеджер, зависящий от графа сцены (даже если он реализован отдельно и соответствующий компонент лишь зовёт его инициализатор при старте игры) - антипаттерн и отвратительный говнокод.
Биндинги управляемых объектов к нативным с перегрузкой оператора сравнения с null. Это вообще трэшак, как будто авторы не понимали как нормально связать нативные объекты и управляемые (движок их в принципе трогать не должен, если нужно освободить ресурс - GC сам вызовет финализатор, из которого можно вызвать нативный delete object. Если его все таки нужно освободить заранее, чтобы к примеру загрузить уровень и не вывалится в OOM, то можно подчистить граф сцены, принудительно вызвать GC с нативной стороны (т.е Mono) и потом загрузить все нормально).
Бандлы, насколько я понял, не умеют в нормальные хэши для ресурсов, из за чего кратно растет время загрузки уровней. Вспоминаем Rust.
Позорные пришлепки типа SRP и DOTS, которые должны были стать именно кор функционалом движка лет 10 назад.
как мало проблем вы озвучили :-D
Умеете конечно насмешить 3 пунктом)
Я так понимаю вы более менее "в теме". Можете, если не затруднит, прокомментировать пару нюансов Unity? В частности, меня всегда напрягала его тормозная работа именно в плане самого интерфейса - почти на каждый чих происходит блокировка интерфейса и компиляция кода, даже если туда добавился комментарий, а не логика. Так было всегда?
Я просто неоднократно пытался подступиться к Unity в разные годы, кажется это были 2011, 2015, 2020 и вот недавно смотрел на Unity 6. И я не могу избавиться от ощущения, что движок вместо того чтобы помогать и упрощать, занимается тем что раздражает и "блокирует", делая весь процесс взаимодействия таким рваным, словно ты пассажир в отечественного авто с мкпп, а за рулем новичок бросающий сцепление. И сюда же вдогонку тысячи deprecated вещей, которые я точно уверен были на запуске прошлой версии движка, но поди ж ты - уже нет. Это такая линия партии у них с самого основания что ли?
Это норма, это ж не Java где можно скомпилировать отдельно изменившиеся классы :) в дотнете единица выполнения это именно сборки, т.е dll
А так да, многие болячки тянутся с первых версий. Но скидку на сомнительную архитектуру можно сделать с учётом того, что юнити это именно RAD


Ранее уже верно прокомментировали эти моменты.
Необходимость рекомпиляции кода после его изменения — это особенность стека, на котором работает Unity. Чтобы правки подхватились, необходимо пересобрать assembly с изменённым кодом. И чем больше assembly, тем дольше оно будет пересобираться.
Также Unity ещё нужно домен перезагрузить: статику сбросить и пр. формальности, чтобы стартануть Playmode с актуального и чистого листа.
Подробнее - в оф. доке
Немного сгладить ситуацию можно, отключив автоматическую рекомпиляцию и перезагрузку домена (см. скриншоты). Я это делаю только вручную по Ctrl+R
.
Постоянный deprecated — это уже мем в сфере Unity. Так и живём. Это нормально. Но со временем оно становится стабильнее и таких неприятностей с пакетами, которые находятся в официальном релизе, всё меньше.
Не всегда так было. Даже компиляция побыстрее работала где-то в 4.6 версии. Потом добавили сбор телеметрии и на каждый чих и данные летели на сервера.
Новый фреймворк — Unity Graph Toolkit