태초에 프로그래머가 있었다. 캐릭터가 필요해 그림을 그리고, 소리가 없으니 밋밋하여 사운드를 만들었다. 마지막으로 생명을 불어넣기 위해 로직을 작성하니…. 비로소 게임이 완성되었다.
|
어설픈 글솜씨로 최초의 게임 프로그래머의 모습을 적어 보았다. 하지만 이는 사실이다. 게임은 프로그래머로 시작됐다. 혼자서 그림도 그리고, 사운드도 만들고, 게임 로직도 작성했다. 하지만 이 모든 것을 혼자서 다 하는 건 쉽지 않은 일이었다. 하지만 천재들도 있기 마련.
<카라테카>(Karateka)라는 게임을 기억할지 모르겠다.
한국에서는 ‘태권도 게임’이라고 불리기도 했다. 이 게임의 제작자는 조던 메크너(Jordan Mechner)이며 프로그래밍과 디자인 작업을 모두 혼자 했다. 그리고 무려… 예일대 학생일 때 이 게임을 개발했다.
천재는 외국에만 있나? 한국에도 있었다.
(출처: 구글)
프로그래머 남인환 씨가 만든 <신검의 전설>이라는 게임이다. 이 게임 역시 남인환 씨 혼자 프로그래밍, 기획, 그림 심지어는 판매까지 했다. 더 놀라운 사실은 이때 고등학생이었다고 한다.(필자도 고등학교 때 게임을 만들어서 판매하기도 했지만 시기가 다르다.)
최근에도 혼자서 게임을 만드는 사람들이 존재하며, 1인 개발자라고 불린다. 중요한 사실은, 예전에는 원래 게임은 혼자서 만들었다는 점이다. 하지만 혼자서 모든 것을 다 잘할 수는 없는 법.(천재들은 제외하자…) 그림은 잘 그리는 사람이 따로 있고, 음악적 재능이 뛰어난 사람이 있으며, 프로그래밍을 잘하는 사람이 따로 있다.
그리고 게임의 수준이 올라감에 따라 혼자서 만드는 것이 실제로 거의 불가능해지는 상황까지 오게 되었다. 실력을 떠나서 물리적으로 불가능하기 때문이다. 필자는 혼자서 <스타크래프트>나 <피파>와 같은 게임을 만들 수 있다고 생각한다. 하지만 모든 로직을 작성하고 모델링, 애니메이션, 사운드, 기획까지 한다면 아마 50년은 걸리지 않을까?
업무의 수준이 올라감에 따라 분업화가 되었고 원화가, 기획자(프로듀서), 애니메이터, 모델러, 서버 프로그래머, DBA, 클라이언트 프로그래머, 이펙터 등등… 수없이 많은 직업이 생겨났다. 이제 일정 수준 이상의 게임 만들기는 혼자 절대로 할 수 없는 지경에 이르렀다.
분업화가 된다는 것은 좋은 것이다. 왜냐하면, 전문 지식을 갖춘 전문가가 생기면서 더 높은 수준의 게임을 만들 수 있기 때문이다.
국내에서 출간된 FPS게임의 레벨 디자인에 관한 책. 국내를 포함해 외국에서도 이런 주제의 서적은 독보적이다.
위의 사진은 필자가 얼마 전에 읽었던 FPS게임의 레벨 디자인에 관한 책이다. 개인적으로 FPS게임 <퀘이크>를 굉장히 좋아했고 실제로 클랜 활동도 했었다. 게임의 월드를 돌아다니면서 최적의 이동 경로를 알아낸다거나 하는 것은 재미있었지만, 그 정도가 끝이었다. 하지만 이 책을 읽으면서 흥미로운 것을 발견했다.
중간에 뚫린 경로로 인해 너무 긴 시야를 갖게 되어 게임 플레이에 큰 영향을 준다.
의도적으로 만든 것이라면 상관없지만, 의도한 것이 아니었다면 다음과 같은 방법을 통해 긴 시야를 없앨 수 있다.
중간에 장애물을 설치해서 긴 시야를 가렸다.
시야 문제는 책 내용의 일부분일 뿐이고 그 외에도 레벨 디자인에 관해 배울 것이 많았다. 필자가 프로그래밍 외에 레벨 디자인까지 겸해서 일한다면 이 정도 전문적으로 게임 플레이 레벨을 만들진 못할 것이다.(FPS게임 시야 부분은 ‘FPS레벨 디자인 테크닉’의 저자 이용태님의 허락을 받고 일부분 인용하였습니다.)
이처럼 전문화가 된다는 것은 장점이 많다. 하지만 장점이 있다면 단점도 있기 마련.
바로
.
.
.
커뮤니케이션!
게임 제작 업무에 따라 의존 관계가 있는 것들과 없는 것들이 존재하는데, 의존적이지 않은 것들은 병행으로 업무 진행이 가능하지만 의존 관계를 가진 것들은 반드시 순서대로 일을 진행해야 한다.
예를 들어 A라는 사람의 업무가 끝나야만 B라는 사람이 업무를 진행할 수 있다면, B는 반드시 A를 기다려야 한다. 이때 A라는 사람의 업무가 언제 끝나는지 모른다거나 업무가 끝났는데도 그 사실을 B에게 알리지 않으면 B라는 사람은 업무를 진행할 수가 없다.
B라는 사람이 매우 능동적이어서 A라는 사람의 업무가 끝났는지 안 끝났는지 계속 확인한다면 모르겠지만, 역시 가장 좋은 방법은 A가 자신의 업무가 끝났을 때 바로 B에게 알려주는 것이다. 아니면 미리 B와 이야기해서 언제 자신의 업무가 끝나는지 알려주는 것이다.
업무 분담으로 인해 생기는 문제는 해결하기가 사실 간단하지 않다. 왜냐하면, 모두 사람에 대한 부분이기 때문이다.
게임회사에 취직해서 업무를 담당하면 혼자서 일하지 않는 한 당연히 커뮤니케이션을 해야 한다. 본인의 작업물을 기다리는 사람이 있는가 하면 다른 사람의 작업물을 기다려야 할 수도 있다. 또는 동시에 다른 일을 진행할 수도 있다. 이러한 업무들을 시간에 맞추어 스케줄을 잘 잡아 개발을 진행하는 것이 프로듀서의 역할이기도 하다.
자신의 업무가 어느 정도의 시간이 걸릴지 예측하기는 쉬울까?
업무량을 예측하는 것은 흔한 현업 개발자들의 고민이기도 하다. 왜냐하면, 각각 개인의 예측 시간에 따라서 시간을 잘 분배해야 프로젝트를 성공적으로 끝낼 수 있기 때문이다. 가장 큰 문제는 개인의 입장에서 업무량을 “어떻게 예측하는가?”이다.
이것은 연습으로 예측할 수 있게 자신을 단련하는 방법밖에 없다.
※ 가장 확실한 예측 방법은 이미 해본 것을 다시 하는 것이다. 이미 해본 것이라면 어느 정도의 시간이 걸렸는지 알 수 있기 때문에 그것과 비슷한 업무를 하는 것은 충분히 예측할 수 있다.
|
프로젝트를 관리하는 입장에서는 최대한 업무를 쪼개서 예측이 실패하더라도 재빠르게 대응하는 방법이 있다.
예를 들어서 한 명의 프로그래머에게 A라는 업무를 주었을 때 이것의 예측 양이 한 달이라면 실패했을 때 한 달이나 날려먹게 된다. 의존 관계가 없다면 한 사람의 한 달치 월급 정도만 날린 것으로 생각할 수 있지만 이 사람에게 의존 관계가 엮인 모든 사람의 ‘한 달 월급 + 기타 비용’을 생각하면 매우 큰 낭비가 아닐 수 없다.
그래서 최대한 위험부담을 줄이려고 생긴 프로젝트 관리 방법이 업무량을 잘게 나누어서 최대한 작은 단위로 만드는 것이다. 만일 A라는 업무가 A1, A2, A3, A4로 나뉠 수 있다면 하나의 업무당 일주일의 시간을 가질 수 있다. 이 때 실패한다고 해도 ‘일주일 + 기타’ 정도의 시간만 낭비한다. 게다가 보통 마감일이 다가올 때 개개인은 마감일까지 주어진 일을 끝낼 수 있을지 없을지 예측할 수 있다. 이 때는 위험을 더 줄일 수 있다.
하지만 업무량을 무조건 잘게 나눈다고 해서 좋은 것이 아니고 항상 가능한 것도 아니다. 너무 작게 나누면 ‘마이크로 매니지먼트’(Micro Management)라고 해서 오히려 역효과가 날 수 있다. 결국 프로젝트 관리자가 개개인의 성향이나 업무 능력에 따라 적절하게 일을 나누는 방법을 제시해야 한다.
프로젝트 관리는 개개인으로서 신경 쓰지 않아도 될 것 같지만, 실제 게임 개발팀에 들어가서 일하다 보면 이 부분에 대해 신경 쓰면 쓸수록 좋다. 필자의 경우 프로젝트 개발 방법론을 혼자서 터득했는데 그것은 지극히 개인적으로 기억력이 안 좋아서였다.
기억을 잘하지 못해서 포스트잇 혹은 공책에 내가 무엇을 할지 적어 놓고 업무가 끝날 때마다 V자로 표시해서 업무가 제대로 진행되고 있는지 아닌지 알 수 있었다.
윈도우7에 기본적으로 설치 되어 있는 스티커 메모 프로그램.
스티커 메모 프로그램의 한 예.
스티커 프로그램을 포스트잇 대용으로 사용할 수 있다. 하지만 필자는 이것보다는 실제로 공책이나 포스트잇을 사용하는 편을 추천한다. 디지털로 되어 있는 것은 버튼 한 번이면 삭제되기 때문이다.
필자가 업무를 하면서 사용했던 공책들.
혼자서 축구게임을 만들 때 적어 놓았던 노트. 참고로 필자는 글씨를 매우 못쓴다.
포스트잇을 사용하는 것이 낭비처럼 보인다면 ‘트렐로’(Trello)라는 서비스를 이용해 보는 것도 괜찮다.
‘트렐로’(Trello)를 이용해 태스크를 관리하는 모습. 태스크를 만들고, 지우고, 이동하고, 편집하는 등 모든 작업이 하나의 카드로 관리된다.
업무를 잘게 쪼개는 연습, 계획했던 대로 업무를 시작하고 끝내는 연습을 하다 보면 자연스레 몸에 익숙해지고, 이렇게 업무를 진행하다 보면 내가 무엇을 할지 다른 사람이 쉽게 알 수 있게 된다. 프로젝트 관리자의 처지에서 보면 다루기 쉬운(?) 개발자가 된다.
※ 왜냐하면 어떠한 업무를 하고 있고 얼마만큼 시간을 사용했었는지 개발자 스스로 예측하고 진행할 수 있기 때문이다. 그리고 그것을 프로젝트 관리자가 언제든지 알 수 있다.
|
하지만 포스트잇이나 공책은 지극히 개인적인 영역이므로 다른 사람에게 충분히 공유될 수 없다. 그래서 이러한 포스트잇을 붙이는 공간을 개인 책상이 아니라 지정된 공간에 마련해 프로젝트가 어떻게 진행되고 있는지 알 수 있게 하는 방법론이 존재한다.
필자는 이러한 방식을 좋아한다. 하지만 이것을 강제하는 것은 좋아하지 않는다. 이것은 강제로 한다고 해서 되는 것이 아니기 때문이다. 습관이 되어 있지 않은 개발자에게 이러한 습관을 강제하면 오히려 역효과가 일어난다.
다른 예로 ‘테스트 주도 개발법’ 같은 방법도 본래 필자가 항상 사용하던 방식이었는데 정립된 어떠한 방법론으로 책이 나오고 이후에 그것을 공부한 사람들이 필자에게 이러한 개발 방법론을 강제했을 때 꽤 스트레스를 받았다. 습관 자체로 생각하는 것이 아니라 이러한 개발 방법론을 강제했기 때문에 오히려 필자 같은 사람에게는 역효과가 났다.
※ 테스트 주도 개발(Test Driven Development)이라고 하며 Kent Beck이라는 프로그래머가 저술한 책을 참고하도록 하자.
|
이처럼 게임 개발은 단순히 기술적인 것만을 공부해서 완성할 수 있는 것이 아니다. 게임은 혼자서 만들 수 없고, 여러 사람과 협업해서 개발해야 하며 그것을 가장 효과적으로 하기 위해 스케줄, 업무 예측, 리스크 관리와 같은 방법들이 생겨났다. 특히 프로그래밍에 관련된 것들이 많은데 그 이유는 가장 예측이 힘든 부분이기 때문이다.
이제 다시 본론으로 돌아와서 이야기해 보자. 게임 개발은 어쩔 수 없이(?) 혼자서 할 수 없게 되었다. 그래픽 디자이너도 필요하고, 사운드 디자이너도 필요하고, 게임 디자이너(기획자)도 필요하게 되었다. 그 외에도 많지만, 각각의 분야마다 전문화가 되었고 공부할 것이 태산처럼 많아졌다. 하지만 이러한 모든 부분을 다 알 필요는 없다. 본인의 업무에 전문가가 되면 된다. 물론 프로젝트를 진행하거나 게임을 완성하려면 프로젝트를 진행하는 중요 임무를 가진 사람 한 명 이상은 이 모든 부분을 알아야 한다.
프로젝트 관리에는 균형이 중요하다. 프로그램, 그래픽, 기획을 포함한 어느 하나에만 너무 치우쳐 버리면 프로젝트는 거의 100% 산으로 가게 되어 있다. 게다가 이러한 프로젝트는 개발팀의 진을 다 빼버리게 하는 결과로 이어지는데, 대부분 프로젝트 드롭, 팀 해산이 대표적이다.
필자는 아주 소규모의 게임 개발 팀부터 대규모의 게임 개발(MMORPG 및 콘솔게임) 팀에서 일했고, 수많은 실패 사례를 듣고 체험했다. 게임 <리그 오브 레전드>의 캐릭터 카사딘이 하는 말이 있다.
“힘의 균형은 유지되어야 한다.”
이것은 게임 개발에도 똑같이 적용된다. 균형이 한쪽으로 치우쳐 버리면 대부분 완성을 하지 못한다. 매니저, 기획자, 그래픽 디자이너, 프로그래머, 사운드 디자이너, QA 등등 중요하지 않은 분야가 없다. 그리고 이 모든 분야의 전문가들이 한마음으로 프로젝트에 임했을 때 최고의 게임이 나온다.
디스이즈게임 댓글 ()
디스이즈게임
