记者｜技术前沿
在游戏与编程语言交叉的极客世界里，重写《DOOM》几乎是开发者“成年礼”式的挑战。从用Excel渲染到用乐高模拟，无数人用脑洞大开的方式向这部1993年的FPS鼻祖致敬。然而最近，一位名为亚历克斯·陈（Alex Chen）的独立开发者做出了一个更激进的决定：他使用自己亲手设计的编程语言，重新实现了整个《DOOM》游戏的核心逻辑——共计56000行代码，全部运行在一个此前从未有人使用过的语言之上。
“我想证明，一种新语言不是只能写写Hello World或LeetCode题目。”亚历克斯在个人博客中写道。他管这门语言叫“Glide”——一个同时指向“滑翔”与“优雅滑动”的双关词，寓意代码流畅且无摩擦。
从“造轮子”到“造引擎”
Glide语言的设计始于两年前。亚历克斯对现有主流编程语言有着复杂感受：C/C++性能优异但内存管理繁琐，Python开发效率高却难以胜任实时渲染，而Rust虽然安全，学习曲线陡峭。“我想要的是一种兼具C的速度和Python表达力的语言，同时让‘裸指针恐惧’消失。”于是，Glide诞生了。它采用静态类型系统，支持自动内存管理（基于区域推理），并内置了一组针对图形和游戏开发的语法糖——比如原生向量类型、GLSL风格着色器嵌入以及零成本协程。
但语言本身只是工具。亚历克斯明白，要说服社区接受Glide，必须有一个重量级的“杀手应用”。他选中了《DOOM》——原因有二：一是代码规模适中（原版约10万行C），足以暴露语言设计缺陷；二是游戏有大量开源实现（如Chocolate Doom、PrBoom+），可以作为对比基线。
56000行的硬仗
开发耗时整整九个月。亚历克斯从最基础的BSP（二进制空间分割）树开始，逐步重建了地图渲染器、怪物AI、碰撞检测、武器系统乃至音效混合。他刻意避免逐行翻译原版C代码，而是用Glide的语法特性重新架构了逻辑。
“最大的挑战不是写代码，而是让我的语言编译器先能通过所有测试。”亚历克斯回忆说。在编写渲染管道时，他遇到了Glide类型推断的边界情况——一个多态向量操作导致编译器生成了错误的SSE指令。他花了三周修复了编译器后端的指令选择模块，顺便优化了浮点运算的寄存器分配。
最终成果令人惊叹：56000行Glide代码实现了完整的《DOOM》第一章节（Knee-Deep in the Dead），包含全交互式物品、敌人巡逻路径以及脉冲步枪的音效反馈。性能测试显示，在相同硬件上，Glide版本的平均帧率比经典C版本仅低约8%——考虑到这是语言原型，而非经过二十年优化的产品级编译器，这个成绩已属优秀。
一场“自举”实验
更值得玩味的是，亚历克斯甚至用Glide编写了一个简单的《DOOM》关卡编辑器，而该编辑器本身又在Glide环境中运行。“这有点像‘自举’——你用语言写出的东西反过来成为语言生态的一部分。”他在博客中展示了编辑器截图：左下角是场景树，右侧是3D预览窗口，全部基于Glide的即时模式GUI库。
开源社区对此反应热烈。一位Reddit用户在帖子下评论：“这比写一个JIT编译器更疯狂，因为你需要同时做语言设计和游戏实现，两件事都很难。”也有人质疑：为何不用现有语言（如Rust或Zig）完成同样工作？亚历克斯回应：“如果我只想玩《DOOM》，直接下载GZDoom即可。造语言不是为了解决具体问题，而是探索‘我们还能怎样解决问题’。”
语言设计的“极点测试”
在编程语言圈，一个流传已久的说法是：“任何语言如果不能在自身中实现一个编译器和一款游戏，就不值得认真对待。”尽管这个标准有些偏激，但它确实触及核心：语言设计者必须经手真实的复杂度，才能发现抽象模型与现实硬件之间的裂痕。
亚历克斯的实践恰好为Glide做了“极点测试”。在移植《DOOM》的过程中，他发现了语言早期设计中的多处疏漏：比如缺乏对指针别名的清晰定义导致优化受阻、异常处理模型无法干净地处理帧丢失、全局状态管理在协程切换时出现数据竞争。每一次修复都让Glide更健壮，也让他对语言设计有了更深理解。
目前，亚历克斯已将Glide编译器与《DOOM》源码开源在GitHub上，并附带了详细的开发日志。他表示下一步计划是完善标准库，吸引更多贡献者，同时继续优化编译器性能。“也许有一天，有人会用Glide写出下一个《半条命》，”他半开玩笑地说，“但在此之前，我希望至少它能用来写个像样的扫雷游戏。”
写在最后
从某种意义上说，用自创语言重写《DOOM》比制作一款新游戏更难：不仅需要掌握图形学、游戏引擎和编译原理三重知识，还要有勇气在无人之径上踩出脚印。亚历克斯的56000行代码，与其说是对经典的复刻，不如说是一场关于“创造力边界”的宣言——当所有人都使用通用工具时，仍然有人选择从头建造自己的工具，只为看看那条路的尽头有什么。