Вы правы для мобильных платформ возможно это будет и сложно. Но я их не не рассматриваю для себя. Что касается количества объектов. Так вот у меня был проект, один из моих первых, так сказать. На сцене работало порядка 2-х тысяч объектов, некоторые из низ с достаточно солидным набором компонентов. Все было связано, запутано. Так как почти все в методах Update обрабатывалось. И единственная сложность в этом проекте была, это его поддержка и основная задача сформировывалась это сделать архитектуру грамотнее и удобнее, чтобы упростить и ускорить процесс. Вопросов касаемо производительности вообще не возникало, так как ниже 70 кадров в секунду никогда не проседало. Я не планирую участвовать или создавать ААА проекты, я ориентируюсь на инди разработку и статья как раз для начинающих инди разработчиков. Если вдруг у меня бы встал вопрос о просадке производительности, то тогда это бы стало более приоритетным. Но до тех пор, удобство и скорость разработки, а также maintenance проекта находится в приоритете.
У меня проект не оч большой, но и не тетрис. И для данного проекта, как и для многих, этого более чем достаточно. Я не скажу что я не умею готовить именно zenject, я с разными ioc фреймворками работал, с ним нет, помотрел только исходники. И обязательно попробую как нибудь на тестовом проекта
Вот именно это и было моей целью. Потому что применение фреймворка, тоже займет время, и даже если новый член команды появится, который не знаком с этим фреймворком, так же затратит определенное время. Но я согласен, что для крупных проектов, применять фреймворк нужно. В проектах, вне геймдева я оч много всего из нугета использую.
Ну а я показал, что в нем нет необходимости. Еще раз, статья для начинающих и для них это было бы сложно. Я много раз пытался объяснять людям почему не стоит создавать мегакомпоненты, которые включают все, или реализация всей логики в методе апдейт, и подобное мракобесие. Я пытался объяснять зачем применять шаблоны и для чего это нужно. Зачастую это бесполезно, а вы говорить вкрячить фреймворк с другим подходом в разработке, нежели то что предлагают стандартные средства юнити.
Опять же, если бы в ней был бы смысл, в моем примере, я бы согласился. Но у меня небыло в этом необходимости и прикручивать фреймворк, который пусть и немного но отъест ресурсов, при этом не давая мне ничего, от чего бы я не смог реализовать, мне не нужно
Конечно можно, только зачем, если шину данных я сам заимплементировал, достаточно быстро и мне для этого не потребовался сторонний фреймворк. Это не настолько сложная задача, чтобы прикручивать, опять же, целый фреймворк
Так применение шаблона это не суть статьи. Какая разница какой шаблон применен, главное что в целом решение решает какую-то проблему. И статья именно ориентирована на новичков, и мне бы не хотелось чтобы у них развивались «паттерны головного мозга». Иногда шаблоны можно не использовать или менять их, главное чтобы это решало задачу и не создавало трудностей в развитии проекта.
Так если бы она мне была остро необходима, я бы согласился, но я смог и без лишней траты ресурсов обойтись, так зачем тогда мне прикручивать крупный фреймворк?
Я не изобретал шаблоны, я их применил в собственной имплементации. Разберитесь, что такое шаблон и какую роль он играет в разработке программного обеспечения.
Zenject активно использует рефлексию, а это значит, что не оч положительно сказывается на произовдительности. И не вижу выгоды в использовании его, против своего решения «под себя».
Чем модель акторов лучше, для данной задачи? И зависимость разрешается за счет RequireComponent, а использование контейнера у меня на другом уровне, в данной статье на раскрыто
Да, в UniRx есть компоненты со схожим смыслом, но мне показалось он излишне перегружен и слишком универсален. И у меня не совсем синглтон, так как для каждого геймобджекта будет использоваться свой экземпляр
Щас бы статьи Ссыкутина читать
Тут лог разработки прототипа, где это применяется