3월이 되었고, 학원은 개강했다. 나는 세부 기획안을 짜기는 했지만, 계속해서 팀원들의 문제점 지적은 계속되었다. 아무래도 "지휘로 전쟁을 지휘한다."라는 컨셉이 머리속에 한번에 들어오는 그러한 구상은 아니었기 때문이일 것이다.
우선, "플레이어의 지휘에 따라 병사들의 행동이 달라진다."라는 것으로 구체화 해나갔다. 플레이어의 지휘방법에 따라 병사들의 스탯이 변화하고, 스탯의 상태의 따라 병사들의 인공지능이 변화한다라는 것이었다. 이러한 기초를 토대로 기획서를 써나갔지만, 나 스스로도 어딘가 한 구석이 허전함을 알고 있었다. 하나의 퍼즐조각이 빈 직소퍼즐을 맞춰나가는 느낌이었다. 그래도 내가 만드는 게임은 신선해야한다는 강박관념이 있었고, 거기에 맞추기 위해 온갖 무리를 했었다.
대게 이런 강박관념들 때문에, 졸업 프로젝트때 메인 기획자들이 흔히 하는 실수가 있다. 보통 게임의 규모를 굉장히 크게 잡고, 무리한 기획을 한다는 점이다.
내 경우를 예를 들면, 음악 지휘를 <위 뮤직>처럼 플레이어의 지휘에 따라 자유자제로 음악의 빠르기를 조절할 수 있게 하자고 하였다.
<Wii Music>처럼만 구현 된다면 얼마나 멋있을까?
하지만 팀원들과 회의결과 이건 불가능하다는 결과가 나왔다. 마우스 포인터의 빠르기를 순간순간적으로 판단한다는 것은 어렵다는 것이었다. 나는 이를 해결하기 위해 결국은 키보드로 빠르기를 단계적으로 조절하는 방법으로 우회하였다. 이 외에도 많은 시스템들이 회의를 통해 점차 수정해나가면서, 애초의 기획했던 의도는 우리 수준에서 매우 힘든 것이었음을 실감했다.
당시 또 다른 주요 쟁점 중 하나가 스테이지의 수를 결정하는 것이었다. 나는 애초의 7명의 플레이가능한 캐릭터가 나오고, 각 캐릭터마다 7~8개의 스테이지를 배정할 생각이었다. 맵 툴로 스테이지를 판에 찍듯이 찍어내면 될 것이라는 생각이었다. 하지만 프로그래머 파트장을 맡은 형의 생각은 달랐다. 그렇게 많은 양으로 가려다가는 무슨 일이 생길지 모든다는 것과 그렇게 많이 찍어내기에는 일정이 부족할 것이라는 생각이었다. 결국은 스테이지 수를 줄여 단일 스테이지로 가자는 쪽으로 결정했다가, 나중에 다시 스테이지를 4개 까지 늘렸다.
결과적으로 보면 50여개의 스테이지를 만드는 일은 확실하게 무리한 생각이었다. 우리가 만든 게임의 맵의 수는 총 5개인데, 그걸 일정에 맞추어 만드는데도 상당히 힘들었기 때문이다.
그래픽 컨셉 또한 많이 불안한 요소 중 하나였다. 당시, 나는 좀 드문 그래픽 컨셉을 잡아보려고 시도하였다. '미래지향적인 판타지'를 추구 하고자 하였는데, 마땅히 예로 들만한 그림이 별로 없는 것이었다. 나름 일러스트집을 찾아보기도 하고, 인터넷을 뒤지기도 했지만, 내가 상상하는 그대로의 그림을 찾기란 쉬운 일이 아니었다.
또한 처음으로 원화가와 공동작업을 하는 터라 참고 사진을 보내는 일에도 많은 애로사항이 있었다. 원화가가 보기 힘든 사진을 참고자료로 주는 경우도 있었다. 가장 난감했던건 캐릭터 컨셉을 정해주는데 있어 얼마나 정확하게 묘사를 해주어야 하냐는 점이었다. 너무나 정확하게 그리고 참고 그림 그대로 묘사를 해주면, 참고그림과 너무 똑같은 그림을 그려줄지도 모른다는 두려움이 있었다. 그렇다고 너무 묘사를 대충해주면 내가 원하는 대로 그려주지 못할거라는 두려움도 있었다.
당시에는 원화가가 최대한 자세하게 묘사해주는 것을 원했기 때문에, 원화가에 맞춰서 기획서를 작업해주었다. 그리고 그림이 나왔을 때, 이전에 했던 걱정은 모두 기우였다는 것을 알 수 있었다. 그림의 독창성은 어느정도 확보되었기 때문이었다. 하지만 꼭 마음에 드는 것도 아니었다. 서로 학생이었기 때문에 많은 기대는 하지는 않았지만, 좀 더 수정되엇으면 하는 생각은 언제나 들었다. 물론 원화가도 그림이 어느정도 완성된 뒤에 보여주고 수정하는 작업을 거쳤지만, 많은 부분을 고치기에는, 이미 지나온 길이 너무 멀어보였다.
나중에 알게 된 것이지만, 그 당시 우리가 했었던 방법이 잘못되었다는 것을 깨달았다. 기획자가 처음 원화를 확인하는 시기가 채색되기 이전인 러프스케치 단계에서 일일이 확인하고, 수정하는 작업을 거칠 필요가 있었던 것이었다. 특히 실력이 가다듬어지지 않은 아마추어들에게는 이러한 과정이 자주필요하다는 생각이 든다.
3. 프로젝트 일정 잡기
학원 내에는 졸업 프로젝트를 중간 점검하기 위해, 4차례의 프레젠테이션을 한다(4차는 최종 완료일). 프레젠테이션 날에 자신의 팀이 한 성과를 보여주어야 하기 때문에 보통 이 프레젠테이션 날짜에 맞춰서 팀 일정을 짜게 된다.
우리 팀의 경우 프레젠테이션에 맞춰서 일정을 짜기 보다는 자체적으로 목표일을 잡았다. 할일의 목록을 크게 잡아놓고, 1차 목표일, 2차 목표일을 나누어 마감시한을 정해두었다. 물론 이 것도 단순히 목표 설정일 뿐, 제대로 지켜지지는 못했다. 아무래도 처음 만들어보는 3D게임이다보니 팀원들 모두 정확한 일정을 짜고 맞춘다는 건 불가능 한 일이었다.
자체적으로 일정을 잡았다고 하더라도, 결국에는 프레젠테이션 날짜에 맞춰서 작업하게 되었다. 아무래도 외부에 프로젝트 성과를 보여주는 날인 만큼 프레젠테이션을 소홀히 할 수 없기 때문이었다. 프레젠테이션의 성과는 팀원들의 사기와도 연관되었다. 그래서 종종 프레젠테이션 전날에 밤을 새우기도 했다. 물론, 그 다음날 바로 후회했다. 다음 날 제대로 작업을 하지 못하게 되면서 시간적으로 손해를 봤기 때문이었다.
(1/6)
<졸업 프로젝트 일정표... 라기보단 일정을 체크하기위한 달력.>
프로젝트 중반 부터는 프로그래밍 강사님인 김선생님께서 프로젝트 일정을 많이 봐주셨다. 각, 팀의 기획 파트장(대게의 경우 팀장)과 프로그래밍 파트장을 따로 불러서 일정을 봐주셨다.(기획파트 보다는 프로그래밍파트를 주로 봐주셨다.) 언제 까지 어느 부분 만큼 완성되어야 한다는 숙제를 내주셨는데, 기획파트의 경우 별로 무리한 숙제는 없었다. 그러나 프로그래밍 파트의 경우 상당히 무리한 요구를 하는 경우도 있어서, 이 일정을 제대로 맞추기는 여간 쉬운일이 아니었다.
기획 파트의 경우, 리소스 리스트를 만들라고 지시하시거나, 프레젠테이션 준비에 대해서 관여하셨다. 프로그래밍 파트의 경우에는 좀 더 자세히 봐주셨다. 주 단위로 작업일지를 제출하게 하셨고, 맡은 파트별로 좀 더 구체적인 지시를 하시기도 했다.
4. 1차 프레젠테이션
프레젠테이션에 대해서는 좋은 기억이 별로 나지 않는다. 대체로 밤을 새고 피곤한 상태에서 발표를 했었고, 언제나 남의 팀이 더 잘한 것 같아 보였기 때문이다.
그래도 1차 프레젠테이션에서 우리 팀은 나름 보여 줄 것이 많았다. 그래픽 파트가 기수 전체에 불과 3명(선생님 까지 4명)밖에 안되었다. 그래서 4개 팀 모두 작업을 해주는 형식이었는데, 다행히 우리 팀 작업을 제일 먼저 해주어서 그래픽적으로 보여줄 것이 많았기 때문이었다.(그래봐야 3~4장 정도?)
그 외에는 무난했다. 엔진은 틀이 잡혀있었고, 나머지 툴도 기본적인 부분은 완성되어 있었다.(툴로써 기능은 없었지만...)
<1차 중간 발표 당시 프레젠테이션>
그림파일로 추출하여 애니매이션이 들어간 장면은 이상하게 나왔다.
하지만 다른 팀 프레젠테이션을 보면 언제나 주눅이 들었다. 특히, 옆 팀인 "Nine O'Clock"팀의 프레젠테이션은 볼만 했다. 동영상을 활용해 프로젝트의 진행된 모습을 보여주었고, 그 진척도가 다른 팀에 비해서 높은 편이기 때문이었다.
또 개인적으로 프레젠테이션날이 힘든 이유가 있었다. 그 날은 프로젝트를 쉬는 날이 되었기 때문이다. 그날은 프레젠테이션이 끝나고 나서, 일찍 집에 갈 수 있었다. 하지만 본인의 경우 학원 조교(근로장학생)인지라 학원을 지켜야 할 의무가 있었다. 학원생들이 모두 떠난 교실을 외로이 지킨다는 건 정말 쉬운 일이 아니었다.(다행히 조교는 두 명인지라, 같이 있었던 형과 같이 외로움을 달랠 수 있었다.)
