В Godot показали рой из 100 тысяч частиц. Что за ним стоит

По экрану движется плотное облако точек, которое расступается перед курсором. В новом примере команды Conan таких частиц 100 тысяч. Для инди-разработчика здесь интересно устройство сцены: движение считает библиотека C++, а Godot остаётся местом, где собирают и показывают результат.

Условный рой светящихся частиц расступается вокруг круглого просвета

Редакционная иллюстрация, созданная через Provod. Не скриншот Godot и не результат измерения производительности.

29 сентября авторы Conan опубликовали разбор подключения C++-библиотек к Godot. Рой служит демонстрацией подхода. Мы изучили описание и исходные материалы, но самостоятельно пример не собирали и производительность не измеряли.

За движение отвечает flecs — библиотека с подходом ECS. В упрощённом виде у каждой частицы есть данные о положении и скорости, а общая система обновляет их. В авторском примере частицы отталкиваются от курсора и отскакивают от границ окна.

Godot подключает этот код через GDExtension. Документация движка описывает механизм загрузки нативных библиотек во время работы: ради расширения не требуется собирать собственную версию Godot. В примере появляется узел Swarm, у которого в инспекторе можно менять число частиц и радиус их реакции на мышь.

Conan берёт на себя зависимости и их сборку. В опубликованном проекте это godot-cpp и flecs; CMake собирает расширение, которое затем загружает сцена. То есть знакомая работа в редакторе сохраняется, но рядом появляется отдельный проект на C++.

У каждой частицы здесь нет отдельного узла Godot. Для изображения роя используется MultiMesh: он позволяет отрисовывать множество экземпляров одной геометрии за один вызов отрисовки. В документации MultiMesh именно сокращение таких вызовов названо его преимуществом.

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

Есть и любопытная граница между расчётом и картинкой: авторский код каждый кадр копирует рассчитанные позиции в буфер MultiMesh. Для своей игры я бы отдельно измерил время симуляции, передачи данных и отрисовки. Иначе легко ускорить одну часть и не заметить, где теперь задерживается кадр.

Подключение библиотеки не заканчивается тем, что сцена запустилась на рабочем компьютере. Расширение и зависимости нужно собирать под целевые платформы и архитектуры, учитывать версию API Godot и различать отладочную и релизную сборки.

В разборе отдельно отмечен Linux: при динамической линковке libstdc++ на компьютере игрока должна быть достаточно новая версия этой библиотеки. Авторы предлагают учитывать самое старое поддерживаемое окружение при выборе инструментов сборки. Это как раз тот вопрос, который полезно решить до отправки билда друзьям.

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

Если захотите разобраться в устройстве примера, код расширения и сцена опубликованы в репозитории Conan. Какую игровую механику вы бы построили вокруг управляемого роя?

В Provod можно подготовить визуальный референс для такой сцены: форму роя, свет и цвет частиц. Зарегистрируйтесь в Provod; доступные модели проверяйте в каталоге. Движение и производительность затем предстоит проверить в игровом прототипе.