JC의 일상사 ::

「위대한 게임의 탄생」을 읽고서, 그간 했던 프로젝트의 포스트모템을 써야겠다는 생각을 하게 되었다. 이건 그 첫번째.

드레드노트 포스트모템

서문
드레드노트는 2008년 6월에 시작하여 2009년 9월 19일에 프로젝트 종료된 게임이다. 퍼블리싱이 된 적이 없기 때문에, 아마 그 존재를 아는 사람이 많지는 않을 거라 생각된다[...] 우리 과 사람이면 알 가능성이 조금 높긴 하겠지만.
드레드노트는 서울대학교 컴퓨터공학부 유영대(05), 이연성(05), 김재찬(08), 서울대학교 시각디자인학과(...왠지 기억이 확실하진 않지만 맞겠지) 김보나(06), 김영호(07) 다섯 명이 만든, 스팀펑크 세계관 기반의 2:2 전용 3D TPS 게임이다.
한 팀은 땅을 걸어다니는 거대한 머신 드레드노트와 작고 하늘을 날아다니는 스팀라이더로 구성되며, 상대방의 드레드노트를 파괴시키면 게임에서 승리하게 된다. 보통의 공격으로는 드레드노트에 큰 타격을 줄 수 없으므로 강력한 공격을 해야 하는데, 이를 위해 스팀라이더는 맵 곳곳에 있는 증기탄을 모아서 드레드노트에 전달해 줘야 한다. 증기탄은 드레드노트가 강력한 공격을 할 수 있게 하고, 스팀라이더가 드레드노트를 수리하는 데 쓸 수도 있으며, 스팀라이더 고유의 기능을 수행할 수도 있다. 스팀라이더는 격추되어도 일정 시간 이후 드레드노트 근처에서 부활하게 된다.
3종류의 국가(영국/중국/조선) 중 하나를 선택하여 플레이할 수 있으며, 각 국가마다 스팀라이더와 드레드노트의 특수 기능이 다르다. 플레이어는 이를 초반에 잘 숙지하고 적절한 특수능력을 사용하여 승리해야 한다.
이 게임은 넥슨이 지원받을 게임 제작 동아리를 심사할 때 출품하여 우리 동아리(UPnL)가 선정되었으며, 여러 게임 공모전에도 출품했으나 아쉽게도 수상한 적은 없다. 퍼블리싱되지 않아 대중들이 접할 기회가 없었고, 앞으로도 퍼블리싱 계획은 없으므로 앞으로도 기회는 없을 것 같다. 다만 최근에 NEXONin(http://www.nexonin.com)에 동아리 제작 게임을 걸 기회가 생겼고, 드레드노트를 UPnL과 서울대학교 디자인학부팀의 합작이라는 이름으로 Xna로 포팅해서 거는 것을 고려하고 있다.

잘 된 점

끝냈다
이거 정말 중요한데, 인디 게임을 만들겠다는 열정을 가지고 의욕적으로 시작은 하지만 제대로 끝마치는 경우는 많지 않다. 제작을 진행하면서 결과는 언제 보일지 모르겠고, 정말 이게 재밌을까? 라는 생각이 계속 들면 의욕은 떨어지기 마련이다. 의욕을 지속적으로 끌어들이기 위해선 팀원들에게 끊임없이 비전을 보여줘야 한다. 그런 의미에서 드레드노트는 꽤 성공적이었다. 맨 처음에 한 게 비주얼 구현이었고, 비록 속은 없어도 보여주는 걸 가장 먼저 했으니까.
2년 넘게 끈 프로젝트였는데, 학부생의 신분으로(2009년에는 개발팀 중에 나만 학부생었고, 한 명은 대학원, 한 명은 회사원이 되었다) 이렇게 오랜 시간동안 한 프로젝트를 잡고 있는 건 정말 쉬운 일이 아니었다. 그럼에도 끈기있게, 어떻게든 끝을 보겠다는 마음으로 끝까지 하고 결국 완성까지 한 것은 정말 잘 한 것이라 생각된다.

빠른 프로토타입 완성
사실 드레드노트엔 프로토타입이라고 할 만한게 없다. 그럼에도 굳이 프로토타입이라고 한 이유는 그래픽 자원이 거의 없는 상태에서 빠르게 비주얼을 완성시켜서 어떤 모습이 될 지 미리 볼 만한 것이 있었기 때문이다. 그 때는 그래픽 자원이 없어 글자를 원통형으로 말아서(...) 드레드노트(그땐 엄마배)와 스팀라이더(그땐 아기배)를 만들고, 클릭하면 미사일이 날아가는 것을 구현했다. 이런 빠른 Visualization이 향후에 계속해서 게임을 개발해 나가는데 도움이 되었던 것 같다.

효과적인 분업
드레드노트는 오직 C#과 Managed DirectX 만으로 만들어진 게임이며, 다른 엔진은 아무 것도 이용하지 않았다. 따라서 TPS 게임을 만들기 위해 처음부터 모든 엔진을 만들었어야 했는데, 엔진을 만들기 위해 자칭 슈퍼프로그래머(...) 유영대 선배가 3D/물리 엔진 및 네트워크 클라이언트/서버를 만드셨고, 이연성 선배는 엔진 기초부분을 제외한 거의 모든 부분(?)을 담당하셨다. 그리고 나는 2D UI, 잔버그 몇 개 수정 등을 했다(그 땐 C# 프로그래밍, 아니 프로그래밍 자체가 처음이었으니까...) 이렇게 파트가 나눠진 덕분에(의도적인 건 아니었지만) 비교적 빠르게 작업이 이루어질 수 있었다.

자주 가진 모임
학교에서 하는 프로젝트가 잘 되지 않는 이유 중 하나는 자주 모이지 않아서 피드백과 동기부여를 받을 기회가 많이 나지 않는다는 것이다. 초반에는 자주 모여도 얼마 지나지 않아 바쁘다는 핑계로(실제로 바쁘기도 하고), 그리고 여러가지 약속도 생기고 해서 모임 자체가 이루어지지 않는 경우가 많다. 그렇게 되면 팀원들은 자기가 코딩을 해도 프로젝트에 기여하고 있다는 느낌을 받기 힘들게 되고, 의욕도 떨어질 수밖에 없다.
드레드노트는 처음 만들 때 유영대 선배는 우리를 거의 강압적으로(?) 유피넬 동아리방에 모여서 작업을 하기를 지시했고, 그래서 나의 첫 대학 여름방학은 그렇게 날아갔다(...) 하지만 소중한 경험이었다. 10시까지 동아리방에 와서 놀기도 하고 이것저것 하다가 막차를 타고 집에 돌아가는 걸 월요일에서 금요일까지 하기는 정말 쉬운 일이 아니다. 심지어 회사 다니는 지금도 그렇게 의욕적으로 코딩을 하진 않는다. 모이고서 코딩만 하는 건 아니고 같이 놀기도 하고, 아이디어 회의를 하기도 하면서 드레드노트 작업을 했다. 중요한건 모여서 일을 하느냐 마느냐가 아니라 모인다는 것 그 자체인 것 같다. 모여서 오랜 시간 함께 작업을 하는 것만으로도 능률은 배 이상으로 오른다.

효과적인 커뮤니케이션
사실 팀원이 5명이었기 때문에 여기서도 커뮤니케이션이 제대로 이뤄지지 않을 수 있냐고 반문하는 사람이 있을지도 모르겠다. 하지만 팀원이 단 둘이라도 커뮤니케이션이 제대로 이뤄지지 않을 수 있다. 하물며 개발팀 셋/아트 팀 둘 로 나눠진 이 상황에서, 소통에 조금만 신경을 덜 써도 개발팀과 아트팀이 완전히 단절될 수도 있다.
하지만 드레드노트는 아트가 필요한 일이 있을 때는 아트팀도 유피넬 동아리방에 와서(아트팀은 유피넬 회원이 아니었다. 지금도 아니고.) 모델링과 텍스쳐 작업을 하고 일부 코딩을 하기도 하였다. 모이는 시간이 많은 것과 밀접한 관련이 있는데, 우리는 회의를 할 때 메신저는 거의 이용하지 않고 오프라인으로 모이는 걸 선호했다. 오프라인으로 모이는 건 메신저로 대화하는 것보다 몇 배는 효율적이다.

잘못된 점

늘어진 개발 기간
애초에 드레드노트는 2008년 여름방학 때 개발하고 끝낼 프로젝트였다. 사실 그 때 게임의 모습은 현재 드레드노트와는 컨셉이 어느 정도 비슷하기만 하지 전혀 다른 게임이었다. 탑뷰 형식의 2:2 슈팅 게임이었고 프로토타입은 7월이 지나기 전에 거의 완성된 상태였다. 그런데 뒤에서 후술할 여러가지 이유 때문에 개발 기간이 너무 늘어졌다. 1년 3개월이 걸렸으니 거의 5배로 일정이 길어진 셈이다. 이 상태에서 끝낸 것이 기적이라고 생각된다. 기간이 늘어짐에 따라 프로젝트 자체가 좌초될 위기도 여러 번 있었다. 물론 예상 Due가 지켜지는 경우가 거의 없긴 하지만, 이 정도는 좀 심하다고 생각된다.

완전히 바뀐 컨셉
앞에서 말한 바와 같이, 원래 드레드노트는 이름이 드레드노트도 아니었고, 탑뷰 형식의 2:2 슈팅 게임이고 배경도 우주였다. 스팀라이더(그땐 스팀라이더가 아니었지만)가 소행성을 파괴해서 나오는 광석을 모아서 드레드노트(그땐 드레드노트가 아니었지만)에게 전달하면 적 드레드노트를 강력한 필살기인 그랜드캐논으로 강한 데미지를 줘 없애면 승리하는 방식의 게임이었다. 그래픽 리소스가 만들기 그렇게 어려워보이진 않았으므로 2008년 여름 방학 내로 끝낼 수 있겠다고 생각했는데, 프로토타입이 거의 완성된 7월 중순 즈음에 아트 팀에서 TPS 게임으로 바꾸자는 제안을 했고(그 때 아트팀은 3D 모델링에 대한 열망이 넘쳤던 것 같다) 그게 별로 부담이 될 것이라고 생각하지 않았던 개발팀은 간단하게 컨셉을 갈아치우기로 했다. 그리고 그 여파는 개발기간을 1년 연장하는 결과를 낳았다(...)
더 좋은 게임, 더 멋진 게임을 만들려는 건 좋다. 하지만 완전히 컨셉을 바꾸는 건 또 다른 이야기다. 이런건 개발에 돌입하기 전에, 기획회의를 할 때 나왔어야 했다. 처음부터 3D TPS 게임을 만들자는 게 합의가 되었으면 개발 기간이 조금은 단축되었을 것이다.

베이스부터 제작
드레드노트는 잘 된 점에서도 서술한 바와 같이, 완전히 처음부터 만든 게임이다. 그러니까 DirectX만을 가지고 3D 모델링 렌더, 중력, 속도 및 가속도, 충돌 처리 등을 모두 처리했다. 이건 게임 엔진을 다루게 된다면 소중한 경험이 될 수도 있겠으나, 이렇게 제작한 엔진이 시중에 나와 있는 여러 엔진을 따라갈 수는 없다. 결국 나중에는 최적화가 제대로 되지 않아 그 당시의 중급 컴퓨터로는 버벅대서 제대로 플레할 수도 없는 게임이 되었다. 물론 그 때는 '처음부터 내 손으로 만들어보자!' 라는 생각이 있었기에 그렇게 제작한 것이었지만, 조금만 뒤져봐도 3D 게임 엔진은 상당히 많은데 그런걸 썼으면 개발 기간은 줄어들고 최적화는 잘 되면서 양질의 게임을 만들 수 있지 않았을까? 엔진의 사용법을 배우는 것도 일이겠지만, 바닥부터 새로 만드는 것보다야 나을테니.

튜토리얼의 부재
보통 유저는 드레드노트 게임을 시작하면 무엇을 해야 할 지 모른다. 도움말에는 게임의 목표와 플레이 방법, 사용 키, 전략 등이 나와있긴 하지만 (당연히) 유저는 도움말을 읽지 않는다. 빨리 플레이하고 싶은 생각 뿐인 유저에게 도움말은 아무 쓸모 없는 텍스트 덩어리일 뿐이다. 아니, 애초에 도움말 버튼이 잘 보이지도 않는다.
그래서 처음에 유저가 들어오면 튜토리얼을 제일 먼저 하게 해야 한다. 그래서 게임의 목적과 스팀라이더의 역할, 드레드노트의 역할을 알려주고 자연스럽게 유저가 드레드노트 게임 내에서 하는 일을 알게 했어야 했는데, 일단 게임 완성만 하자는 일념 하에 그런걸 전혀 고려하지 않았다.

테스트의 부재
게임은 만들었으면 사람들이 즐길 수 있도록 해야 한다. 여러 사람들에게 하게 해서 피드백을 받고, 그 피드백을 바탕으로 버그 수정 및 기능 개선을 하는 게 게임 개발의 기본 중 하나이다. 그런데 우리는 앞서 말한 '일단 완성만 하자'는 일념 때문에 테스트 같은 걸 거의 하지 못했다. 내부적으로 약간의 테스트가 있었고 동아리원들에게도 한 번 해보라고 권유하기는 했으나 그 피드백 결과가 잘 나오지 않았고, 나온 피드백 결과를 잘 활용하지도 못했다. 결과적으로 테스트는 거의 하지 않았던 거나 마찬가지였으며, 그래서 그렇게 훌륭한 게임이다... 라고는 하기 힘든 게임이 되었다.

결론

학부생의 신분으로 이런 3D 게임을 만들어볼 기회는 흔치 않다. 이 기회가 내가 1학년 때 온 것은 대단히 큰 행운이다. 게다가 게임 자체도 꽤나 재미있게 플레이할 수 있는 게임이다. 앞서 말한 여러 가지 잘못한 점들이 많긴 하지만, 일개 동아리에서 이 정도의 게임을 만들어냈다는 건(동아리원만으로 이루어진 팀은 아니긴 한데) 꽤 의미가 있다고 생각한다. 같은 팀에서 더 이상의 게임이 나오지 않고 있는데, 이건 팀원들의 여러 가지 사정이 있기도 하지만(주로 회사 취직), 드레드노트 같은 작품을 만들어서 팀 내부에서부터 기대치가 너무 높아지다 보니 게임이 잘 나오지 않는 것 같기도 하다. 드레드노트는 회사가 만들었다고 하면 그저 그럴 게임이었겠지만, 팀 전원이 학부생일 때부터 시작해서, 그것도 오직 DX만 써서 여기까지 만든 건 대단히 훌륭한 성과라고 할 수 있을 것이다.