《德军总部 3D》（Wolfenstein 3D）原始开源源码存档

这是 id Software 于 1997 年 12 月 23 日由 John Carmack 亲自发布的一份源代码档案，而不是一个可以直接安装游玩的成品项目。发布说明开门见山地指出：DOOM 源码以非盈利使用为前提公开，但代码本身不包含游戏内容，使用者仍然需要自备一份正版 DOOM 的游戏数据才能把它跑起来；如果手头没有，作者建议去软件商店购买。因此这个仓库在今天的意义更接近一份「源头文件」——它记录了一款定义了第一人称射击品类的作品当年是如何被写出来的，供后人阅读、实验、移植和在其上继续搭建新东西。

发布说明特别感谢了 Bernd Kreimeier，是他花时间把工程重新清理了一遍，确认它确实还能正常编译运行。Carmack 坦言代码放几年不用就会「腐烂」，要让别人重新接手需要付出额外努力，这段致谢也从侧面说明了这份代码在公开前经历过一次抢救式的整理，而不是简单地把内部目录打包上传。

渲染部分是整份文档里技术含量最高的自述。Carmack 回顾说，自己当年采用的基本渲染概念是「横竖方向上恒定 Z 的线段、每个光照带使用固定的明暗」——他认为这个思路本身完全正确，但具体实现如果重新做一遍可以大幅改进。原始代码按墙、地板、精灵（sprite）的先后顺序分别推进渲染；他后来意识到，可以把这一整套流程压缩成一次对 BSP 树从前到后的遍历：在下降过程中收集信息，再在回溯上行的路上把同一个子扇区（subsector）里的内容一次性画完。要做到这一点，需要把地板和天花板当作真正的多边形来处理，而不是只当成墙与墙之间的空隙；同时还需要把精灵公告板裁剪成子扇区片段。他称这才是「The Right Thing」。

核心特性

移动与视线检测被作者点名为「回头看时比较大的失误之一」。原来的实现是让移动和视线与地图线段做求交检查，代码混乱且存在若干失败情形，而一个更简单也更快的方案其实一直摆在眼前：BSP 树当时只被他用于渲染，他并未意识到它同样可以用于环境测试。把视线检测换成一次 BSP 线段裁剪会相当容易；真正棘手的是用扫掠体积来做移动检测，这会牵涉到 Quake 与 Quake2 中多面体边缘倒角所面对的那一类难题。这些反思对学习老式 FPS 碰撞与可见性判断的人来说，本身就是很有价值的注解。

平台与许可方面，发布说明给出的坏消息相当直接：这份代码只能在 Linux 上编译和运行。DOS 版本之所以没有一并放出，是因为当时使用了一个受版权保护的声音库（Carmack 自己都感慨那是个错误，并说自己后来都自己写声音代码了）；至于微软方面做的 Windows 移植，他坦言甚至不知道最终下落如何。不过他强调代码的可移植性其实相当好，移植到几乎任何平台都应该是直截了当的工作。他还自嘲代码写于很久以前，回头看有不少做法显得相当傻，比如用极坐标来做裁剪。文件末尾标注了版权归属 ZeniMax Media Inc.，并以 GNU GPL 2.0 授权（早年公开声明强调非盈利使用），这决定了它作为开源项目在现代的分发与衍生规则。

文末列出了一份颇具体的方向清单，可以看作作者给社区的作业：把它移植到你喜欢的操作系统；加入透明、上下视角、斜坡等渲染特性；加入武器、跳跃、蹲下、飞行等玩法要素；做一个基于 packet server 的互联网对战，或者更进一步做客户端／服务器结构的网络游戏；以及做 3D 加速版本。关于最后一点，Carmack 认为在现代硬件（他当时的说法是快速奔腾加 3DFX）上甚至不需要取巧，直接把整关画出来就能获得可接受的速度，稍加努力锁 60 fps 也不难，只是 DOOM 的 35 Hz 时基会带来一些问题；3D 加速最大的障碍大概是非 2 的幂纹理尺寸，以及由多张纹理拼成的墙面。

技术要点

放到今天来看，这个仓库最适合的用法是「读」而不是「玩」：它需要额外游戏数据才能运行，代码风格古老、全局状态密集，并非现代工程范本，但 BSP 渲染、子扇区组织、精灵裁剪、视线检测与扫掠碰撞这些概念在这里都能看到最原始的形态。对想理解 FPS 渲染演进、或者打算做一次源码考古式移植练手的人来说，它是一份不可替代的第一手材料。需要留意的是，代码与游戏数据资产是分离的，许可证约束的是代码，而游戏素材的使用需要另行合规判断。