요약
Quake 맵 에디터 TrenchBroom을 만든 크리스티안 두스케가 개발 과정과 성공 비결을 밝혔습니다.
고전 FPS 커뮤니티 사이트 func_arena가 이메일로 진행한 인터뷰입니다. 2010년 다시 Quake 맵을 만들고 싶었던 맥 사용자 두스케는 기존 에디터 ToeTag의 작업 방식이 마음에 들지 않아 직접 에디터를 만들기 시작했습니다.
왜 중요한가
- 한 사람이 취미로 시작한 오픈소스 도구가 요즘 Quake 맵 상당수를 만드는 도구로 자리 잡은 과정을 보여 줍니다.
- Wrath, GRAVEN 같은 레트로 슈터와 Godot 프로젝트도 이 에디터를 써서, 쓰임새가 Quake 밖으로 넓어졌습니다.
- 저녁 시간에 혼자 유지하던 개발자가 AI 도구 덕분에 미뤄 둔 구조 정리를 해냈다는 사례이기도 합니다.
핵심 내용
- 성공 요인으로 3D 중심 작업 방식, 연결 그룹(복제한 구조물을 한꺼번에 고치는 기능), 큰 맵 지원, 텍스트 맵 형식을 꼽았습니다.
- 통제권을 조금 내주더라도 쓰기 쉽게 하고, 옵션을 늘리지 않는 것을 설계 원칙으로 삼고 있습니다.
- 2012년 Objective-C 맥 앱으로 시작해 C++ 재작성, 2018년 2.0, 2020년 Qt 전환을 거쳤습니다.
- 연결 그룹은 코드 거의 모든 부분에 영향을 줘서 안정적이고 빠르게 만들기가 가장 어려웠다고 했습니다.
- CSG 빼기(입체에서 다른 입체를 깎아 내는 연산) 개선은 NP-완전 문제여서 몇 달 매달리다 포기했다고 밝혔습니다.
HN 반응
- 여러 이용자가 Hammer나 q3radiant보다 훨씬 쾌적하다고 칭찬했고, func_godot로 Godot 게임의 레벨 에디터로 쓴다는 경험담도 이어졌습니다.
- 브러시(볼록한 입체 조각)를 쌓기보다 Unreal Editor처럼 공간을 깎는 방식이 실내 맵에 낫다는 반론에, 두 방식이 기술적으로 거의 같다는 설명이 붙었습니다.
Trenchbroom은 제가 써 본 소프트웨어 중에서 정말로 손꼽히게 훌륭합니다. 저는 Hammer를 쓰면서 자랐는데, 이건 Hammer를 완전히 압도합니다.
좋은 점 하나는 Godot에서 func_godot을 쓰면 내 게임의 레벨 에디터로도 쓸 수 있다는 겁니다.
동의합니다! 저는 13kb짜리 퀘이크 데메이크[1]의 맵을 만들 때 이걸 썼습니다. 예전에 쓰던 q3radiant와 비교하면 Trenchbroom은 작업하기가 훨씬 쾌적합니다. 돌이켜 보면 맵 에디터는 이렇게 동작해야 한다는 게 너무나 당연해 보입니다.
[1] https://phoboslab.org/log/2021/09/q1k3-making-of
func_godot은 처음 써 봤을 때 기대했던 것보다 훨씬 잘 돌아갑니다. 트리거, 조명, 머티리얼, 사운드 같은 것들을 Trenchbroom에서 곧바로 제대로 가져와 컴파일해 주니까, 작업의 90%는 정말로 Trenchbroom에서 끝낼 수 있습니다. 프로토타입 만들 때 끝내줍니다!
세팅만 끝나면 훌륭하긴 한데, 거기까지 가는 데 꽤 험악한 수준의 주술 의식이 필요하거든요. 공식 통합 기능이 있었으면 좋겠어요. Godot 자체의 3D 레벨 편집 기능이 워낙 형편없으니까요.
Godot은 서드파티 앱에 의존해야 하는 일이 너무 많은데, 그 연동이 불안정하거나 아예 없어서 발목이 잡혀 있다는 느낌이 강해요. 개발자들은 IDE 학습 곡선 가지고 욕을 자주 먹지만, 오픈 소스 게임 개발 도구만큼 "세상에, 너희 이러고 살았니?" 싶은 분위기를 풍기는 건 없어요. Blender에서 텍스처 페인팅 하는 것 같은 아주 기본적인 작업조차 그렇다니까요? 맙소사. 그에 비하면 GIMP가 애플이 전성기 때 내놓은 어떤 물건보다도 잘 다듬어진 것처럼 보일 지경이에요.
"Hammer를 쓰면서 자랐다"는 말이 낯설게 들리네요. 저한테 Hammer는 아직도 Worldcraft의 신식 업데이트 같은 존재거든요.
물론 어떤 퀘이크 맵 에디터를 쓰든 퀘이크 엔진이 못 하는 건 할 수 없습니다.
id Software가 그랬듯[0] 맵을 먼저 종이에 그린다면, 어떤 에디터를 쓰는지는 그리 중요하지 않습니다.
J.A.C.K.[1]가 현재 Hammer 계보의 계승자입니다.
그리고 Trenchbroom에는 슬롭(slop)이 들어 있다는 이유로 생겨난 커뮤니티 포크[2]도 있습니다. "기계가 생성한 코드"든 "wAIfu가 생성한 코드"든, 기분이 덜 상하는 쪽으로 부르시면 됩니다.
"모두가 쓰는 맵 에디터"라는 표현은 지나친 단순화입니다.
[0] https://xxcancel.com/romero/status/643540836072992768
[1] https://jack.hlfx.ru/en/
[2] https://codeberg.org/NextBroomTeam/NextBroom
TrenchBroom은 훌륭합니다. 저는 Neverball의 메인테이너인데, Neverball은 공교롭게도 지금도 예전 방식의 텍스처 투영을 쓰는 몇 안 되는 게임 중 하나입니다. TrenchBroom은 제가 아무것도 하지 않았는데도 Neverball 게임팩이 이미 제대로 작동하던 최초의 퀘이크 에디터였습니다.
세월이 이렇게 흐른 뒤에도 Qt가 이따금 눈에 띄는 걸 보면 반갑습니다. 글쓴이 같은 사용자들이 "그래요, 그럴 만한 가치가 있었어요."라고 말하는 댓글과 함께 묵묵히 제 할 일을 하고 있죠. 그저 자기 일을 하면서 방해되지 않게 비켜서서, 사용자가 만들고 싶은 걸 만들게 해 줍니다.
재미있는 글이네요. Trenchbroom이 어떻게 시작됐는지 그 실제 역사는 몰랐습니다! 저는 지난 10년쯤 아주 가볍게 써 왔어요. 퀘이크를 한동안 못 본 분이라면 입이 떡 벌어질 만한 것들을 만드는 놀라운 퀘이크 맵퍼들이 많이 있습니다.
예를 들면 Arcane Dimensions[0]나 Quake Brutalist Jam[1]이 있습니다.
[0] https://www.moddb.com/mods/arcane-dimensions
[1] https://www.youtube.com/watch?v=vquTPCYbOxk
싱글 플레이 퀘이크에 입문하려는 분이라면 IronWail 같은 엔진을 받아서 Brutalist Jam 세 편을 전부 쭉 해 보시길 권합니다. 여러 맵퍼가 참여한 맵 팩인데, (많은 잼이 그렇듯) 박물관 같은 기본 맵으로 서로 이어져 있습니다. Brutalist Jam은 회를 거듭할 때마다 30년 된 기본 게임이 아직도 해낼 수 있는 일의 한계를 밀어붙입니다.
Trenchboom 정말 좋습니다!
뻔뻔한 홍보이긴 한데, 직접 만든 Trenchboom MCP로 이 q3 맵을 만들었습니다.
https://sajarin.com/q3inc
Trenchbroom은 아주 좋지만, 그래도 최고의 맵 에디터는 아니라고 생각합니다. 브러시 기반 방식을 쓰는데, 이건 (퀘이크처럼) 폐쇄된 공간을 다루는 게임의 맵을 설계하기에 맞는 방식이 아닙니다. 방 하나를 만들려면 벽, 바닥, 천장용으로 브러시가 최소 6개 필요한데, 이런 용도로는 너무 많습니다. 반면 (첫 언리얼과 언리얼 토너먼트의) Unreal Editor는 방을 (뺄셈 브러시로) 직접 만들 수 있고, 방 프리미티브 두 개가 맞닿으면 자동으로 연결됩니다.
저는 예전에 퀘이크 3와 언리얼 토너먼트 맵을 많이 만들었습니다. Unreal Editor는 Radiant보다 버그가 훨씬 많았지만 작업 흐름은 훨씬 우월했어요. 뺄셈 방식 덕분에 평면도를 아주 빨리 뚝딱 만들 수 있었죠. 게다가 caulk 텍스처를 다룰 필요도 없었습니다(caulk는 벽을 만들려고 쓴 상자의 옆면 중 플레이어에게 보이지 않는 면에 입히는, 렌더러가 무시하는 특수 텍스처입니다).
둘 다 써 봤는데 둘 다 흥미롭습니다. 개념적으로는 어떤 종류의 맵에는 브러시 방식이 더 직관적인 것 같아요. 방 몇 개가 열린 공간으로 이어지는 맵이라든지, 피라미드 모양 방처럼 좀 특이한 모양을 만들 때 말이죠. 잘 모르겠어요, 둘 다 흥미롭고, 한번 익숙해지면 덧셈 방식도 꽤 잘 돌아갑니다.
언리얼 방식과 퀘이크 방식은 기술적으로 거의 똑같습니다. 레벨은 반드시 밀폐되어 있어야 하고, 안에서 밖으로 새는 곳이 없어야 합니다. 야외 영역도 사실은 실내입니다. 제 짐작으로는 가시 집합(PVS) 계산이 제대로 동작하게 하려고 그런 것 같습니다. 두 에디터 모두 CSG 브러시 기반이었고 비슷한 BSP 데이터 구조로 컴파일됐습니다. 그런데 문제를 뒤집어 버리는 번뜩이는 발상으로, 언리얼 에디터 개발자들은 "꽉 찬 세계에서 시작해서 원하는 방을 빼내게 하면 레벨이 새는 일은 절대 없다"고 했습니다. 건물을 짓는다고 생각하는 방식과 비교하면 엄청나게 엉뚱하지만, 대체로 잘 먹혔습니다.
참고로 저는 맵을 많이 만들어 보진 않았고, 제 기본 방식은 대체로 맵의 대략적인 모양대로 큰 방 몇 개를 파내는 것이었습니다(영리한 시작 방식에도 불구하고 너무 빨리 욕심을 부리면 언리얼은 체처럼 줄줄 샜으니까요). 그런 다음 덧셈 브러시와 뺄셈 브러시를 섞어서 세부 지오메트리를 만들었는데, 이는 퀘이크 맵과 똑같았습니다. 누수를 피하려고 크고 단순한 방을 만들고(이번에는 조립이 필요했지만) 거기에 덧셈과 뺄셈으로 세부 지오메트리를 채우는 식이었죠.
초기 id와 Epic 엔진을 한마디로 요약하면 이렇습니다. 기술은 id가 낫고, 도구와 사용성은 Epic이 낫습니다.
그리고 브러시에 대한 각주를 덧붙입니다. 저는 맵 작업을 그만두고 한참 지나서야 이걸 이해했거든요. "브러시"는 3D 모델링 소프트웨어에서 흔히 쓰는 점·면 방식과는 다른 3D 프리미티브입니다. 브러시는 평면들이 교차해서 만들어지는 볼록한 형태로 정의됩니다. 점·면 모델에서는 점이 어디 있는지, 어떤 점들이 면을 이루는지를 정의하지만, 브러시에서는 면이 어디 있는지(점, 법선)와 브러시에 어떤 면들이 속하는지를 정의하고, 형태는 그 면들이 교차하는 방식에서 나옵니다. 제 짐작으로는, CSG 연산을 할 크고 단순한 지오메트리에는 점 모델보다 평면 모델이 더 매력적이었기 때문인 것 같습니다.
저는 이 분야에 대해 아는 게 전혀 없지만 더 알고 싶습니다. 언리얼 토너먼트 엔진이 내부적으로 이 뺄셈 모델을 썼다고 들은 기억이 있는데, 그러면 에디터 UX만의 결정은 아닌 건가요?
언리얼 토너먼트가 내부적으로 뭘 썼는지는 모릅니다. 소스 코드가 (공식적으로) 공개된 적이 없어서 조사하기 어렵거든요. 다만 퀘이크/퀘이크 II/퀘이크 III 맵을 만드는 데 브러시 기반(덧셈) 방식이 꼭 필요한 건 아니라는 건 압니다. 뺄셈 방식의 포맷으로 된 맵을 받는 맵 컴파일러를 작성하는 것도 기술적으로는 가능합니다. 그렇게 하지 않는 (적어도 흔하지 않은) 이유는 만만한 작업이 아니기도 하고, 기존 인프라와 맞물리면서 마찰이 생기기 때문입니다.
Trenchbroom은 훌륭하고 재미있습니다. 게임 개발자 중에는 레벨을 대충 블록으로 잡아 보거나 게임 전체를 만드는 데 쓰는 사람이 많습니다.
제가 둠 2 맵 만들기에 푹 빠져 있던 시절이 기억납니다. 일종의 테트리스 효과가 생겨서, 현실의 건물 내부가 섹터와 텍스처로 보이기 시작했어요. 둠에서 그 건물을 재현하는 데 쓸 수 있는 것들로요.
퀘이크 맵 제작도 해 보려 했지만, 어린 저한테는 3D 도구가 너무 복잡해서 감당이 안 됐고, 제 PC도 그걸 돌리기엔 너무 느렸습니다.
Qoole 기억하는 분 계신가요? 제가 쓰면서 자랐고 정말 좋아했던 에디터입니다.
저는 맵을 많이 만들진 않았지만(진짜 관심이라기보다는 호기심이었어요), 만들 때는 늘 Qoole이 첫 번째 선택이었습니다.
제 기억이 맞다면 CSG가 더 좋았고, 평면들을 연결해서 하나의 면처럼 텍스처가 입혀지게 하는 멋진 방법도 있었습니다.
새 프로젝트를 하고 있어서 TrenchBroom과 NetRadiant를 둘 다 살펴봤습니다. 둘 다 저한테는 그다지 쓸 만하지 않았어요. 저는 옛 UnrealEd와 새 UnrealEd에 익숙해서, 결국 UnrealEd를 쓰기로 했습니다. OldUnreal 릴리스 덕분에 이제 무료로 내려받을 수 있거든요.
모두요? 저는 1998년에 퀘이크 2 맵을 편집했는데 이건 안 썼는데요. ;)