TrenchBroom: 15 Years of the Quake Map Editor Everyone Uses

8 min read

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The interview

• The Quake Fan who built the map editor everybody uses, func_arena, Oct 20 2026

On October 20, 2026, the retro shooter site func_arena published an email interview with Kristian Duske, the developer behind TrenchBroom. If you have played a custom Quake map in the last ten years, there is a good chance it was built in TrenchBroom. Indie teams used it to make Wrath and GRAVEN, and Godot projects plug it in through Qodot and other extensions.

The detail everyone is quoting is the punchline func_arena opened with. Duske started TrenchBroom in 2010 because he wanted to make Quake maps again on his Mac. Fifteen years, a couple of full rewrites and one UI framework swap later, he has never made a single map. Not in TrenchBroom, not in anything else.

Key takeaways

• TrenchBroom started in 2010 as a Mac-only app in Objective C and C. The first GitHub commit is dated April 2, 2011.
• It has been rebuilt more than once: a C++ rewrite for 1.0, a major rewrite for 2.0 in 2018, and a move from wxWidgets to Qt in 2020.
• Duske's biggest regret is over-engineering. He says he wishes he had used much less object orientation, and he is still cleaning it up.
• He spent months on a better CSG subtraction algorithm, hit an NP complete problem, and shipped the simple version instead.
• AI tools let him finally split the project into smaller libraries and fix the build system, work he says would have taken too long in his evenings.
• He maintains all of this as one person with a family and a full time job at a music company.

What is TrenchBroom and how did it get here?

TrenchBroom is an open source level editor for Quake and Quake-derived engines. Mappers swear by its 3D first workflow, where most of the building happens in 3D views rather than 2D ones.

Here is the timeline as Duske told it.

When	What happened
2010	Duske starts TrenchBroom as a Mac OS X app, in Objective C and C only
April 2, 2011	First commit on GitHub
2012	The Mac-only version is released
About a year later	TrenchBroom 1.0, rewritten in C++ for portability, ships for Windows and macOS. Linux builds follow
2018	TrenchBroom 2.0, a major rewrite
2020	The UI moves from wxWidgets to Qt, driven mostly by co-maintainer Eric Wasylishen
Lately	Duske uses AI to reorganize the project into smaller libraries and improve the build system

The first rewrite happened for a plain reason. People liked the 3D only approach, but most Quake modders and mappers were on Windows, so they could not use a Mac app. He started over in C++, a language he also wanted to learn, with portability in mind from day one.

He did not plan any of this. Asked what the 2011 version of himself would find most surprising, he said: "That it's so successful and that I'm still working on it." He also never wanted 2D views at all. TrenchBroom has them now.

Why should a developer care about a Quake map editor?

Because this is a 15 year case file on one long-lived codebase, kept alive by one person in their spare time. Most of us will work on something like that. Very few of us will get an honest look back at it from the person who wrote it.

Three parts of the interview apply to almost any project.

He regrets the abstractions, not the features. When asked which early decision he would take back, Duske said "Lots!" and then got specific: "TrenchBroom has a lot of over engineered code that I'm still cleaning up to this day. I wish I had kept things simpler back then and used much less object orientation. I have spent enormous efforts in undoing past mistakes."

Read that as a cost estimate. The extra layers he added early are still being paid for, fifteen years on.

He picks code that is nice to work with, on purpose. On the Qt switch, he said wxWidgets forced the team into many platform specific workarounds, while Qt abstracts most of them away. His reasoning goes beyond the technical: "I really don't want to spend my free time working on ugly and hard to maintain software." For a hobby project, a pleasant codebase is what keeps the maintainer showing up.

He uses a plain, shared file format. TrenchBroom stores maps in the textual map format instead of a custom one. That means maps can be edited in other tools, so mappers can reach for something else when TrenchBroom does not handle a task well. He lists this as one of the reasons behind the recent Quake mapping revival, next to the 3D centric workflow, linked groups and solid support for large maps.

What changes in practice when one person maintains a tool this big?

This is where the interview gets useful, because Duske is direct about the tradeoffs.

When do you stop chasing the perfect algorithm?

The hardest feature he never got right was a nicer CSG subtraction. He wanted the output to match what a human mapper would build: no unnecessary extra vertices, clean symmetry. The problem turned out to be NP complete, which he explains as "proven to be untractable for large inputs".

"I tried this for months with many approaches, but they all failed, so I gave up and did the simple approach that we have now in TB."

That is a decision a lot of developers avoid making. He made it, shipped the simple version, and TrenchBroom is still the editor everybody uses.

Which hard features are worth the pain?

The hardest feature that did ship was linked groups. Duske says it "affected almost everything else" and took a long time to become stable and fast, especially with protected entity properties. His verdict: the effort paid off, because linked groups can change the whole mapping workflow. He says you can see their influence in recent maps if you look for symmetry.

So the line he drew was not "hard means no". The CSG work could not produce the result he wanted. Linked groups could, it just took time.

How is AI changing a 15 year old open source project?

This is the part I find most practical. Duske says he has been more motivated lately "because AI support allows me to take on tasks that I couldn't take on alone before."

His example is not a flashy feature. It is the boring structural work: reorganizing the project into smaller libraries and improving the build system. He had wanted to do it for a long time, but doing it by hand in the evenings would have taken too long. With that out of the way, he says he can focus on the more interesting features and contributions.

He also points at the other side of it. TrenchBroom is a Quake editor first, and sometimes his priorities clash with what other communities using it want. His answer: it is open source, so people can fork it, "and with AI tools, they can adapt it to their workflows."

How does one maintainer say no to contributors?

Early on, saying no was harder because there was barely any interest, let alone contributions. Now his rule is simple. If a request helps a lot of people, it has a chance. If it only helps a vocal minority, he will usually deny it.

He answers issues and pull requests during work breaks or before dinner, and some answers are short. For topics that were "discussed to death years ago", he will just say "I don't want to discuss this again". He knows how that reads on the receiving end. His explanation: "I'm just one guy with a family and full time job. I simply don't have the time to write a lot of prose, or I wouldn't get any feature work done at all."

His design principles are just as short. Keep the UX and workflow simple. Sacrifice some control for ease of use. Do not add too many options or preferences. Do not overwhelm users. Do not surprise them.

What engine and format support does TrenchBroom have today?

A few concrete points from the interview, useful if you are picking an editor for a retro project:

• Valve 220 is the format to use. The original Quake format only has axis aligned texture projection, which distorts textures on slanted surfaces and makes texture lock impossible. Duske does not think anybody still uses the original format. Linked groups also depend on exact texture lock.
• Brush primitives from Q3Radiant are not supported. He says they do not offer anything beyond Valve 220 that he is aware of, so they are low priority.
• Quake 3 support is not finished. He says he is working on it.
• Daikatana has the most quirks, and TrenchBroom still does not handle all of them.

Who is Kristian Duske?

He was in the Quake scene long before TrenchBroom existed. He played Wolfenstein 3D and Doom, mail ordered a Doom level editor, and released a few Quake and Quake 2 deathmatch maps using WorldCraft and the original QERadiant.

His first Quake programming projects were tools for himself: a converter that let him use QERadiant, a Quake 2 editor, for Quake 1 maps, and a port of the FitzQuake engine to SDL so he could play Quake on his Mac.

He started programming at around 16 because he spent all his money on synthesizers and samplers and could not afford the software, so he wrote his own sequencer and MIDI utilities. Today he works as a programmer at a music company. In his words, he "somehow ended up where I started".

What should you do this week?

You do not need to care about Quake to take something from this.

• Delete one abstraction you added "for later". Duske's biggest regret is over-engineered code. Find one interface or base class with a single real implementation and flatten it.
• Set a time box on your hardest problem. He gave CSG subtraction months, then shipped the simple version. Decide now how long your version of that problem gets.
• Hand your structural chores to AI first. He used it to split a codebase into libraries and fix a build system, not to write features. Pick the refactor you keep postponing and try it there.
• Store data in a plain, documented format. If users can edit your files in other tools, they can work around the things your tool does not do well.
• Write your "no" rule down. His is "helps a lot of people, or helps a vocal minority". A rule like that saves you from re-arguing every request.
• If you make games, try it. Duske's point is that you do not need much to make Quake levels. Almost any laptop will do, and the tools are available for every major platform.

FAQ

What is TrenchBroom?

TrenchBroom is an open source level editor for Quake and Quake-derived engines, built around a 3D first workflow. Kristian Duske started it in 2010, and indie teams have used it to build retro shooters like Wrath and GRAVEN. Godot projects use it through Qodot and other extensions.

Did the creator of TrenchBroom ever make a map with it?

No. Duske started the project because he wanted to make Quake maps again, but he told func_arena he never made a single map afterwards, in TrenchBroom or anything else. He did release a few Quake and Quake 2 deathmatch maps years earlier using WorldCraft and QERadiant.

Why did TrenchBroom switch from wxWidgets to Qt?

The move happened in 2020 and was almost fully driven by co-maintainer Eric Wasylishen. Duske says wxWidgets forced the team into many platform specific workarounds, while Qt abstracts most of them away. He says the switch was worth it because the code became much nicer to work with.

Does TrenchBroom support Quake 3?

Not fully yet. Duske says Quake 3 support is still unfinished and that he is working on it. TrenchBroom also does not support Q3Radiant brush primitives, which he considers low priority because they offer nothing beyond the Valve 220 format that he knows of.

Pick the one abstraction you would take back and remove it this week, then browse the free tools on Art of Code for the small jobs around it. If you want another story about one developer building for years before it paid off, read how Postiz went from $17K to $191K MRR.

Written by Adithya Guttha, Founder of Art of Code.