Making a Mod
이 글은 밸브 게임의 MOD 게임을 만드는 데 도움을 드리고자 작성되었습니다. 우선 MOD 개발을 시작하고 팀 구성에 대한 몇 가지 조언을 드린 뒤, 게임 디자인에 대한 팁들, 마지막으로 최종 릴리즈까지의 가이드를 서술할 겁니다.
MOD 개발 시작
MOD 개발 시작 시 핵심은 소규모로 유지하되, 풀타임으로 해야 합니다. 온라인으로 개발한다면 시간 대부분을 팀원 관리에 소모하며, 그만큼 개발에 할애되는 시간도 줄어듭니다. 팀원을 늘려도 그만큼 관리할 일거리도 늘어 개발 속도가 확연히 늘어나진 않을 겁니다. 팀 포트리스의 핵심 팀은 3명이었고, 카운터 스트라이크는 1명(민 리)이었습니다.
팀원을 고를 때는 꼭 필요한 사람만 고용하세요. 코딩, 모델링, 맵 등 다다익선이란 생각이 들 수도 있는데, 첫 버전에서는 각 영역(코드, 사운드, 모델, 맵)에 한 명 이상은 필요하지 않을 겁니다. 게다가 작업물을 확인하세요. 예컨데 모델을 20개 만들어도, 만들다 만 것이라면 필요 없습니다.
MOD 디자인
MOD 개발 시 자문해 볼 수 있는 가장 큰 질문은 "누군가가 내 MOD를 플레이해야 할 이유가 있나?"입니다. 완벽하게는 아니더라도 어렴풋이 타겟층을 잘 알고 있다면 올바르게 가는 겁니다. 또한 타 MOD들이 어떤지, 무슨 경험을 제공하는지 생각해 보세요. 당신 MOD는 플레이어들에게 새로운 경험을 제공할까요? 당신 MOD가 타 MOD를 플레이하는 유저들을 충분히 끌어들일 수 있을까요? 물론 이 질문에 답할 수 없더라도, 그저 생각해 보는 것만으로도 개발 방향에 도움이 될 것입니다.
게임 플레이로 경쟁하기
상업 개발자와 달리 당신에겐 새로운 게임플레이 스타일의 상업적 타당성에 대해 걱정할 필요가 없습니다. 상업 개발자는 유통과 손익분기점, 기타 불쾌한 것들을 걱정해야 하지만 당신은 그럴 필요가 없습니다. 차세대 유행을 이끌 새로운 게임플레이 아이디어를 (MOD 유저들 상대로) 테스트 해 볼 수 있습니다. 그렇다고 상업 게임 수준으로 완성하려고 시간을 허비하지 마십시오. 대다수 MOD들은 수년 이상의 노하우를 가진 상업 게임들과 상대가 안 됩니다. 그러니 독창적 게임플레이로 유저들을 끌어들이세요.
빨리, 그리고 자주 배포하세요
상업 게임에 비해 또 다른 강점이 있는데, 그건 바로 훨씬 더 빠르고 자주 배포할 수 있다는 것입니다. 상업 개발자들은 2,3년 개발하고 출시하며 사람들이 좋아해 주길 바랍니다. 하지만 여러분은 대략 25% 정도 대강 플레이 가능하게 (선개통 후완공 개념으로) 완성하고 배포해 유저들의 호불호 반응들을 살펴보며 방향을 정할 수 있습니다. 그렇게 한두 달에 한 번씩 몇가지를 추가하거나 개선하며 계속 배포를 이어갑시다.
다만 착각하지 말 것은, "잦은 배포"는 '만들다 만 MOD를 출시'한다기보단 하나씩 하나씩 개선해 완성해 나간다는 뜻입니다. 카운터 스트라이크의 첫 버전은 지금의 절반도 되지 않는 기능을 갖추고 있었고, 그 후에도 품질은 높아지되, 자체 컨텐츠는 많은 편이 아니었습니다.
뭘 바꾼다고 늘 개선되는 것은 아닙니다
게임 디자인을 할 때 "달라질수록 좋다"는 함정에 빠지지 마세요. 예컨데 게임 플레이에 획기적인 영향을 미치지 않는 한 샷건 효과나 모델을 굳이 바꿀 필요가 없습니다. 상술한 "누군가가 내 MOD를 플레이해야 할 이유가 있나?"를 상기하세요. "내 MOD에는 새로운 전투 시스템과 새로운 이동 시스템이 있습니다."라는 답은 늘 좋은 답은 아닙니다. 당신 MOD의 게임 플레이는 하프라이프 본편과 다르다 칩시다, 그런데 더 재미있게 개선했나요? 유저들은 기존 게임 플레이에 익숙해져 있기 때문에 새로운 플레이에 익숙해지고, 중독되게 만들려면 그만한 가치가 있어야 합니다. 그러니 하프라이프의 게임 플레이를 그대로 두는 것도 두려워하지 마세요.
현실적 목표
현실적 목표를 세우세요. 상업 개발사가 무기 10개짜리 FPS 게임을 왜 만들까요, 만약 MOD에 무기 40개를 추가한다면 여러분과 하는 플레이어 모두에게 부담을 주는 겁니다. 명심하세요, 양보다 질입니다. 플레이어는 고만고만한 무기 40개보다 각자 독특하고 균형 잡히고 사용하기 즐거운 무기 10개를 훨씬 선호합니다.
컨텐츠와 기능 삭제도 두려워하지 마세요. MOD가 완성되지 않을 것 같거나, MOD와 어울리지 않는 컨텐츠가 있다면 삭제하세요. HL 개발 역시 개발 당시 만들어졌던 컨텐츠 중 최소 30%가 삭제되었습니다. 촉박한 개발 기한 내 완성 불가가 명백해졌거나, 굳이 시간을 들여 다듬을 가치가 없다고 판단되었기 때문입니다. 다시 강조하지만 "양보다 질"입니다. 플레이어는 테스트되지 않은 맵 10개보다 플레이테스트를 거친 훌륭한 맵 3개를 선호하며, 이는 MOD의 컨텐츠 품질을 높여줍니다. 세상에 최악의 컨텐츠를 보여주지 마세요.
엔진 기능 이해하기
개발 전후로 SDK 설명서를 꼭 읽어보세요. 요는, 엔진에 무슨 기능들이 있는지 다 알아야 하기보단 내가 원하는 기능이 어떻게 잘 구현되게 할 지 입니다. 예컨데 로켓 50개가 든 다연장 로켓 발사기를 만들 수 있지만, 엔진의 작동이나 한계를 이해하지 못하고 만들면 게임 중 튕기는 결과로 이어집니다. 이는 MOD 개발에 있어 중요합니다. 레벨 제작 역시 엔진 내 기능과 한계를 이해하지 못하고 만들면 프레임이나 네트워크 과부하로 이어져 쓸데없는 게 많다고 비난받을 겁니다. 프로그래머라면 HL Coders 메일링 목록에 가입하면 다른 MOD 프로그래머와 Valve 직원과도 대화할 수 있습니다. 메일링 목록에는 오랜 역사를 가진 아카이브가 있으며, 일반적인 MOD 문제에 대한 많은 유용한 솔루션이 포함되어 있습니다.
마무리 전
시작은 강렬했으나, 완성을 못하고 중단되는 용두사미 MOD들도 많습니다. 미완성 개발 버전에서 어느정도 완성된 버전까지 시간을 대략 5주로 잡아봅시다. 물론 MOD 개발량과 소속 팀원들이 많으면 많을수록 이보다 더 걸릴 수 있겠지만 마무리 단계는 다음과 같습니다. 가능하다면 이 기간동안 만큼은 팀원들이 마무리 작업에 전념하도록 하세요. 만약 팀원 중 일부가 이를 감당할 수 없다면, 해당 팀원을 제외하는 것이 좋습니다. 아무리 작은 제품이라도 완성은 늘 어렵고 상당한 헌신이 필요합니다.
그리고 냉혹한 말이지만 마무리를 앞두고 가장 어렵고, 가장 힘들고, 안타까운 부분은 이미 넣어져 호평받은 것들을 삭감할 때입니다. Valve에도 "게임 상에서 누구나 좋아하는 기능이 삭제될 수 있다"라는 말이 있습니다. 게임에 모든 멋진 기능을 담으면서도 합리적인 기간 내에 출시할 수는 없습니다.
마무리 동안
참고로 마무리 과정은 향후 게임 업계에 취직 시 심사관들이 관심깊게 살펴보는 부분이기도 합니다. 얼마나 멋진 것들을 많이 만들고, 얼마나 많은 사람들이 플레이 했는지와는 별개로 제대로 완성을 못 했다면 아무 소용이 없습니다. 그래도 걱정 마세요, MOD를 서너 번 완성할 시점이면 쉬워질 거예요.
권한을 중앙집중화
대략 5주 동안의 마무리 작업에 앞서 개발 팀원들 중에서 한 명을 총괄자(이하, SL)로 지정해야 하며, 이 사람은 마무리 작업을 총괄합니다. 그리고 이 때부터 각 팀원들은 이 사람의 지휘나 요청 속에서 작업들을 해야 하며, 아무 말이 없으면 아무리 사소한 변경이라도 임의로 해서는 안 됩니다. 이는 나머지 팀원들이 상하관계로 부려먹힌다기보단 예컨데 레벨 디자이너가 이 기간 중 게임 코드가 바뀐 줄도 모르고 임의로 변경했다가 이전에 없던 버그를 마주하는 것 같은 문제를 방지할 수 있습니다. 반면 SL은 마무리 기간 중 게임의 모든 구성 요소(코드, 맵, 모델, 텍스처 등)의 상태를 거의 전부 파악하고 스프레드시트(예: 엑셀) 등에 기록하며 전술한 버그 발생을 최소화 해야 합니다.
SL 선택에 있어 몇 가지 기준이 있는데,
- 지금껏 MOD 개발을 주도하는 사람이 늘 적합한 사람은 아닙니다. 특히 해당 MOD가 몇 달 동안 개발되어도 완성될 기미가 보이지 않으면 더욱 그렇습니다.
- 게임 코더(프로그래머)가 아마 좋은 선택일 수도 있습니다. 마무리가 다가올수록 코드 수정이 중요하니깐요.
- SL은 높은 동기 부여, 규율, 조직력, 그리고 교만함과는 거리가 있어야 하며, 또한 마무리 기간 동안 여기에 할애할 시간이 있어야 합니다.
- SL은 MOD 개발 방향에 대해 전반적 결정을 내릴 수 있어야 합니다. 또한 완성을 앞두고 뭘 더하고 뺄 지 이해하고 있어야 합니다.
설치 파일 빌드
팀원들의 각 작업물들을 SL이 수합해 설치 파일로 굳혀가는 과정입니다. 이 작업은 마무리 기간 동안 SL이 단독으로 수행해야 하며, 이 때 SL은 각 변경사항이나 특징들을 파악, 기록해야 향후 발견할 버그 원인을 추적하는 데 시간을 덜 허비하게 됩니다.
SL은 이제 배포를 앞두고 뭘 넣고 뺄 지 결정해야 합니다. 또한 이로 인해 MOD의 나머지 부분에 무슨 영향이 갈 지도 충분히 파악해야 하며, 이 과정 중 얘기치 못한 버그가 발생하거나 어처구니 없이 날려먹는 것에 대비해 코드와 컨텐츠 백업을 정기적으로 해두세요.
이후 어느정도 만족스럽다 싶으면 아래 단계로 넘어갑니다.
파일 잠금 및 플레이테스트
이 단계는 이제 더는 뭘 넣고 빼지 못하게 됨을 의미합니다. 이 단계는 오로지 위 SL가 빌드한 파일을 받아 여기에 아무것도 넣고 빼지 말고 각자 테스트를 번복해 버그가 있는 지 파악하는 것이며, 심각한 버그가 아닌 한 발생 조건이나 위치 등을 각 단계(즉시 수정, 심각, 보통, 사소, 없음, 연기)별로 나눠 기록해 두었다가 다음 업데이트에서 수정하세요.
또한 각 팀원들은 매일, 혹은 이틀에 한 번이라도 플레이테스트에 매진해야 합니다. 또한, 일손이 부족하다면 클로즈 베타로 외부인도 참여시키는 것도 좋습니다. 그리고 멀티플레이어 MOD라면 서버 콘솔 로깅 기능도 활성화하세요.(server.cfg 파일에서 "log"를 "on"으로 설정.) 이렇게 하면 서버의 모든 출력이 gamedir/logs 디렉터리 파일에 저장됩니다.(파일 이름은 날짜와 일치해야 합니다.) 동시에 각 테스터들은 버그를 발견 시 게임 내 텍스트 채팅 기능을 켜고 "BUG: 증상 설명"을 적어줘야 합니다. 이렇게 테스트가 끝나면 위 기능을 켠 플레이어는 로그 파일을 열어 "BUG"라는 단어를 검색해 버그가 있는 지 파악할 수 있습니다.
버그 및 변경 사항
SL은 각종 버그의 존재와 그 증상들, 심각한 버그가 발견되면 코더에게 보내 수정하기 전/후 내역들을 모두 기록한 뒤 패치된 파일을 전 팀원들에게 배포, 갱신시킨 후 테스트를 이어가야 합니다. 또한 이메일로 버그 제보받는 것은 각 메일들이 뒤섞여 수신받았는지조차 모르는 경우가 잦아 비추천 합니다.
열심히보단 똑똑하게 작업하세요
SL은 언제 무엇을 넣고 빼고, 패치할 지 신중하게 생각해 정하지 않으면 안 됩니다. 심지어 이 단계임에도 멋진 기능이 있다고 이를 개선한답시고 일주일을 허비하지 마세요. 오로지 게임 진행에 심각한 버그 발견과 수정에만 전념하세요.
아무튼 이런 식으로 패치에, 패치를 거듭해 심각한 버그가 마지막으로 발견된 지 48시간 경과되어 플레이 가능 기준을 충족 시, 이제 배포해도 문제없을 겁니다!
배포 후
만약 당신 MOD가 재미있다면 각 커뮤니티마다 당신 MOD에 대해 얘기하고 있을 겁니다. 그리고 이 반응들과 위에서 기록한 수정 목록들을 가지고 추가 업데이트를 할 지는 여러분 몫입니다. 다만 온라인 멀티플레이어 분야에서의 저희 경험에 따르면, MOD는 업데이트가 지속되는 기간동안만 인기를 유지합니다. 게다가 아무리 훌륭한 MOD라도 첫 술에 많은 인기를 얻을 수 없습니다. 새로운 컨텐츠의 지속적인 출시, 버그 수정, 그리고 커뮤니티 지원이 겹쳐질수록 플레이어 수는 증가합니다. 카운터 스트라이크와 팀 포트리스 모두 작은 규모로 시작했지만 시간이 지남에 따라 성장했습니다. 새 버전이 출시될 때마다 더 많은 플레이어들이 게임을 플레이하기 시작했습니다.
행운을 빕니다!