Записки ленивого разработчика

ECS данные обычно рассматриваются как “база данных”, записи в которой не имеют четкого порядка. Но что если этот порядок необходим, например, для отрисовки пользовательского интерфейса?
ECS данных может быть очень много, но что если количество сущностей не превышает десятка тысяч, количество компонентов - нескольких тысяч, а надо запускаться в ограниченном по ресурсам окружении типа web-браузера?
Последние доработки LeoECS Proto были направлены на решение этих двух проблем.

В свете последних новостей (тут и тут) про будущие блокировки иностранных облачных сервисов для всех пользователей в РФ было решено подготовиться к прозрачной миграции таблиц с GoogleDocs на ЯндексДиск или свой сервер.

LeoECS Proto был портирован на Golang, что позволит использовать его как на стороне сервера, так и в любом Golang-движке (Ebitengine, G3N и т.п).

Тут вышла занимательная статья по сравнению двух фреймворков. Предлагаю расширить ее до четырех: LeoECS Lite, Morpeh, DragonECS и LeoECS Proto.

Часто задают вопрос - а как выключать системы в ECS? Как запускать определенные системы через определенные промежутки времени? Как выполнять список систем только если активирован определенный режим в игре? В качестве ответа на эти вопросы появился пакет EcsProto.ConditionalSystems.

Когда требуется реализовать какие-то простые анимации, то первым делом прибегают к готовым пакетам, реализующим tween-анимации с поддержкой определенного набора функций сглаживания (easings). Но что, если нужно более точно контролировать анимацию программно как часть игромеханики и при этом сохранить поддержку функций сглаживания?

Деревья поведений (BehaviourTree) - довольно часто используемый подход для построения логики поведения ботов. Существует много комплексных решений, предоставляющих визуальное построение, отладку, плотную интеграцию в какой-то движок. Но что, если все это излишне и требуется минимальный размер, простота сборки, скорость работы и возможность работать на сервере без движка?

Часто бывает необходимо сделать процедурную анимацию для цепочки сочлененных сегментов, когда координаты узлов не известны, а есть только набор правил, которым эта цепочка должна следовать (длина сегментов, углы поворота и т.п). На помощь приходит инверсная кинематика.

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

Часто бывает нужно обрабатывать достаточно много объектов, разнесенных в пространстве, причем нужно иметь возможность искать самый близкий объект (или даже несколько) к конкретной точке. Например, любая игра в стиле Tower Defense, где нужно для каждой башни находить ближайшего врага из сотен или даже тысяч бегущих мимо. Как это можно сделать?