Помогите придумать или найти название для архитектуры проекта (ECS, C#)
Я разработчик на Unity и для одной коммерческой компании я разработал решение для создания сценариев через граф и последующего их воспроизведения
При создании этого инструмента, я вдохновлялся архитектурой ECS и придумал достаточно странную архитектуру, для которой хочу придумать название или найти аналоги у других
Архитектура
У некоторых нод (Node) есть список компонентов (components), в котором хранятся не сами компоненты, а их интерфейсы, что позволяет обойти ограничение ECS на компоненты одного типа в сущности
При проигрывании сценария, нода при активации, передаёт свой массив компонентов в шину данных (SignalBus от Zenject). Системы (systems) через шину принимают компоненты и исполняют их
То есть сама идея разделения данных и их исполнения взята из ECS, но при этом тут отсутствуют сущности (entity) и вместо них для компоновки компонентов используются ноды
Я думаю, что это плохой ECS, так как эта архитектура не подразумевает Data Oriented дизайна и хранит компоненты крайне не эффективно, но сама идея систем, которые исполняют компоненты, тут сохранена
Я нашёл похожий по названию подход CGS на Rust, но тут скорее речь идёт про модификацию оригинального подхода ECS с превращением сущностей в компоненты со указателями на компоненты
И также стоит учитывать тут шину данных, так как она работает в обе стороны. То есть системы сами могут посылать данные нодам (да, ноды имеют поведение при активации)
Как вообще такое можно охарактеризовать? Я думал про что-то вроде Node Component System, но тут проблема в том, что ноды имеют своё поведение и тут правильнее сказать про использование нескольких архитектурных шаблонов
Часть с нодами и графам понятна, это просто ориентированный исполняемый граф с нодами как единицами исполнения. Но как назвать этот огрызок ECS, который работает через шину данных и связывает ноды, компоненты и системы?
Мне это очень не нравится. Эта архитектура пытается усидеть на двух стульях.
Она пытается делать разделение данных и логики, но не делая это до конца и не обладая ни вычислительной эффективностью, ни эффективностью в атомизации преобразований (т.к. преобразования привязаны к состоянию и коду ноды).
Но также она пытается сохранить удобство, которое дает модель компонентов, но и это делает плохо, т.к. код больше не локализован, частично лежит в системах, частично лежит в нодах, к тому же исполнение преобразуется в состояние через шину событий и гоняется между нодами, между системами, туда и обратно. Отладка кода, который умеет превращаться в состояние, и так сам по себе малоприятный процесс в ECS, а тут ещё и шина событий двухсторонняя.
Причем, такую систему сценариев можно спокойно реализовать на базом ECS. Или на системе компонентов. Зачем вообще на нодах сценария нужны компоненты, если ноды по сути отвечают за преобразования контекста? Это ведь на контексте должны быть компоненты, которые используются и преобразуются нодами в процессе исполнения сценария, разве нет? А ноды это просто код преобразования с фильтрами входа и выхода. Перемещение между нодами сценария санкционируется компонентом на конетксте, который сообщает системе что контекст #AAA хочет посетить систему с такими-то параметрами ноды сценария #BBB.
Нода сама по себе ничего не исполняет, скорее имеет данные и логику, которую уже вызывает плеер. Нода имеет состояние активности и для её включения/отключения уже требуется контекст исполнения (который генерирует плеер)
Сами ноды и компоненты иммутабельные и скорее ближе к списку, который плеер использует как последовательность действий для систем. И компоненты в нодах имеют смысл, так как они не состояния. Они по логике ближе к сигналам-инструкциям, которые системы принимают через шину и исполняют
Наверное ты прав, что логика нод и систем не должны существовать раздельно, и то, что через обычный ECS это вполне можно было бы реализовать, но тут изначально было командное решение создавать именно граф с последовательными инструкциями, которые бы изменяли мир
Наверное можно было бы создать ECS со специальными системами-нодами, или убрать сущность нод, но так уж получилось и инструмент уже написан и работает
Мне кажется "спагетти" подойдет.
unity 6 behavior tree глянь кстати.
Тут сам пакет не столько про повторяющееся поведение сущностей, сколько про исполнение заранее подготовленных последовательностей сценариев, он так и называется: Scenario Controller
А про спагетти тут конечно правда, если бы я умел нормально рисовать схемы, было бы лучше
Название "Nahuevertil System", думаю, подойдет. :)