GoRoX
Мне впадлу тебе А4 листы накатывать в ответ на все твои запросы, если честно. У меня лишь поинт про перфу был. Какая разница сколько у меня юнитов на сцене, если у меня проблема первичная будет в том, что анимации и рендер этих сущностей мне всю перфу тут убьют. Оптимизировать вызовы Update не проблема и без ECS. Причем тут опять MVP/MVVM я не понимаю.
Я с ECS работал и понимаю о чем говорю:)
Работал, вероятно, неправильно. Вообще аргумент какой-то детский.
И мнение что ECS только для проектов где куча сущностей на сцене тоже ошибочно. Такое ощущение что ты думаешь, что ECS нужен только чтобы Update в одном цикле вызывать и все.
Humano5974
> То есть если нет разницы в производительности то и использовать смысла решения нет, по вашим словам.
>
> Разве это так?
Я не говорю что в нем нет смысла. Потому что исходя из того что я прочел, на тот момент, выше - я не увидел смысла никакого кроме:
1. Это промежуточное решение с подвязкой под ECS, которая при необходимости может в производительность также как ECS (с большим количеством сущностей) и при этом проще чем условный LeoECS, DOTS, Морпех для новичков
Далее я прочел ознакомился подробнее и пришла вторая мысль:
2. "Т.е. в первую очередь он для того чтобы была архитектура хоть какая-то + делать также быстро игры, как если бы мы писали все на монобехе." Ну и при этом подвязка на будущее, что легче будет ECS освоить.
Но в целом, ЛИЧНО для меня (именно поэтому мне было интересно а в чем прикол то) - если нету преимущества (кроме абстрактного удобства) в производительности в рамках проекта с большим количеством сущностей перед MV* реализацией, то я бы выбрал MV*. Но если она есть и при этом предлагает "втягиваться в ECS без боли" - это очень круто и тут я бы для себя думал.
Я не пытался "доебацо", как могло показаться МБ - я задал вопрос потому что мне действительно интересно:)
> Можно много чего вам ответить, но по моему мнению у вас с ECS миром общего мало что есть в опыте, это видно по тому что вы говорите.
Ну как минимум "все утверждения ложны" было громко и тут уже хотелось бы до конца, я 4 пункта обозначил. 1 требует пруфа, 3 оспариваются хотя будто бы факты:)
При всем это я не утверждаю, что у меня опыта в ECS больше)
Для меня это использовать в ситуациях когда у меня игра про большое количество сущностей. В иной ситуации я бы использовал MV* если это долгоиграющий проект.
При всем этом на всякий повторю - от архитектуры можно отступать, когда реализация чего-либо в рамках архитектуры не стоит свеч.
А с точки зрения "не понимаю гибкости" - понимаю.
Другой вопрос из-за того что я не знаком с какими-то кейсами или у меня лично не было таких проектов - я не считаю что та гибкость в рамках ECS стоит своих свеч. Когда я могу использовать условный MV и если понадобится же Zenject - с прямыми руками они точно также дают гибкость, хоть и меньшую чем ECS.
Но тут уже момент что исходя из знакомых мне кейсов и моего личного опыта - на мой взгляд не стоит свеч ECS просто и соответственно не претендую на истину.
Jaxel
> И мнение что ECS только для проектов где куча сущностей на сцене тоже ошибочно. Такое ощущение что ты думаешь, что ECS нужен только чтобы Update в одном цикле вызывать и все.
Ну как я обозначил - ECS хоть где можно использовать при желании.
Но лично я не встречал крупный кейс где был бы ECS и не было бы много сущностей. Поэтому и запросил такой кейс:)
То что для кого-то ECS в целом удобно использовать - я это понимаю, хоть и не разделяю
> LeoECS
ну виновник треда точно не проще чем LeoECS )
В EasyCS куча магии интеграции с движком, в то время как с LeoECS ты работаешь с Unity так же, как и без него, никакой магии. Ну а сам LeoECS просто прост. В нем нет ничего чего нельзя было бы выкинуть.
Sell point виновника треда вроде как в определенном, предположительно удобном подходе для интеграции с движком. Но я, если честно не выкупил пользы. На первый взгляд выглядит сложнее чем подход в лоб.
kkolyan
Ну давайте тогда обозначим пункты, которые показались сложнее в EasyCS)
Очень интересная тема, постараюсь ответить и сделать выводы на будущие релизы.
Думаю больше кажется сложнее, чем есть на самом деле.
Humano5974
Уже качаю, завтра погляжу, мб будут мысли)
А вообще повторю - ты обозначил мои утверждения ложными. Я обозначил 4 пункта, которые по твоему мнению ложные. Хотелось бы ответ увидеть:)
А то я зашел правда заинтересованный, апнул тему, а на меня накинулись:D
И даже кейс не скинули, который бы показал мне что вот мол, крутая игрушка без миллиона сущностей и использует данный паттерн.
Даже его если нет - опять же не отменяет сам факт, что у данного паттерна все равно есть свои преимущества и как любая внятная архитектура это масштабируемость и поддержка при всем этом.
Increaser
> Конечно, ты мне сейчас скажешь, что я-де неправльные MVP/MVVM видел, а вот если его правильно использовать, то огого, ну да и Бог с ним, используй "правильно"
MVVM кстати говоря OwlCat использует. Точно в своем новом проекте, на счет рог трейдер и прошлых не интересовался)
Humano5974
мне в принципе не нравится подход с возможностью конструировать энтити в инспекторе. Инспектор - это поверхность для дизайнеров. Для них лучше сделать четкий, валидируемый интерфейс на монобехах и СОшках. со всякими красивостями вроде [Required] или [ConditionalField]. Чтоб фасад был како можно непротиворечивым и минимизирующим неконсистентность.
А перекладывать данные из монобехов и СОшек в компоненты уже в коде систем (каждая система берет оттуда свою часть данных).
Очевидно, вы иных взглядов и проделали некоторую работу чтобы дизайнер мог конструировать энтити. Мне трудно оценить насколько хорошо вы это сделали, потому что в моей философии это в принципе лишний функционал)
GoRoX
> MVVM кстати говоря OwlCat использует.
Они еще и Event Bus используют. Что же теперь, бежать всем Event Bus использовать везде? Я рад за них, что они его используют, что еще сказать?
Increaser
Да я просто вспомнил и решил вкинуть)
Но в целом я все равно не совсем понял о чем ты.
Накинь какой-нибудь пример логики, которую сложнее было бы написать в рамках MVP/MVVM и какую бы в этом контексте архитектуру использовал бы ты.
kkolyan
В целом если у вас есть свой пайплайн работы с конкретным ECS и вас всё устраивает то вам EasyCS незачем от слова совсем.
У этого решения другая аудитория и кейсы и поскольку проект эксперементальный то многие вещи еще могут измениться.
Там подразумевается сбор entity как на монобехах так и без них, в ScriptableObject-ах.
2 варианта интерфейса.
GoRoX
Принял ваш интерес, тогда по вопросам попробую ответить позже)
Если что - спрашивайте, не стесняйтесь.
Но производительности - не ищите, она на стандартном уровне, впрочем может быть улучшена в будущем относительно не сложно.
Я готов обеспечивать долгосрочную поддержку в зависимости от запросов пользователей.
GoRoX
ECS даёт оверхед если надо сделать что-то быстро, RND, прототипы и т.д.
Но обеспечивает лучшую архитектуру в долгосрок.
EasyCS решает эту боль с оверхедом.
Вы можете так же работать как раньше, только теперь у вас появляется универсальные контейнеры для данных, отвязанные от Monobehavior - это Entity.
Так же есть контейнер для компонентов Monobehavior в виде Actor.
Прочие плюшки улучшающие работу и уменьшающие тот бойлерплейт, что вам приходилось делать на MVP/MVVM при этом вы можете продолжать работать с этим паттерном, только лучше.
GoRoX
> Накинь какой-нибудь пример логики, которую сложнее было бы написать в рамках MVP/MVVM и какую бы в этом контексте архитектуру использовал бы ты.
Мне лень, честно. Я уже сегодня итак в одной специальной олимпиаде для умственно отсталых поучавствовал. Если тебе все нравится в MVP/MVVM, у меня нет ни малейшего желания тебя переубеждать.
Humano5974
> У этого решения другая аудитория и кейсы
а какая? какие кейсы?
почитал ридмишку чуть получше.
1. Мне если честно показалось что бойлерплейта не меньше чем при разработке с LeoECS (c DOTS я не работал). В ECS, если уже использовал какой-то фреймворк и в целом понимаешь идею - просто подключаешь фреймворк к проекту и пишешь код) какой-то вводной работы там не больше чем если делать проекты без ECS.
2. Управление поведением в общем-то организовано так же как в обычных юнитевских компонентах. Если честно, не очень понимаю, чем использование этого фреймворка лучше чем просто Unity+DI. Учитывая заявляемый тобой опыт, допускаю что там есть какая-то идея чем-то помогающая. Но выходит чтобы начать эффективно пользоваться твоим фреймворком (и главное - понять зачем), явно придется пройти некий порог чтобы понять твою философию, а зачем если можно потратить силы чтобы пройти входной порог чистого ECS, который моден и молодежен?
3. Ну и вроде как общего с ECS у твоего фреймворка не больше чем у обычного Unity. Там тоже есть компоненты, и тоже есть своего рода энтити - гейм обджекты. Но при этом в отличие от ECS - нет применения игровой логики к выборкам по компонентам, а это собственно главное что отличает ECS от юнитевских компонентов.
Increaser
Я не говорю что мне все нравится)
Я говорю о том что мне интересно о чем ты, чтобы понять про что ты говоришь конкретно:)
Humano5974
> Принял ваш интерес, тогда по вопросам попробую ответить позже)
Благодарю)
kkolyan
> В ECS, если уже использовал какой-то фреймворк и в целом понимаешь идею
Я так понял тут по сути не надо запариваться над тем, что у нас в ECS ДОД подход присутствует, а не ООП в полной мере. И сама ж проблема в ECS - что тебе надо осознать, прочувствовать и понять как же это все делать не в рамках ООП, чтобы вся мощь и суть ECS работала.
И соответственно в EasyCS - берет на себя всю боль ДОД и тебе остается работать как раньше в рамках ООП + инспектор. Но это я так из рассуждений пришел к такому выводу. Смотреть буду только завтра)