用 APL 语言编写的 3D 体素游戏引擎：一场关于编程范式与性能的实验

背景

这篇来自 Hacker News 的讨论帖展示了一个极具极客精神的个人项目：一个完全使用 APL 语言编写的 3D 体素游戏引擎。作者最初发起这个项目的动机源于一个自我挑战（bet）：验证 APL 的符号表示法（notation）是否真的能提供一种更简洁、更高效的方式来开发体素游戏。

APL（A Programming Language）是一种以高密度、数组导向和符号化著称的编程语言。它允许开发者用极少的代码行数表达复杂的数学和逻辑操作，但同时也因其陡峭的学习曲线和相对小众的生态而鲜见于大型商业项目。该项目不仅是一次技术验证，更是一次对传统游戏开发范式的边缘探索。

核心内容

该项目目前处于高度实验性阶段，代码中存在大量 Bug，且性能表现尚不稳定。以下是该项目的详细技术实现、运行环境及操作指南：

1. 游戏控制与交互

游戏提供了基础的体素世界交互功能，操作方式如下：

• 移动：W-A-S-D 键控制角色移动。
• 跳跃：空格键（Space）。
• 视角：鼠标控制摄像机视角。
• 退出：Q 键。
• 调试信息：I 键切换渲染信息（Render information）显示。
• 穿墙模式：F 键进入快速无碰撞（noclip）模式。
• 鼠标锁定：L 键在游戏内锁定/解锁鼠标。
• 方块放置：数字键 1-5 用于选择不同种类的方块进行放置。

2. 技术栈与依赖环境

该项目对底层图形 API 和构建工具链有明确要求：

• 核心语言：Dyalog APL 20.0。
• 编译工具：需要 C 编译器（C Compiler）和 CMake。
• 图形后端：支持 Vulkan、DirectX 12 或 Metal。具体支持情况需参考官方说明。
• 窗口与输入库：依赖 SDL3 及其扩展库 sdl3_ttf 和 sdl3_image。
  • MacOS 用户：可通过 Homebrew 安装依赖。
  • Windows 用户：需手动获取 SDL3 的开发库（.dlls），并放置在 ./libs 目录下。

3. 构建与安装流程

项目包含一个名为 LSE 的库，需要先构建并安装。

Linux/macOS 构建步骤：

cd lse
mkdir build
cd build
cmake ..
make
make install

此过程会在 ./libs/ 目录下生成 libLSE.dylib（macOS）或 libLSE.so（Linux），以及相关的 SDL3 库文件。

运行游戏： 构建完成后，可通过以下命令运行：

./main.apls

• Linux 用户注意：如果 dyalogscript 位于非标准目录，需修改 main.apls 文件中的 shebang 行，将其替换为 which dyalogscript 输出的路径。

Windows 构建注意事项： Windows 下的编译较为复杂，建议使用 cmake-gui 并找到 SDL3 发布版中提供的开发库。

APL 会话运行方式： 也可以通过 Dyalog APL 会话直接运行：

]cd <ROOT DIRECTORY>
]link.create # ./avg
state.Play

4. 着色器（Shaders）管理

• 源代码中的着色器位于 ./shaders/glsl 目录。
• 仓库默认捆绑了着色器文件。
• 若需修改，可编辑 GLSL 着色器后运行 ./compile_shaders.sh 脚本。
• 注意：此脚本依赖 DirectX Shader Compiler、glslc 和 spirv-cross。

5. 已知问题与限制

作者明确列出了当前版本的诸多缺陷：

• 性能回退：Windows 平台存在显著的性能回归问题，正在修复中。
• 图形 API 限制：Windows 上目前不支持 DirectX 12 后端。
• 会话限制：当前无法在同一会话中多次运行游戏。
• 系统错误：已知会导致 syserror 999。
• 内存泄漏：作者坦言代码中可能存在内存泄漏。

6. 资源归属

游戏纹理资源由 Madeline Vergani (@RubenVerg) 提供。

关键要点

• 范式验证：项目核心目的是验证 APL 在 3D 游戏开发中的可行性，特别是利用其数组处理能力简化体素逻辑。
• 实验性质：代码质量不高，Bug 较多，属于早期原型（Prototype），不具备生产环境可用性。
• 跨平台复杂性：虽然支持 Vulkan、DirectX 12 和 Metal，但 Windows 平台的构建和运行最为棘手，尤其是 DirectX 12 支持尚不可用。
• 依赖管理繁琐：需要手动处理 LSE 库、SDL3 依赖以及着色器编译工具链，对普通用户门槛极高。
• 性能瓶颈：Windows 平台存在严重的性能问题，且存在潜在的内存泄漏风险。
• 社区协作：使用了外部艺术家提供的纹理资源，体现了开源项目的协作特性。

意义与影响

尽管该项目目前存在诸多技术缺陷，但其在编程社区中仍具有一定的象征意义和技术探讨价值：

1. 挑战主流开发范式：在 C++、Rust 和 C# 主导的游戏引擎领域，使用 APL 这种函数式/数组式语言构建 3D 渲染引擎是一种反直觉的尝试。它证明了即使是在需要高性能图形计算的领域，高抽象级别的编程语言也能通过特定的架构设计（如调用 C 库、使用外部着色器）实现功能。
2. APL 的现代生命力：通过 Dyalog APL 20.0 和现代图形 API（Vulkan/Metal）的结合，展示了 APL 并未过时，而是可以通过互操作性（Interoperability）融入现代软件栈。
3. 极客精神的体现：该项目是典型的“为了证明一个观点而构建”的个人项目。它提醒开发者，技术选型不应仅局限于行业惯例，探索边缘工具链有助于深化对编程语言本质和图形渲染原理的理解。
4. 对性能优化的启示：作者提到的 Windows 性能回退和内存泄漏问题，为那些试图在非传统语言中构建高性能应用的人提供了宝贵的反面教材或调试切入点，强调了底层资源管理在图形编程中的重要性。

总的来说，这是一个充满实验精神的代码艺术项目，而非一个成熟的游戏引擎产品。它的价值在于探索边界，而非提供即插即用的解决方案。