-
-
0년차 게임 개발 - 아마추어들의 게임 프로젝트 관리와 기획, 게임 디자인 이야기
김다훈 외 지음 / 성안당 / 2021년 8월
평점 :
구판절판
네 분의 게임 개발자가 이 책의 공저자들입니다. 연령대는 다양한 듯 보이며 처음부터 게임 개발을 천직으로 여긴 듯한 분, 나중에 게임학과에 입학한 분 등 동기와 경력 들도 각기 차이가 나는 듯했습니다.
게임 개발은 요즘 젊은 세대 사이에서 핫한 직업 중 하나로 떠올랐고, 얼마전까지만 해도 크래프톤, 넥슨이나 NC 등이 투자자들의 큰 주목 대상이었으며, 직접 게임 관련은 아니지만 소위 네카라쿠베, 혹은 네카쿠야 라고 해서 IT 기업 소속 개발자군이 선망 대상임이 분명해지기도 했습니다. 그런 점에서 이 책은 게임 개발자들의 삶이 어떠한지, 해당 직업의 자부심과 보람, 혹은 애환이 무엇인지 엿볼 수 있는 좋은 기회가 되었습니다. p20에 보면 용어 해설에서 "개발자"란 프로그래머뿐 아니라 널리 게임 디자이너, 아티스트 등을 널리 포함한다고 합니다. 이에는 2D 아티스트도 포함되는데 예를 들면 이 책 저 뒤 p192, p194, p196 등에 그 작업이 소개되는 엄수영 씨, p209의 곽연정 씨 같은 분들이겠습니다.
<괴도 앙팡>은 수업을 위해 진행된 프로젝트였으며 이 부분은 박소현 저자가 집필했습니다. 교내 프로젝트이므로 우리 같은 일반인이 잘 모르는 게 당연한데요. 이 부분을 읽고 완전한 문외한이었던 독자로서 아 이런 식으로 게임 하나가 만들어지는구나 하고 아주 어렴풋한 감이나마 잡을 수 있었습니다. 캐릭터는 일단 시각적으로 인식이 쉬워야 하는데, "맵 크기의 최대치를 정했더니 맵 구성의 범위가 좁아지면서 퍼즐이 매우 한정적으로 되"는 문제가 발생(p31)했다고 합니다. 개발자는 전혀 아니고 일반 유저의 입장에서 이 대목을 읽었으나, 아마도 대개 무슨 의미인지 정도는 감이 올 것입니다. 이 "맵"에 대해서는, 책 저 뒤의 pp.184~190에서, 같은 저자가 더 상세하게 설명을 해 주는 대목이 나옵니다. 또 "포털"이라는 게 그런 뜻으로 쓰이는지(p31)도 처음 알았습니다.
여기서 우리가 눈치챌 수 있는 건, 게임 개발도 일반 제품 디자인이나 마찬가지로, 이런저런 상황에 대입하여 시행 착오를 거친 끝에 시장에서 가장 거부감 없이 받아들일 수 있는 꼴을 갖추고 출시된다는 점 정도이겠습니다. "앙팡"은 물론 enfant의 불어식 발음이며, 우리에게는 애니메이션 혹은 지면 만화 캐릭터인 "괴도 루팡(뤼팽)"이 이미 익숙하기 때문에 두 단어 발음의 유사성(하나는 프랑스 출신일망정 일어, 하나는 불어 발음이긴 하나) 때문에 나온 이름이겠습니다.
pp.36~40에는 제작 or 작업 목록이 나오는데 여기에는 애니메이션(작품을 말하는 게 아니라 개별 연속동작 구현을 뜻합니다) 목록, 연출효과, UI 작업 목록 등이 포함됩니다. 이 중에는 개발자들끼리의 소통을 위한 것도 있고, 나중에 출시 후 유저들에게 알려 줄 튜토리얼로 활용할 전단계 자료도 있습니다. <괴도 앙팡>이라는 게임을 해 보지 않았기에 알 수 없으나(앞으로도 영원히?), 아 이런 식으로 게임이 만들어지는구나, 또 이런 동작 이런 효과를 낳기 위해 이런 토론과 고민이 이뤄지는구나 하고 고개를 끄덕여가며 상상하게도 되었네요. "UI 아티스트에게 다소 강하게 내 의견을 전달했는데 그가 공과 사를 잘 구별할 수 있으리라는 신뢰 때문이기도 했다(p42)."라든가, "결과물이 좋고 나쁨과 상관 없이 협업의 경험과 사례를 돌아보는 것이 앞으로의 발전에 양분이 될 수도 있다는 점을...(p7)" 같은 대목은, 아무래도 커리어상 본격 협업보다는 프리랜서로서 개인 작업이나 프로젝트 참여가 더 많을 젊은 개발자들에게 큰 도움이 될 격려 같습니다.
프로젝트 <나이트베리>에 관한 두번째 개발 사례의 집필자는 김다훈 저자입니다. "현실적으로 학교에서 개발하는 게임은 취업의 관문이 되기 마련이고..."라든가 머리말 중의 "팀 개발에서 불화를 최소화하는 방법은 존재하며, 프로젝트 관리를 통해 팀이 해체되는 것을 막을 수 있다(p5)" 같은 대목에서 이 저자가 지금 이 책(의 해당 집필 부분)을 통해 무슨 말을 주로 하고 싶었는지 어렴풋이나마 짐작할 수 있었습니다. 곳곳에서 게임 개발자도 개발자이지만 프로젝트 관리자(p69, p71)로서의 고충이 드러나는 듯했습니다. 참고로 다른 대학도 사정이 비슷하겠으나 이 책에서 언급되는 "학교"는 저자들이 속했거나 현재 속해 있는 청강문화산업대를 가리키며, 작품은 미대생들처럼 "졸업 작품"을 가리키는 경우가 많습니다. 이 게임 <나이트베리>는 넥슨GT에서 선정한 우수게임이었으며, 그럼에도 불구하고 저자 눈에는 아쉬운 점들이 여전히 눈에 많이 띄었다고 합니다.
독자로서 저 개인적으로는 세번째 사례 <캣칭>에서 보다 생생한 개발 과정 구체적인 모습을 엿볼 수 있었던 듯합니다. 특히 pp.78~81까지의 서술에서는 개별적인 완성도를 놓고 치열하게 고민을 할 뿐 아니라, 아예 방향성까지 수정되곤 하는 모습이 느껴집니다. 게임은 이렇게 만드는구나, 또 프로그램의 지식이 게임이라는 시각적 UI에 이렇게 적용되거나 접점이 생기는구나 같은, 아주 어설픈 문외한의 감각이었지만 말입니다. 또 p91의 테이블 엎기 게임안 문서를 보고, 이 부분 집필자인 이재호 저자 같은 분들이 하는 일에 대해서 역시 어렴풋하게나마 감이 욌고 말입니다. 팀명이 잔다르칸이라고 나오는데 그 작명 동기에도 공감이 갔습니다.
아마도 게임 개발자들이 현실적인 관심을 특히 느낄 만한 부분은 p109 이하의 step2가 아닐까 생각합니다. 개발자라면 step1의 내용은 가장 많이 시간을 투자할 만한 작업들이며, step2에서는 팀빌딩이라든가 일정관리, 커뮤니케이션 방법 등이 나오는데 개발자로서는 설령 실무 능력이 뛰어나도 오히려 이런 부분이 낯설거나 서투를 수 있기 때문이죠. 반대로 게임 개발 업무와 무관한 일을 하는 독자는 이 대목이 당장 읽기는 가장 편하지 싶습니다. 이런 부분은 사회 생활에서 으레 겪게 마련인, 소통과 인간 관계, 혹은 조직론의 각론과 디테일에 관련된 것이기 때문입니다. 다른 면도 있고, 또 아 이런 부분은 공통점이구나 싶은 면도 있었습니다. 일정관리에 대해서는 pp162~165의 표가 독자의 이해에 큰 도움이 되었습니다.
게임 개발자가 되려면 개별 프로젝트에서 적용할 만한 여러 기법들을 알아 둬야 하며, 이 중 어떤 것을 해당 스테이지에 적용시킬지가 바로 개발자의 역량 척도가 아닐까 싶었습니다. 이를테면 p197에 나오는 FSM 같은 것입니다. "미리 계산해 두어야 하고 무한하게 만들 수 없으므로 유한한 상태를 가진 기계가 된다(p197)."
"학생들의 개발에서 교수님의 피드백은 위험하면서도 달콤하다(p229)." 즉 교수님들은 "상용화까지 가 보신 분들이므로" 장단점이 한눈에 보이기 마련인데, 좋은 평가를 받지 못한 경우 "위축되고 활기가 사라지거나" "아예 팀이 붕괴되는 경우"도 잦다고 합니다. 그러나 외부 피드백(교수님은 당연히, 당해 프로젝트의 구성원이 아니므로 외부겠죠)은 어떤 경우에나 필요하며 게임이란 상용화를 전제하는 상품이기 때문입니다. "결국 책임을 지는 사람은 내부의 책임자이기 때문(p240)"에 이 외부 피드백은 양날의 칼이라 할 만합니다.
게임뿐 아니라 일반 회사라고 해도 요즘은 어떤 천재적 기안자의 주도로 일이 진행되는 경우가 극히 드뭅니다. 물론 팀장 역량이 뛰어나서 각 분야의 최고들을 한 데 모아 드림팀을 꾸릴 수는 있지만, 오히려 이 경우 아폴론의 역설처럼 더 분위기가 융화 안 되기도 합니다. 게임이란 더군다나 각 분야의 겸직이 어려운, 다채로운 개성과 역량이 팀 안에서 잘 조화되어야 최종 프로젝트의 성공이 가능하다는 점, 그 디테일에서 기술적으로 이러이러한 난점이 있겠구나 하는 점들에 대해, 책을 읽으면서 공감하게 되었네요. 이런 점은 역시 IT 서적에 다년간 깊은 노하우를 쌓은 출판사에서 책에 잘 구현할 수 있었겠다는 점도요.
*본 포스팅은 네이버 카페 문화충전으로부터 제공 받아 솔직하게 작성된 서평입니다.