人人都在用的地图编辑器，是一个 Quake 迷自己写的

2010 年，一位名叫 Kristian Duske 的 Mac 用户想重新拾起 Quake 地图制作。问题在于市面上没有一款 Duske 真正喜欢的编辑器。Warren Marshall 的 ToeTag 就在那里，但工作流就是不对味。有些 3D 编程经验的 Duske 于是做了唯一合理的事，从零写一个。

十五年过去，中间经历了几次彻底重写，这个编辑器就是 TrenchBroom。如果你在过去十年里玩过自定义 Quake 地图，那它很可能就是在 TrenchBroom 里诞生的。地图作者们对它的 3D 优先工作流赞不绝口。独立团队用它来做《Wrath》《GRAVEN》这类现代复古射击游戏。Godot 项目通过 Qodot 等扩展也在用它。而 Quake 社区本该和你父母车库里的 Voodoo2 一起积灰，眼下却正经历着历史上最好的一段时期，TrenchBroom 就坐在派对正中央。

有意思的是，Duske 此后再没做过一张地图。一张都没有。不是在 TrenchBroom 里，也不是在别的什么工具里。

我们通过邮件联系上了 Duske，当时他正夹在一份音乐公司的全职编程工作、一个家庭，以及在《Control Resonant》里令人担忧的游玩时长之间。我们聊了最初的火花、本该保持简单的代码、从 wxWidgets 迁移到 Qt、那个怎么都驯服不了的 CSG 算法，以及维护这种规模项目的门道。拿起你的火箭筒，开始吧。

最初是什么火花让你做出 TrenchBroom？是一时兴起，还是筹划已久？

我在 2010 年启动 TrenchBroom，因为我想重新做地图，但我是（现在仍然是）Mac 用户，找不到喜欢的关卡编辑器。Warren Marshall 的 ToeTag 是有的，但我对它的工作流不太满意。另外，我已经有 3D 编程经验，也想提升自己的技能。所以我开始把 TrenchBroom 做成一个 macOS（当时还叫 Mac OS X）应用，只用 Objective C 和 C 写。这个版本于 2012 年发布。

不少人对纯 3D 的方案感兴趣，但当时大多数 Quake mod 作者和地图制作者都在用 Windows，用不了这个方案。我决定推倒重来，这次改用 C++（我本来也想学这门语言），并且把可移植性考虑进去。一年后 TrenchBroom 1.0 发布，最初支持 Windows 和 macOS：TrenchBroom 1.0 release。Linux 版本稍晚一些才推出。此后经历过一次大规模重写（2018 年的 TrenchBroom 2.0），2020 年我们又把手头的 UI 框架从 wxWidgets 换成了 Qt。

讽刺的是，我再也没做过一张地图，用 TrenchBroom 也好，用别的工具也好。

一个名为 Neuron Uplink 的 Quake 2 地图正在 TrenchBroom 中编辑，可见实体标签和材质浏览器 — Em3raldTig3r 的 Neuron Uplink 正在用 TrenchBroom 进行编辑

2011 年 4 月 2 日，GitHub 上的第一个 commit，距今已经 15 年。今天的 TrenchBroom 里，哪一点最让 2011 年的你吃惊？

是它这么成功，而且我还在做它。刚开始的时候我完全没料到会这样。也许还有 2D 视图，因为我原本根本不想加这些。

早期有没有哪个设计决定是你现在想收回的？

太多了！TrenchBroom 里有很多过度设计的代码，我到现在还在清理。我希望当年能把东西做得更简单，少用很多面向对象。为了撤销过去的错误，我花了巨大的精力。

这么多年下来，你和这个项目的关系是怎样的？有没有哪段时间你离开过，或者差点放弃？是什么让你回来的？

有过起伏，如果你按年份翻我的 github profile 就能看出来，但总体上是比较平稳的。我从没退出过这个项目，所以也谈不上回来。最近我更有动力做它，因为 AI 辅助让我能接下以前一个人接不下的任务。比如我用 AI 把项目重新拆成了更小的库，还改进了构建系统。这些事我想做很久了，但靠晚上手动做要花太长时间。这些改善使用体验的改动让写代码轻松了很多，现在我可以把精力放在更有意思的功能和贡献上。

Quake 地图创作圈近几年确实复兴了。你觉得你在 TrenchBroom 里做的技术决定起了多大作用？

这个问题不好回答，但我认为可能有几个因素起了作用：

以 3D 为中心的工作流能更直接地控制，迭代也更快。我还认为，主要用 3D 视图而不是 2D 视图，会影响制图者对自己设计的思考方式。
链接组（linked groups）让建立和演进一套设计语言舒服得多。最近一些地图里的设计明显受到了这个功能的影响（留意对称性）。
TrenchBroom 对大地图的支持相对不错，所以制图者可以做出这样的地图，并且用起来很舒服。
我们存储时用的是文本地图格式，而不是自定义格式，所以地图可以在其他工具里编辑。这样，对于 TB 支持得不太好的任务，用别的工具会更容易。

我希望我做出的那些技术决策（以及 UX 决策）加在一起，能让制图者轻松进入心流状态。心流状态既有趣又有成就感，因此人们会花更多时间用 TB 制作地图。

一个名为 Remnant of a Powerful Sphere 的 Quake 地图在 TrenchBroom 的 3D 视图中打开，显示网格线和高亮笔刷 — Nicco 的 Remnant of a Powerful Sphere，用 TrenchBroom 编辑

你在 TrenchBroom 中实现过的最难的功能是什么？

我一直没能做好的最难功能，是一个更好的 CSG 减法算法。我希望它的输出和 mapper 手动做出来的一样：不添加多余的顶点，保留漂亮的对称性，等等。但这个问题非常难解，属于 NP complete，这是一个计算机术语，意思是“已被证明在输入规模较大时无法求解”。我试了好几个月，换了很多种思路，全都失败了，最后放弃，改用了 TB 现在这个简单做法。

真正进了 TB 的最难功能是 linked groups。它几乎牵动了其他所有部分，花了很长时间才做到稳定、性能也够用，尤其是还要支持受保护的实体属性。不过我认为这番功夫很值：用得好的话，linked groups 能彻底改变整个 mapping 工作流，效率高得多，也好玩得多。

换到 Qt 值得吗？你觉得它现在还有意义吗？

值得。这件事基本上是 Eric Wasylishen 推动的，他当时是我的共同维护者。wxWidgets 逼着我们写了很多针对各个平台的绕行方案，Qt 把其中大部分都抽象掉了，代码用起来舒服多了。

对这样一个业余项目来说，让代码用起来舒服相当重要。我实在不想把业余时间花在又丑又难维护的软件上，所以会投入大量时间，让代码对我自己来说好用。当然，各人看法不同，我觉得难用的东西，在别人眼里可能糟透了。

TrenchBroom 的 3D 视图显示带有物品和触发器实体标记的 Quake 地图，以及面检查器面板 — TrenchBroom 中的实体编辑

同时支持多个 Quake 系引擎是什么体验？要对付哪些 brush 的怪毛病？

Daikatana 的怪毛病最多，TB 至今也没能 100% 支持它。除此之外倒不算太难，不过我们仍有一批引擎没有完整支持。比如 Quake 3 的支持还没做完，我正在弄。

不同的纹理投影格式呢？

最初的 Quake 格式只有轴对齐的纹理投影，纹理在斜面上会变形，纹理锁定根本无从谈起。所以我们才需要 Valve 220 地图格式。我觉得现在已经没人还在用原始 Quake 格式了。没有精确的纹理锁定，链接组也用不顺畅。还有第三种方案 TrenchBroom 尚未支持：Q3Radiant 的 brush primitive。据我所知，brush primitive 相比 Valve 220 地图并没有多出什么功能，所以支持它的优先级对我来说不算高。

你是怎么开始玩游戏的？又是什么让你跨过了玩和想深入了解之间的那条线？

80 年代我就在家里的电脑上玩游戏了。玩的是点击式冒险游戏，还有早期的飞行模拟，比如 Secret Weapons of the Luftwaffe，或者 Lucasarts 的 X-Wing。有一天我哥弄到了 Wolfenstein 3D，从那以后我就迷上了 FPS。我玩 Doom，邮购了一个 Doom 关卡编辑器，然后爱上了做地图。接着是 Quake 和 Quake 2，还有在线死亡竞赛。我下载并玩了大量 Quake 和 Quake 2 的自制死亡竞赛地图，自己也用 WorldCraft 和原版 QERadiant 发布过几张。我成了那个圈子的一分子，交到了几个一辈子的朋友。从玩家到自己做内容，感觉是很自然的过渡。那时我挺年轻，大概 20 岁上下，互联网还很新，可能性无穷无尽。

也是在那时，我开始了自己最早的 Quake 相关编程项目，第一个是个转换工具，让我能用 Quake 2 的编辑器 QERadiant 来做 Quake 1 地图。后来我把 FitzQuake 引擎移植到 SDL，好在自己的 Mac 上玩 Quake。但我最早开始编程还要更早，大概 16 岁左右。那时我特别迷电子音乐，买了几台合成器和采样器想做 Techno，可钱全花在硬件上了，软件买不起。出于天真，我决定自己写音序器和 MIDI 工具。我在学校上过一点编程基础课，其余都是从书和离线手册里学的。后来我学了计算机科学，现在在一家音乐公司做程序员，兜兜转转又回到了起点，只是对自己在干什么稍微多懂了一点。

现在我的游戏基本都在 PlayStation 5 上玩。我喜欢 The Last of Us、Death Stranding 和 Control。眼下在玩 Control Resonant，所以 TrenchBroom 的开发进度有点滑坡。Quake 我还在玩，但不像以前那样每张新图都打了。

你怎么守住自己的构想？怎么保持动力？

我没有什么特别清晰的构想，只有几条指导原则。这些年下来，它们已经深深刻进我的思路里，基本成了本能，所谓构想，也许不过是这些决定自然长出来的东西。我尽量让 TB 的交互和工作流保持简单。牺牲一部分控制力，换取易用性。不引入太多选项和偏好设置。不让用户不知所措，也不让他们意外。

当然，我并不总能做到。近几年 TB 的用户群扩大了很多，而我对其他用 TB 的社区远不如对 Quake 社区那么熟悉，所以对他们的需求了解得也没那么透。对我来说，TrenchBroom 首先仍然是 Quake 关卡编辑器，这决定了我在做功能时的取舍和优先级，但有时这些取舍会和其他社区的要求与期望相冲突。不过 TrenchBroom 是开源的，人们可以 fork，再借助 AI 工具把它改造成适合自己工作流的样子。

我的动力来自看到 Quake 社区用 TrenchBroom 做出来的东西，来自看到 TrenchBroom 如何让人发挥创造力。这真的让我很开心。做 Quake 关卡不需要太多东西。不需要性能强悍的电脑，也不需要额外的硬件，几乎任何一台笔记本都够用。工具覆盖所有主流平台。所以 Quake 地图制作在设计上多少是民主而包容的，尽管并非所有社区一直以来都对所有人那么友好。也有独立开发团队用 TrenchBroom 做复古射击游戏，比如 Wrath，这同样让我感到自豪。

拒绝贡献者很难吗？

最初拒绝别人更难，因为那时关注度低得多，更不用说贡献了。对我来说，一个功能请求是会让很多人受益，还是只惠及少数声音大的人，差别很大。如今遇到后者，我通常会直接拒绝。我尽量保持得体，但也知道自己并非总能做到。我会在工作间隙或晚饭前的晚上回复 issue 和 pull request，有时回复会比较简短。有些事几年前就已经讨论透了，再被提起时，我只会说“这个我不想再讨论了”。在对方看来这大概不太得体，但我只是一个人，有家庭，有全职工作。我根本没有时间写长篇大论，否则功能开发就一点都做不成了。