MOD 만들기
역: 2008-04-22 Iron Smith
역자 서문
아래 글은 Half-Life로 유명한 Valve Studio의 Source Engine을 활용한 MOD 제작 가이드 문서입니다. 개인적인 목적으로 읽어보던 중 비단 MOD 개발자뿐만 아니라 우리 일반적인 게임 개발자들도 함께 읽고 공유하면 좋을 것으로 판단 되어 부족한 영어 실력에도 불구하고 번역하게되었습니다. (번역이 이상한 문장은 원문 참조 바람 ^^)
내용 중 상당부분이 “우리와는 맞지 않는 상황이잖아?”, “뭐야… 별로 새로울 것도 없잖아?” 혹은 “당연한 거잖아?” 라고 반문 할만한 것들 이지만, 우리 상황에 대입해 한번 더 생각해 보거나 역으로 돌아보면 크게 독이 되지는 않을 듯 합니다.
참고로 원문 주소는
입니다.
이 글은 Source Engine 을 이용한 mod 제작을 돕기 위해 쓰여졌습니다. MOD 제작을 시작하고 팀 구성을 하는 데 있어 필요한 조언을 시작으로 여러분이 MOD 게임 설계를 하는 데 있어 필요한 다양한 tip들을 포함 하고 있으며, MOD 제작에 있어 가장 힘든 부분이라 할 수 있는 MOD 제작의 마무리 과정을 단계별 가이드 하는 것으로 글을 마무리 하고 있습니다.
|
|
시작하기
일단 “어떻게 팀을 구성할 것인가?” 부터 생각해 보겠습니다. 그에 관해 우리가 해줄 수 있는 가이드는 가능하다면 소규모로 팀을 유지하라는 것입니다. 사람들을 관리한다는 것은 full-time 업무에 해당하며, 이는 심지어 같은 장소에 모든 팀원이 상주하고 있더라도 크게 달라지지 않습니다. 더욱이 팀이 online으로 구성되어 있다면, 팀 매니징을 위해 하루 중 대부분의 시간을 투자해야 할 수도 있으며, 그로 인해 여러분이 정작 MOD 제작 실무에 할애해야 하는 시간은 모두 사라져 버릴 수도 있습니다.
팀에 많은 인력을 투입할수록 언제나 그에 비례하여 생산력 증대 되는 것은 아닌 반면 팀 관리시간은 팀원 수에 비례하여 확실히 증가하게 됩니다. 참고로 ‘Team Fortress’의 핵심 개발 인력은3명으로 구성되었으며, Counter-Strike의 핵심 팀은 단지 1명 이었습니다. (역주: 좌절이다… OTL 대단한 녀석들…)
그럼에도 불구하고 팀 멤버를 구하려 한다면, 그 사람이 없을 경우 더 이상 정상적인 프로젝트진행이 불가능하다고 판단되는 경우로 한정하기 바랍니다.(can’t survive without)
일반적인 경우라면 본능적으로 팀에 도움이 될만한 능력을 가진 사람이라면 누구라도 채용부터하고 보려는 경향이 있습니다. (코딩, 모델링, 맵제작, 등등)
그렇지만, 아마도 최초 version제작 시에는 각 분야별로(code, sound, models, maps) 한 명씩의담당자 이상으로는 굳이 필요하지 않을 것이며, 이 단계라면 심지어 새로운 model, sound, map들을 제작할 필요 자체가 없을 수도 있습니다. (역주: 아마도 Source Engine이 자체적으로default artistic resource들을 가지고 있기 때문에 그냥 그거 활용해도 되잖아? 가 아닐까… 음..걍 half-life 것을 뽑아 써도 되겠군…)
아울러, 실제 작업 결과물을 눈으로 확인하기 전에는 어떤 누구도 채용하려 하지 않는 것이 좋습니다. 뿐만 아니라 그 각각의 결과물들은 실제로 제작이 완료된 것인지도 확인해야 합니다. 만약modeler를 채용하려는 과정에서 그가 이미 20개나 되는 모델을 제작했지만 그것들 모두 마무리가 안된(half-finished) 상태라면 그는 여러분 팀에게 필요한 사람이 아닙니다.
(역주: 음… 이 녀석들도 역시나 일의 크기를 떠나 마무리할 수 있는 능력을 중요하게 생각하는군요…)
Mod 설계
MOD 제작자로서 스스로에게 자문해 볼 수 있는 최고의 질문은 “도대체 왜 사람들이 네 놈이많든 MOD를 플레이 해야 하는 거냐?” 가 되겠습니다. (역주: 상당히 본질적이며, 아픈 곳을정확히 찌르네요…)
이에 대한 올바른 답변을 한다는 것은 대단히 어려운 것이 사실입니다. 그러나, 만약 여러분이이에 대해 즉시 truthful한 답변을 제시할 수 있다면, 적어도 일단은 프로젝트가 올바른 방향으로나아가고 있는 것 입니다. (on the right track)
기존의 다른 사람들이 만든MOD들과 그 안에서 제공하고 있는 것들에 대해 생각해 보기 바랍니다.
- 그들과 비교하여 여러분이 만들려고 하는 MOD는 유저들에게 뭔가 좀더 새로운 것을 제공하고있습니까?
- 이미 다른 MOD들을 플레이하는 것 만으로도 하루가 부족한 유저들을 유혹하기에 충분한 뭔가를 제공하고 있던가요?
지금 당장 이 질문들에 대한 적절한 답을 찾지 못하더라도 꾸준히 그 해답을 찾으려 노력하는 것만으로도 여러분의 프로젝트에 긍정적인 영향을 미치게 될 것입니다.
게임 플레이에 집중하자!
여러분은 실제 현업의 게임 개발자들(commercial developer)은 갖고 있지 못한 한가지 강점을가지고 있는데, 우리는 새롭게 고안한 게임플레이 방식에 대한 상업적 성공 가능성에 대해서 일단은 그다지 크게 신경 쓸 필요가 없다는 점입니다.
상용 게임 개발자라면 시장에 어필할 수 있을 지, 투자비 외에 실수익을 거둘 수 있을 지, 등등그 밖의 잡다하고 골치 아픈 것들을 고민할 수 밖에 없으며, 그로 인해 이미 검증된 기존의 게임플레이에 약간의 변경을 가하는 것 이상으로 과감한 시도를 할 수 없기 때문입니다.
그러나 여러분은 굳이 그럴 필요가 없습니다. 그런 복잡한 것들에 얽매일 필요 없이, 엄청난 대작이 될 수도 있는 정말 새로운 게임플레이 아이디어를 찾아내는 것에만 집중할 수 있는 것 입니다..
이것이야 말로 현업의 개발자들에 비해 여러분이 우위에 있을 수 있는 부분입니다. 부디 현명하게 행동하기 바랍니다. 절대로 상용 타이틀들과 싸워서 이길 수 없는 부분들 때문에 쓸데 없이많은 시간을 낭비하지 말고, 앞서 언급한 바와 같이 여러분만이 가지고 있는 장점에 가능한 모든노력을 집중하기 바랍니다.
대부분의 MOD게임들은 적어도 map, model, sound 등과 같은 컨텐트 레벨에서는 상용 게임들과 경쟁하기가 곤란한 것이 사실입니다. 상용 게임 개발팀은 이미 수년에 걸친 경험을 가진 분야별 유능한 artist들을 팀으로 확보하고 있기 때문에 결국 그들과 경쟁할 수 있는 것은 여러분만이 할 수 있는 독특한 게임플레이밖에 남는것이 없습니다.
사람들이 MOD를 즐기는 이유는 새로운 content때문이 아니라 여러분이 정말로 독특하고 재미있는 게임플레이를 제공할 것이라는 기대 때문이라는 점을 잊지 마시기 바랍니다. (역주: 여기서언급된 content는 우리가 일반적으로 사용하는 것 보다는 대단히 협의로 쓰이는 듯 합니다. 문서전체에 걸쳐 주로 artistic resource들에 한정 되어 있는 듯 하군요)
실제로 ‘Team Fortress 1’의 경우 처음 출시된 이후 수년간 아무런 artistic 컨텐트가 추가되지 않고 있지만, 대부분의 사람들이 그 사실에 신경 그다지 쓰지 않고 있습니다 J
재빨리, 그리고 자주 release 하자!
현업 개발자들에 비해 여러분들이 가지고 있는 또 하나의 강점이 있습니다. 여러분은 현업 개발자들보다 대단히 빨리 그리고 매우 자주 release하는 것이 가능하다는 점 입니다.
우리는 이러한 MOD 개발 철학을 하나의 문장으로 압축했는데, 그 것이 바로 “Release soon, Release often” 입니다. 상용 개발자들의 경우는 하나의 게임 출시를 위해 약 2~3년간 죽어라개발하게 되는데, 막상 출시 때까지 그들이 할 수 있는 일이라곤 그저 잘 되기만 신께 기도하는것입니다.
반면에 여러분은 굳이 상용 개발자들처럼 막연히 잘되기만 바라는 소극적 입장을 취할 필요가없습니다. (leap of faith)
일단 여러분의 전체적인MOD 구상(design)이 완료 되었다면 우선 25% 정도만 개발을 마친 다음적당히 게임 플레이가 가능하도록 다듬어서 큰 부담 없이release하고, 즉시 유저들의feedback을 취합해 볼 수 있습니다.
그런 이후, 남아있는 부분을 하나씩 추가해 나아가는 동시에 첫 버전에 대한 유저들의feedback을 수용하여, 매 1~2개월마다 새로운 버전을 release 해 나가는 것이 가능합니다.
이처럼 여러분은 유저들과 직접 호흡할 수 있기 때문에, 상용 개발자들과 같이 막연히 유저들이재미있어 할 것이라는 착각 속에서 시간을 낭비하지 않을 수 있습니다.
일단은 여러분의 게임을 만들기 쉽도록 가능한 한 잘게 나누기 바랍니다. 최초의 버전은 약간의재미와 플레이 가능한 수준이면 충분하며, 굳이 여러분이 고려하고 있는 게임의 독특한 내용들모두를 담고 있지 않아도 상관없습니다.
“Release soon”의 의미는 허접 하더라도 일단 release하자는 것이 아니라 여러분의 MOD에 비록작지만, 그 각각이 완성도 있는 발전을(small, polished increments) 지속하라는 것임에 유의하기바랍니다..
사실 Counter-Strike의 경우 역시 최초 버전 때만 해도 현재 적용된 feature들의 절반도 채 지니고 있지 않았습니다. 그러나 Counter-Strike팀은 비록 작지만 완성도 높은 MOD를 출시했으며,과거 수년 동안에 걸쳐 정기적으로 다양한 feature들을 추가했고, 그 결과 CS의 유저 층 역시도끊임 없이 증가되어 오늘에 이르게 되었습니다.
차별화가 항상 바람직한 것만은 아니다.
새로운 게임을 design함에 있어 “남들과 차별화 되야 한다(Different is better)”라고 하는 맹신에빠지지 않도록 주의 하기 바랍니다. 여러분의 게임에 뭔가 확실한 재미를 주는 것이 아니라면, 굳이 shotgun 코딩을 새로 하거나 세상에 없는 shotgun 모델을 만들어야 할 필요는 전혀 없기 때문입니다.
첫 번째 질문을 다시 한번 상기해 보겠습니다.
“왜 누군가 내가 만든 MOD를 즐겨야 하지?”
이 질문에 대한 답변으로 “내가 만든 MOD는 새로운 전투 시스템과 새로운 이동 시스템을 가지고 있지요~” 는 그다지 적절해 보이지 않는군요.
좋습니다.
여러분이 Half-Life와는 다른 뭔가 새로운 전투 시스템을 개발했다고 가정하겠습니다.
그래서?
그 때문에 뭐가 더 좋아진 거죠?
그게 여러분의 게임을 더 재미있게 만든다고 확신하고 있나요?
새로운 이동 시스템이 게임을 더욱 즐겁게 해주는 거 맞나요?
유저들은 이미 기존 게임에서 플레이 하던 시스템들에 익숙해 있는데, 그럼에도 불구하고 그들이 여러분이 만든 새로운 것을 익히도록 하려면 충분히 그럴만한 가치를 가지고 있어야 합니다.따라서, 여러분은 뭔가를 새로운 것을 넣기 위해 고민하기 이전에 그러한 변경이 게임을 보다 현실적으로 개선시키며, 더욱 재미있게 하는지에 대해 확신하는 과정을 반드시 선행해야 합니다.
결론적으로 Half-Life에 이미 적용되어 있는 시스템을 그대로 재활용한다고 해서 막연한 두려움이나 찜찜함을 가질 필요는 없다는 얘기입니다. (역주: 정말 주옥 같네요… 한마디로 쓸데 없는 곳에 목숨 걸지 않는 게 어때? 이군요 )
현실적인 목표들
여러분 스스로를 위해서라도 현실적인 목표를 세우는 것이 좋습니다. 상용 게임 개발자들이10종류의 무기를 가진 FPS shooter하나를 만들기 위해 얼마나 많은 시간을 투입할 지 생각해보시기 바랍니다. 만약 여러분들이 현재 40종의 무기를 만들어 넣을 계획을 가지고 있다면, 결과적으로 여러분의 인생만 고달파질 뿐입니다.
여기서 반드시 머리 속에 각인해야 할 점은 “양보다는 질이다! (Quality over Quantity)” 라는것 입니다. 유저들은 어설프게 남이 만든 것들을 베껴서 우겨 넣은 밸런싱 조차 제대로 안된40종이나 되는 무기를 사용하는 것 보다는 비록 10가지뿐이지만 각각 독특하고 밸런싱이 잘 되어있으며, 사용 자체가 재미를 줄 수 있는 무기로 플레이 하는 편을 훨~씬 선호할 것이기 때문입니다.
Content와 feature들을 과감히 cut하는 것에 대해 결코 두려워하지 않아야 합니다. 만약 여러분이 제작 중인 MOD 개발의 끝이 보이지 않거나, 이미 개발된 다른 부분에 비해 상대적으로quality가 떨어지는 content가 있다면, 과감히 cut해 버리기 바랍니다.
Half-Life역시도 개발 과정에서 일정에 맞춰 제작이 곤란할 것으로 판단되었거나 투입해야 하는개발시간 대비 얻을 것이 상대적으로 적은 것으로 예상되는 것들은 과감히 버려졌으며(cut) 그결과 당초 게임 설계에 비해 최소한 30%정도의 feature들이 결과적으로 cut 되어 출시 되었습니다.
다시 한번 말하지만 “양 보다는 질이다!”
유저들은 잘 만들어지고, 수 많은 테스트를 거친 3개의 맵에서 플레이 하기를 원하지 비록 10개가 넘지만 각각이 허접한 맵을 원하는 것이 아니라는 것을 다시 한번 명심하시기 바랍니다.
여러분이 게임 제작과정 전체에 걸쳐 이러한 접근을 지속할 수 있다면 세상은 여러분의 MOD에게 “고품질 컨텐트” 라는 멋진 평판을 부여해 줄 것입니다.
절대로 세상 사람들에게 여러분의 허접함을(worst stuff)를 드러내지 않도록 하십쇼!
사실 여러분들은 반드시 SDK에 포함된 documentation을 읽어야 합니다. 그렇게 해야 하는 이유는 우리의 engine(역주: 당연히 여기서는 Valve studio의 Source Engine을 말하고 있으나 아무렴 어떤가? 우리는 우리가 만든 혹은 만들 engine으로 생각하면 될 테니… ) 을 이용해서 무엇을 할 수 있는지, 없는지를 알아내기 위한 것이 목적이 아니라, 뭔가를 만들 때, 어떻게 만드는것이 최적화된 동작을 이끌어 낼 수 있는 지를 이해하기 위한 것입니다. (역주: 여러분이 프로그래머이건 아니건 단순히 엔진의 가죽만 보지 말라는 얘기!)
예를 들어, 50발의 rocket을 발사하는 rocket launcher를 만든다고 가정해 보겠습니다. 이때, engine의 내부 동작 원리에 대한 이해가 없다면, 유저 입장에서 같은 결과물을 얻기 위해network traffic을 엄청나게 사용하는 괴물을 만들어낼 수도 있을 것입니다.
이 사실은 여러분의 MOD팀 구성원 모두에게 대단히 중요한 것이며, 예를 들어 만일 여러분 팀의 map 제작 담당자가 engine에 대한 이해도가 전혀 없다면, 어떤 방식으로 맵 안에 있는 플레이어들 간에 얼마나 많은 데이터가 네트워크를 통해 전송될 지에 대한 고려 없이 거대한(huge)맵 들을 찍어 낼 수도 있을 것이고, 이는 많은 네트워크 사용(network intensive)량을 발생시켜 결국 유저들로부터 게임 자체가 잘못 만들어졌다고 비난을 받게 될 수도 있기 때문입니다.
특히 프로그래머 같은 경우라면, Half-Life coders mailing list 에 참여하는 것도 좋은 방법이 될수 있습니다. 이 mailing list 를 통해 전세계의 수많은 MOD 프로그래머들을 비롯해 Value의 직원들과도 직접 교류하는 것이 가능하며, 오랜 시간 축적된 MOD제작 과정에서 발생할 수 있는각종 문제들에 대한 유용한 해법들이 가득 담긴 archive도 참고할 수 있습니다.
마무리하기
그간 우리는 의욕적으로 시작하여, 보기에 멋들어진 content를 생산해 내는 MOD들을 많이 보아왔지만 그들 중 실제로 플레이어들에게 배포되어 즐기도록 하기 위한 마지막 단계까지 제대로도달하는 경우는 거의 보지 못한 것이 사실입니다. 이번 섹션에서는 release mode (역주: Visual Studio Release Mode가 아니라 ^^a [출시 준비 단계]를 말하는 것 임) 에 돌입하여실제로 releasable version의 MOD를 만들어낼 수 있도록 돕기 위해 필요한 내용들을 다루고 있습니다.
일단은 일반적인 개발모드 (development mode)를 끝내고 shippable version을 만들어 내기까지걸리는 전체 시간을 약 5주로 설정했는데, 사실 이 기간은 이후 지속적인 release를 거듭하면서과정 자체에 여러분들이 익숙해질 것 이므로, 점차 단축될 것이라 생각됩니다.
만약 여러분 MOD프로젝트의 규모 자체가 상당히 크다거나 혹은 팀 구성원이 전세계 여기저기흩어져 있는 난감한 상황이라면, 비록 진행하는 step 자체는 크게 차이가 없음에도 5주 이상의시간이 소요될 가능성이 있음을 염두 하기 바랍니다..
가능하다면, 이 시기에는 모든 팀원이 매일 약 2~3시간이라도 반드시 프로젝트를 위해 할애할수 있도록 해야 하며, 만일 이것이 곤란한 팀원이 있다면, 차라리 해당 팀원(들)은 shipping process에서 제외 시키는 것이 바람직하고, 대신 기꺼이 해당 업무를 대신할 수 있는 누군가에게 그 역할을 넘기도록 하기 바랍니다. 제품 규모에 상관 없이 어떤 결과물을 shipping한다는 것은 대단히 어려운 일이며, 상당한 노력이 필요한 것 입니다.
이번 섹션에서는 다소 냉정하고, 빡빡하게 느껴질 수 있는 많은 내용을 담고 있습니다만 불행히도 이는 곧, 이 단계의 process자체가 실제로도 대단히 어려운 부분이란 것을 반증하는 것 이기도 합니다.
이 곳에서 언급되는 충고들은 대부분 실제로 우리가(Valve studio) 수 많은 제품들을 shipping하는 과정에서 얻게 된 교훈들을 집약한 것이며, 그 것들 대부분은 출시일정을 연기하게 만들었던수많은 고통스러운 실수들의 결과물이라고 보아도 무방합니다.
만약 여러분이 우리의 조언들 중에 과연 그대로 따라야 할 지 의심이 드는 부분이 있다면 반대로이렇게 생각하시기 바랍니다.
“우리(Valve studio)역시 그러한 지침을 따르지 않았던 관계로 수주 이상의 출시 일정을 지연시킨 경험이 있다고…”
두 가지 경우를 고려해 보겠습니다.
상당히 멋진 결과물을 만들어낸 A라는 팀과, A 팀에 비해서는 다소 떨어질 수 있지만 나름 괜찮은 결과물과 함께 성공적으로 출시하여 실제 유저들이 현재 즐기고 있는 게임을 가지고 있는B팀… 장래 여러분의 사장님(employers)께서는 어떤 경우에 더 관심을 가지게 될까요? 아무리멋진 map, model, code, sound, 등등을 만들고 적용했을 지라도 마지막 단계인 shipping에 이르지 못한다면 결국 그 모든 노력들은 무용지물이 될 것입니다.
그러나, 너무 크게 걱정할 필요는 없습니다. 2~3번 정도만 이 과정을 반복하게 되면 쉽게 익숙해질 수 있으니까요. MOD를 3~4차례 release하고 난 후 여러분은 이미 shipping의 달인이 되어있을 것이라 장담합니다! J
5주 남았다! Ownership을 일원화 하자!
향후 5주간 여러분 팀의 모든 진행을 책임지게 될 Shipping Leader (SL) 한 명을 지정해야 할 필요가 있습니다. 지금부터 이루어지게 될 모든 변경은 반드시 SL의 요구에 의해서만 이루어져야하며, 마찬가지로 변경을 위한 모든 요청들은 SL에게 집중 되어야 합니다. 게임에 가해지는 변경의 중요도, 작업의 크기에 상관 없이 SL이 요청한 것이 아니라면 그 누구도, 그 어떠한 변경작업도 임의로 진행하지 않아야 합니다.
그렇다고 SL을 제외한 나머지 모든 팀 멤버들은 MOD에 대한 모든 제어권을 잃게 되는가? 그것은 아닙니다. 왜냐하면 여전히 SL은 팀원 중 한 명이며, 여러분들의 모든 feedback에 대해서 귀기울일 것이기 때문이다.
SL이 필요한 핵심적인 이유는MOD에 대해 이루어지는 모든 변경이 반드시 한 사람을 통해 일원화 된다는 것을 보장할 수 있기 때문이며, 결국 이를 통해 우리는 실제 게임 코드에 어떤 수정이이루어졌는지 모르는 상태에서 맵 제작자가 build막판에 임의의 수정을 해서 게임 진행자체가불가하게 만들어 버리는 것과 같은 문제를 사전에 피할 수 있을 것 입니다.
SL은 향후 5주간 게임을 구성하는 각 요소들(code, map, model, texture, 등등)의 현 상태를 정확히 파악하게 될 것이며, 결국 이를 통해 위에 예로 들은 상황이 실제로 발생하지 않도록 조율하는 역할을 담당하게 될 것입니다.
SL을 지정하는 것은 사실 쉬운 일이 아니지만 현명한 선택을 할 수 있도록 돕기 위한 몇 가지tip들을 소개하도록 하겠습니다.
즉흥적으로 현재 프로젝트 진행을 담당하고 있는 사람이 SL 적임자라고 속단하지 말자.특히나 여러분의 MOD 프로젝트가 이미 수개월간 진행되어 왔음에도 불구하고 실제 release와는 여전히 거리가 먼 상태라면 더더욱 그렇다.
- Shipping Process의 막바지에 이를수록 대부분의 수정이나 변경은 실제로 game code 에서 이루어질 가능성이 높기 때문에 아마도 game coder중 한 명을SL로 지정하는 것이현명한 선택이 될 수 있다.
- 가능하다면 SL은 적극적인 성향을 지니며(highly motivated), 조직 친화적이어야 하고(organized), 가급적 경험과 지식이 풍부해야하며(disciplined), 너무 강한 자아를 지니지 않은 사람이어야 한다.(ego-less) 뿐만 아니라, 남은 5주간 자신의 거의 모든 시간을 shipping을 위해 몰빵 할 수 있어야한다. -_-+
- 끝으로 SL은 MOD 프로젝트 전반에 걸쳐 의사결정을 내릴 수 있는 사람이어야 하며, 이과정에서 shipping을 위해 당초 계획했던 각종 feature들이나 게임 content들을 과감히버릴 수 있어야 한다는 것을 스스로 납득하고 있어야 한다.
Build 프로세스를 수립하자!
여러분은 여러분의 MOD 빌드를 위한 절차를 확립할 필요가 있습니다. 여기서 builing이라 함은각 멤버들의 작업물을 취합하여 정상적으로 게임이 진행되며, (일반적으로) 인스톨 가능한 상태의 MOD version을 만들어내는 과정을 말하게 됩니다.
이 것은 향후 5주간 무슨 일이 있어도 지켜져야 하며, SL은 이러한 절차가 반드시 지켜질 수 있도록 확고한 Building Process를 확립하고 있어야 합니다.
이를 통해 사람마다 멋대로 MOD를 build하고 그로 인해 발생된 버그를 찾기 위해 소중한 시간을 낭비하는 상황이 발생하지 않도록 미연에 방지할 수 있습니다.
SL은 지금부터 항상 최종 출시 가능 버전을 지속적으로 확보하고 있어야 합니다. (역주: 최악의경우에도 지금 작업 중이라서 컴파일이 안돼! 혹은 게임 실행이 안돼! 와 같은 상황이 발생하지않도록 안정된 최신 버전을 항상 확보하고 있어야 한다는 얘기)
모든 변경사항은 SL에게 전달되어야 하며, SL은 그 것들 각각이 게임에 미칠 영향을 완벽히 이해한 상태에서 자신의 local copy MOD 에 하나씩 하나씩 적용해 보아야 합니다. 물론 이 과정에서 모든 데이터의 정기적인 backup을 진행하는 것은 필수입니다!
앞으로 SL은 플레이 테스트를 하기 위해 매일 빠짐없이 MOD를 빌드해야 합니다.
Playtesting
지금부터 여러분은 매일, 또는 (이것이 너무 부담스러울 경우) 적어도 2일에 한번씩은 Playtest를 돌려야 하며, 이 모든 테스트는 SL이 build한 인스톨 가능한 버전으로부터 이루어져야 합니다.
절대로, 팀 멤버들이 자신의 local PC에 있는 서로 다른 버전으로 테스트하는 일이 없도록 해야하며, 반드시 모든 팀원들은 SL이 build하여 전달해 준 버전을 install하여 활용하도록 하기 바랍니다. 여러분이 테스트해야 할 것은 유저들이 설치하여 플레이하게 될 것과 동일해야 하며, 그것은 곧 SL이 빌드한 것이어야만 하기 때문입니다.
만약 이 규칙을 따르지 않는다면, 서로 상이한 버전으로 인한 호환성 문제로 발생하는 각종 버그들을 찾기 위해 많은 시간을 낭비하게 될 것입니다.
이런 과정을 보다 편하게 하기 위해서는 여러분의 MOD를 언제라도 플레이 가능한 상태로 유지해야 합니다. 혹시라도 MOD가 도중에 플레이 불가한 상태에 빠지지 않도록 매일 꼼꼼히 신경쓰고 고려해야 하며, 만일 누군가의 작업내용을 적용한 이후 MOD가 플레이 불가한 상태가 되어버린 경우에는 문제의 버전을 빌드 하기 직전에 SL이 적용한 내용이 무엇이었는지 조심스럽게살펴보기 바랍니다.
얼마나 오랫동안 여러분의 게임이 플레이 불가 상태에 있었는가?
그로 인해 얼마나 오랫동안 여러분은 플레이테스트를 빼먹었는가?
얼마나 오랫동안 MOD가 동작하지 않았기 때문에 여러분의 팀원들이 개발을 중지한 채 방치 되었는가?
언제라도MOD가 플레이 가능한 상태로 유지되도록 하는 것은 여러분들 팀에게 일종의 확고한신념(religion)이 되어야만 합니다.
플레이 테스트를 진행 할 시, 가능한 한 많은 팀원이 함께 참여할 수 있도록 해야 하며, 모든 팀원은 그러한 플레이 테스트를 정기적으로 진행해야 합니다. 뿐만 아니라 함께 참여할 수 있는 외부 테스터들 역시도 확보하고 있어야 합니다.
Server.cfg파일을 편집하여 서버콘솔 logging 기능을 켜도록 하세요. 이렇게 함으로써 모든 서버output 정보를 log 디렉토리의 특정 파일에 출력하도록 할 수 있습니다. 게임에 접속해 있는 플레이어는 누구라도 언제나 게임의 console창을 통해 “say” command를 사용하여 발견된 버그사항을 “BUG: 버그내용” 과 같은 형태로 출력되도록 할 수도 있습니다.
이후 여러분은 Log파일을 열어 단지 “BUG”라는 단어만 모두 찾아서 확인하면 이번 테스트 과정에서 발견되었던 전체 버그 내용을 손쉽게 확인할 수 있게 됩니다.
버그와 변경
SL은 반드시 온전한(적어도 현재까지 발견된) 모든 버그리스트와 변경 목록 그리고 그들 각각의현재 상태를 유지하고 있어야 합니다. 이러한 관리가 실제 database를 활용해 이루어질 수 있다면 더욱 바람직할 것 입니다.
E-Mail은 누락될 가능성이 농후하기 때문에 버그 트래킹 용으로는 절대적으로 부적합한 시스템입니다. 매번 플레이 테스트가 끝난 이후 SL은 Log파일에 기록된 버그 내역을 정리해야 하며,사안별로 각각의 팀 멤버들에게 할당해야 합니다. 팀원은 할당된 버그나 변경사항을 fix한 이후SL에게 제출해야 하며, SL은 실제로 해당 문제가 해결 되었는지 여부를 직접 꼼꼼하게 확인한이후, 버그 리스트에서 해당 항목의 상태를 갱신해야 합니다.
버그 리스트는 실제로 여러분의 프로젝트가 얼마나 잘 진행되고 있는 가를 평가할 수 있는 실로환상적인(fantastic -_-) 툴이라 할 수 있습니다. 버그 리스트를 통해 우리는 누가 과도한 업무 부하를 받고 있는지, 누가 널널한지, 그리고 누가 버그 수정을 게을리 하고 있는지, 등을 파악할 수있습니다.
이미 수정 완료된 항목을 포함하여 절대로 어떠한 내용도 버그 리스트로부터 삭제하지 않아야합니다. (차라리, 어떤 형태로건 수정완료 되었다는 mark를 남기는 방법을 찾아야 합니다)
어떤 버그가 프로젝트 전체 진행과정 중에서 어떤 과정을 거쳐 발생되고 수정되어 왔는지 트래킹 이 가능하다면 이것은 대단히 유용하게 활용될 수 있습니다.
때때로, 이미 수정된 버그가 재발 하는 경우가 있기 때문에, 최근에 해당 버그를 누가 어떻게 해결 했었는지에 대한 정보를 버그리스트로부터 얻을 수 있다면 상대적으로 손쉽게 해결이 가능하기 때문입니다.
프로젝트 막바지 단계에서 여러분은 반드시 shipping process 전체 과정에서 수정된 모든 버그와 변경 내역에 대해서 언제라도 확인이 가능해야 합니다.
또한 SL은 버그리스트에 충분히 상세하게 관련 내용을 기술하기 전에는 어떠한 버그 수정이나변경도 자신의 master copy에 적용해서는 안됩니다.
여러분이 버그리스트를 생성하고 유지관리 하는데 유용한 프로그램들이 많이 있겠습니다만, 다시 한번 말하지만 e-mail은 절대 추천하지 않으며, 차라리 excel과 같은 spreadsheet가 훨씬 유용한 대안이 될 것입니다.
Cut or defer broken features
가장 어렵고, 피하고 싶지만 불행히도 shipping단계에 있어서 가장 중요한 부분은 바로 버릴 것은 과감히 버릴 수 있는 냉정함을 가지는 것입니다.
Valve studio 에서 구전되는 바에 의하면, 그 누구라도 정말로 만들고 싶은 기능은 끝내 커트되고 만다는 전설이 있습니다.
비록 이 얘기가 사실은 아닐지라도, 실제로 꼭 만들고 싶어하는 기능들(features) 또는 오랜 시간을 투자하여 만들어오던 기능 들 역시도 부득이 도중에 cut될 가능성이 있다는 것에 대해 마음의 준비를 하게끔 돕는 역할을 할 수는 있습니다.
단순하게 말해서 합리적인 기간 안에 만들고 싶은 모든 멋진 기능들(feature)을 구현하면서 출시일정까지 지키는 것은 사실상 불가능에 가깝습니다. 이런 이유로 SL은 출시까지 남아있는 시간적 여유를 확인하여 어떤 것을 반드시 끝내야 하고 어떤 것은 과감히 포기해야 할지를 판단할 수있어야 합니다.
출시예정일이 다가올수록 여러분은 새로운 개발이나 신규 content 보다는 발견될 버그들에 더욱 집중해야 합니다.
현재 버그를 가지고 있는 어떤 feature가 있을 때, 해당 feature가 이번 버전에 꼭 포함되어야 하는 내용인가?
그렇다면 그 버그를 수정하는 데 얼마나 많은 시간이 필요할까?
문제가 되는 feature 자체를 cut 하거나 다음 버전으로 미룰 수는 없는가?
등등…
‘열심히’ 가 아니라 ‘현명하게’ 일하자!
누차 언급한 바와 같이 shipping과정은 상당히 고단한 작업이며, 여러분이 어떤 것들을 해 나가야 할 지 신중히 고려하지 않는다면 더욱 힘들어질 것입니다. 열심히(혹은 많이) 일하는 것 만으로 ‘어떤 버그나 문제를 수정할 지’, ‘어떤 것은 다음 기회로 미룰 지’, 그리고 ‘어떤 것을 버려야 할지’ 에 대해서 고민하는 것을 대신할 수는 없습니다.
SL은 어떤 버그수정과 변경작업을 진행해야 하는 지 선택해야 하고, 그러한 업무를 누구에게 할당할지에 대해서 지극히 신중하게 고려해야 합니다. 단지 아주 멋진 feature라고 해서 해당 feature가 가지고 있는 사소한 문제의 해결을 하려고 한주간이나 사용해 버리는 우를 범하지 않도록 하기 바랍니다.
일단은 게임의crash를 유발하는 버그부터 수정해야 합니다. 전적으로 여러분 게임의shipping 자체를 불가하게 만들 수 있는 버그부터 수정해야 합니다. 다른 팀 멤버들까지 자신의 버그를 수정하지 못하도록 방해하는 근원이 되는 버그부터 수정해야 합니다.
SL은 신속하게 올바른 결정을 내릴 수 있도록 각종 버그들을 categorize해야 합니다. 그에 대한적절한 category 레벨로는 ‘Must Fix’, ‘Severe’, ‘Medium’, ‘Minor’, ‘Zero’, ‘Deferred’ 정도면 적당할 것이라 생각합니다.
Shipping이 다가옴에 따라 SL은 드러나는 모든 버그들에 대해 신중하게 평가해야 합니다.
새롭게 이루어지는 모든 버그 수정 작업은 항상 그 만큼의 테스트 일거리와 일반적으로 더 많은버그들을 유발해 낸다는 점을 항상 명심하시기 바랍니다!
지금 여러분의 MOD가 출시까지 2주가 남은 상황이라고 가정해 보겠습니다. 현재 어떤 버그가발견 되었고, 해당 버그의 수정을 위해서는 누군가 약 3일의 작업을 해야 하며, 이 과정에서 대략 500줄 정도의 코딩이 필요한 상황이라면, 해당 부분의 feature를 버리거나(cut), 다음 버전으로 미루는 것 외에는 출시 일정을 맞출 방법이 없을 것 입니다. -_-+
3주 남았다! Content Locked
지금까지는 여러분의 목표는 모든 각각의 컨텐트가 완성되는 것이었어야 합니다. 이 얘기는 곧게임 code를 제외한 나머지 모든 content 들의 제작 및 수정이 완료 되었어야 한다는 것을 의미합니다.
모든 maps, models, textures, sounds, HUD arts, Launcher art, 등등의 모든 content들은 제작이 끝난 상태로 이미 SL의 master copy에 포함되어 있어야 합니다.
Shutting down
이 내용은 ‘5주 남았다!’ 섹션에서 이미 언급된 바 있지만, 지금 시점에서는 그 중요성이 더욱 더커지는 내용입니다. SL만이 유일하게 Master Copy에 손댈 수 있어야 하며, coder (이 역시 오직 SL로부터 버그 내용과 그 수정을 지시 받은 사람이어야 함)로부터 전달받은 bug fix들의 적용 여부를 결정할 수 있는사람이어야 합니다.
Playtesting
MOD는 매일 최소한 2시간이상 동안 플레이 테스트 되어야 하며, 앞으로 출시 되기까지의 기간동안 꾸준히 테스트를 진행해 줄 가능한 많은 인력이 필요합니다.
또한 현 시점에서는 내용이 무엇이건 게임에 중요한(major) 변경을 가하기에는 너무 늦었습니다. 모쪼록 그러한 시도는 꿈조차 꾸지 말기 바랍니다.
1주일 남았다! No last minute changes
SL은 변경이 필요한 모든 사안에 대해 평가해야 하며, 다음 버전으로 해당 변경을 미루어야 할지의 여부를 판단해야 합니다. 이 때 가장 확실한 판단 기준은 현재부터 이루어지는 모든 수정은 (심지어는 단 1줄의 코드 변경일지라도…) 출시 예정일을 2일씩 지연시킨다고 생각하면 정확할 것 입니다.
Two day safe period
이제 반드시 고쳐야 했던 버그들은 모두 수정이 된 상태이고, 여타의 것들은 다음 버전으로 미루기로 결정했습니다. 그러나 아직 모든 게 끝난 것이 아니며, 앞으로 적어도 2일간의 빡센 테스트과정에서 버그가 발견되지 않아야 합니다.
가능한 모든 사람을 동원하여 48시간 동안 미친 듯이 테스트를 진행하고, 이 과정에서 버그가발견된다면, 수정하고 다시 새롭게 48시간의 테스트를 반복하기 바랍니다.
이런 48시간의 heavy test 과정을 반복하는 동안 여러분의 MOD로부터 어떤 새로운 버그도 발견되지 않는다면 이제 비로소 “Ready to Release’ 버전을 확보하게 된 것입니다!
출시 이후…
드디어 여러분의 MOD가 출시 되었고, 사람들이 여러분의 게임을 즐기고 있으며, 수 많은 웹 페이지에서 여러분의 MOD가 얼마나 재미있는가에 대해 얘기들을 하고 있습니다.
자! 이제 여기서 개발을 마칠 것인지의 여부는 전적으로 여러분에게 달려있습니다. 그간 우리의경험에 의하면 online multiplayer field상에서 support가 지속되는 MOD만이 꾸준히 인기를 유지하고 있습니다.
아무리 잘 만들어진 MOD라 할 지라도, 첫 버전으로 수 많은 유저를 확보하기는 곤란하며, 신규content 와 버그수정, 그리고 커뮤니티를 지원하는 새로운 update가 지속적으로 이루어지는 경우에만 플레이어 수는 꾸준히 늘어나게 됩니다.
Counter-Strike나 Team Fortress와 같은 게임들 역시도 처음에는 매우 작은 크기로 시작했으나,시간을 두고 성장해 나갔습니다. 매번 그들이 새로운 버전을 release할 때 마다, 보다 많은 새로운 사람들이 플레이를 시도했으며, 결국엔 열혈 유저들이 되었습니다.
어떤 것을 수정해야 하고, 무엇을 변경해야 하며, 커뮤니티로부터 어떤 것들에 귀 기울여야 할지를 알아가는 것은 시간을 두고 꾸준히 배워나가야 하는 문제입니다.
여러분의 행운을 빕니다!
댓글 없음:
댓글 쓰기