Доброго времени суток. Сейчас я работаю над своей архитектурой Component /

Systems.
Если просто, это то что использовали до дробления на ECS. Потому что ECS это все таки нишевая вещь. ИМХО.
Так вот в расте и го я использую интерфейсы для создания обобщенных систем.
Но в D в D у нас не все так просто, мы не можем использовать структуры с Interface? Насколько я зняю.
Выходит у нас 2 пути. Классы, что не всегда хорошо и метопрограммирование..
В моем случае в функцию куда мы отправляем объект, мы должны проверить, если ли у него методы.
Или поля. Гибко, но я совсем не знаю...насколько это ударит по времени компиляции?
Вообще есть какие то исследования или заметки, что быстро компилируется, а что нет?
Ну и в целом, какие у вас идеи по решение задачки. Нужна принять разные данные, проверить обобщенные вещи и вернуть ошибку компиляции или записать объект куда либо.
Тут даже суть не в обобщенности типо интерфейса. А скорее создание точечных обобщенных вещей.
Для наглядности, пример.
У нас есть N компонентов которые мы рисуем.
Но по сути просто рисовать мы их не можем напрямую, нам нужно составить пулл объектов которые удовлетворяют данным. Например они видны, их позиция и.т.д.
В итоге это наследование или создание интерфейсов. Возможно концепты.
Я бы наверное мог просто все хранить в классах и возможно стоит так сделать, но есть нюансы.
Классы это же ссылочный тип? в итоге будет массив ссылок, а нам бы массив структур. Для разных оптимизаций. и.т.д. и.т.п
Считаю это актуальная проблема D, в остальных языках это решено +-.

scoped!(Class)[]

Стикер

Стикер

Стикер

Стикер

можно создать хоть пул объектов класса(D позволяет вручную создавать объекты класса), если их количество достаточно большое.

Gandalf Korney
пример из моей обёртки над mi_malloc.

извиняюсь за говнокод :)

Они нишевые. 1. задача, это не умение в архитектуру. 2. параллелизм и перфоманс. Если посмотреть на существующие движки и игры, у ECS будет не так много реальных использований. Они будут, но это не будет чем то доминирующем и никогда не будет. ECS это способ отделить часть логики и данных от общей системы. Многие вещи вы все так же будете делать отдельно, вне ECS. Проблем у ECS не меньше, чем плюсов. От дробления на компоненты, до раздувания кодовой базы. То за что например ругают Го. Есть и другие проблемы. Исторически ECS это одна из разновидностей Component / System подхода и их тоже много. И из второго можно сделать первое, но не наоборот. Если приводить человеческий пример, взрывать дома это нишевый подход для разрушения здания и не подойдет в ряде случаев. Почему я не хочу доверятся классам, они не работают в BetterC, они требуют избыточных решений. Первое я никак не измен. Второе, просто даст мне больше времени думать над каждым компонентом. Самое главное тут отделить, любые данные от любой логики. То есть ориентироваться на структуры. Концепты и либы, что были выше..Главный тут вопрос это время компиляции, если никто сам не имел опыта. Что ж я вероятно это потом протестирую.

Стикер

Стикер

Стикер

Стикер

Вы правда говорите в том, о чем не понимаете. Этот паттерн появился в конце 90х. Вы представляете сколько игр делается в целом? Так вот у ECS не будет и 3-5%. Я что должен говорить что такое ниша? Я это лишь говорю, потому что чувствую что устал как люди выдают поверхностные знания, за действительно полезные. Вы думаете у меня есть студия уровня AAA или миллиарды долларов? Увы нету у меня таких ресурсов. Даже если вы наберете 1000 отличных игр на ECS, то 1 000 000 будут без них. Даже если вы скажете что они использовали ECS, это не будет чем то уровня У НАС ВЕСЬ ДВИЖЕК НА ECS. ECS будет отвечать за определенную часть системы. UI, Объекты, тесты бизнес логики,что то еще. Единственные движки на Only ECS я видел в Rust. В Rust очень сложно в архитектуру. Это даже грустно, маркетологи из Unity навешали лапши, а теперь даже в инди сегменте какой то треш. Хотя большинство игр на Unity как делалось без ECS так и будет делаться. Так же как на Unreal / Godot / ect. А там где нужна будет ECS, люди напишут ECS. Если это не ниша? ТО я хз.

Стикер

Стикер

Стикер

Стикер

Стикер

Стикер

Unreal как коммерческая технология, которая вышла в релиз в том самом конце 90-ых. Им незачем переходить на другой архитект, т.к. это ресурсозатратно и может тупо отпугнуть разработчиков, которые привыкли к классам наследуемым от Actor. Может я чего-то и не знаю об Unreal, но примерно их архитектура скриптов долгое время оставалась такой-же очень долгое время, изменяя фунционал и возможности движка.

Стикер

Ты причину и следствие перепутал

-_-

а как ECS соотносится с акторной моделью?

В Unreal Engine элемент сцены - объект класса, наследуемый от класса Actor. В ECS другой подход, элемент мира - некоторая сущность, к которой можно привязать компоненты, которые обрабатываются системами. Это два разных архитектурных подходов/решений.