みんなが使うマップエディタを作った Quake ファン

2010 年、Kristian Duske という Mac ユーザーが Quake のマップ制作を再開しようとしていた。困ったことに、Duske が心から気に入るエディタはどこにもなかった。Warren Marshall の ToeTag はあったものの、ワークフローがどうにも肌に合わない。3D プログラミングの経験が多少あった Duske は、当然のことながら一から自分で書くことにした。

15 年が過ぎ、その間に何度か全面的な書き直しを経て、このエディタが TrenchBroom だ。この 10 年の間にカスタム 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++（これも学びたかった言語だ）に切り替え、移植性を考慮に入れた。1 年後に TrenchBroom 1.0 がリリースされ、当初は Windows と macOS をサポートした。TrenchBroom 1.0 release。Linux 版はもう少し後になってからだ。その後、大規模な書き直しを一度経て（2018 年の TrenchBroom 2.0）、2020 年には UI フレームワークを wxWidgets から Qt に切り替えた。

皮肉なことに、私はあれ以来マップを一枚も作っていない。TrenchBroom でも、他のツールでも。

2011 年 4 月 2 日、GitHub に最初の commit が上がってから 15 年。今の TrenchBroom を見て、2011 年当時のあなたが最も驚くとしたら何だろうか。

これだけ成功したこと、そして今も自分が開発を続けていることだ。始めた頃はまったく予想していなかった。あとは 2D ビューだろうか。もともとあれを入れるつもりは全くなかったので。

初期の設計判断で、今なら撤回したいものはあるか。

山ほどある。TrenchBroom には過剰設計なコードがたくさん残っていて、今も片付け続けている。もっとシンプルに、オブジェクト指向をずっと控えめにして作ればよかった。過去の過ちを取り消すために、ものすごく手間をかけている。

長年やってきて、このプロジェクトとの関係はどう変わってきたのか。離れた時期や、諦めかけたことはあったか。戻ってきた理由は何か。

浮き沈みはあった。年ごとにgithub profileを追えば分かると思うが、全体としては安定している。プロジェクトから離れたことは一度もないので、戻ってきたとも言えない。最近はやる気が増している。AI 支援のおかげで、以前なら一人では引き受けられなかった作業に手を出せるようになったからだ。たとえば AI を使ってプロジェクトをより小さなライブラリに分割し直したり、ビルドシステムを改善したりした。ずっとやりたかったことだが、夜の手作業だけでやるには時間がかかりすぎる。こうした使い勝手の改善でコーディングはずいぶん楽になり、今はもっと面白い機能やコントリビュートに力を注げる。

Quake のマップ制作コミュニティはここ数年で確かに盛り返している。TrenchBroom でのあなたの技術的な判断は、どの程度寄与したと思うか。

答えるのが難しい質問だが、いくつかの要因が効いていると思う。

• 3D 中心のワークフローは直接的な操作ができ、イテレーションも速い。また、2D ビューではなく主に 3D ビューを使うことが、マッパーが自分の設計をどう考えるかに影響するとも思う。
• リンクグループ（linked groups）のおかげで、デザイン言語を組み立てて育てるのがずっと楽になった。最近のマップには、この機能の影響が明らかに見て取れる（対称性に注目）。
• TrenchBroom は大きなマップの扱いが比較的得意なので、マッパーはそうしたマップを作れて、しかも快適に作業できる。
• 保存に独自形式ではなくテキストのマップ形式を使っているので、マップを他のツールでも編集できる。TB がそれほど得意でない作業は、別のツールでやる方が楽だということだ。

私が下した技術的な判断（そして UX の判断）が合わさって、マッパーがフロー状態に入りやすくなっていればいいと思う。フロー状態は楽しく達成感もあるので、人はより長い時間 TB でマップを作るようになる。

TrenchBroom で実装するのが最も難しかった機能は何か。

最も難しく、どうしてもうまく実装できなかったのが、優れた CSG 減算アルゴリズムだ。マッパーが手作業で作ったのと同じ出力になることを目指していた。余計な頂点を追加せず、美しい対称性を保つ、といった具合だ。しかしこの問題は非常に難しく、NP complete に属する。これは「入力規模が大きくなると解けないことが証明されている」という意味の計算機用語だ。数か月かけて多くのアプローチを試したが、すべて失敗し、最終的に諦めて TB の現在のシンプルな方式に切り替えた。

実際に TB に入った最も難しい機能は linked groups だ。これはほぼ他のすべての部分に影響を及ぼし、安定して十分な性能を出すまでに長い時間がかかった。特に保護されたエンティティ属性への対応が大変だった。ただ、この苦労は十分に価値があったと思う。うまく使えば、linked groups はマッピングのワークフロー全体を一変させ、はるかに効率的で、はるかに楽しいものになる。

Qt への移行は価値があったか。今でも意味があると思うか。

価値はあった。これは主に当時の共同メンテナーだった Eric Wasylishen が推進したものだ。wxWidgets では各プラットフォーム向けの回避策を大量に書かざるを得なかったが、Qt はその大部分を抽象化してくれ、コードはずっと扱いやすくなった。

こうした趣味のプロジェクトでは、コードが扱いやすいことはかなり重要だ。自由時間を醜くて保守しにくいソフトウェアに費やしたくはないので、自分にとって使いやすいコードにするために多くの時間を投入する。もちろん感じ方は人それぞれで、私が使いにくいと思うものが、他人には最悪に見えるかもしれない。

複数の 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 のマップを作れるようにするものだった。その後、自分の Mac で Quake を遊ぶために FitzQuake エンジンを SDL に移植した。ただ、プログラミング自体はもっと早く、16 歳くらいに始めている。当時は電子音楽に夢中で、テクノを作ろうとシンセサイザーとサンプラーを何台か買ったのだが、お金はすべてハードウェアに消え、ソフトウェアまでは手が回らなかった。若気の至りで、自分でシーケンサーや MIDI ツールを書くことにした。学校でプログラミングの基礎科目を少し履修した以外は、本とオフラインマニュアルで学んだ。その後コンピュータサイエンスを専攻し、今は音楽会社でプログラマをしている。一周回って元の場所に戻ったわけだが、自分が何をしているかは少しだけ分かっている。

今はゲームのほとんどを PlayStation 5 で遊んでいる。好きなのは The Last of Us、Death Stranding、Control。現在は Control Resonant を遊んでいるので、TrenchBroom の開発は少し遅れ気味だ。Quake もまだ遊んでいるが、以前のように新しいマップが出るたびに全部プレイするというわけではない。

ビジョンはどうやって守っているのか。モチベーションはどう保っているのか。

はっきりしたビジョンがあるわけではなく、指針がいくつかあるだけだ。長年かけてそれが考え方に深く染み込み、ほとんど本能になっている。ビジョンと呼んでいるものも、そうした判断が自然に形になったものにすぎないのかもしれない。TB の操作とワークフローはできるだけシンプルに保つ。制御性の一部を犠牲にして、使いやすさを取る。オプションや環境設定を増やしすぎない。ユーザーを圧倒しない。驚かせない。

もちろん、いつもできているわけではない。ここ数年で TB のユーザー層は大きく広がったが、Quake コミュニティに比べて他のコミュニティのことはよく分かっていないので、彼らの要望もそれほど深くは理解できていない。私にとって TrenchBroom は今もまず Quake のレベルエディタであり、それが機能を作るときの取捨選択と優先順位を決めている。ただ、その取捨選択が他のコミュニティの要求や期待とぶつかることもある。とはいえ TrenchBroom はオープンソースなので、fork して AI ツールを使えば、自分のワークフローに合うように作り変えられる。

モチベーションの源は、Quake コミュニティが TrenchBroom で作ったものを見ること、TrenchBroom が人の創造性を引き出しているのを見ることだ。それが本当にうれしい。Quake のレベル作りに必要なものはほとんどない。高性能な PC も追加のハードウェアも要らず、ノート PC がほぼ一台あれば足りる。ツールは主要なプラットフォームをすべてカバーしている。だから Quake のマップ制作は設計上いくぶん民主的で開かれている。もっとも、すべてのコミュニティがこれまでずっと誰に対しても友好的だったわけではないが。Wrath のように、インディーの開発チームが TrenchBroom でレトロシューターを作っている例もあり、これも誇りに思っている。

貢献を断るのはつらいか。

最初の頃は断るのがもっとつらかった。当時は注目度も貢献もずっと少なかったからだ。私にとって、その機能リクエストが多くの人の役に立つのか、声の大きい少数の人だけのものなのかは大きな違いがある。今は後者ならたいていはっきり断る。失礼にならないように心がけてはいるが、いつもできているわけではないことは分かっている。issue や pull request への返信は仕事の合間か夕食前の夜にやるので、短くなることもある。何年も前に議論し尽くした話がまた出てきたときは、「これ以上は議論したくない」とだけ返す。相手からすれば失礼に見えるだろうが、私は一人しかいないし、家族もフルタイムの仕事もある。長文を書いている時間などまったくなく、そうしていたら機能開発が一切進まない。