Комментарии 9
Ваше описание проблемы вынуждает думать, что и решение придумано не самое оптимальное, особенно в рамках ECS.
События подошли бы идеально для получения их извне ECS, для интерфейса, например. Но вы пишете, что только системы могут получать события.
Возможно, для описанной проблемы стоит поискать другое решение?
Ну это как раз размышления для будущего.
Первостепенно проблема заключается в исполнении кастомной логики без постоянного оверхеда, с чем решение справилось удовлетворительно.
Если прямо сейчас потребуется использовать это для интерфейса - то достаточно будет для каждого сообщения создать систему, которая переотправит сообщение через другой мессенджер. Но это шаблонный код и его конечно хочется избежать, подписываясь напрямую.
В статье несколько сумбурно описана проблематика из-за чего не очень понятно во имя чего автор всё это затеял. Создание энтитей и навешивание на них компонентов десятками и сотнями каждый кадр это нормальная тема в ECS и фреймворки для таких задач хорошо оптимизированы. Плюс непонятно зачем пихать в джобы вещи которые происходит очень редко и вообще никак не аффектят перфоманс, а затем жаловаться на бойлерплейт.
Вообще для разруливания логики между объектами разных "типов" в ECS существуют фильтры. Если нам нужно например написать кастомную логику интеракшена с допустим дверью то мы заводим под это систему и пишем в ней фильтр который отбирает сущности с компонентами Door и Interacted и пишем туда свою кастомную логику, посути это и есть аналог виртуального метода. Судя по статье автор об этом знает, на этом и следовало остановится дабы остатся в рамках ecs-way.
Что касается ивентов они в ECS так же реализуются через ентити с компонентом события, который отлавливается системой в обычном порядке и обрабатываются.
В общем мотивационная часть осталась для меня загадкой, что за проблему автор пытался решить...
Если нам нужно например написать кастомную логику интеракшена с допустим дверью то мы заводим под это систему и пишем в ней фильтр который отбирает сущности с компонентами Door и Interacted и пишем туда свою кастомную логику, посути это и есть аналог виртуального метода.
Это самый первый - наивный метод, рассмотренный в статье. Его проблемы там же и описаны.
Что касается ивентов они в ECS так же реализуются через ентити с компонентом события, который отлавливается системой в обычном порядке и обрабатываются.
Этот подход я тоже пробовал, но при написании статьи он совсем вылетел у меня из головы.
В рамках Unity ECS он оказался невероятно медленным и скейлить его по этой причине - невозможно.
Я не знаю почему он у вас оказался медленным тут надо в код смотреть и искать где именно Вы ошиблись. Когда я писал проект в котором активно взаимодействовали (перестреливались) тысячи объектов одновременно там была просто тьма тмущая ecs-событий и создавалось/уничтожалось много сущностей каждый кадр и всё это отлично работало без тормозов даже на телефоне десятилетней давности.
Вот можете полюбопытствовать: https://www.youtube.com/shorts/NERogo5dyoQ
Этот проект так же писался на DOTS-е причём древнющей версии, новые версии подозреваю еще производителней.
Я не знаю почему он у вас оказался медленным тут надо в код смотреть и искать где именно Вы ошиблись.
Структурные изменения в Unity ECS происходят только на главном потоке. Чтобы запустить эти изменения из привычной логики, внутри джобов, требуется командный буфер, который точно также воспроизводит эти структурные изменения, просто медленней и чуть позже. Скейлится это всё очень плохо, почему я и решил обойти стороной структурные изменения.
По сути, с точки зрения логики-обработчика это одно и тоже. Отличается лишь то, как именно данные добираются до него.
Да я вкурсе про командный буфер, в демке выше все структурные изменния так же через него происходили сотнями каждый кадр. Писать в него можно многопоточно, изменния действительно применяются в гланом потоке но это происходит очень быстро.
Ну ок если в Ваших руках он плохо скейлится остаётся только посочувствовать.
Вроде и работал с Unity, но видимо надо разобраться с ECS, т.к. не понял ни сути проблемы, ни решения, ни области, к которой это применяется. Все очень абстрактно для меня.
Решение концептуальной проблемы с Unity ECS. Messenger для System