"Всё что нужно знать про Entity-Component-System"
(геймдев открывает для себя функциональное программирование:)
Ну, да, для системы с тысячами типов данных, как dwarf fortress, ECS + реляционная модель, "усиленная" джсонами.
Связи через графовые отношения:
Гном (id=123) держит меч (id=456) из обсидиана (id=789) =>
CREATE (:Сущность {id:123})-[:HOLD]->(:Сущность {id:456})-[:MADE_OF]->(:Материал {id:789});
Да вот только тривиальное "найти всех гномов в радиусе 10м, держащих деревянный меч", систему сразу подвесит :) Я бы ещё для хардкора DDD накинул, чтобы только первичные требования составлять пару лет (и через месяц реализации понять, что надо было делать совсем по другому).
-- Реактивщина + стрим процессинг?
Чисто лучше, да только помрёшь в отладке асинхронных цепочек событий )))
Поэтому и от модели акторов я наверное всё же откажусь.
"Возьми кафку", говорили они...
-- Онтика? RDF/OWL?
:Лава rdf:type :МагматическийМатериал ;
:hasReaction [:with :Вода ;
:produces :Пар, :Обсидиан] .
:Гном :можетДержать :Предмет .
+ SPARQL-ом "найти материалы, которые ржавеют при контакте с водой"
Пихаем всё графом в Neo4j...
да только оверхэд на инференс в реалтайме получаем уже на первых 50 сущностях :)
Разве что на Rust + Bevy пилить, да тут сам загнёшься соответственно от когнитивный перегрузки.
Родной df на плюсах, на райзене 5600 и так-то большой тормоз уже на паре сотен дварфов и сотне прирученных животных (и уж молчу про симуляцию магмы :)
-- На виртуально бесконечных ресурсах я бы выбрал скорее всего Event Sourcing + CQRS, тут не просто отладка элементарная, а мы вообще получаем по сути детерминированную машину времени, и решаем кучу проблем.
Собственно вот:
Domain-Driven Design: The Power of CQRS and Event Sourcing
Да только на практике в таком подходе заткнёмся ещё быстрее, чем с онтологиями...
-- На самом деле наиболее легко и просто было бы такое спроектировать просто в чистом ФП, да только из-за иммутабельности тоже совсем не потянет в плане продуктивности.
Размышления продолжаю.