Comments 14
Интересно, но не понятно, сравнивать Zenject и MonoBehaviour, это как сравнивать мышку и windows) Как я понял вы написали игру просто на GO потом переписали с использованием SOLID и DI(Zenject)?
Доброго времени суток, немного не так. Я всё писал на С#, в первом случаем писал всё только при помощи инструментов Unity и наследования от MonoBehaviour пытался придерживаться SOLID, ну а во втором DI. Можно подробней почему это бессмысленно сравнивать ?
Ну просто это не корректно, используя Zenject вы же не перестаете использовать MonoBehaviour? Всё равно надо где то поддерживать жизненный цикл unity плюс скорее всего вы создает объекты на них прикреплены скрипты с MonoBehaviour. А Zenject ну он просто регистрирует и выдает интерфейсы по запросу, и архитектурного подхода он не несет. Примеров не хватает) По мне все видится что GetComponent заменился на [Inject]
DI-библиотеки просто решают проблему инъекции зависимостей, чтобы руками не прописывать, архитектура тут может быть любая, а про неё ни слова
0.4 строчки в час в лучшем случае это нормальный КПД?
Zenject не единственное и не всегда лучшее решение. Мне нравится VContainer и по производительности, и по функционалу
Очень субъективно, ни слова про код, просто описываешь свои ощущения. Это как если бы ты сравнил строительство деревянного дома одним топором или набором инструментов. Понятное дело у топора функционал меньше и займет дольше. Но в итоге и там и там дом из брёвен.
Зенжект - древнее тормозное зло и карго культ
Частота кадров (FPS)
Замерять FPS после внедрения зенжекта странная мысль. Каким образом он должен повлиять на это?
Число вызовов Garbage Collector
Их вообще не должно быть после старта, ни с зенжектом, ни с монобехами. Если они есть - лучше углубиться в практики написания производительного кода, а не в SOLID и прочую ересь
От сюда следует, что поставленная гипотеза, полностью подтверждается, более сложная архитектура упрощает разработку
Если более сложная архитектура упрощает разработку, то, по идее, на разработку должно быть затрачено меньше времени, не так ли? Но по вашим данным получается как раз наоборот - более простая архитектура требует меньше времени, а следовательно - упрощает разработку.
Не ясно, почему у вас именно такой вывод.
Как человек который буквально прошлую неделю мучительно выбирал между VContainer, Reflex или просто сделать всё на ГО, я негодую и ставлю статье минус.
Никакой конкретики, есть какие-то абстрактные метрики фиг пойми откуда. Ощущение что статью вообще писал ИИ, мусолится одна и та же мысль в разных обертках.
Кстати я выбрал всё-таки ГО, потому что обучающих материалов по ioc для юнити примерно нет, а то что находится - это вот такие статьи уровня "используйте ioc потому что модульность высокая". При этом на форумах только и слышно, что юнити уже реализует di через инспектор.
Имхо есть самый трушный обучающий материал - исходники игр на юнити. Слава богу разработчики инди шедевров предоставили их исходники и просто положили их в папку с игрой, и вертели они этот solid и di каргокульт на своём синглтоне ;)
А по поводу статьи - действительно, метрики ради метрик, без единой детали реализации. Сомневаюсь что автор использовал GO-less подход через DrawInstanced или вообще hybrid/pure ecs, т.к. там одного бойлерплейта для рендера было бы в раза 3 больше.
Почему нужно слушать старших или как я наступил на грабли, выбирая архитектурный подход при разработке игры