EasyCS: Когда ECS это легко! Эксперементальный фреймворк с Entity-Data-Monobehaviors (4 стр)

Humano5974
Перед твоим 1м ответом у меня было сообщение с утверждениями и ты назвал их ложными)
Утверждения которые я выделил:
1. Крупный кейс (а лучше несколько) где была бы архитектура ECS не для достижения перфы использована?)
2. ECS это архитектурный паттерн - ???
3. Специалистов с КО использования ECS меньше - ???
4. У каждого паттерна есть свое предназначение - ???

1 - я утверждал что все ком. проекты успешные о которых я знаю, использовали ECS для производительности прежде всего (как оптимальная архитектура для ее достижения). Допускаю что это не так - и мне интересен 1 (а лучше несколько) таких кейсов, которые бы демонстрировали что разработчики использовали данную архитектуру не с точки зрения добиться производительности (наличие большого количества сущностей)

2-4 у меня были такие утверждения (если в несколько слов их сжимать) - ты их назвал ложными, почему?)

Фреймворк еще пока не тестил, загруз по работе, думаю перед сном смогу опробовать)

GoRoX

Что считается "крупным" кейсом в данном контексте? Более того я не могу знать на каком паттерне сделана та или иная игра. Лишь за редким исключением.

Да

Не понял вопроса

Да, но используя ECS теряется надобность в применении ряда паттернов в ряде случаев. В этом одно из преймуществ - универсальность и надёжность подхода. Как и сказали для UI MVP/MVVM будет как раз то что надо.

ECS при этом не подходит на практике для таких кейсов, когда надо быстро что-то сделать, например прототип или простую игру. Но проекты средней сложности и более уже оптимально делать на ECS, ПРИ УСЛОВИИ что команда умеет с ним работать.

И речь не про performance, а про масштабируемость, технодолг, долгосрочную разработку.

ECS даст буст производительности, условно, 25% и это никак не станет боттл-неком для любой игры, следственно и на перфоманс не влияет существенно.

Буст это когда x2-10 и т.д. Для этого и есть DOTS, Jobs, Burst которые могут работать даже без ECS фреймворка, просто нужна будет логика-мост.

Humano5974
> ECS при этом не подходит на практике для таких кейсов, когда надо быстро что-то сделать, например прототип или простую игру.
это не так :) одно из частых применений LeoECS, судя по его дискорду (старому, конечно) - гиперкэжуал.

kkolyan

Это его выбор =)

У меня был опыт прототипирования на ECS в гиперкеже...
Там только говнокодом можно выжить)

Но если бы был у меня EasyCS тогда...)

Humano5974
> Это его выбор =)
не его, а их. выбор обусловлен эффективностью подхода. там были явно не только энтузиасты)

Humano5974
> У меня был опыт прототипирования на ECS в гиперкеже...
какие были проблемы ?

Humano5974
> Там только говнокодом можно выжить)
ну и что) красивый код являлся требованием? и как это связано с ECS?

kkolyan

Это всё очень хорошие вопросы, но предлагаю чуток сместить тему ближе к топику)

Сильно далеко ушло)

Humano5974
это напрямую касается топика. фреймворк призван заменить ECS в определенных кейсах. было бы хорошо, если бы автор фреймворка мог четко объяснить чем ECS в этих кейсах хуже этого фреймворка.

иначе формируется мнение что автору было не очень интересно разбираться с ECS и как им пользоваться, а просто хотелось реализовать свои идеи, которые возникли после базового ознакомления с ECS.

kkolyan

Было бы хорошо, но автор не должен что-то каждому объяснять персонально, увы)

Неочевидность профита это проблема презентации, над которой надо будет поработать.

Персонально я такие вопросы решать не буду, это не выгодно, сами понимаете =)

kkolyan

По этому и говорю, что надо будет поработать над этим вопросом презентации.

Humano5974
можешь потренироваться здесь в диалоге. это ускорит итерации по полировке презентации.

У меня был период, когда мне сложно было понять ecs, решилось это тем, что я поработал с MVVM, в трёх проектах...
Затем я подумал *не может быть так плохо во всем мире*, так я вернулся к ecs уже осознанно, я отмел дотс, морпех мне тоже не понравился, вспомнил Actors, это было одновременно прикольно и ужасно.

В итоге я оформил подписку на leo-proto и как же обрадовался увидев там змейку. Я её изучил, понял как добавить новый input вместо старого, а также чтобы вы понимали всё завелось на юнити 6.2, с 0 изменений.

На самом деле, если не перебарщивать с измельчением view компонентов без необходимости, то это идеальный подход, а Лео любой фреймворк, лайт например или прото, уже решают все проблемы.

Я это к чему, а зачем ещё один egoecs, а также зачем в целом приближенный к юнити подход, всё равно никто в середине разработки это внедрять не будет, это звучит как боль.

Также насчёт э... Э... Ну производительность, сорян она важна, как и использование фреймворком памяти, если это ГК поверьте это тоже важно, вы просто MVVM не кушали видимо, это говно жрёт и жрёт, я задолбался это тащить, это дерьмо надо закатать в асфальт и забыть как страшный сон. (Но деньги зарабатывать там приятно, работа долгая, ставишь почасовку и кайф)

В догонку, ecs по сути не только решает проблему разделения view - model, он также предоставляет системы, я благодаря этому пишу свою игру и игру заказчика одновременно, потому что могу копировать 75% кода.

Какие нафиг ГО сущности, которые теряют в универсальности.

Processor

Всё-таки есть серьёзные качественные отличия от EgoECS, например в том что существует Entity отвязанный от Gameobject, который можно привязывать к Gameobject с помощью Actor.

Работать с данными и сериализовывать их становится намного проще.

Так же появляется возможность создавать легковесные Entity без Gameobject и нет необходимости писать ООП-бойлерплейт классы типа Item для инвентаря, а потом морочиться с этим говнокодом и MVP/MVVP, интерфейсами и т.д.

На моей практике такая потребность была неоднократно, но из-за того что "боль" то и не было возможности даже думать об этом.

Решением стало создание EasyCS, который эти вопросы снимает =)

Я начинал свою карьеру в геймедеве с Actors, можно сказать. И да, мне не всё понравилось.

EasyCS позволяет писать системы, опционально.