Boolean

О, интересно. Некоторые идеи мне в голову не приходили.

Мне кажется, разместить два объекта для пружины подряд не получится, потому что к объекту может быть присоединено много разных пружин. Но в целом идея хорошая, может для чего-то ещё подойдёт. Я точно знаю, что так можно сделать иерархию объектов и положить всех детей после родителя, но у меня сейчас нет иерархии в принципе :)
Кстати, для итерации конкретно по пружинам я их в линейный массив складываю и по нему бегу, а не по HashMap. Так действительно быстрее.

Про дублирование данных я почему-то вообще не думал.

Но в общем и целом JVM не даёт возможности класть объекты в памяти как захочется и ECS радикальных бонусов производительности не даёт. Но мне оно просто понравилось как способ огранизации кода и масштабировая программы дописыванием новых компонент вместо выстраивания сложной иерархии.

У меня ещё сильный упор на то, что код должно быть легко писать и менять, чтобы я в одиночку быстро его писал и не сильно страдал от багов, с JVM в этом плане попроще.

Ещё вариант — есть sshfs, который под капотом работает как scp и от сервера требует только установленный ssh.

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

rsync круто копирует, но в нём туева куча параметров и настроек и они все на что-то влияют. Например, rsync может по-разному определять, надо ли копировать файл — может по таймстампу создания или редактирования, может использовать rolling hash, может ещё как. Ещё вопрос, что rsync будет делать с симлинками. Мне обычно лень во всём этом разбираться, я один и тот же скрипт копирую и какие-то опции по необходимости добавляю/убираю.

Я до этого прочитал цикл статей ECS back and forth и пробовал сделать примерно как там.

И я пытался код более абстрактным и эффективным сделать, получилась какая-то неудобная фигня.

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

Я вместо этого хранил хеш-таблички entity->T, а когда вызывался фильтр, например, для двух компонент, я просто брал две хеш-таблички, выбирал ту что меньше, итерировался по её объектам и проверял наличие вторых.

Как итог у меня было почти бесплатное добавление-удаление компонентов (просто поменять одно значение в табличке), но не такая эффективная итерация по объектам. А у тебя наоборот — итерация вроде эффективная, но добавление компонента или фильтра требует обновлять кеш.

А, я кажется понял. Просто в моём подходе компоненты были тупые, а у тебя каждый компонент ещё знает его родительскую entity. Поэтому часть логики иначе сделана.

Хм, а годот при удалении ноды Target автоматически занулит все ссылки на неё?

Что если, допустим, где-то осталась ссылка на компонент противника, а противник уже убит и даже убран с карты?

Ещё вопрос.
github.com/nakoff/Core-Godot/blob/main/Framework/Components/DamageComponent.cs
Получается, за один игровой цикл нельзя получить урон два раза?

Кстати по коду — я видел идею (и мне самому так понравилось) по папкам раскладывать по смыслу — типа система + компоненты которые она использует, а не так что в одной папке только системы и в другой только компоненты.

А как сделано удаление и ссылки из компонентов других Entity на удаляемую Entity? Особенно с учётом того, что у тебя компоненты могут ссылаться и на другие ноды (которые могут быть ещё и компонентами).

Просто я видел разные подходы и они все были со своими недостатками.

Ещё вопрос про компоненты. У тебя можно прицепить несколько компонент одного типа к одному объекту? Выглядит так что можно (раз в коде есть компонент типа DamageReceiveComponent).

Я пытался свой ECS сделать, и кажется так и не нашёл баланса между удобством использования ECS и жёсткостью ограничений (которые позволили бы делать всякие крутые оптимизации).
Я пробовал ограничить, что ссылки из компонентов могут быть только на Entity и чтобы компонент какого-то типа мог быть только один. Для случаев когда входящего урона, например, может быть несколько, я делал компонент со списком элементов.
И даже в таком случае решение задачи типа «хотим сохранить снапшот мира со всеми ссылками» уже выглядело довольно костыльно.

https://github.com/Kright/mySmallProjects/tree/master/2024/wellcome2valhalla
Вот мой код с уже готовым проектом если кто захочет по-быстрому попробовать.

Для истории — я сделал четыре класса.
изменяемый, с final полями, record и Value класс. Rysen 3700x, VM version: JDK 23.0.1, OpenJDK 64-Bit Server VM, 23.0.1+11-39

Benchmark                           Mode  Cnt      Score     Error  Units
BenchValhalla.finalPoint            avgt    5   3399.923 ±  88.193  us/op
BenchValhalla.plainOldMutablePoint  avgt    5  52134.455 ± 942.619  us/op
BenchValhalla.recordPoint           avgt    5   3354.371 ±  56.565  us/op
BenchValhalla.valhallaPoint         avgt    5   3385.298 ±  39.188  us/op