'게임 기획자'에 해당되는 글 8건
[글강, 2009/02/06 00:06, Game]
아 영양가도 없고 쓰잘데기 없는 글이 넘 길었다. 8연작은 또 처음 해보네. 이제 좀 끝내자능.
게임 디자인이란 실로 모호한 일이다.
정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.
그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?
그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;
그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?
어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?
그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.
뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.
그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?
확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?
... 신념?
... 라고?
아니.
나는 바로 이 지점이 위험하다고 생각한다.
게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!
그 순간 기획자의 신념은 개발에 독이 된다.
이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.
아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?
아니.
그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.
그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?
아니.
게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.
그리하야 내가 내리는 결론은...
기획자는 프로세스를 먹고 살아야 한다는 것이다.
개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.
혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.
하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...
그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...
우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.
핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.
기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.
이 경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?
아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.
구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...
기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.
이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.
따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.
아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.
이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.
그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.
이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.
그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.
아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.
이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?
그렇기 때문에, 우리 팀이 현재 채택하고 있는...
...라는 프로세스가 나는 옳다고 생각한다.
프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.
이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?
아니.
이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.
드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.
아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.
최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.
무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.
마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.
그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.
남은 것은 '노예처럼 일하셈!!!' 뿐.
물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a
[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.
하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.
피식. 마지막은 또 용비어천가인가효.
뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-
언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?
'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'
... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.
쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/
게임 디자인이란 실로 모호한 일이다.
정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.
그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?
그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;
그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?
어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?
그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.
뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.
그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?
확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?
... 신념?
나는 내가 내린 판단을 믿어. 이것이 내 역량 내에서 내가 내린 최선의 판단이었다고 믿어. 이 디자인은 게임을 재미있게 만들어 줄거야. 믿자!
... 라고?
아니.
나는 바로 이 지점이 위험하다고 생각한다.
게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!
그 순간 기획자의 신념은 개발에 독이 된다.
이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.
아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?
아니.
그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.
그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?
아니.
게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.
그리하야 내가 내리는 결론은...
기획자는 프로세스를 먹고 살아야 한다는 것이다.
개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.
혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.
물론 말단 기획자 따위가 무슨 수로 개발 프로세스를 바꾸냐... 라고 하신다면 할 말 없음 ㄱ- 그래서 사실 이 부분은 디렉터 분들이 좀 신경 써주시면 감사하겠는데 말이졈 -ㅁ-
하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...
그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...
우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.
핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.
기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.
이 경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?
아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.
구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...
기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.
이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.
따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.
아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.
우리가 만드는 게임을 위하여 과연 무엇이 최선의 길이고 - 궁극적으로는 최상의 재미를 이끌어낼 수 있는 길인가?
이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.
그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.
이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.
그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.
아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.
이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?
그렇기 때문에, 우리 팀이 현재 채택하고 있는...
누구에게도 결정을 전담시키지 않고 논의를 통해 결정한다.
다양한 통로를 통하여 끊임없이 개발팀 내에서 공유하고 공유하며 또 공유한다.
다양한 통로를 통하여 끊임없이 개발팀 내에서 공유하고 공유하며 또 공유한다.
...라는 프로세스가 나는 옳다고 생각한다.
프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.
이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?
아니.
이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.
드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.
아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.
최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.
무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.
마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.
그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.
남은 것은 '노예처럼 일하셈!!!' 뿐.
물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a
[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.
하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.
피식. 마지막은 또 용비어천가인가효.
뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-
언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?
'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'
... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.
쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/
|
Trackback Address :: http://glekang.com/trackback/345
|
[글강, 2009/02/05 00:14, Game]
게임 기획자가 뭐하는 놈들인지에 대한 질문에서부터 시작하야... 이제는 무슨 프로세스 이야기를 하고 있나효. 삼천포도 이런 삼천포가 업ㅂ는... ㄱ-
하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)
그러므로 다시 전진~
NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.
물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...
추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.
뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.
혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.
그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?
그렇지는 않다고 생각한다.
이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.
1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.
2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.
3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.
4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.
5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.
... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...
글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a
그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.
1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.
2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?
3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)
4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?
에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;
또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;
... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;
그래도 이제 남은건 결론 뿐이다.
게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.
그럼 마지막 글에서 ( '')
하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)
그러므로 다시 전진~
NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.
집단 창작으로 게임은 만들어 지지 않는다.
게임은 민주적으로 만들어 지지 않는다.
게임은 민주적으로 만들어 지지 않는다.
물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...
추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.
뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.
혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.
그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?
그렇지는 않다고 생각한다.
이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.
1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.
이건 뭐 너무나도 당연한 이야기. 이게 흔들리면 배가 산으로, 하늘로, 안드로메다로 날아간다.
2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.
즉 결정을 위한 논의 과정에서는 디렉터조차도 결국 한 사람의 발언자 지위에 머물러야 하며, 권위에 의한 압박이 없어야만 한다. 더불어 서로에 대한 정치적 배려(?)를 기반으로 한 타협같은건 애초에 존재하지도 말아야 한다. 그리하야... 쪼까 과장을 섞어보자면 이런 양상이 만들어져야 한다.
...
... 어랏 적어놓고 보니 되게 소모적이네? ㄲㄲㄲ 하지만 나무를 보지 말고 숲을 보시라능.
저런 논의를 거치고 거치면서, 치열하게 치고 받으며 결정하되 절대 '타협'은 하지 않는다. 그렇다고 쓸데없는 고집을 피우지도 않으면서, 가장 합리적이고 최적화된 결론을 도출하기 위하여, 자칫 산으로 가버리는 배를 모두가 끌어내리면서 집중한다. 그리고 결국 최종 결정은 디렉터가 하며, 여기에 대해서는 이의를 제기하지 않는다.
다행히 지금까지 '절대 아니라고 생각하지만 디렉터가 까라고 하니까 깐다 내 참 더러워서'라는 상황은 발생하지 않았다. 모호하게 구부러지며 타협하는 상황 역시 발생하지 않았다. 그리고 이런 추세라면 앞으로도 발생하지 않을 듯 싶고... 애초에 나라는 인간부터가 까란다고 곱게 깔 생각이 없기 때문에 ( '')
디렉터 : 이런 아이디어 죽이지 않아?
개발자A : 당신 바보야?
개발자B : 당신 바보지?
디렉터 : 아놔 이러저러해서 끝내주잖아!
개발자A : 아놔 요로조로해서 말도 안되자늠!
개발자B : 아놔 이리저리하면 말은 되겠지만 역시 해괴한데?
디렉터 : 어 그럼 이리저리하면서 요로조로한 문제를 해결하면 의도에도 부합하게 되지 않나?
개발자A : 아니 그보다는 이러쿵 저러쿵한 쪽이 더 낫지 않아?
개발자B : 당신 바보야?
디렉터 : 당신 바보지?
개발자A : 당신 바보야?
개발자B : 당신 바보지?
디렉터 : 아놔 이러저러해서 끝내주잖아!
개발자A : 아놔 요로조로해서 말도 안되자늠!
개발자B : 아놔 이리저리하면 말은 되겠지만 역시 해괴한데?
디렉터 : 어 그럼 이리저리하면서 요로조로한 문제를 해결하면 의도에도 부합하게 되지 않나?
개발자A : 아니 그보다는 이러쿵 저러쿵한 쪽이 더 낫지 않아?
개발자B : 당신 바보야?
디렉터 : 당신 바보지?
...
... 어랏 적어놓고 보니 되게 소모적이네? ㄲㄲㄲ 하지만 나무를 보지 말고 숲을 보시라능.
저런 논의를 거치고 거치면서, 치열하게 치고 받으며 결정하되 절대 '타협'은 하지 않는다. 그렇다고 쓸데없는 고집을 피우지도 않으면서, 가장 합리적이고 최적화된 결론을 도출하기 위하여, 자칫 산으로 가버리는 배를 모두가 끌어내리면서 집중한다. 그리고 결국 최종 결정은 디렉터가 하며, 여기에 대해서는 이의를 제기하지 않는다.
... 넵. 대신 곱게 최종 결정을 내리도록 가만 놔두질 않는거졈 ( '')
다행히 지금까지 '절대 아니라고 생각하지만 디렉터가 까라고 하니까 깐다 내 참 더러워서'라는 상황은 발생하지 않았다. 모호하게 구부러지며 타협하는 상황 역시 발생하지 않았다. 그리고 이런 추세라면 앞으로도 발생하지 않을 듯 싶고... 애초에 나라는 인간부터가 까란다고 곱게 깔 생각이 없기 때문에 ( '')
3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.
이게 되게 중요하면서도 쉽지 않은 부분이기는 한데... 뭐랄까 다행히 우리 팀의 구성원들은 다들 사회 생활을 꽤 오래 경험한 고령자(-_-)들이 많은지라, 나름 프로페셔널하고 쿨하다.
더불어 대부분의 팀원들이 이미 예전 프로젝트부터 함께 일하던 이들인지라... 협업 경험이 보통 3~4년 이상씩은 훌쩍 넘어가는 팀. 서로를 어떻게 긁어대면 되는지를 잘 알고 있다 ㄲㄲㄲ
이건 사실 그냥 우리 팀이 가지고 있는 행운이 아닐까 싶기도.
더불어 대부분의 팀원들이 이미 예전 프로젝트부터 함께 일하던 이들인지라... 협업 경험이 보통 3~4년 이상씩은 훌쩍 넘어가는 팀. 서로를 어떻게 긁어대면 되는지를 잘 알고 있다 ㄲㄲㄲ
이건 사실 그냥 우리 팀이 가지고 있는 행운이 아닐까 싶기도.
4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.
즉 '우리'가 게임을 만들어 나간다는 비전에 모두가 공감대를 형성하고 있어야 한다. 그렇지 않으면 아무리 게임 디자인을 공유하고 오만 난리를 피워도... 애초에 응할 마음이 없는 사람에게는 하등 소용이 없기 때문.
다행히 우리 팀의 구성원들은 대부분 게임 바닥에서 꽤 오래 구른 분들인지라 (이제 개발 경력이 5년 정도 되는 내가 막내뻘), 그리고... 안타까운 일이지만 고생은 고생대로 하고서는 결국 게임을 말아먹은 경험을 함께 공유하고 계시는 분들인지라 ㄱ- 저 기조의 중요성을 뼈저리게 인지하고 있는 듯 싶다.
더불어 이는 2번에서의 논의가 자칫 소모적인 양상으로 빠지는 위험을 해소하는 데에도 도움을 준다. 다들 짬밥이 좀 되니까 -ㅅ- 말같잖은 뻘소리는 애초에 잘 나오지 않는다.
이것도 3번과 더불어 그냥 우리 팀이 가지고 있는 행운인 듯 싶다능.
다행히 우리 팀의 구성원들은 대부분 게임 바닥에서 꽤 오래 구른 분들인지라 (이제 개발 경력이 5년 정도 되는 내가 막내뻘), 그리고... 안타까운 일이지만 고생은 고생대로 하고서는 결국 게임을 말아먹은 경험을 함께 공유하고 계시는 분들인지라 ㄱ- 저 기조의 중요성을 뼈저리게 인지하고 있는 듯 싶다.
더불어 이는 2번에서의 논의가 자칫 소모적인 양상으로 빠지는 위험을 해소하는 데에도 도움을 준다. 다들 짬밥이 좀 되니까 -ㅅ- 말같잖은 뻘소리는 애초에 잘 나오지 않는다.
이것도 3번과 더불어 그냥 우리 팀이 가지고 있는 행운인 듯 싶다능.
5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.
'개발자가 자신이 만드는 게임에 대해 파악하는 것, 그리고 자신이 속한 개발팀의 현재 상황을 아는 것'은 당연히 필요한 일이고 매우 중요한 일이다... 라지만 이거이 생각처럼 쉽게 달성되는 것은 또 아니다.
'개발자라면 당연히 저런 자세를 가져야 하지 않아?'라고 말하기는 쉽겠지만, 애초에 개발팀 내에 이러한 리마인드를 지속적으로 해주는 프로세스가 갖추어져 있지 않으면서 그냥 강요만 한다면... 결국은 죽도 밥도 아니될 뿐.
따라서 개발 프로세스 내에 이를 위한 자원 혹은 일정을 정기적으로 마련해야 하고, 그 외에도 개발 현황판 등의 시각적 요소를 통한 리마인드 역시 필요하다.
주의할 점은... 현황판은 아날로그여야 한다는 점. 흔히 디지털 - 보통 웹을 통한 - 이 아무래도 더 깔끔하고 업데이트 및 공유, 관리하기에 편하다는 생각을 할 수 있는데... 그러나 디지털은 아날로그에 비해 접근성이 떨어진다. 웹을 통한 액세스가 모든 이에게 편리할 것이라는 생각은 편견임. (특히 고령자들에게... 어머나 내가 무슨 말을...)
그래서 우리 팀은... 뭐 정기적인 팀 회의를 일단 기본적인 공유의 시간으로 활용하고 있으며, 현황판은... 넵. 와보신 분들은 아시겠지만 우리 사무실 벽면을 온통 덕지덕지 뒤덮고 있지효 -ㅅ-
'개발자라면 당연히 저런 자세를 가져야 하지 않아?'라고 말하기는 쉽겠지만, 애초에 개발팀 내에 이러한 리마인드를 지속적으로 해주는 프로세스가 갖추어져 있지 않으면서 그냥 강요만 한다면... 결국은 죽도 밥도 아니될 뿐.
따라서 개발 프로세스 내에 이를 위한 자원 혹은 일정을 정기적으로 마련해야 하고, 그 외에도 개발 현황판 등의 시각적 요소를 통한 리마인드 역시 필요하다.
주의할 점은... 현황판은 아날로그여야 한다는 점. 흔히 디지털 - 보통 웹을 통한 - 이 아무래도 더 깔끔하고 업데이트 및 공유, 관리하기에 편하다는 생각을 할 수 있는데... 그러나 디지털은 아날로그에 비해 접근성이 떨어진다. 웹을 통한 액세스가 모든 이에게 편리할 것이라는 생각은 편견임. (특히 고령자들에게... 어머나 내가 무슨 말을...)
그래서 우리 팀은... 뭐 정기적인 팀 회의를 일단 기본적인 공유의 시간으로 활용하고 있으며, 현황판은... 넵. 와보신 분들은 아시겠지만 우리 사무실 벽면을 온통 덕지덕지 뒤덮고 있지효 -ㅅ-
... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...
글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a
그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.
1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.
... 프로토타이핑에만 1년 가까이 쓴거 같은데 말이졈. 그 과정에서 참... 오래오래 징하게도 싸웠다능.
그렇다고 지금 실개발 단계에서는 또 안싸우느냐, 그럴리가효.
즉 아무래도 논의 베이스이다 보니, 뭐 하나 결정하는 데에도 논의 - 논쟁 - 논의 - 논쟁 왔다갔다... 적잖은 시간을 소모한다.
뭐 하지만 아직은 이러한 시간 소모가 오히려 긍정적이라고 생각된다. 섣부른 개발보다는 이렇게 신중한 개발을 진행하는 것이 - 그리고 거기에 소요되는 시간은 정당하게 지출되는 비용이라 생각하는 것이 맞는 듯.
다만 추후에... 대중에게 게임을 공개하는 시점을 넘어서게 되면, 이제는 시간을 우리 마음대로 쓰지 못하는 상황이 '반드시' 닥쳐오게 될 것이다. 그 때엔 인해전술로 쏟아져 나올 다양한 이슈에 대하여 어떻게 기민한 대처를 할 수 있도록 프로세스를 재정립할 것인가...
이거이 우리에게 남아있는 숙제랄까.
그렇다고 지금 실개발 단계에서는 또 안싸우느냐, 그럴리가효.
즉 아무래도 논의 베이스이다 보니, 뭐 하나 결정하는 데에도 논의 - 논쟁 - 논의 - 논쟁 왔다갔다... 적잖은 시간을 소모한다.
뭐 하지만 아직은 이러한 시간 소모가 오히려 긍정적이라고 생각된다. 섣부른 개발보다는 이렇게 신중한 개발을 진행하는 것이 - 그리고 거기에 소요되는 시간은 정당하게 지출되는 비용이라 생각하는 것이 맞는 듯.
다만 추후에... 대중에게 게임을 공개하는 시점을 넘어서게 되면, 이제는 시간을 우리 마음대로 쓰지 못하는 상황이 '반드시' 닥쳐오게 될 것이다. 그 때엔 인해전술로 쏟아져 나올 다양한 이슈에 대하여 어떻게 기민한 대처를 할 수 있도록 프로세스를 재정립할 것인가...
이거이 우리에게 남아있는 숙제랄까.
2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?
100%라고 한다면 물론 거짓말. 팀 전체에게 공유되는 부분은 아무래도 각종 어셋들의 header 정도이다. 세부 항목까지 모두 공유했다가는... 공유하는 데에만 시간을 다 쓸테니 ㄱ- 사실 그렇게까지 필요하지는 않고.
(예를 들자면 나는 우리 게임에 림 라이트가 대충 어떻게 사용된다... 라는 정도까지만 알 뿐, 그래서 구체적인 세팅은 어떻게 하나효... 뭐 이런 부분에 대해서는 그냥 모른다 -ㅁ- 거기까지 내가 알아야 함? AD와 TD를 믿읍시다 -ㅁ- 다만 내 눈에 영 이상하게 보인다면 용감무식하게 '때깔이 이상하자늠?'이라는 의견은 손쉽게 낼 수 있어야 하는거고)
그리고 인간이란 망각의 동물인지라, 아무래도 자신의 직군과 직접 연계되지 않는 부분에 대해서는 공유받는다 할지라도 시간이 좀 지나면 쉽사리 까먹게 된다. 아니 이건 자연스러운 일이니 뭐라 할 수 없다.
그럼에도 불구하고 한 번이나마 이야기를 들었던 사안은, 추후 리마인드할 때 기억을 떠올리기가 상대적으로 수월하기 때문에... 이거이 딱히 문제가 된 적은 없다.
다만 잠재적인 리스크는, 나중에 게임 어셋의 수가 지금보다 훨씬 더 많아지고, 복잡성이 증대되었을 때에도 지금과 같은 긍정적인 상황을 유지할 수 있을 것인가... 으음... 잘 모르겠다.
(예를 들자면 나는 우리 게임에 림 라이트가 대충 어떻게 사용된다... 라는 정도까지만 알 뿐, 그래서 구체적인 세팅은 어떻게 하나효... 뭐 이런 부분에 대해서는 그냥 모른다 -ㅁ- 거기까지 내가 알아야 함? AD와 TD를 믿읍시다 -ㅁ- 다만 내 눈에 영 이상하게 보인다면 용감무식하게 '때깔이 이상하자늠?'이라는 의견은 손쉽게 낼 수 있어야 하는거고)
그리고 인간이란 망각의 동물인지라, 아무래도 자신의 직군과 직접 연계되지 않는 부분에 대해서는 공유받는다 할지라도 시간이 좀 지나면 쉽사리 까먹게 된다. 아니 이건 자연스러운 일이니 뭐라 할 수 없다.
그럼에도 불구하고 한 번이나마 이야기를 들었던 사안은, 추후 리마인드할 때 기억을 떠올리기가 상대적으로 수월하기 때문에... 이거이 딱히 문제가 된 적은 없다.
다만 잠재적인 리스크는, 나중에 게임 어셋의 수가 지금보다 훨씬 더 많아지고, 복잡성이 증대되었을 때에도 지금과 같은 긍정적인 상황을 유지할 수 있을 것인가... 으음... 잘 모르겠다.
3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)
... 즉 바꿔 말하자면 일단 신입은 살아남기 힘든 구조이다 -ㅅ- 프로세스가 개발자에게 '우리는 이런 게임을 만들거등. 너 이거 다 알아야 해. 하지만 자세한 설명은 생략한다. 대충 말해도 다 알아듣겠지?'라는 부분을 계속 강요(?)하는 구조이기 땜시...
더불어 누군가 일을 던져주는 수동적인 프로세스가 아니라, 능동적으로 개발의 흐름을 지속적으로 조망하며 자신의 일을 찾아서 해야 하는 구조이기 때문에... 팀원에게 요구되는 능동성의 수준이 높다. 양날의 검이랄까? 이 흐름에 맞추어 잘하면 당연히 좋지만, 잘 못하는 경우에는... 으음 이럴 땐 또 가차없죠 -ㅅ-
그나마 다들 닳고 닳은(?) 경력자들이고, 또 대부분 파트장급 이상 출신들이 많은지라 이런 프로세스를 돌릴 수 있는 것이 아닐까?
그리고 더불어... 사실 이건 난 잘 모르겠는 부분이긴 한데, 이러한 프로세스는 개발자로 하여금 끝없는 자기 성찰(?)을 요구하고, 그만큼 또 강한 스트레스를 유발시키는 듯 싶다.
... 나야 '내 역량이 모자른다 싶으면 자르시등가. 거기까지가 내 한계인갑지. 어쩔라미?'라는 뻔뻔한 배째라 정신으로 무장하고 있기 때문에 잘 모르겠는데 -ㅅ-;;;, 몇몇 이들은 일이 자신에게 요구하는 수준을 자신이 충족시키지 못하고 있다는 생각에 괴로워하는 모습을 보이곤 한다.
으음... 내가 보기엔 다들 잘하고 있는 것 같은데 -ㅁ- 일헌 자기 자신에게 지나치게 엄격한 살암들 같으니 ;;;
아무튼 그런 문제가 있는 것... 같다.
더불어 누군가 일을 던져주는 수동적인 프로세스가 아니라, 능동적으로 개발의 흐름을 지속적으로 조망하며 자신의 일을 찾아서 해야 하는 구조이기 때문에... 팀원에게 요구되는 능동성의 수준이 높다. 양날의 검이랄까? 이 흐름에 맞추어 잘하면 당연히 좋지만, 잘 못하는 경우에는... 으음 이럴 땐 또 가차없죠 -ㅅ-
그나마 다들 닳고 닳은(?) 경력자들이고, 또 대부분 파트장급 이상 출신들이 많은지라 이런 프로세스를 돌릴 수 있는 것이 아닐까?
그리고 더불어... 사실 이건 난 잘 모르겠는 부분이긴 한데, 이러한 프로세스는 개발자로 하여금 끝없는 자기 성찰(?)을 요구하고, 그만큼 또 강한 스트레스를 유발시키는 듯 싶다.
... 나야 '내 역량이 모자른다 싶으면 자르시등가. 거기까지가 내 한계인갑지. 어쩔라미?'라는 뻔뻔한 배째라 정신으로 무장하고 있기 때문에 잘 모르겠는데 -ㅅ-;;;, 몇몇 이들은 일이 자신에게 요구하는 수준을 자신이 충족시키지 못하고 있다는 생각에 괴로워하는 모습을 보이곤 한다.
으음... 내가 보기엔 다들 잘하고 있는 것 같은데 -ㅁ- 일헌 자기 자신에게 지나치게 엄격한 살암들 같으니 ;;;
아무튼 그런 문제가 있는 것... 같다.
실제로 이로 인해 뼈아픈 손실도 몇 번 있었고 크흑 ;ㅁ;
4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?
사실 이거이 가장 아리까리한 부분인데... 20여명 정도의 중규모 팀에서는 이러한 프로세스를 운영하는 데에 별반 문제가 발생하지 않는다.
하지만 개발 인원이 5~60명, 혹은 수백명인 경우에도... 과연 이런 프로세스를 적용하는 것이 가능할까?
사실 [5번 글]에서 언급한 3번째 프로세스의 문제가 발생한 원인 중의 하나는 인원이 통제하기 힘들 정도로 많았다는 점이 아니었을까 싶다.
당장 손쉽게 생각할 수 있는 것은 역시 공유 자체의 난점. 직접 공유는 힘들고 간접 공유 체제를 만들어야 하지 않을까... 그 경우에 과연 이만큼의 효과를 기대할 수 있을까...?
이 부분을 잘 모르겠다. 이 프로세스는 과연 범용적일까? 대규모 인원에 대해서는 무언가 다른 방도를 찾아야하지 않을까?
... 뭐 당장 우리 개발팀에게는 별반 문제가 되지 않는 부분이지만, 그럼에도 불구하고 프로세스 자체에 대한 탐구로써, 이 부분은 여전히 의문으로 남는다.
하지만 개발 인원이 5~60명, 혹은 수백명인 경우에도... 과연 이런 프로세스를 적용하는 것이 가능할까?
사실 [5번 글]에서 언급한 3번째 프로세스의 문제가 발생한 원인 중의 하나는 인원이 통제하기 힘들 정도로 많았다는 점이 아니었을까 싶다.
당장 손쉽게 생각할 수 있는 것은 역시 공유 자체의 난점. 직접 공유는 힘들고 간접 공유 체제를 만들어야 하지 않을까... 그 경우에 과연 이만큼의 효과를 기대할 수 있을까...?
이 부분을 잘 모르겠다. 이 프로세스는 과연 범용적일까? 대규모 인원에 대해서는 무언가 다른 방도를 찾아야하지 않을까?
... 뭐 당장 우리 개발팀에게는 별반 문제가 되지 않는 부분이지만, 그럼에도 불구하고 프로세스 자체에 대한 탐구로써, 이 부분은 여전히 의문으로 남는다.
그래서 난 대규모 팀에 속해 있으면서, 대규모에 걸맞는 프로세스가 어떻게 구축되고 운영되는지를 알려주는 산업 스파이가 필요하...
에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;
또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;
... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;
그래도 이제 남은건 결론 뿐이다.
게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.
그럼 마지막 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/344
|
[글강, 2009/02/04 00:18, Game]
이건 뭐 재미도 없고 감동도 없는 글이 쓰잘데기 없이 길기만 욜라리 길어서리 벌써 6번일세 ㄱ-
이 즈음 해서 잠시 정리 좀.
[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.
[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.
[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-
[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.
[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...
그래서 이제 6번부터는...
기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.
넵. 저는 그게 개발 프로세스라고 생각해효.
그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?
그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.
그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.
그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.
지금까지 내가 경험해 본 개발 프로세스는 총 4가지.
사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.
[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)
암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.
그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...
물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...
그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.
자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
우와... 이게 뭐야.
적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-
아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)
당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.
그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.
하지만 이미 스크롤 압뷁 ㄱ-
... 7번으로 넘어가야 겠네효.
이 즈음 해서 잠시 정리 좀.
[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.
[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.
[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-
[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.
[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...
그래서 이제 6번부터는...
기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.
넵. 저는 그게 개발 프로세스라고 생각해효.
그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?
... 와 이렇게까지 이야기하니 뭔가 좀 무서운데 -ㅁ-;
그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.
그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.
그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.
지금까지 내가 경험해 본 개발 프로세스는 총 4가지.
사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.
[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)
암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.
그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...
물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...
그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.
자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
일단 의도의 설정. 디렉터의 업무라고 정의한 바 있지만, 그렇다고 또 디렉터가 독고다이로 할 필요까지는 없는 일. 개발팀원들의 도움을 받을 수 있는 일이다. (물론 최종 결정은 디렉터가 함미다.)
그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.
아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...
여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.
여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.
그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.
이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.
대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.
물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/
... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.
그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.
여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?
세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.
그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.
여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.
... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.
그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.
아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...
여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.
여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.
그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.
이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.
대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.
물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/
... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.
그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.
여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?
세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.
그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.
여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.
... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자 고유 업무이긴 하지만, 이걸 나 혼자 하지는 않는다. 역시 또 '논의'라는 놈이 끼어드는데...
애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.
그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?
물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.
스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.
역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.
다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.
애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.
그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?
물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.
스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.
역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.
다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
기획자들이 흔히 내지르는 비명. '죽어라 문서를 만들어봤자 아무도 안읽어!'라는 것은... 사실 해결이 난해한 일이다.
당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)
그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?
어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.
공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.
기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.
당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)
그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?
어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.
공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.
... 물론 기획자가 특출난 문서 작성 능력을 발휘하야 가독성 높은 정리를 해주신다면 더욱 금상첨화이겠지만, 내가 그렇게 잘 하고 있는 것인지는 알 수 없으니 패스 ( --) 딱히 불만을 표출하시지는 않던데 말이졈 ㄷㄷㄷ
기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
3번과 똑같다. 물론 구현이 아니라 제작이니까, 양식이랄까 그런건 좀 달라지지만 기본적인 기조는 동일하다.
모든 것은 '우리'가 게임을 만들기 위하여.
모든 것은 '우리'가 게임을 만들기 위하여.
5. 어셋 구현 후에는... 리소스들의 조립.
이건 기획자가 독고다이로 하게 되는 일이지만, 어차피 이전 단계에서 충분한 논의가 전제되었다면 기획자가 독고다이로 한다 해서 딱히 문제될 것은 없다.
그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.
[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.
그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.
[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
역시 기획자 고유 업무. 하지만 이 단계에서도 수많은 논의가 끼어들게 된다.
밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.
만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.
기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.
즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.
밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.
만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.
기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.
즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
자 즐거운 테스트 시간이야. 물론 테스트 업무 자체의 주도는 QA와 기획자가 하게 마련이지만, 참여는 모든 팀원이 함께 한다.
그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.
뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.
그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.
뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.
우와... 이게 뭐야.
적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-
적는 내가 다 부끄러워서 손발이 오그라드네 ;;;
아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)
당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.
그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.
하지만 이미 스크롤 압뷁 ㄱ-
... 7번으로 넘어가야 겠네효.
|
Trackback Address :: http://glekang.com/trackback/343
|
[글강, 2009/02/03 00:25, Game]
이제 슬슬 삼천포야 ㄱ-
뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')
이번엔 다른 관점에서 한 번 접근해 보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?
개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.
이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.
이제는 좀 지겨운 ;;; 7단계 다시 시작.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!
이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.
즉, 재미 창출의 전문가처럼 보이게 되는 것이다.
더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.
사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...
그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.
그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?
과연?! 퍽이나?!
게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?
물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.
코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.
그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?
자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?
글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.
그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?
글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.
혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...
내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.
등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.
수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;
더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...
이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.
게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.
혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.
어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.
결론을 내려 보자면...
기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,
기획자가 아무리 열심히 일을 잘 한다 할지라도,
개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,
이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,
기계적으로 일을 하게끔 만들어,
필연적으로(!) 수많은 문제를 야기하게 되고,
그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,
최종적으로는 게임의 성공 가능성을 깎아먹게 된다.
... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;
... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.
'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'
기획자 무용론에 동참하셨군효 /박수
자아, 다시 처음으로 돌아가보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.
역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;
게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.
저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.
그럼에도 불구하고...
그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?
위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?
그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?
... 논리적으로만 보자면 그리 부당하지 않아 보이는데?
하아...? 잠깐만.
그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?
그럼 기획자라는걸 다 치워버리면 괜찮은건가?
하지만 기획자들을 다 치워버린 상황을 상정해 보자면...
[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.
그럼 무엇이 문제인가?
... 이미 충분히 길다. 다음 글로.
다음 글의 힌트.
저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?
뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')
이번엔 다른 관점에서 한 번 접근해 보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?
개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.
이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.
이제는 좀 지겨운 ;;; 7단계 다시 시작.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
여전히 의도는 디렉터가 설정하지만, 의도를 달성하기 위한 아이디어를 기획자'만' 내고, 기획자들끼리'만' 이 아이디어에 대해 논의한다. 뭐 디렉터가 여기 참여할 수는 있겠다만...
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자'만' 게임 디자인을 한다. 즉 다른 직군과의 소통 없이 기획자 독고다이로.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
기획자 혼자서 작성한 구현 스펙을 '일방적으로' 프로그래머에게 전달한다. 프로그래머 입장에서는 이 스펙은 뜬금없이 떨어진 일이 되고, 게임
어셋의 전후 맥락을 파악하지 못한 상황에서 '기계적으로' 구현만 하게 된다. 물론 상호 논의를 통해 스펙을 수정하는 가운데
일방성이 조금 완화될 수는 있지만, 프로그래머가 맥락에서 소외되어 있다는 점은 여전히 변하지 않는다.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
기획자 혼자서 작성한
리소스 제작 명세를 '일방적으로' 아티스트에게 전달한다. 아티스트 입장에서는 이 명세는 뜬금없이 떨어진 일이 되고, 게임 어셋의
전후 맥락을 파악하지 못한 상황에서 '기계적으로' 제작만 하게 된다. 물론 상호 논의를 통해 명세를 수정하는 가운데 일방성이
조금 완화될 수는 있지만, 아티스트가 맥락에서 소외되어 있다는 점은 여전히 변하지 않는다.
5. 어셋 구현 후에는... 리소스들의 조립.
게임 어셋의 조립을 기획자'만' 한다.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
밸런싱을 기획자'만' 한다.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
테스트 및 검증을 QA와 기획자'만' 한다. 뭐 사람이 부족하면 다른 팀원들을 테스트에 참여시킬 수는 있겠다만, 검증해야 할 지점의 설정이나 피드백은 오직 기획자'만'.
요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!
이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.
즉, 재미 창출의 전문가처럼 보이게 되는 것이다.
더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.
사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...
그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.
그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?
과연?! 퍽이나?!
게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?
물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.
코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.
그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?
자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?
글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.
그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?
글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.
혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...
내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.
기획자 : 고민에 고민을 거듭해서 디자인 문서를 완벽하게(?) 만들었는데 아무도 안읽어! 뭐 하나 구현하고 제작할 때마다 계속
사람들을 감독(!)해야 하다니 아놔! 게임 나 혼자 만드냐?! 왜 이렇게들 자신이 만드는 게임에 관심이 없어? 게임의 전체적인
상에 대해서 당연히 다들 파악하고 있어야 하는거 아냐?!
프로그래머 : 뭐 이런 해괴한 시스템이 다 있노? 아무래도 이건 일관성에 문제가 있는 것 같... 기는 한데, 뭐 다른 부분들과의 연계 때문에 어쩔 수 없이 이렇게 된 것일라나? 다른 시스템을 모르니 할 말이 없네...
그런데 나한테 갑자기 50페이지짜리 문서를 휙 던져주면서, 3중 4중으로 연결된 다른 문서들도 참고해가며 구현을 하라니 어이가 좀 상실된다능.
어 잠깐만, 이거 구현하려면 예전에 만들었던 알고리즘을 갈아엎어야 하잖아? 아니 지난번에 이거 구현할 때엔 나중에 이런게 나올거라는 이야기 안하더니만!!!
그런데 나한테 갑자기 50페이지짜리 문서를 휙 던져주면서, 3중 4중으로 연결된 다른 문서들도 참고해가며 구현을 하라니 어이가 좀 상실된다능.
어 잠깐만, 이거 구현하려면 예전에 만들었던 알고리즘을 갈아엎어야 하잖아? 아니 지난번에 이거 구현할 때엔 나중에 이런게 나올거라는 이야기 안하더니만!!!
아티스트 : 만들라고 하니까 만들기는 하겠지만, 대체 이것들이 우리 게임 어디에 들어가는거지? 어라 이렇게 만들면 비쥬얼
퀄리티가 확 떨어질텐데? 다른 부분에서 퍼포먼스를 잡아먹기 때문에 어쩔 수 없는건가? 다른 부분을 모르니 할 말이 없네...
그런데 뜬금없이 날아온 컨셉 문서가 50페이지 -_-a 다 읽다가 지친다.
어 잠깐만, 이렇게 제작하면 전반적인 비쥬얼 컨셉이랑 어긋나잖아? 음? 비쥬얼 컨셉보다는 기능성을 우선하기로 결정했다고? 언제? 난 몰랐는데? 그냥 까라면 까라는거냐!!!
그런데 뜬금없이 날아온 컨셉 문서가 50페이지 -_-a 다 읽다가 지친다.
어 잠깐만, 이렇게 제작하면 전반적인 비쥬얼 컨셉이랑 어긋나잖아? 음? 비쥬얼 컨셉보다는 기능성을 우선하기로 결정했다고? 언제? 난 몰랐는데? 그냥 까라면 까라는거냐!!!
등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.
수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;
더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...
이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.
게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.
혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.
어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.
결론을 내려 보자면...
기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,
기획자가 아무리 열심히 일을 잘 한다 할지라도,
개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,
이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,
기계적으로 일을 하게끔 만들어,
필연적으로(!) 수많은 문제를 야기하게 되고,
그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,
최종적으로는 게임의 성공 가능성을 깎아먹게 된다.
... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;
결국 기획자 잘못이니까 욕먹을 만 하다고? 글쎄.
... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.
'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'
결국 기획자 잘못이니까 그런 생각이 맞다고? 글쎄.
기획자 무용론에 동참하셨군효 /박수
자아, 다시 처음으로 돌아가보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.
역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;
게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.
글쎄. 나는 의문이 든다.
저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.
그럼에도 불구하고...
그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?
위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?
그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?
... 논리적으로만 보자면 그리 부당하지 않아 보이는데?
하아...? 잠깐만.
그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?
그럼 기획자라는걸 다 치워버리면 괜찮은건가?
하지만 기획자들을 다 치워버린 상황을 상정해 보자면...
[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.
그럼 무엇이 문제인가?
... 이미 충분히 길다. 다음 글로.
다음 글의 힌트.
저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?
|
Trackback Address :: http://glekang.com/trackback/342
|
[글강, 2009/02/02 00:04, Game]
쓰면 쓸수록 '내가 이 글을 왜 시작한거랍쇼'라는 생각이 들고 있기는 하지만 -_-a
뭐 그래도 솔직히 내 인생, 내 커리어의 지금 이 시점에서 내 생각은 이러하다.
... 라고 정리, 기록하는 의미 정도는 가질 수 있을테니 계속 용감무식무쌍하게 전진 -ㅁ-/
자 자, 개발 수순의 구간에서 기획자의 전문성이 드러나는 지점을 찾아보는 것은... 일단 2가지 정도 짚을 수는 있었지만, 그 2가지는 모호함의 경계가 너무나도 넓다는 정도로 결론 ㄱ-
그래서 결국 기획자가 대체 뭐하는 놈들인지에 대한 이야기는, 그나마 희뿌옇게 무언가 보이기는 하지만서도 그거이 뭔지는 모르겠는, 혹은 알지만 너무 넓어서 모르는 거나 마찬가지인 상황 ㄱ-
그러니 여전히 '이런 애매모호한 직군 따위 필요없어'에 대한 반박은 쉽지 않은 상황이다.
아놔 데꿀멍 함 하기 참 힘드네 (...)
그럼 이번에는 기획자를 함 없애보자.
기획자를 없애고도 개발이 매끄럽게 잘 진행된다고 예상된다면... 뭐 기획자 따위 별로 필요없는거졈 ㅋ
일단 기획이라는 일이 사라질 수는 없다. 기획 없는 개발이라는건... 설계도 안하고 건물을 냅다 짓겠다는 셈이니 말이 아니된다.
즉 기획자를 없앤다는 것은... 결국 기획 업무를 다른 직군이 맡는다는 뜻이 된다.
과연 어떤 일이 벌어질까요?
일단 개발은 여전히 7단계의 수순을 따라 진행된다고 가정해보자. [2번 글]에서도 언급한 바와 같이 저건 협업 체제 개발 수순으로도 얼마든지 치환할 수 있으니까.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
정리해 보자면... 우와... 기획자 없이도 어케어케 일이 되기는 하겠는데?
다만 크리티컬한 문제로 대두되는 부분은 '개발 효율'이 극도로 떨어질 가능성이 높다는 지점.
그럼 기획자는 개발 효율을 높이기 위해 존재하는 건가효...?
'잡부'라는 생각이 다시 고개를 들이밀기 시작하지만... -_-a
뭐 반장난스럽게 평가절하스러븐 단어를 사용한다 할지라도, 개발 효율이라는건 매우매우 무지무지 중요한 요소이므로, 기획자는 있는 편이 좋다! 라는 실로 알흠다운 결론이 나오는군요.
음헤헤. '나는 그냥 월급 도둑이란 말인가?'라는 존재론적인(?) 자학에 빠져 사표 쓸 필요는 없겠다 (...)
자 '기획자 따위 필요없어!'에 대한 대답은... 실로 대충 떼워막기로 해버린 듯 싶지만 암튼 어떻게 했다고 치자.
그런데 '기획자가 없다!'라고 가정을 해봤다면... 그 반대 급부에 대한 의문이 꼬리를 물고 나오는근염.
만약 기획자가 저 모든 걸 다 맡아서 해치운다면 과연 어떻게 될까?
호옹... 어떤 양상으로 흘러갈는지 벌써 감이 딱 오기는 하는데...
아마도 '기획자 따위 필요없어!'라는 주장을 아직 포기하고 싶지 않으신 분들이 기꺼워 할만한 내용으로 채워질...
다음 글에서 ( '')
뭐 그래도 솔직히 내 인생, 내 커리어의 지금 이 시점에서 내 생각은 이러하다.
... 라고 정리, 기록하는 의미 정도는 가질 수 있을테니 계속 용감무식무쌍하게 전진 -ㅁ-/
자 자, 개발 수순의 구간에서 기획자의 전문성이 드러나는 지점을 찾아보는 것은... 일단 2가지 정도 짚을 수는 있었지만, 그 2가지는 모호함의 경계가 너무나도 넓다는 정도로 결론 ㄱ-
그래서 결국 기획자가 대체 뭐하는 놈들인지에 대한 이야기는, 그나마 희뿌옇게 무언가 보이기는 하지만서도 그거이 뭔지는 모르겠는, 혹은 알지만 너무 넓어서 모르는 거나 마찬가지인 상황 ㄱ-
그러니 여전히 '이런 애매모호한 직군 따위 필요없어'에 대한 반박은 쉽지 않은 상황이다.
아놔 데꿀멍 함 하기 참 힘드네 (...)
그럼 이번에는 기획자를 함 없애보자.
기획자를 없애고도 개발이 매끄럽게 잘 진행된다고 예상된다면... 뭐 기획자 따위 별로 필요없는거졈 ㅋ
일단 기획이라는 일이 사라질 수는 없다. 기획 없는 개발이라는건... 설계도 안하고 건물을 냅다 짓겠다는 셈이니 말이 아니된다.
즉 기획자를 없앤다는 것은... 결국 기획 업무를 다른 직군이 맡는다는 뜻이 된다.
과연 어떤 일이 벌어질까요?
일단 개발은 여전히 7단계의 수순을 따라 진행된다고 가정해보자. [2번 글]에서도 언급한 바와 같이 저건 협업 체제 개발 수순으로도 얼마든지 치환할 수 있으니까.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
[3번 글]에서도 언급한 바와 같이... 의도의 설정은 애초에 디렉터라는 '직급'에서 해야 할 일이고, 아이디어의 제안은 기획자만 할 수 있는 일이 아니다. 적절한 상상력과 게임에 대한 이해력을 갖추고 있다면 누구라도(넵 물론 비개발자도) 할 수 있는 일이다.
물론 적절한 아이디어를 채택하기 위한 논의 진행은 해당 개발팀의 상황에 따라 양상이 많이 달라질 수 있으므로, 이건 개발팀에 소속된 개발자들이 진행하는 것이 맞겠지만... 그렇다고 꼭 기획자라는 직군이 그 논의 테이블에 존재해야 하는 것은 아니다.
... 그럼에도 불구하고 개발 중인 게임 전반을 통찰하고 있는 기획자가 이 논의에 참여하는 경우, 일은 조금 더 매끄럽게 진행될 수 있다.
이 정도일 듯.
물론 적절한 아이디어를 채택하기 위한 논의 진행은 해당 개발팀의 상황에 따라 양상이 많이 달라질 수 있으므로, 이건 개발팀에 소속된 개발자들이 진행하는 것이 맞겠지만... 그렇다고 꼭 기획자라는 직군이 그 논의 테이블에 존재해야 하는 것은 아니다.
... 그럼에도 불구하고 개발 중인 게임 전반을 통찰하고 있는 기획자가 이 논의에 참여하는 경우, 일은 조금 더 매끄럽게 진행될 수 있다.
이 정도일 듯.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자 고유의 업무! 근데 만약 기획자가 없다면?!
... 예측하건데 아마도 프로그래머 직군에서 이 일을 담당할 수 있지 않을까?
게임 디자인을 하기 위해서는 논리력이랄까, 게임의 공학적 구조에 대한 이해가 어느 정도 필요한데... 프로그래머는 이러한 소양을 이미 자기 직군의 기본 소양으로 가지고 있다.
그래서 프로그래머 출신의 기획자가 적지 않은 듯 싶기도 하지만, 암튼 저 기본 소양의 위에 경험이나 분석 능력 등이 덧대어 지기만 한다면 프로그래머는 충분히 게임 디자인을 할 수 있을 듯 싶다.
아티스트는? 글쎄... 이거이 좀 편견에 가까운데, 논리력이라면 모르겠지만 게임의 공학적 구조에 대한 소양은 아티스트의 기본 소양은 아닌 듯 싶어서, 아티스트에게 이걸 요구하는게 맞는건지 잘 모르겠다.
(다만 이거이 레벨 디자인이나 퀘스트 디자인의 영역으로 확장되면 센스가 반드시 필요해지는 부분이 있으니, 아티스트가 또 이런 센스는 발군일 듯도 싶고 -ㅅ-)
... 물론 그럼에도 불구하고 프로그래머는 비싼 몸. 디자인은 만만찮은 시간을 잡아먹는 일이고, 디자인된 시스템에 대한 지속적인 유지 보수가 꼭 필요하다. 프로그래머를 여기에 투입하는게 과연 '효율적'인가? 라고 한다면 좀 갸우뚱. 개발 효율이라는 측면에서 볼 때 이 일을 따로 맡는 이가 있는 쪽이 아무래도 나을 듯.
... 예측하건데 아마도 프로그래머 직군에서 이 일을 담당할 수 있지 않을까?
게임 디자인을 하기 위해서는 논리력이랄까, 게임의 공학적 구조에 대한 이해가 어느 정도 필요한데... 프로그래머는 이러한 소양을 이미 자기 직군의 기본 소양으로 가지고 있다.
그래서 프로그래머 출신의 기획자가 적지 않은 듯 싶기도 하지만, 암튼 저 기본 소양의 위에 경험이나 분석 능력 등이 덧대어 지기만 한다면 프로그래머는 충분히 게임 디자인을 할 수 있을 듯 싶다.
아티스트는? 글쎄... 이거이 좀 편견에 가까운데, 논리력이라면 모르겠지만 게임의 공학적 구조에 대한 소양은 아티스트의 기본 소양은 아닌 듯 싶어서, 아티스트에게 이걸 요구하는게 맞는건지 잘 모르겠다.
(다만 이거이 레벨 디자인이나 퀘스트 디자인의 영역으로 확장되면 센스가 반드시 필요해지는 부분이 있으니, 아티스트가 또 이런 센스는 발군일 듯도 싶고 -ㅅ-)
... 물론 그럼에도 불구하고 프로그래머는 비싼 몸. 디자인은 만만찮은 시간을 잡아먹는 일이고, 디자인된 시스템에 대한 지속적인 유지 보수가 꼭 필요하다. 프로그래머를 여기에 투입하는게 과연 '효율적'인가? 라고 한다면 좀 갸우뚱. 개발 효율이라는 측면에서 볼 때 이 일을 따로 맡는 이가 있는 쪽이 아무래도 나을 듯.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
넵. 프로그래머. 자기가 만들걸 자기가 직접 정리하는 거니까 오히려 훨씬 더 잘할는지도 (...)
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
넵. 아티스트. 역시 자기가 만들걸 자기가 직접 정리하는 거니까...
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
요이. 또 기획자의 고유 업무.
그러나 기획자가 없다면 이걸 누가 하지?
흔히 밸런싱이라 쓰고 '계산'이라 읽는 경우가 많으니 프로그래머가 적격일는지도... 하지만 뭐 여기에 쓰이는 계산이 딱히 거창한 것도 아니니 아티스트가 이걸 못할 이유도 없고...
그러니 각 직군에서 자신이 참여한 부분에 대한 밸런싱을 직접하는 방법도 생각해볼 수는 있다. 다만 이 경우에는 직교성이랄까 수치 스케일이랄까 그런 기준들을 잡기가 쉽지 않으니, 만만찮은 시행 착오와 밸런스가 안드로메다로 날아가고 귀환하는 일이 반복되는 비효율적인 흐름이 예상되는데...
그런 의미에서 그냥 깔끔하게 기획자가 다 맡아준다면 좀 낫기는 하겠다. 에... 근거는 역시 또 개발 효율인가효?
그러나 기획자가 없다면 이걸 누가 하지?
흔히 밸런싱이라 쓰고 '계산'이라 읽는 경우가 많으니 프로그래머가 적격일는지도... 하지만 뭐 여기에 쓰이는 계산이 딱히 거창한 것도 아니니 아티스트가 이걸 못할 이유도 없고...
그러니 각 직군에서 자신이 참여한 부분에 대한 밸런싱을 직접하는 방법도 생각해볼 수는 있다. 다만 이 경우에는 직교성이랄까 수치 스케일이랄까 그런 기준들을 잡기가 쉽지 않으니, 만만찮은 시행 착오와 밸런스가 안드로메다로 날아가고 귀환하는 일이 반복되는 비효율적인 흐름이 예상되는데...
그런 의미에서 그냥 깔끔하게 기획자가 다 맡아준다면 좀 낫기는 하겠다. 에... 근거는 역시 또 개발 효율인가효?
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
넵. 원래 QA의 업무임 ㄳ
근데 이 과정에서 애초에 디자인을 한 사람이 참여하지 않는다면 검증, 보정 참 힘들죠.
그러니까 이 부분 전담해 줄 디자이너가... 아 기획자 없애기로 했으니 전담할 사람이 없어져 버렸나?
뭐 없이도 어떻게 할 수는 있겠지만, 역시 있는 쪽이 더 매끄러울 듯.
근데 이 과정에서 애초에 디자인을 한 사람이 참여하지 않는다면 검증, 보정 참 힘들죠.
그러니까 이 부분 전담해 줄 디자이너가... 아 기획자 없애기로 했으니 전담할 사람이 없어져 버렸나?
뭐 없이도 어떻게 할 수는 있겠지만, 역시 있는 쪽이 더 매끄러울 듯.
정리해 보자면... 우와... 기획자 없이도 어케어케 일이 되기는 하겠는데?
다만 크리티컬한 문제로 대두되는 부분은 '개발 효율'이 극도로 떨어질 가능성이 높다는 지점.
그럼 기획자는 개발 효율을 높이기 위해 존재하는 건가효...?
'잡부'라는 생각이 다시 고개를 들이밀기 시작하지만... -_-a
뭐 반장난스럽게 평가절하스러븐 단어를 사용한다 할지라도, 개발 효율이라는건 매우매우 무지무지 중요한 요소이므로, 기획자는 있는 편이 좋다! 라는 실로 알흠다운 결론이 나오는군요.
음헤헤. '나는 그냥 월급 도둑이란 말인가?'라는 존재론적인(?) 자학에 빠져 사표 쓸 필요는 없겠다 (...)
자 '기획자 따위 필요없어!'에 대한 대답은... 실로 대충 떼워막기로 해버린 듯 싶지만 암튼 어떻게 했다고 치자.
그런데 '기획자가 없다!'라고 가정을 해봤다면... 그 반대 급부에 대한 의문이 꼬리를 물고 나오는근염.
만약 기획자가 저 모든 걸 다 맡아서 해치운다면 과연 어떻게 될까?
호옹... 어떤 양상으로 흘러갈는지 벌써 감이 딱 오기는 하는데...
아마도 '기획자 따위 필요없어!'라는 주장을 아직 포기하고 싶지 않으신 분들이 기꺼워 할만한 내용으로 채워질...
다음 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/341
|
[글강, 2009/02/01 00:03, Game]
[2번 글]에서 말한 바와 같이, 이번엔 개발 수순에서 기획자만의 고유한 전문성이 개입하는 구간을 함 고민해봅세.
기획자만의 전문성?!
... 그러니까 이게 뭔지를 알면 문제가 참 간단해지는 셈인데 -ㅅ- 가장 아리까리한 부분이기도 하다능.
기획자라는 타이틀을 달고 있는 주제에, 내 직업을 명확하게 정의조차 내리지 못하다니 참으로 쓸모업ㅂ는 놈이로다... 싶지만 ㄱ-
뭐 그래도 계속 함 가봅세.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
... 라고 한다면. 자 정리해보자.
1번부터 7번까지 중에서, 내가 보기에 기획자라는 직군의 성격을 규정짓는다고 할만한 작업은 게임 디자인과 밸런싱 2가지이다.
그러나 그래서 게임 디자인과 밸런싱에 있어 어떠한 전문성이 요구되는가... 라고 한다면 여전히 그 점에 있어서는 모호함이 나를 휘어 감싼다.
물론 필요한 스킬이 '없다'라고 할 수는 없다. 즉 일반인과 게임 기획자를 가르는 선은 분명히 존재한다.
'그 선은 이 지점이다'라고 명확히 할 수는 없겠지만, 사실 이런 식으로 분해해 가면서 접근한다면 어느 직군이든 그 선은 1차원적인 구분자로 존재하는 것이 아닌, 2차원적인 면으로서 존재할 것이다.
하지만 역시 기획자는 그 면이 너무 넓다 ㄱ-
일단 나열하기 시작하자면... 이 뭐 인문학 거의 전반, 혹은 이학이나 공학까지도 넘나들게 되어버리는 것이다. 그렇다고 또 어느 분야에 대해 Master가 될 필요까지는 없고, 이 분야 저 분야 모두 툭툭 건드림에 부족함이 없는 정도면 족하다.
(그러니 '게임 기획자가 되려면 어떻게 해야 하나효?'라는 질문에 대하여 우리가 해줄 수 있는 대답이라는게 '게임 하나 만들어 보세효' 정도 밖에 못되는 것이다. 기획자로 넘어오는 선이 너무 넓으니까 차라리 통째로 함 해보라는... 그것 참 이게 정답이라고 생각하기는 하지만, 이게 정답이라는 사실은 사실 참 슬픈 사실이 아닐 수 업ㅂ다 ㄱ-)
그리하야... 결국 '개발팀의 잡부'라는 결론이 다시 튀어나와 버리는 것이다 -ㅁ-;;;
... 뭐 잡부라는 단어를 조금 부정적인 뉘앙스로 써서 단순히 거부감이 드는 것일는지도 모르겠지만 ㄱ-;
또는 기획자는 원래 저 모호함의 넓은 면에서 헤엄치는 존재가 맞는 것인지도 모르겠지만...
혹은 애초에 내가 진행한 사고 전개가 완전히 틀려먹은 것일는지도 모르겠지만...
어찌되었든 현재로서는 내가 게임 기획자라는 직군에 대하여 설명할 수 있는 지점은 이 정도이다.
워킹 딕셔너리, 혹은 개발의 짐덩어리 사이에서 모호하게 존재하는 직군이랄까 ㄱ-;
... 이 시점에서 '역시 게임 기획자 따위는 필요없군'이라 읊조리며 고개를 끄덕이는 당신을 위한 이야기는 다음 글에서 ( '')
기획자만의 전문성?!
... 그러니까 이게 뭔지를 알면 문제가 참 간단해지는 셈인데 -ㅅ- 가장 아리까리한 부분이기도 하다능.
기획자라는 타이틀을 달고 있는 주제에, 내 직업을 명확하게 정의조차 내리지 못하다니 참으로 쓸모업ㅂ는 놈이로다... 싶지만 ㄱ-
뭐 그래도 계속 함 가봅세.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
일단 의도의 설정... 이건 기획자의 일이 아님미다. 디렉터라는 '직급'에서 해줘야 하는 부분이졈.
기획자들조차 쉽게 착각하는 부분이기도 한데, 게임의 상이랄까 혹은 기조를 뚜렷이 설정하고 결정하는 것은 디렉터가 해야 하는 일이지 기획자가 할 일은 아니예효.
물론 기획자가 그걸 도와줄 수는 있겠지만... 딱히 기획자만 도와줄 수 있는 것도 아니고, 개발 팀원이라면 누구나 함께 참여해서 디렉터가 결정을 내리는 데에 도움을 줄 수 있는거졈.
그럼 의도 설정이 완료되었다고 할 때, 이 의도랄까 목적을 달성하기 위한 최적의 솔루션... 어떤 게임 어셋으로 의도를 적절히 표현하면서도, 날로 먹는(?) 개발을 할 수 있을까?! 에 대한 대답을 찾는 문제는...
요거이 흔히 '아이디어'라고도 불리우는 부분이고, 기획자가 참여할 여지가 있는 일이긴 하지만서도...
이게 '기획자만의 전문성이 드러나는 부분인가?' 라고 묻는다면 내 대답은 '아니올시다'이다.
아이디어는 기획자만 내나효? 프로그래머는 아이디어 없나효? 아티스트는? 당연히 아이디어는 누구나 낼 수 있는 거고, 개발팀 내에서 아이디어는 자유롭게 제안되고 논의될 수 있어야만 한다.
'참신한' 아이디어를 낼 수 있는 능력은 상상력의 영역에 가깝고, '유용한' 아이디어를 내기 위해서는 게임에 대한 이해가 필요하다. 그리고 이러한 상상력과 이해력은... 특정 직군에게만 종속되는 것이 아니다. (아니어야만 한다.)
고로 이건 기획자 고유의 업무는 아니라능. 물론 기획자가 이 일을 잘한다면 좋다. 기획자는 개발 중인 게임 전반에 대한 통찰을 하고 있어야 하므로, 이 일을 잘 하기에 조금 더 유리한(?) 것도 사실이기는 하지만...
그럼에도 불구하고 기획자만의 고유 업무가 되어버리면 안되는 종류의 일인지라, 기획자만의 전문성이 두드러지는, 기획자라는 직군의 성격을 규정짓는 일은 아니라고 할 수 있다.
(그래서 [예전 글]에서 기획자한테 아이디어는 사실 없어도 된다고 한거다 ㄲㄲㄲ)
그러니까 1번은 패스~
기획자들조차 쉽게 착각하는 부분이기도 한데, 게임의 상이랄까 혹은 기조를 뚜렷이 설정하고 결정하는 것은 디렉터가 해야 하는 일이지 기획자가 할 일은 아니예효.
물론 기획자가 그걸 도와줄 수는 있겠지만... 딱히 기획자만 도와줄 수 있는 것도 아니고, 개발 팀원이라면 누구나 함께 참여해서 디렉터가 결정을 내리는 데에 도움을 줄 수 있는거졈.
그럼 의도 설정이 완료되었다고 할 때, 이 의도랄까 목적을 달성하기 위한 최적의 솔루션... 어떤 게임 어셋으로 의도를 적절히 표현하면서도, 날로 먹는(?) 개발을 할 수 있을까?! 에 대한 대답을 찾는 문제는...
요거이 흔히 '아이디어'라고도 불리우는 부분이고, 기획자가 참여할 여지가 있는 일이긴 하지만서도...
이게 '기획자만의 전문성이 드러나는 부분인가?' 라고 묻는다면 내 대답은 '아니올시다'이다.
아이디어는 기획자만 내나효? 프로그래머는 아이디어 없나효? 아티스트는? 당연히 아이디어는 누구나 낼 수 있는 거고, 개발팀 내에서 아이디어는 자유롭게 제안되고 논의될 수 있어야만 한다.
'참신한' 아이디어를 낼 수 있는 능력은 상상력의 영역에 가깝고, '유용한' 아이디어를 내기 위해서는 게임에 대한 이해가 필요하다. 그리고 이러한 상상력과 이해력은... 특정 직군에게만 종속되는 것이 아니다. (아니어야만 한다.)
고로 이건 기획자 고유의 업무는 아니라능. 물론 기획자가 이 일을 잘한다면 좋다. 기획자는 개발 중인 게임 전반에 대한 통찰을 하고 있어야 하므로, 이 일을 잘 하기에 조금 더 유리한(?) 것도 사실이기는 하지만...
그럼에도 불구하고 기획자만의 고유 업무가 되어버리면 안되는 종류의 일인지라, 기획자만의 전문성이 두드러지는, 기획자라는 직군의 성격을 규정짓는 일은 아니라고 할 수 있다.
(그래서 [예전 글]에서 기획자한테 아이디어는 사실 없어도 된다고 한거다 ㄲㄲㄲ)
그러니까 1번은 패스~
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
와우. 기획자를 영어로 하면 Game Designer(사실 영어로 하면 좀 더 세분화 되기는 하지만 일단 퉁쳐서)이니까... 뭔가 기획자만의 고유 영역 같아 보이는 놈이 나왔군염.
그러나... 이걸 '어떠한 일이다'라고 명확하게 정의내릴 수 있을까.
게임 디자인이라는게 대체 구체적으로는 어떤 일인지... 즉 코딩 한다, 드로잉 한다, 모델링 한다 등과 같이 명확하게 정의내릴 수 있다면 '기획자는 xx 하는 사람'이라고 그 전문성을 명시할 수 있을텐데...
문제는 '게임 디자인을 한다'라고 해버리면 너무 모호하게 추상화되고 넓어져 버린다는 점이다.
관점을 좀 바꿔볼까? 그럼 좋은 게임 디자인이란 무엇인가?
... 아 넵. 역시나 추상적이근염. 그냥 '좋은 게임 디자인은 좋은 게임 디자인이다'라는 말과 그닥 달라보이지 않는데 말이졈 ㄱ-
관점을 다시 바꿔볼까? 그럼 좋은 게임 디자인을 하기 위해서는 어떤 스킬이 필요한가?
... 하아 그래도 모호하네. 뭐 논리력이니, 객관화 능력이니, 추상화 능력이니, 시스템 분석 능력이니 등등 뜬구름 잡는 류의 이야기는 늘어놓을 수 있겠지만, 이것들이 게임 디자인에 연결되는 지점을 설명하려 들면 다시 갸우뚱해져 버린다.
물론 그럼에도 불구하고 좋은 게임 디자인은 존재한다.
그리고 그 실체가 모호함에도 불구하고, 게임 디자인이라는 업무는 현상으로 존재하고 있다. (내가 그 일을 하고 있다 ㄱ-)
아울러 좋은 디자인을 하는 게임 디자이너 - 기획자 역시 존재한다.
그런데 그래서 좋은 게임 디자인이 뭐냐고 묻는다면, 그 좋은 게임 디자인을 위해서 무엇이 필요한지를 묻는다면... 아리까리해 넓어져 버리는 것이 우리 직군의 문제 ㄱ-
다시 또 뒤집어서, 좋은 게임 디자이너가 되려면 어떠한 스킬이 필요한지를 묻는다면... 역시 아리까리.
즉... 레퍼런스가 없다!!!
뭐 게임 기획이랄까 디자인 전반을 다루고 있는 여러 책들을 보면(넵 그렇게 많이 보지는 못했슴미다. 사실 그렇게 많이 나와있는 것도 아니고... 외서는 거진 콘솔 - Stand Alone - 이야기이고 ㄱ-) 나름의 방식대로 게임 디자인을 정의하고 있기는 한데... 이야기가 다 달라. 아니 '다르다'라고 딱 떨어지는 말을 하기엔 또 모호한 것이... 따로따로 보자면 맞는 말이긴 한데, 중앙을 관통하는 무언가가 모호해지는 것이다. 뜬구름 잡아버리는 레퍼런스라고나 할까...
상황이 이러니 유독 쓸모없다고 알려진 게임 관련 자격증 중에서도 기획 자격증은 정말 낮은 평가를 받고 있는게 아닐까. 자격증이라는건 레퍼런스가 명확한 직군에 대해서나 유의미할 수 있을텐데... 기획은 레퍼런스가 명확하지 않거등.
더욱 곤란한 지점은... '레퍼런스가 명확하지 않다는 점을 인식했다면, 기획 업무를 분류하고 정리해서 레퍼런스를 구축하면 되지 않는가?'라는 질문에 대하여 '그러기가 좀 힘든데염, 혹은 불가능해 보여효'라는 대답을 할 수밖에 없다는 점이다.
... 그 이유는 프로젝트, 혹은 개발하는 게임에 따라 Case by Case이기 때문에...
어떤 게임에서는 최악의 디자인이, 어떤 게임에서는 최선의 디자인이 될 수 있다. 물론 반대로 어떤 게임에서는 최선의 디자인이 다른 게임에서는 최악의 디자인이 될 수 있고.
게임만 놓고 보자면 최선의 디자인인데, 개발 자원 활용 효율성이 최악이라면 그건 또 최악의 디자인이 되고... 경우의 수는 계속 늘어난다.
즉 그 때 그 때 달라효. 아놔... 어쩌라고.
이러저러한 이유 때문에 결국 기획자를 'xx 하는 사람'이라 명확하게 정의할 수 없다 보니...
'아이디어 내는 사람?'이라는 쓰잘데기 업ㅂ는 인식도 생겨버리는 듯 싶고, '재미를 만들어 내는 사람?'이라는 GODLIKE ㅎㄷㄷ한 정의도 나오는게 아닐까?
더불어 '기획자 따위 필요없어'의 근원지 역시 이 지점이 아닐까.
사실 레퍼런스가 명확하지 않다 보니... 더불어 디자인이라는건 (손, 발이 돕기는 하지만서도) 결국 머리 속에서 일어나는 일이다 보니... 아무나 할 수 있는 것처럼 보이거등. 실제로 다른 직군에 속해 있는 사람이 게임 디자인을 하려 들면 '난 이러저러한 스킬이 없으니까 못하겠는데'라 할만한 명확한 지점이 없는 것도 사실이니까. 그런 상황에서 주섬주섬 한 디자인이 얼추 들어 맞는다면... 사실 그 사람은 게임 디자인을 한 것임에도 불구하고, 자기 자신이 게임 디자인을 한 것인지 여부를 명확히 인지하기도 힘들다.
'뭐 게임 기획자 필요없네. 그냥 내가 해도 되는데?'로 귀결해 버리는, 그리고 이에 대해 딱히 반론하기도 힘든 상황이 벌어지는 것이다.
정리하자면... 게임 디자인은 기획자 고유의 영역이 맞다.
하지만 그 고유의 영역을 가르는 구분선은... 모호하기 짝이 없다.
이것이 내가 '게임 기획자란 대체 뭐하는 놈들인가'라는 질문에 명확하게 '이거다'라는 대답을 제시하지 못하는 지점이기도 하고.
그러나... 이걸 '어떠한 일이다'라고 명확하게 정의내릴 수 있을까.
게임 디자인이라는게 대체 구체적으로는 어떤 일인지... 즉 코딩 한다, 드로잉 한다, 모델링 한다 등과 같이 명확하게 정의내릴 수 있다면 '기획자는 xx 하는 사람'이라고 그 전문성을 명시할 수 있을텐데...
문제는 '게임 디자인을 한다'라고 해버리면 너무 모호하게 추상화되고 넓어져 버린다는 점이다.
관점을 좀 바꿔볼까? 그럼 좋은 게임 디자인이란 무엇인가?
설정된 의도를 가장 명확하게 반영하면서도, 이를 실제로 구현할 개발자들의 능력과, 개발 자원 활용에 있어 가장 효율적이고 최적화된 게임 디자인. 이 디자인은 여러 게임 어셋들과 모순을 발생시키지 않아야 하며, 실제로 플레이할 유저로 하여금 의도에 부합하는 반응을 보이도록 이끌어 낼 수 있어야 한다... 등등.
... 아 넵. 역시나 추상적이근염. 그냥 '좋은 게임 디자인은 좋은 게임 디자인이다'라는 말과 그닥 달라보이지 않는데 말이졈 ㄱ-
관점을 다시 바꿔볼까? 그럼 좋은 게임 디자인을 하기 위해서는 어떤 스킬이 필요한가?
... 하아 그래도 모호하네. 뭐 논리력이니, 객관화 능력이니, 추상화 능력이니, 시스템 분석 능력이니 등등 뜬구름 잡는 류의 이야기는 늘어놓을 수 있겠지만, 이것들이 게임 디자인에 연결되는 지점을 설명하려 들면 다시 갸우뚱해져 버린다.
물론 그럼에도 불구하고 좋은 게임 디자인은 존재한다.
그리고 그 실체가 모호함에도 불구하고, 게임 디자인이라는 업무는 현상으로 존재하고 있다. (내가 그 일을 하고 있다 ㄱ-)
아울러 좋은 디자인을 하는 게임 디자이너 - 기획자 역시 존재한다.
그런데 그래서 좋은 게임 디자인이 뭐냐고 묻는다면, 그 좋은 게임 디자인을 위해서 무엇이 필요한지를 묻는다면... 아리까리해 넓어져 버리는 것이 우리 직군의 문제 ㄱ-
다시 또 뒤집어서, 좋은 게임 디자이너가 되려면 어떠한 스킬이 필요한지를 묻는다면... 역시 아리까리.
즉... 레퍼런스가 없다!!!
뭐 게임 기획이랄까 디자인 전반을 다루고 있는 여러 책들을 보면(넵 그렇게 많이 보지는 못했슴미다. 사실 그렇게 많이 나와있는 것도 아니고... 외서는 거진 콘솔 - Stand Alone - 이야기이고 ㄱ-) 나름의 방식대로 게임 디자인을 정의하고 있기는 한데... 이야기가 다 달라. 아니 '다르다'라고 딱 떨어지는 말을 하기엔 또 모호한 것이... 따로따로 보자면 맞는 말이긴 한데, 중앙을 관통하는 무언가가 모호해지는 것이다. 뜬구름 잡아버리는 레퍼런스라고나 할까...
상황이 이러니 유독 쓸모없다고 알려진 게임 관련 자격증 중에서도 기획 자격증은 정말 낮은 평가를 받고 있는게 아닐까. 자격증이라는건 레퍼런스가 명확한 직군에 대해서나 유의미할 수 있을텐데... 기획은 레퍼런스가 명확하지 않거등.
더욱 곤란한 지점은... '레퍼런스가 명확하지 않다는 점을 인식했다면, 기획 업무를 분류하고 정리해서 레퍼런스를 구축하면 되지 않는가?'라는 질문에 대하여 '그러기가 좀 힘든데염, 혹은 불가능해 보여효'라는 대답을 할 수밖에 없다는 점이다.
... 그 이유는 프로젝트, 혹은 개발하는 게임에 따라 Case by Case이기 때문에...
어떤 게임에서는 최악의 디자인이, 어떤 게임에서는 최선의 디자인이 될 수 있다. 물론 반대로 어떤 게임에서는 최선의 디자인이 다른 게임에서는 최악의 디자인이 될 수 있고.
게임만 놓고 보자면 최선의 디자인인데, 개발 자원 활용 효율성이 최악이라면 그건 또 최악의 디자인이 되고... 경우의 수는 계속 늘어난다.
즉 그 때 그 때 달라효. 아놔... 어쩌라고.
물론 언제 어디서나 먹히지 않는 그냥 막장이라는 것도 없지는 않지만... 이런걸 골라내는 정도를 전문성이라고 내세우기엔 (...)
이러저러한 이유 때문에 결국 기획자를 'xx 하는 사람'이라 명확하게 정의할 수 없다 보니...
'아이디어 내는 사람?'이라는 쓰잘데기 업ㅂ는 인식도 생겨버리는 듯 싶고, '재미를 만들어 내는 사람?'이라는 GODLIKE ㅎㄷㄷ한 정의도 나오는게 아닐까?
더불어 '기획자 따위 필요없어'의 근원지 역시 이 지점이 아닐까.
사실 레퍼런스가 명확하지 않다 보니... 더불어 디자인이라는건 (손, 발이 돕기는 하지만서도) 결국 머리 속에서 일어나는 일이다 보니... 아무나 할 수 있는 것처럼 보이거등. 실제로 다른 직군에 속해 있는 사람이 게임 디자인을 하려 들면 '난 이러저러한 스킬이 없으니까 못하겠는데'라 할만한 명확한 지점이 없는 것도 사실이니까. 그런 상황에서 주섬주섬 한 디자인이 얼추 들어 맞는다면... 사실 그 사람은 게임 디자인을 한 것임에도 불구하고, 자기 자신이 게임 디자인을 한 것인지 여부를 명확히 인지하기도 힘들다.
'뭐 게임 기획자 필요없네. 그냥 내가 해도 되는데?'로 귀결해 버리는, 그리고 이에 대해 딱히 반론하기도 힘든 상황이 벌어지는 것이다.
정리하자면... 게임 디자인은 기획자 고유의 영역이 맞다.
하지만 그 고유의 영역을 가르는 구분선은... 모호하기 짝이 없다.
이것이 내가 '게임 기획자란 대체 뭐하는 놈들인가'라는 질문에 명확하게 '이거다'라는 대답을 제시하지 못하는 지점이기도 하고.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
넵. 문서 작성. 물론 잘 해야 하졈... 일반적으로 플머님께 넘기는 문서이니까, 기획자는 플밍에 대한 지식도 얼추 갖추고 있어야 하고...
... 근데 가독성이 높은 이해하기 쉬운 문서를 작성해 내는 능력을 기획자 고유의 전문성이라고 할 수 있을까효?
아 물론 잘하면 좋은 일이고, 잘해야 하는 일이지만, 이 일이 과연 기획자라는 직군의 성격을 규정지을까효?
아리까리... 아니올시다... 싶다. 이건 그냥 '생각의 공유'가 필요한 '협업' 체제에 속해 있는 모든 개발자가 어느 정도 갖추어야 할 소양인 듯.
... 근데 가독성이 높은 이해하기 쉬운 문서를 작성해 내는 능력을 기획자 고유의 전문성이라고 할 수 있을까효?
아 물론 잘하면 좋은 일이고, 잘해야 하는 일이지만, 이 일이 과연 기획자라는 직군의 성격을 규정지을까효?
아리까리... 아니올시다... 싶다. 이건 그냥 '생각의 공유'가 필요한 '협업' 체제에 속해 있는 모든 개발자가 어느 정도 갖추어야 할 소양인 듯.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
아 물론 그러니까 기획자는 그래픽이나 사운드에 대한 지식을 얼추 갖추고 있어야 하지만... 나머지는 3번과 마찬가지.
5. 어셋 구현 후에는... 리소스들의 조립.
... 사실 문서화만 잘 되어 있다면 조립은 누구나 할 수 있다 -ㅁ- 매뉴얼 따라서 프라모델 조립하는 것과 크게 다르지 않으니.
물론 특히나 레벨 디자인이나 퀘스트 디자인 쪽에서는 여기에 센스가 요구되기는 지점이 겹치기는 하지만서도, 역시나 이걸 기획자만의 고유성을 결정짓는 일이라 하기엔... 이를 위해 딱히 필요한 스킬이나 전문적 지식이 요구되지는 않는다.
그냥 개발 효율상 이 일은 기획자가 맡는게 좋다. 정도가 아닐까...?
물론 특히나 레벨 디자인이나 퀘스트 디자인 쪽에서는 여기에 센스가 요구되기는 지점이 겹치기는 하지만서도, 역시나 이걸 기획자만의 고유성을 결정짓는 일이라 하기엔... 이를 위해 딱히 필요한 스킬이나 전문적 지식이 요구되지는 않는다.
그냥 개발 효율상 이 일은 기획자가 맡는게 좋다. 정도가 아닐까...?
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
게임 디자인과 더불어 뭔가 기획자스러운 업무가 튀어나오셨음. 밸런싱.
그러나 이 업무 역시 게임 디자인과 똑같은 문제를 가지고 있다. 레퍼런스랄까, 혹은 정답이 없고 Case by Case.
그나마 게임 디자인보다는 손에 명확히 잡히는 결과물을 내놓는 작업이기 때문에 좀 낫기는 하고, 여러 게임 어셋들과의 연계를 모두 고려해야만 하는 일이기에 기획자가 진행할만한 고유 업무라 할만한 녀석이기는 하지만서도...
그래서 밸런싱을 잘 하기 위해서 필요한 스킬이 뭔가요? 라고 묻는다면 나는 또 침묵하게 된다 (...)
아 넵. 뜬구름잡는 이야기에 더하여 '사칙 연산'이라는 스킬같지도 않은 스킬 (...) 을 추가할 수는 있겠지만... 말하기도 부끄럽다 ;
따라서 기획자 고유 업무이며, 게임 디자인보다는 좀 더 작업의 가시성이 높기는 하지만, 역시 '그래서 좋은 밸런싱이 뭔데? 뭐가 필요한데?'라고 묻는다면 그 모호함에 먼 산을 바라보아야 하는 영역.
어째 다 이 모냥이냐고효 -ㅅ-
그러나 이 업무 역시 게임 디자인과 똑같은 문제를 가지고 있다. 레퍼런스랄까, 혹은 정답이 없고 Case by Case.
그나마 게임 디자인보다는 손에 명확히 잡히는 결과물을 내놓는 작업이기 때문에 좀 낫기는 하고, 여러 게임 어셋들과의 연계를 모두 고려해야만 하는 일이기에 기획자가 진행할만한 고유 업무라 할만한 녀석이기는 하지만서도...
그래서 밸런싱을 잘 하기 위해서 필요한 스킬이 뭔가요? 라고 묻는다면 나는 또 침묵하게 된다 (...)
아 넵. 뜬구름잡는 이야기에 더하여 '사칙 연산'이라는 스킬같지도 않은 스킬 (...) 을 추가할 수는 있겠지만... 말하기도 부끄럽다 ;
따라서 기획자 고유 업무이며, 게임 디자인보다는 좀 더 작업의 가시성이 높기는 하지만, 역시 '그래서 좋은 밸런싱이 뭔데? 뭐가 필요한데?'라고 묻는다면 그 모호함에 먼 산을 바라보아야 하는 영역.
어째 다 이 모냥이냐고효 -ㅅ-
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
어랍쇼? 이건 QA의 업무인거 같은데?
기획자가 여기에 참여를 안한다면 그것도 문제이지만, 엄밀히 말해 이건 QA의 메인 업무에 기획자가 서브로 끼어드는 형태가 되는 듯 싶다.
고로 기획자를 결정짓는 업무라 할 수는 없을 터.
기획자가 여기에 참여를 안한다면 그것도 문제이지만, 엄밀히 말해 이건 QA의 메인 업무에 기획자가 서브로 끼어드는 형태가 되는 듯 싶다.
고로 기획자를 결정짓는 업무라 할 수는 없을 터.
... 라고 한다면. 자 정리해보자.
1번부터 7번까지 중에서, 내가 보기에 기획자라는 직군의 성격을 규정짓는다고 할만한 작업은 게임 디자인과 밸런싱 2가지이다.
그러나 그래서 게임 디자인과 밸런싱에 있어 어떠한 전문성이 요구되는가... 라고 한다면 여전히 그 점에 있어서는 모호함이 나를 휘어 감싼다.
물론 필요한 스킬이 '없다'라고 할 수는 없다. 즉 일반인과 게임 기획자를 가르는 선은 분명히 존재한다.
'그 선은 이 지점이다'라고 명확히 할 수는 없겠지만, 사실 이런 식으로 분해해 가면서 접근한다면 어느 직군이든 그 선은 1차원적인 구분자로 존재하는 것이 아닌, 2차원적인 면으로서 존재할 것이다.
하지만 역시 기획자는 그 면이 너무 넓다 ㄱ-
일단 나열하기 시작하자면... 이 뭐 인문학 거의 전반, 혹은 이학이나 공학까지도 넘나들게 되어버리는 것이다. 그렇다고 또 어느 분야에 대해 Master가 될 필요까지는 없고, 이 분야 저 분야 모두 툭툭 건드림에 부족함이 없는 정도면 족하다.
(그러니 '게임 기획자가 되려면 어떻게 해야 하나효?'라는 질문에 대하여 우리가 해줄 수 있는 대답이라는게 '게임 하나 만들어 보세효' 정도 밖에 못되는 것이다. 기획자로 넘어오는 선이 너무 넓으니까 차라리 통째로 함 해보라는... 그것 참 이게 정답이라고 생각하기는 하지만, 이게 정답이라는 사실은 사실 참 슬픈 사실이 아닐 수 업ㅂ다 ㄱ-)
그리하야... 결국 '개발팀의 잡부'라는 결론이 다시 튀어나와 버리는 것이다 -ㅁ-;;;
... 뭐 잡부라는 단어를 조금 부정적인 뉘앙스로 써서 단순히 거부감이 드는 것일는지도 모르겠지만 ㄱ-;
또는 기획자는 원래 저 모호함의 넓은 면에서 헤엄치는 존재가 맞는 것인지도 모르겠지만...
혹은 애초에 내가 진행한 사고 전개가 완전히 틀려먹은 것일는지도 모르겠지만...
어찌되었든 현재로서는 내가 게임 기획자라는 직군에 대하여 설명할 수 있는 지점은 이 정도이다.
워킹 딕셔너리, 혹은 개발의 짐덩어리 사이에서 모호하게 존재하는 직군이랄까 ㄱ-;
... 이 시점에서 '역시 게임 기획자 따위는 필요없군'이라 읊조리며 고개를 끄덕이는 당신을 위한 이야기는 다음 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/340
|
[글강, 2009/01/31 01:12, Game]
자 [1번 글]에서 던져진 질문은 '게임 기획자라는건 대체 뭐하는 놈들인데?'라는 거였는데... ㄱ-
이거이 쉽게 대답할 수 있는 거였다면, 그냥 지난 글에서 휙 정답을 던져 버리고 걍 끝냈겠지.
이렇게 넘버링까지 해가면서 글을 분리하지도 않았을 터...
그러니까 솔직히 결론부터 말하자면 나는 아직 기획자라는 직군을 한 문장, 혹은 한 단어로 명확히 정의하지는 못하겠다.
([예전 글]에서 언급한 바와 같이 '잡부'라는 한 단어로... 하려면 할 수야 있겠지만 -ㅁ- 설마 이런 대답을 원하는건 아닐테고;;;)
그러니까... 같이 함 고민해봅세.
4년 전 면접에서 '기획이란 무엇이라고 생각하시나요?'라는 질문을 받았을 때, 내가 했던 대답은 '룰의 정의'였는데...
아주 틀린 말이라고 생각하지는 않으나, 이건 어디까지나 시스템 디자인의 단편에서나 먹히는 이야기인 듯 싶어서리, 역시 좀 반쪽스럽다.
그럼 기획이 대체 뭔데?
나도 잘 모르겠으니까... 기획자가 하는 일을 한 번 죽 나열해보면, 좀 더 명확해지지 않을까?
기획자라는 직군은 개발팀 내에서 무슨 일을 하고 있는가?
뭐 어쩔 수 없이 일단 내 경험에 기반하여 썰을 함 풀어보자.
내가 해왔던, 그리고 지금도 하고 있는 일들을 조금 많이(!) 단순화하고, 순차적으로 나열해 보자면...
... 뭔가 다분히 시스템 디자인스러운데... -ㅁ- 그거야 내가 시스템 디자이너이니까 (...)
레벨 디자이너라면 좀 다를까?
... 비슷하네.
퀘스트 디자이너라면 좀 다를까?
물론 매우매우매우매우 단순화하고 추상화 해버렸기 때문에, 조금은 억지로 끼워맞춘 감이 없지는 않은데...
... 중간에 몇 단계가 빠지는 경우도 있고, 시스템의 성격에 따라 내가 참여하지 않는 단계도 존재하며, 특정 단계에서 몇바퀴를 돈 다음에야 다음으로 넘어가는 경우도 있는 등등 저 문장들의 뒷면이나 행간에 숨어있는 무수한 예외들이 존재한다.
뭐 대충 알아먹으시면 된다능ㅋ
(일정 조율이나 시장 파악 등등, 내가 했었던 다른 일들이 빠져있기는 하지만... PM이라는 직급의 업무나 마케터의 영역을 기획자의 업무로 간주해도 되는건지 잘 모르겠으니까 걍 패스 ~_~ 시나리오 라이터라면 또 다를 것 같지만... 아 잠깐. 우리나라에서야 라이터를 기획자로 뭉뚱그리지만, 엄밀히 말해 라이터를 기획으로 분류하는건 좀 아닌 것 같으니 또 패스 ~_~)
암튼 마구마구 단순화시킨 저 과정을, 개별 게임 어셋들의 수만큼 무한 루프 (...) 돌리는 것이 내 일이다.
에... 그런데 말이졈. 일이라고 적어놓은 걸 보고 있자니 갸우뚱해져 버린다.
저게 기획자의 일이라고?
저건 그냥 게임을 개발해 나아가는 수순을 나열해 놓은 거잖아?
기획자만 이렇게 일하나효? 프로그래머도, 아티스트도 용어만 조금 바꾸면 일하는 순서를 이와 비슷하게 끼워맞출 수 있다.
아니 직군을 따로 나누지 않는다 하더라도, 협업이 이루어지는 순서 역시 여기 끼워맞추는 데에는 그닥 무리가 없을 듯. 원래 개발은 이런 수순으로 진행된다.
그러니 이걸 '기획자라는 직군을 정의하는 일'이라고 보기는 아무래도 힘들다. 뭐 기획자가 일련의 과정들을 모두 매니징한다... 라고 한다면 저 흐름을 만들어내는 것 자체를 하나의 일로 구분할 수는 있겠지만서도, 그건 역시 PM의 일인 것 같으니 패스.
아익 경험에 의거하여 일단 생각나는대로 썰을 풀었더니만, 이건 '기획자의 일'이라기 보다는 그냥 '일' 혹은 '개발'이 튀어나와 버렸넹.
그럼 기획자는 대체 '구체적으로' 뭐하는 놈들인데?
흐음... 저 흐름에서 기획자가 '고유의 전문성'을 발휘할 수 있는 구간이 있는지를 한번 살펴본다면 좀 더 명확해지지 않을까?
그러나 그건 다음 글에서 ( --)
...
...
...
... 이제 겨우 2번인데도 내가 무슨 짓을 하고 있는거랍쇼 ㄱ- 라는 생각이 벌써 들기 시작하는데...
뭐 그래도 일단 칼을 뽑았으니 오늘은 무를 썰고 다음엔 뜨거운 감자를 썰어봅세.
이거이 쉽게 대답할 수 있는 거였다면, 그냥 지난 글에서 휙 정답을 던져 버리고 걍 끝냈겠지.
이렇게 넘버링까지 해가면서 글을 분리하지도 않았을 터...
그러니까 솔직히 결론부터 말하자면 나는 아직 기획자라는 직군을 한 문장, 혹은 한 단어로 명확히 정의하지는 못하겠다.
([예전 글]에서 언급한 바와 같이 '잡부'라는 한 단어로... 하려면 할 수야 있겠지만 -ㅁ- 설마 이런 대답을 원하는건 아닐테고;;;)
그러니까... 같이 함 고민해봅세.
4년 전 면접에서 '기획이란 무엇이라고 생각하시나요?'라는 질문을 받았을 때, 내가 했던 대답은 '룰의 정의'였는데...
아주 틀린 말이라고 생각하지는 않으나, 이건 어디까지나 시스템 디자인의 단편에서나 먹히는 이야기인 듯 싶어서리, 역시 좀 반쪽스럽다.
그럼 기획이 대체 뭔데?
나도 잘 모르겠으니까... 기획자가 하는 일을 한 번 죽 나열해보면, 좀 더 명확해지지 않을까?
기획자라는 직군은 개발팀 내에서 무슨 일을 하고 있는가?
뭐 어쩔 수 없이 일단 내 경험에 기반하여 썰을 함 풀어보자.
내가 해왔던, 그리고 지금도 하고 있는 일들을 조금 많이(!) 단순화하고, 순차적으로 나열해 보자면...
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 시스템들의 제안 및 논의 진행.
2. 채택된 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 시스템을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 시스템이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 시스템 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 시스템의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
2. 채택된 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 시스템을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 시스템이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 시스템 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 시스템의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
... 뭔가 다분히 시스템 디자인스러운데... -ㅁ- 그거야 내가 시스템 디자이너이니까 (...)
레벨 디자이너라면 좀 다를까?
1. 게임에서 의도하고 있는 플레이 패턴을 달성하기 위한 레벨의 컨셉 제안 및 논의 진행.
2. 채택된 컨셉을 반영할 수 있으면서, 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 레벨 디자인.
3. 레벨을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 레벨이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 레벨 구현 후에는... 각종 어셋들의 배치.
6. 어셋들을 배치했다면, 각 어셋들에게 적용될 수치들을 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
2. 채택된 컨셉을 반영할 수 있으면서, 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 레벨 디자인.
3. 레벨을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 레벨이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 레벨 구현 후에는... 각종 어셋들의 배치.
6. 어셋들을 배치했다면, 각 어셋들에게 적용될 수치들을 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
... 비슷하네.
퀘스트 디자이너라면 좀 다를까?
1. 게임에서 의도하고 있는 시나리오 전달 혹은 플레이 경험 선사, 보상 제공 등을 달성하기 위한 퀘스트의 제안 및 논의 진행.
2. 채택된 퀘스트를 디자인...
3. ... 4. 5. 6. 7. 똑같자나!
2. 채택된 퀘스트를 디자인...
3. ... 4. 5. 6. 7. 똑같자나!
물론 매우매우매우매우 단순화하고 추상화 해버렸기 때문에, 조금은 억지로 끼워맞춘 감이 없지는 않은데...
... 중간에 몇 단계가 빠지는 경우도 있고, 시스템의 성격에 따라 내가 참여하지 않는 단계도 존재하며, 특정 단계에서 몇바퀴를 돈 다음에야 다음으로 넘어가는 경우도 있는 등등 저 문장들의 뒷면이나 행간에 숨어있는 무수한 예외들이 존재한다.
뭐 대충 알아먹으시면 된다능ㅋ
(일정 조율이나 시장 파악 등등, 내가 했었던 다른 일들이 빠져있기는 하지만... PM이라는 직급의 업무나 마케터의 영역을 기획자의 업무로 간주해도 되는건지 잘 모르겠으니까 걍 패스 ~_~ 시나리오 라이터라면 또 다를 것 같지만... 아 잠깐. 우리나라에서야 라이터를 기획자로 뭉뚱그리지만, 엄밀히 말해 라이터를 기획으로 분류하는건 좀 아닌 것 같으니 또 패스 ~_~)
암튼 마구마구 단순화시킨 저 과정을, 개별 게임 어셋들의 수만큼 무한 루프 (...) 돌리는 것이 내 일이다.
에... 그런데 말이졈. 일이라고 적어놓은 걸 보고 있자니 갸우뚱해져 버린다.
저게 기획자의 일이라고?
저건 그냥 게임을 개발해 나아가는 수순을 나열해 놓은 거잖아?
목적 설정 및 최적 솔루션 모색 → 솔루션 구체화 → 문서화 → 실체화 → 수치적 보정 → 테스트 및 수정
기획자만 이렇게 일하나효? 프로그래머도, 아티스트도 용어만 조금 바꾸면 일하는 순서를 이와 비슷하게 끼워맞출 수 있다.
아니 직군을 따로 나누지 않는다 하더라도, 협업이 이루어지는 순서 역시 여기 끼워맞추는 데에는 그닥 무리가 없을 듯. 원래 개발은 이런 수순으로 진행된다.
그러니 이걸 '기획자라는 직군을 정의하는 일'이라고 보기는 아무래도 힘들다. 뭐 기획자가 일련의 과정들을 모두 매니징한다... 라고 한다면 저 흐름을 만들어내는 것 자체를 하나의 일로 구분할 수는 있겠지만서도, 그건 역시 PM의 일인 것 같으니 패스.
아익 경험에 의거하여 일단 생각나는대로 썰을 풀었더니만, 이건 '기획자의 일'이라기 보다는 그냥 '일' 혹은 '개발'이 튀어나와 버렸넹.
그럼 기획자는 대체 '구체적으로' 뭐하는 놈들인데?
흐음... 저 흐름에서 기획자가 '고유의 전문성'을 발휘할 수 있는 구간이 있는지를 한번 살펴본다면 좀 더 명확해지지 않을까?
그러나 그건 다음 글에서 ( --)
...
...
...
... 이제 겨우 2번인데도 내가 무슨 짓을 하고 있는거랍쇼 ㄱ- 라는 생각이 벌써 들기 시작하는데...
뭐 그래도 일단 칼을 뽑았으니 오늘은 무를 썰고 다음엔 뜨거운 감자를 썰어봅세.
|
Trackback Address :: http://glekang.com/trackback/339
|
[글강, 2009/01/30 11:49, Game]
... 우리나라 게임들 그래픽은 정말 끈내줘효. 개발 기술력 역시 세계 어디에 내놓는다 해도 손색이 업ㅂ졈. 하지만 문제는 기획력. 기획자들이 x같아서 재미있는 게임이 안나와효. 맨날 표절이나 해대고 궁시렁 궁시렁 ...
... 이와 같은 이야기는 게임 관련 커뮤니티에서 벌써 몇년 째 울궈먹고 있음에도, 미끼만 던졌다 하면 여전히 파닥파닥 만선인... 레전드리 떡밥이다.
심지어 개발자들 중에도 저런 생각에 동조하는 사람이 있다 보니, '기획자 따위 필요없어!'를 표방하는 게임이 나온 적도 있고... 뭐 암튼 여타 등등.
이 쉰내나는 떡밥을 이제 와 다시 돌이켜 보는 이유는...
솔직히 좀 억울해서. 헤헤헤.
데꿀멍 데꿀멍 데꿀멍 ( '')
일단 저 위에 나온 이야기에서, 기획자라고 지칭되는건 과연 누구일까? 기획자란 대체 뭐하는 사람일까?
기획자들이 x같아서 재미있는 게임이 안나온다 했으니... 그럼 기획자들이 잘하면 재미있는 게임이 나온다는 거근염.
기획자란 게임의 재미를 만들어 내는 사람?
기획자란 게임의 재미를 보장하는 사람?
기획자란 게임의 재미를 책임지는 사람?
하지만 재미라는건 게임의 궁극적인 목표이고, 개발의 모든 방향성은 결국 '재미'라는 키워드로 집중되게 마련인데... 그러한 재미를 만들고, 보장하고, 책임지는 기획자란...?
게임의 재미를 결정하는 사람인가효?
게임을 어떻게 만들면 재미있어 지는지를 아는 사람?
게임을 재미있게 만들기 위하여 컨텐츠의 방향성을 결정하는 사람?
... 하아. 이 즈음에서 개발자, 혹은 눈치가 빠른 유저라면 '어랍쇼 잠깐만?!'을 외치실 때가 되었는데...
팀이 개발하는 게임의 최종적인 상을 명확히 정립하고,
이에 기반하여 각종 컨텐츠들의 방향성을 결정하고,
결과적으로 팀이 만들어 내는 게임의 재미를 보장하고 책임지는 사람.
이에 기반하여 각종 컨텐츠들의 방향성을 결정하고,
결과적으로 팀이 만들어 내는 게임의 재미를 보장하고 책임지는 사람.
... 우리는 이런 사람을 '기획자'라는 직군으로 분류하지 않는다.
... 이런 사람은 '디렉터'라는 직급으로 분류된다.
물론 기획자가 디렉터를 맡는 경우라면 결국 같은 이야기가 되어 버리겠지만, 그럼에도 불구하고 '정립하고, 결정하고, 보장하며, 책임지는 것'은 기획자의 일이 아니라, 디렉터의 일이다.
즉 디렉터가 기획자 출신이든, 프로그래머 출신이든, 아티스트 출신이든 관계 없이 저것은 디렉터에게 요구되는 역할이고, 권한이며, 책임인 것이다.
그러니까 일개 기획자 따위는 게임이 재미없어도 책임없어효. 그만 좀 까셈. 즐. ㅂㅂ2~
...
...
...
... 요기서 싹 입씻고 도망치고 싶은 마음은 굴뚝같지만 ㄲㄲㄲ
안타깝게도 새로운 의문이 꼬리를 잇게 된다.
그럼 게임 기획자라는건 대체 뭐하는 놈들인데?
오늘은 대충 운만 띄워보고, 그 이야기는 다음 글에서 ( '')
사족 1.
게임을 디렉터 혼자 만드냐? 기획자도 결국 개발팀의 일원인데 게임의 재미에 책임이 없다고???
... 예리하기도 하셔라 ( --) 이 이야기는 기회가 닿는다면 다른 글에서 ( --)
사족 2.
디렉터가 게임의 재미를 보장하고 책임진다고? '재미를 보장한다'라는게 정말 인간에게 가능한 능력인거임? 그리고 '책임'이라는 건 대체 어떻게 질 수 있는건데?
... 자, 잠깐만. 이것도 다음에 기회 닿으면... (이라 쓰고 도망)
|
Trackback Address :: http://glekang.com/trackback/338
|
