Anarak, Zombie shooting survival game

 

• Project Anarak
  https://www.youtube.com/watch?v=gYu9qzL89RA

 

언리얼 엔진4를 통한 FPS 생존게임 개발이 끝이 난지 2달이 지났다.
나는 비록 프로그래머이지만 팀에서 아트를 담당했다.
평소에도 프로그래머같은 사고보다는 예술가적 관점에서 사고하는 경우가 많았고, 솔직히 예술을 하고싶다.
그런 욕심이 있었기에 먼저 아트를 맡겠다고 하여, 그리 되었다.
언리얼 엔진에서 아트와 관련된 기능을 대부분 만져보았고, 최적화도 나름 잘 했다. 단순하지만 컷신도 만들었다.
눈으로 보이는 것들을 만드는 데에 기초적인 부분은 모두 익힌 좋은 경험이었다.
하지만 그런 소득과는 별개로, 만들어진 결과물은 처참했다.
내 맘에 드는 작품도 아니었고, 교수님과 학생들의 평가에서도 하위권을 차지했다.
이런 결과와 과정에 대해서 배운 점들을 잊지 않도록 이 글에 정리한다.

자신의 의견을 보다 강하게 어필하기.

나는 내 역할에 솔직히 최선을 다했고, 괜찮은 결과물이 나왔다고 생각하고 있다. (최고라고 할 수는 없다, 나는 초보자니까)
일주일 평균 5일은 계속 깃허브에 커밋했고(협업 툴로 깃허브를 사용했다.), 눈에 보이지 않는 부분에도 나름 많은 고민이 있었다.
팀원들이 원하는 배경에 알맞은 건물을 찾기도 어려워, 직접 모델링을 하고 텍스쳐를 입혔다.
쉬운 작업은 아니었으나, 최선을 다했다. 이 결과물들에는 후회는 없다.
하지만 게임이 재미없고 형편없으면 그게 무슨 소용인가?
게임이 재미있어지도록 계속해서 의견을 냈어야 했다.
모델링을 하면서도 우리가 만들고 있는 무언가는 결코 게임이 아니었음을 깨닫고 있었지만 이를 팀원들에게 강하게 어필하지 않았다.
내게 더 적극성이 있었더라면, 더 사교적인 사람이었다면, 더 공격적인 개발자였다면 더 좋은 게임이 나올 수 있었을까?
나는 아트에 집중하고 있었기 때문에 회의시간이 되면 내 결과물들을 공개하고, 게임 기획에 관련해서 부족한 부분들에 대해 고민했던 것들을 이야기했다. 게임에 목표에 대해서 아이디어를 내고, 그 목표가 플레이어가 보기에 설득력이 있도록 나름대로 구상하여 팀원들에게 이야기했고, 팀원들도 좋은 아이디어라며 채용했었다.
반면 총보다 근접무기 위주가 되어야한다, 낮과 밤의 사이클이 너무 빠르다, 고쳐야 한다같은 의견은 몇번을 말해도 고쳐지지 않았다.
이 때 내가 했어야할 일은 바로

• 더 강하게 밀어붙이고, 나중이 아닌 지금 당장 바꿔달라고 요청하기.
• 내가 직접 바꾸기.

였을 것이다. 다만 하지 않았던 이유가 있다면, 내가 코드 작성이나 블루프린트에 관여하지 않았던 부분들이었기에 내가 만졌다가 트러블이 생길 가능성에 대한 우려와,
나 자신이 공격적으로 밀어붙이는 것을 못하기 때문이었다.
다음에 내가 다시 프로젝트를 할 일이 있다면(무조건 있다.), 그때는 강력하게 내 의견을 주장해야 한다, 멋진 게임을 만들기 위해서

기획을 탄탄하게 하기.

이런 소규모 프로젝트에 기획에 많은 시간을 쏟지 말라는 교수님의 말씀이 있었다.
이 때문에 팀원들은 기획보다는 기능구현에 열심이었는데, 나는 조용히 있었지만 생각이 달랐다.
기능구현이나 아트와 동일하게 기획은 중요하다. 설계도 없이 어떻게 건물을 짓겠는가?
기획을 설계도에 비유해서, 게임개발에서의 설계도는 “연필로 작성된 설계도”여야 한다.
무슨 말이냐면, 개발 팀은 개발 도중에 기획에서 잘못된 부분이나 더 좋게 수정될 수 있는 여지가 생길 때,
그 부분을 지우개로 지워버리고 새로 작성할 수 있어야 한다는 것, 즉 유연한 대처가 필요하다는 것이다.
이번 게임개발에서 정말 강하게 체감했던 것은, 기획 단계를 너무나 소홀히한 것이다.
명확히 작성된 기획서는 개발팀의 팀원 모두가 “같은 게임”을 상상하게 만든다.
이번 프로젝트에서 우리는 모두 “다른 게임”을 상상하고 있었다.
따라서 많은 소통에도 불구하고 서로 다른 결과물을 상상하고, 그것을 만들어 온다.
팀원들이 그 결과물들을 보여줬을 때, ‘이게 내가 들었던 그게 맞나?’라는 생각이 문득 든 것이다.
기획에 많은 시간을 쏟지는 않아도, 게임에 규모에 맞는 명확한 기획은 반드시 필요하다.
이번 프로젝트의 가장 큰 패인은 바로 그곳에 있었다.

소통의 횟수 줄이기 않기

개발이 진행되면서 모두의 열정이 식어갔는지, 결과물에 대한 부정적인 감정들이 쌓여갔는지 잘 모르겠다. 적어도 나는 그랬었던 것 같다. (그렇다고 대충하지는 않았다, 최선을 다했다.) 나는 처음으로 모여 회의시간을 정할 때, 매일아침 모이는 것을 제안했지만, 모두 농담으로 받아들이고 말았다. 그리고 회의는 일주일에 두번 하기로 했다.
일주일에 두번이었던 회의가 한번이 되고, 모이지 않는 주도 생기게 되었다.
팀의 리더가 소통의 횟수를 줄일 때 나는 반대했지만, 첫번째 항목에서도 말했듯이 강하게 어필하지 못했고, 그렇게 점점 소통의 횟수를 줄어들어갔다.
“기획을 탄탄하게 하기” 파트에서 말했던 “같은 게임”을 생각하기 위해선, 명확한 기획도 필요하지만 더 중요한 것은 “소통”이다.
최대한 많은 아이디어를 공유하고, 서로가 생각하는 점들에 대해서 끊임없이 이야기해야 한다.
과거 다른 강의의 교수님께서 “같은 철학”을 공유하는 것은 매우 중요하다는 말씀을 하셨을 때 깊이 공감했었다.
같은 생각을 하는 것은 매우 중요하다. 나는 이것이 개발자로서 20%의 역량차이는 가볍게 메꿀 수 있는 중요한 부분이라고 생각한다.
그런 생각들을 항상 생각으로만 하다가, 이번 프로젝트가 이를 입증했다. 소통과 생각은 너무나도 중요한 부분이다.

여기까지 내가 느낀 점이지만, 본 프로젝트를 떠올리는 순간마다 다시금 느끼는 점이 있다면 최신화하도록 하자.
성공보다 실패에서 많은 것을 배우는 법이다.