일단 의도의 설정. 디렉터의 업무라고 정의한 바 있지만, 그렇다고 또 디렉터가 독고다이로 할 필요까지는 없는 일. 개발팀원들의 도움을 받을 수 있는 일이다. (물론 최종 결정은 디렉터가 함미다.)

그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.

아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...

여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.

여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.

그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.

이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.

대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.

물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/

... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.

그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.

여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?

세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.

그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.

여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.

... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.

기획자 고유 업무이긴 하지만, 이걸 나 혼자 하지는 않는다. 역시 또 '논의'라는 놈이 끼어드는데...

애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.

그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?

물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.

스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.

역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.

다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.

기획자들이 흔히 내지르는 비명. '죽어라 문서를 만들어봤자 아무도 안읽어!'라는 것은... 사실 해결이 난해한 일이다.

당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)

그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?

어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.

공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.


기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.

3번과 똑같다. 물론 구현이 아니라 제작이니까, 양식이랄까 그런건 좀 달라지지만 기본적인 기조는 동일하다.

모든 것은 '우리'가 게임을 만들기 위하여.

이건 기획자가 독고다이로 하게 되는 일이지만, 어차피 이전 단계에서 충분한 논의가 전제되었다면 기획자가 독고다이로 한다 해서 딱히 문제될 것은 없다.

그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.

[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.

역시 기획자 고유 업무. 하지만 이 단계에서도 수많은 논의가 끼어들게 된다.

밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.

만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.

기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.

즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.

자 즐거운 테스트 시간이야. 물론 테스트 업무 자체의 주도는 QA와 기획자가 하게 마련이지만, 참여는 모든 팀원이 함께 한다.

그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.

뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.