De Quake-fan die de map-editor bouwde die iedereen gebruikt

Vijftien jaar en een paar volledige herschrijvingen later is die editor bekend als TrenchBroom. Als je de afgelopen tien jaar een custom Quake-map hebt gespeeld, is de kans groot dat deze in TrenchBroom is ontstaan. Mappers zweren bij de '3D-first' workflow. Indie-teams gebruikten het om moderne retro-shooters zoals Wrath en GRAVEN te bouwen. Godot-projecten maken gebruik van de tool via Qodot en andere extensies. En de Quake-scene, die inmiddels zou moeten verstoffen naast de Voodoo2 in de garage van je ouders, beleeft een van de beste periodes uit haar geschiedenis, met TrenchBroom midden in het centrum van het feest.

De clou? Duske heeft zelf nooit meer een map gemaakt. Geen enkele. Niet in TrenchBroom, en ook niet in een andere tool.

We spraken met Duske via e-mail, ergens tussen zijn fulltime baan als programmeur bij een muziekbedrijf, zijn gezin en een zorgwekkend aantal uren in Control Resonant. We praatten over de vonk die alles startte, de code die simpel had moeten blijven, de overstap van wxWidgets naar Qt, het CSG-algoritme dat niet getemd wilde worden en de kunst van het onderhouden van een project van deze schaal.

***

Wat was de vonk die ervoor zorgde dat je TrenchBroom creëerde? Was het een kleine behoefte, of had je het al een tijd gepland?

Ik ben in 2010 met TrenchBroom begonnen omdat ik weer maps wilde maken, maar ik was (en ben nog steeds) een Mac-gebruiker en kon geen level-editor vinden die ik leuk vond. Er was ToeTag van Warren Marshall, maar ik was niet supertevreden over de workflow. Bovendien had ik al ervaring met 3D-programmering en wilde ik mijn vaardigheden verbeteren. Dus begon ik TrenchBroom als een macOS-app (destijds Mac OS X genoemd), geschreven in Objective C en C. Deze versie werd in 2012 uitgebracht.

Mensen waren geïnteresseerd in de aanpak waarbij alleen 3D werd gebruikt, maar aangezien de meeste Quake-modders en mappers destijds Windows gebruikten, konden zij het niet gebruiken. Ik besloot opnieuw te beginnen, maar ditmaal met C++, wat ik ook wilde leren, en met draagbaarheid in het achterhoofd. TrenchBroom 1.0 verscheen een jaar later, aanvankelijk voor Windows en macOS. De Linux-versies volgden kort daarna. Sindien is er één grote herschrijving geweest (TrenchBroom 2.0 in 2018) en in 2020 zijn we overgestapt van wxWidgets naar Qt voor de UI-frameworks.

Ironisch genoeg heb ik daarna nooit meer een enkele map gemaakt, in TrenchBroom of anderszins...

Het is inmiddels 15 jaar geleden dat de eerste commit op GitHub werd geplaatst op 2 april 2011. Waar zou de Kristian van 2011 nu het meest van verrast zijn in TrenchBroom?

Dat het zo succesvol is en dat ik er nog steeds aan werk. Dat had ik absoluut niet verwacht toen ik begon. En misschien wel de 2D-weergaven, want oorspronkelijk wilde ik die helemaal niet toevoegen.

Zijn er ontwerpbeslissingen uit de begindagen die je zou terugdraaien?

Veel! TrenchBroom bevat veel 'over-engineered' code die ik tot op de dag van vandaag aan het opschonen ben. Ik wou dat ik de dingen destijds simpeler had gehouden en veel minder objectgeoriënteerd had geprogrammeerd. Ik heb enorme inspanningen geleverd om fouten uit het verleden ongedaan te maken.

Hoe is je relatie met het project door al die jaren geweest? Waren er momenten dat je er afstand van nam of bijna stopte? Wat bracht je terug?

Er zijn schommelingen geweest, wat je kunt zien op mijn GitHub-profiel als je door de jaren heen kijkt, maar over het geheel genomen is het relatief constant gebleven. Ik ben nooit met het project gestopt, dus ik hoefde ook nooit terug te keren. De laatste tijd ben ik meer gemotiveerd om eraan te werken omdat AI-ondersteuning me in staat stelt taken aan te pakken die ik voorheen niet alleen kon doen. Zo kon ik met behulp van AI het project reorganiseren in kleinere bibliotheken en het build-systeem verbeteren; iets wat ik al lang wilde doen, maar wat handmatig in de avonduren te lang zou hebben geduurd. Deze kwaliteitsverbeteringen maken het werken met de code veel makkelijker, waardoor ik me nu kan concentreren op de interessantere functies en bijdragen.

De Quake-mapping scene heeft de laatste jaren een echte renaissance doorgemaakt. In hoeverre denk je dat jouw technische beslissingen in TrenchBroom daar een impact op hebben gehad?

Dat is een lastige vraag, maar ik denk dat een paar factoren hebben bijgedragen:

• De 3D-centrische workflow zorgt voor directere controle en snellere iteratie. Ook geloof ik dat het overwegend gebruiken van 3D-weergaven in plaats van 2D-weergaven invloed heeft op hoe mappers over hun ontwerpen nadenken.
• Gekoppelde groepen (linked groups) maken het veel prettiger om een designtaal vast te stellen en te evolueren. Sommige ontwerpen in recente maps zijn duidelijk beïnvloed door deze functie (kijk naar symmetrie).
• TrenchBroom ondersteunt grote maps relatief goed, waardoor mappers zulke maps kunnen maken en er comfortabel in kunnen werken.
• We gebruiken het tekstuele map-formaat in plaats van een eigen bestandsformaat voor opslag, zodat maps in andere tools kunnen worden bewerkt. Dit maakt het makkelijker om andere tools te gebruiken voor taken die TB niet zo goed ondersteunt.

Ik hoop dat de som van mijn technische en UX-beslissingen mappers in staat heeft gesteld om gemakkelijk in een 'flow-toestand' te komen. Flow is leuk en lonend, waardoor mensen meer tijd besteden aan het maken van maps met TB.

Wat was de moeilijkste functie die je in TrenchBroom moest implementeren?

De moeilijkste functie die ik nooit echt goed heb gekregen, was een beter CSG-aftrekkingsalgoritme. Ik wilde dat het resultaat hetzelfde zou zijn als wanneer een mapper het handmatig zou doen, zonder onnodige extra vertices en met mooie symmetrie, enzovoort. Maar dat is een zeer lastig probleem om op te lossen. Het probleem is 'NP-volledig' (NP complete), wat in de informatica betekent dat het bewezen onbehandelbaar is voor grote input. Ik heb dit maandenlang met verschillende benaderingen geprobeerd, maar ze faalden allemaal, dus ik heb het opgegeven en gekozen voor de eenvoudige aanpak die we nu in TB hebben.

De moeilijkste functie die wél is geïmplementeerd, waren de gekoppelde groepen. Dit had invloed op bijna alles wat erin zat, en het duurde een tijd voordat de functie stabiel en performant was, vooral wat betreft de ondersteunde beschermde entity-eigenschappen. Maar ik denk dat de inspanning het waard was, want als ze goed worden gebruikt, kunnen gekoppelde groepen de hele mapping-workflow transformeren en veel efficiënter en leuker maken.

Was de overstap naar Qt de moeite waard? Denk je dat het nog steeds relevant is?

Ja, dat was het zeker. Dat werd grotendeels gedreven door Eric Wasylishen, die destijds mijn co-maintainer was. wxWidgets dwong ons tot veel platformspecifieke omwegen, terwijl Qt de meeste hiervan abstraheert, waardoor de code veel prettiger is om mee te werken.

Het prettig maken van de code is erg belangrijk voor een hobbyproject als dit. Ik wil mijn vrije tijd niet besteden aan het werken aan lelijke en moeilijk te onderhouden software, dus ik investeer veel tijd in het verbeteren van de code voor mezelf. Meningen verschillen natuurlijk; wat ik prettig vind, kan voor anderen verschrikkelijk zijn...

Hoe was het om verschillende Quake-afgeleide engines te ondersteunen? Met wat voor brush-eigenaardigheden moest je worstelen?

Daikatana heeft de meeste eigenaardigheden van allemaal, en TB ondersteunt ze nog steeds niet voor 100%. Daarbuiten was het niet zo moeilijk, hoewel we nog steeds geen volledige ondersteuning hebben voor een aantal engines. Quake 3-ondersteuning is bijvoorbeeld nog niet af, maar daar werk ik aan.

En hoe zit het met de verschillende texture projection-formaten?

Het originele Quake-formaat heeft alleen as-uitgelijnde (axis aligned) textuurprojectie, wat de texturen op schuine oppervlakken vervormt, waardoor 'texture lock' onmogelijk is. Daarom hebben we het Valve 220 map-formaat nodig. Ik denk niet dat er nog iemand het originele Quake-formaat gebruikt. Gekoppelde groepen zouden ook niet goed werken zonder exacte texture lock. Er is een derde optie die TrenchBroom nog niet ondersteunt: Brush primitives uit Q3Radiant. Voor zover ik weet bieden brush primitives niets extra's bovenop Valve 220 maps, dus het heeft voor mij geen hoge prioriteit om die ondersteuning toe te voegen.

Hoe ben je in de gaming terechtgekomen? En wat zorgde ervoor dat je de stap zette van het spelen van games naar het willen leren hoe ze werken?

Ik begon in de jaren 80 games te spelen op onze thuiscomputer. Ik speelde point-and-click adventures en vroege vluchtsimulators zoals Secret Weapons of the Luftwaffe of X-Wing van Lucasarts. Op een dag kreeg mijn broer Wolfenstein 3D in handen en vanaf dat moment was ik verslaafd aan FPS-games. Ik speelde Doom, bestelde per post een Doom-level editor en werd verliefd op mapping. Daarna kwamen Quake en Quake 2 en online deathmatch. Ik downloadde en speelde veel custom deathmatch maps voor Quake en Quake 2 en bracht er zelf een paar uit met WorldCraft en de originele QERadiant. Ik werd onderdeel van die scene en maakte levenslange vrienden. Het voelde als een natuurlijke overgang van speler naar maker van eigen content. Ik was vrij jong, misschien rond de 20; het internet was nog nieuw en de mogelijkheden waren eindeloos.

Ik begon toen ook met mijn eerste Quake-gerelateerde programmeerprojecten, beginnend met een converter-tool waarmee ik QERadiant (een Quake 2 editor) kon gebruiken voor Quake 1 maps. Later portte ik de FitzQuake-engine naar SDL, zodat ik Quake op mijn Mac kon spelen. Maar ik was eigenlijk al eerder begonnen met programmeren, rond mijn 16e. Ik was destijds erg into elektronische muziek en kocht synthesizers en samplers om techno te maken, maar omdat ik al mijn geld aan hardware uitgaf, kon ik de software niet betalen. Naïef besloot ik mijn eigen sequencer en MIDI-utilities te schrijven. Ik had op school een basiscursus programmeren gevolgd en leerde de rest uit boeken en offline handleidingen. Later heb ik informatica gestudeerd en nu werk ik als programmeur voor een muziekbedrijf; ik ben dus op een bepaalde manier geëindigd waar ik begon, alleen met iets meer begrip van wat ik doe.

Tegenwoordig speel ik games vooral op mijn Playstation 5. Ik hou van The Last of Us, Death Stranding en Control. Momenteel speel ik Control Resonant, wat de reden is dat de voortgang van TrenchBroom een beetje is gestagneerd. Ik speel nog steeds Quake, maar ik speel niet elke uitgebrachte map zoals ik vroeger deed.

Hoe behoud je de visie? Hoe blijf je gemotiveerd?

Ik heb geen superduidelijke visie, alleen een paar leidende principes. Deze zijn in de loop der jaren zo ingebakken geraakt in mijn denken dat het in essentie tweede natuur is; wat overkomt als een visie, vloeit waarschijnlijk gewoon voort uit deze beslissingen. Ik probeer de UX en workflow van TB simpel te houden. Soms offer ik controle op voor gebruiksgemak. Ik probeer niet te veel opties of voorkeuren te introduceren. Gebruikers niet overweldigen. Ze niet verrassen.

Natuurlijk lukt dat niet altijd. De gebruikersgroep van TB is de laatste jaren enorm gegroeid, en ik maak niet zoveel deel uit van de andere gemeenschappen die TB gebruiken als ik deel uitmaak van de Quake-community. Daarom begrijp ik hun behoeften en eisen minder goed. Voor mij is TrenchBroom in de eerste plaats een Quake-level editor, en dat beïnvloedt mijn beslissingen en prioriteiten bij het werken aan functies. Soms botsen deze prioriteiten met de wensen van andere gemeenschappen. Maar TrenchBroom is open source, dus mensen kunnen het forken en met AI-tools aanpassen aan hun eigen workflows.

Wat me motiveert, is zien wat de Quake-community creëert met TrenchBroom en hoe de tool mensen in staat stelt creatief te zijn. Dat maakt me echt gelukkig. Je hebt niet veel nodig om Quake-levels te maken. Je hebt geen superkrachtige computer of extra hardware nodig; bijna elke laptop volstaat. De tools zijn beschikbaar voor elk groot platform. Quake-mapping is dus bij ontwerp democratisch en inclusief, hoewel niet alle gemeenschappen altijd voor iedereen verwelkomend zijn geweest. Dat TrenchBroom ook door indie-ontwikkelaars is gebruikt voor retro-shooters zoals Wrath, maakt me eveneens trots.

Is het moeilijk om 'nee' te zeggen tegen contributors?

In het begin was het moeilijker om nee te zeggen, omdat er veel minder interesse was, laat staan bijdragen. Voor mij maakt het een groot verschil of een functieverzoek veel mensen ten goede komt, of dat het alleen een luidruchtige minderheid is; in dat laatste geval zal ik tegenwoordig meestal weigeren. Ik probeer hoffelijk te zijn, maar ik weet dat dat niet altijd lukt. Ik beantwoord issue-rapporten en pull-requests tijdens werkpauzes of 's avonds voor het eten, en soms zijn mijn antwoorden kort. Sommige zaken zijn jaren geleden tot in den dood besproken; wanneer zo'n onderwerp opnieuw opkomt, zeg ik simpelweg: "Ik wil dit niet opnieuw bespreken". Dat komt aan de ontvangende kant misschien niet erg hoffelijk over, maar ik ben slechts één man met een gezin en een fulltime baan. Ik heb simpelweg geen tijd om lange teksten te schrijven, anders zou ik helemaal geen functies meer kunnen implementeren.