Можно продолжить дискуссию?
На основе оной иерархии (отнюдь не случайной) строится большая часть игровой логики и описательного движка
Меч, зачарованный на огонь, яд или и то и другое — инстанс какого-нибудь из классов мечей с со списком зачарований в соответствующем поле
Пламенный меч — класс, описывающий вундервафлю, представляющую из себя меч, клинок которого является пламенем и который, кстати, запрещает себя зачаровывать.

Когда я пытаюсь сделать подобное компонентами — выходит несколько трешовенько.
Вот что с точки зрения компонент должен из себя представлять короткий меч?
— (Wearon(), Sword(type='short'))?
— (ShortSword)?
— (Wearon(), ShortSword())?

А на что влияет "короткость" меча?

То, о чем мы говорили в прошлый раз: https://en.wikipedia.org/wiki/Entity_component_system

На какие-то события реализованные через диспатч, на тот факт что он занимает только одну клешню игрока, в квесте старого мечника точно от типа диалог зависел

Я к тому, что "короткость" это не свойство только меча скорее всего. Какой-нить малый топорик или булава занимает тоже одну клешню. Если "короткость" это некое свойство влияющее на количество потребных клешней, классы кому можно пользоваться, каким-то специфичным просчетам урона, то я бы "размер оружия" сделал отдельным компонентом

Еще раз - ориентируйтесь на реальный мир. И выделяйте те части, которые вы готовы просчитывать в вашем виртуальном мире. Те части, которые общие для многих предметов выделяйте в компоненты и переносите общий функционал в компоненты из предметов. Предмет как коллекция компонентов должен уметь скомбинировать вызовы абстрактных интерфейсов компонентов не парясь как конкретно они реализованы

> "как представить проблему предметной области в языке программирования"

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

Так и у нас -- изучайте языки программирования, алгоритмы и структуры данных, дискретную математику и пишите больше программ

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

https://t.me/typeslife/14510

Это всё вопросы оптимального конструирования/изготовления моделей.
Одного наилучшего способа нет и быть не может.
Это вопросы создания понятийного базиса мира и моделирования мира в этом базисе.
Аналогичен вопрос - лучшего языка программирования или лучшего вычислителя.

Общее всегда не будет оптимальным. Локальное не общее, специальное и оптимальное всегда будет не оптимально глобально.

Это всё вопросы формализации.

ECS используется в геймдеве ради оптимизации производительности кода через SoA. А так, если состав компонентов не меняется за lifetime объекта, то множественного наследования (C++) или обычной композиции (Java, C#, ...) достаточно.

Если же рассматривать когнитивное удобство, то нужна поддержка "is", как на уровне кода, так и в редакторе.

Про производительность -- я как раз про кэши и сказал, да

Ну а "is" в ECS решается добавлением фантомного компонента "is-X"

Обычной композиции, может, и достаточно, но в ECS и она в разы проще :)

И потом в рантайме бегать по DAG? :) Задача несколько сложнее.

Пример: дизайнер уровней создаёт в редакторе Box с именем Box01, часть свойств настраивает вручную, часть через is HeavyBox (который is Box) и is SpecialWoodenBox (который is WoodenBox, который is Box). Пока всё выводится однократно, и в рантайме движка неотличимо от полностью ручных настроек. Ок, теперь представим, что SpecialWoodenBox содержит сенсор и кусок игровой логики для того случая, если коснувшийся его игрок обладает AncientKey. Тогда "is" влияет и на генерацию специальных структур/компонентов игровой логики. Далее рассматриваем жизненный цикл ящика. Оказывается, что ящик сначала "живёт" по физике, затем управляется анимацией катсцены, а под конец становится статикой. Это требует динамических "is" и ещё более сложной трансляции наборов правил в "плоские" рантайм-состояния.

Полное решение пока не представлено ни в одном игровом движке. Сегодняшний максимум это "потвикать настройки объекта из галереи".

Правильно ли я понимаю, что нужно no-code решение?
Потому что я не вижу препятствий к выражению того, что вы говорите, через комбинацию нескольких компонентов и систем

"no-code" - marketing bullshit, к данной задаче отношения не имеет.

В рантайме могут использоваться разные решения - наследование, композиция, ECS с SoA, в зависимости от требований к производительности и прочему.

Вопрос в том, что в геймдеве (да и, кстати, в САПРах) пока нет развитых систем вывода по "is".

Что за "вывод по is"?