3D-движок для воксельных игр на языке APL

Ключевые факты

• Воксельный движок полностью написан на APL, что редко встречается в графических приложениях
• Требует компиляции из исходников с внешними зависимостями (Vulkan, SDL3, шейдеры GLSL)
• Поддерживает кроссплатформенность (Linux, macOS, Windows), но с известными проблемами на Windows
• Использует Dyalog APL 20.0 и встраивает нативный код на C для критичных операций
• Проект экспериментальный и содержит баги, включая утечки памяти и системные ошибки

Ред. Список фич и список багов тут примерно одной длины, и это, пожалуй, самая честная документация года.

Почему это важно

APL обычно ассоциируется с научными вычислениями и обработкой массивов, но редко используется для разработки игровых движков. Этот проект показывает, что специализированный язык можно применить не только к своей традиционной нише, а использовать его алгебраическую мощь для манипуляции трёхмерными данными и состоянием сцены. Успешная интеграция с современными графическими API (Vulkan, DirectX12, Metal) через C-биндинги расширяет представление о возможностях языка.

Ред. Доказано, что на APL можно сделать игру. Осталось доказать, что её кто-то прочитает после автора.

Кому это важно

Интерес охватывает несколько групп. Для энтузиастов APL это доказательство концепции: язык способен справиться с real-time графикой. Разработчикам движков полезно изучить, как встраивается нативный код и компилируются шейдеры. Исследователям языков программирования проект демонстрирует, как альтернативные нотации справляются с высокопроизводительными задачами. Для сообщества воксельных игр это просто интересный случай использования, хотя практическая применимость ограничена из-за статуса экспериментальности.

Ред. Четыре целевые аудитории, и у всех общий мотив «посмотреть, как оно вообще запустилось».

Как это применить

Практическое применение требует соответствующей инфраструктуры. Разработчик должен установить Dyalog APL 20.0, C-компилятор и CMake, затем собрать библиотеку LSE, которая связывает APL с C-кодом и SDL3. Шейдеры находятся в GLSL и компилируются в несколько форматов через DirectX Shader Compiler и spirv-cross. На Linux и macOS процесс стандартизирован через make, на Windows требуется использовать cmake-gui и самостоятельно размещать DLL. После сборки движок запускается через Dyalog session с командой Run.

Ред. На Windows инструкция честно превращается в квест «найди DLL и положи её сам». Геймплей начинается ещё до запуска игры.

Можно ли доверять

Проект явно позиционируется как экспериментальный и багги. Автор честно перечисляет известные проблемы: регрессии производительности на Windows, отсутствие поддержки DirectX12 на Windows, невозможность переиграть уровень в одной сессии, системные ошибки типа syserror 999 и предполагаемые утечки памяти. Это не готовый продукт и не рекомендуется для производства. Однако для изучения архитектуры, интеграции с нативными библиотеками и построения прототипа проект вполне надёжен.

Ред. Автор сам выписал все свои баги в README, так что доверять можно ровно настолько, насколько он не забыл что-то дописать.

Риски и подводные камни

Основной риск, дефицит документации и поддержки. APL остаётся нишевым языком с маленькой экосистемой, поэтому отладка проблем будет затруднена. Сборка требует точного совпадения версий SDL3 и других зависимостей, что на разных системах может быть болезненно. Утечки памяти и нестабильность на Windows делают продукт непригодным для критичного использования. Кроме того, графический конвейер (шейдеры, компиляция) требует дополнительных утилит (glslc, spirv-cross, DirectX Shader Compiler), отсутствие которых прерывает сборку.

Ред. Нишевый язык, точные версии зависимостей и утечки памяти. Полный набор для вечера, который точно не закончится игрой.

«This started off as a bet with myself that APL notation would provide an easier way to make a voxel game.»

— Автор проекта, HN