Часто задают вопрос - а как выключать системы в ECS? Как запускать определенные системы через определенные промежутки времени? Как выполнять список систем только если активирован определенный режим в игре? В качестве ответа на эти вопросы появился пакет EcsProto.ConditionalSystems.
Когда требуется реализовать какие-то простые анимации, то первым делом прибегают к готовым пакетам, реализующим tween-анимации с поддержкой определенного набора функций сглаживания (easings). Но что, если нужно более точно контролировать анимацию программно как часть игромеханики и при этом сохранить поддержку функций сглаживания?
Деревья поведений (BehaviourTree) - довольно часто используемый подход для построения логики поведения ботов. Существует много комплексных решений, предоставляющих визуальное построение, отладку, плотную интеграцию в какой-то движок. Но что, если все это излишне и требуется минимальный размер, простота сборки, скорость работы и возможность работать на сервере без движка?
Часто бывает необходимо сделать процедурную анимацию для цепочки сочлененных сегментов, когда координаты узлов не известны, а есть только набор правил, которым эта цепочка должна следовать (длина сегментов, углы поворота и т.п). На помощь приходит инверсная кинематика.
Часто бывает непонятно - насколько соотносятся цифры тестов, особенно если их было произведено больше двух. Для выяснения этого часто прибегают к построению графиков для результатов в единой системе координат и дальнейшему сравнительному анализу.
Часто бывает нужно обрабатывать достаточно много объектов, разнесенных в пространстве, причем нужно иметь возможность искать самый близкий объект (или даже несколько) к конкретной точке. Например, любая игра в стиле Tower Defense, где нужно для каждой башни находить ближайшего врага из сотен или даже тысяч бегущих мимо. Как это можно сделать?
Насколько сложно переделать старый проект, написанный с использованием LeoECS Classic, на LeoECS Proto? На самом деле достаточно просто (особенное если уже имеется опыт работы с LeoECS Lite). Давайте сконвертируем один из проектов-примеров на новый фреймворк.
Часто требуется возможность изменения логики без пересборки основного проекта - для этого логика должна быть представлена в виде внешнего контента, который подгружается из локальных файлов или по сети. Так часто хранят графы диалогов, развития событий визуальных новелл, каких-то конфигурационных файлов и т.д. Представление подобных данных в виде визуального графа может быть наглядным, но требует реализации визуального редактора с постоянной актуализацией под меняющиеся требования, что часто избыточно и трудоемко в поддержке. В качестве альтернативы обычно используется встраиваемый скрипт-язык, позволяющий писать логику поведения в виде упрощенного кода, который потом будет интерпретирован основным приложением.
GoogleDocs (GoogleSheets) могут являться источниками данных для локализации, настроек или игрового баланса. Для их импорта и разбора существует множество пакетов, но все эти решения достаточно объемные и ориентированы исключительно на работу в редакторе Unity. Что, если нам хочется что-то подправить на лету и не ждать несколько минут, пока пересоберется новый билд с новыми данными?
UtilityAI - еще один популярный подход наравне с GOAP для реализации поведения ИИ на основе настраиваемых правил. В чем же разница?