<게임 추상화의 바닥에 대한 산만한 이야기>
김동은WhtDrgon.160418#게임기획자하얀용
개요
이 글은 2016년 4월 18일 페이스북에 포스팅했던 글입니다.
옛날 글이기도 하고 다소 산만하지만 전자공학과 부품들, 원론적 물질 구성에 대해 낯설게 하기를 시도하여 추상화로부터 벗어나기 위해 추상화를 파보는 것을 시도한 글입니다. 제목에 경고드립니다. 산만하다고 :)
본문
<게임 기획의 영역에 대해 고민하기 위한 이야기들.>
- 게임 제작의 추상화 단계들에 대한 조금 많이 멀리 가는 산만한 이야기.
워런 버핏과의 점심을 생각해보자. 내가 정말 만나고 싶은 사람이 있나? 그 사람과 40분 정도 식사를 함께 하게 된다면 내가 뭘 물어볼 수 있을까? 오직 그 사람만이 대답해 줄 수 있는 훌륭한 '질문'을 가질 수 있다면 이미 답에 다가가 있는 것이다. 배우는 사람은 질문으로 상대를 (스승이 될 수밖에 없도록) 강요한다. 고로 질문에 답이 있다. 게임 기획이 뭐냐? 무언가에 대한 답을 찾을 때 나는 키워드에 먼저 집중하는 편이다. 어떤 관념들(을 담은 키워드들)에 대해서 고민해야 하는가? 내가 뭘 궁금해하는지 알 수만 있다면 답은 쉽게 알 수 있다.
그래도 뭔지 모르겠다면 키워드를 다른 언어로 바꿔보면 된다. 이 작업은 복합적 단어들을 좀 더 뚜렷하게 분리해준다. 가령 이렇게 해보자. 기획. 기획을 영어로 바꾸면 무엇이 될까? Design? 정말로 게임 디자인'만'일까? Plan은 어떨까? 프로그래머는 프로그래밍을 하고, 그래픽은 그래픽을 한다. 기획도 기획을 하는데 문제는 게임 개발에는 '사업 지원영역'이 있고, 개발팀이 이걸 틀어잡고 있는 이상 누군가가 이걸 해야만 하는데, 게임 기획자들이 여기에 투입된다.
실은 그래픽도 동일한 작업을 한다. 원화-2D-스프라이트-애니메이션-등등.
내가 '그림 그리는 기획자'라고 부르는 원화가들의 역할도 더 중요해졌다. 예전 프로토타입은 분홍색 상자들이 일단 자리를 차지하는 핵심 구현 부분이었지만, 지금의 프로토타입은 '개발팀이 뭘 만들지 알고 있다'라는 것을 증명하기 위해 완성된 게임의 스크린숏을 원화로 그려야 하는 상황이다. (이미지 샷이라고 한다.)
암튼 그래도 애매하면 단어에 내포된 하위 의미를 분류한다.
<추상화의 분해>
게임 기획자의 업무 자체가 게임의 높은 추상화 단계에서 진입하는 탓에 비개발 영역을 설득하기 쉽고, 개발 영역에서 서류와 숫자를 다루고 발표를 하기 때문인 탓이겠다. 이 영역은 종종 조롱거리가 되는 구인공고의 'PM업무 가능한 팀장급 기획자'로 대표된다.
매니지먼트 영역에 이런 단어가 있다. POSD CoRB. Planning, Organizing, Staffing, Directing, Coordinating, Reporting, Budgeting인데, 마지막 Budgeting도 BM기획이라는 이름으로 기획자에게 떨어진다.
( https://www.facebook.com/whtdrgon/posts/1148870338479143 참조)
물론 이것이 게임 기획의 공식(?)적인 역할은 아닐지라도 실제로 기획자의 영역으로 밀려 들어온다. 물론 QA, 운영, PM들, 디렉터, 아트디렉터, 테크니컬 디렉터로 분류하여 분배하기도 하는데 이건 분담할 만큼 회사가 커졌을 때 이야기. 이쯤 되어있으면 기획도 시나리오, 콘텐츠, 시스템, UI, 이벤트 등으로 분리되어 있을 것이다.
저 많아 보이는 일은 '하나의 정점'을 가지고 있다. '게임의 완성'. 그 과정에서 게임 기획자의 일은 게임 제작의 시작이면서 중간이고 끝이 된다. 기획이란 단어는 상당히 많은 단계의 추상화를 가지고 있어서 방대한 의미를 내포하게 된다. 물론 컴퓨터 게임 자체가 많은 단계를 가지고 있다.
물론 프로그래머들도 추상화 단계들을 가지고 있다. 류종택 님의 이런 글도 이해에 도움이 될 것이다. http://ryulib.tistory.com/51 기획자는 더 높은 추상화 단계에 위치한다.
높은 추상화는 낮은 추상화에서 '구현'이 되기 때문에 기획자는 기획을 함에 있어서 '아랫 단계에서 정확히 무슨 일이 벌어지는지' 대답해야 한다. 이게 허공에 가 있으면 프로그래머가 기획자에게 화를 내기 시작한다. 여기서 사장님/경영/사업/서비스팀과 각부 프로그래머들 / 아트 디자이너 등의 실무자 사이에 기획자가 놓이면 그 난이도가 급상승하기 시작한다. 기획자는 이 시점에서 자신의 역할이 어디에 있는지를 정하지 못하면 곧 어느 한쪽 (또는 양쪽)에게 존재 의미를 부정당하게 된다. (경험담)
기획의 분류에 대해서 궁금하다면 시간을 내서 '전사가 강타 스킬을 쓰면 110의 대미지를 주고 적이 나자빠집니다'라는 기획이 무엇을 의미하는지 저 바닥에서부터 한번 훑어보자. 어차피 이 포스팅은 공짜이고, 지면은 충분하니까.
전기 발생(flow) : 열, 빛, 압력, 화학작용, 전자유도, 마찰에 의해 전기가 발생한다. 석탄이든 석유든 원자력이든 열을 얻어서 물을 끓여서 그 힘으로 발전기를 돌리든, 낮은 곳으로 흐르든, 조수간만의 차든 물의 이동이나 바람의 이동으로 돌리든 발전기가 돌아가면 전기가 발생하고, 구리선 같은 전도체에 전기가 통하게 된다. 우리는 전기가 ‘통하거나 안 통하거나’ 하는 2가지 상태를 가지게 된다. 또한 전기는 신호 이외에도 여러 가지 방법으로 다른 형태로 전환된다는 특징 때문에 현대문명을 이루고 있고, 우리는 그것으로 게임을 만들고 즐기고 있다. 하지만 우리는 컴퓨터 게임을 만들 때 (대체로) 전기를 염두에 두진 않는다. 추상화되어있으니까. '하- 이 게임 빠떼리 킬러네.' 정도?
필라멘트 : (View) 전구. 특정한 환경에서 전기는 빛과 열을 발한다. 어떻게 생겼든 전구라고 해두자. 전기가 들어오면 켜지고, 아니면 꺼진다. 이 영역이 바로 ‘View’의 영역이다. 전구를 모아놓고 순서대로 켜고 끄는 것으로 우리는 지하철이 전 역을 통과했다는 사실을 알 수 있다. 컴퓨터나 스마트폰의 모니터도 그렇다. 우리는 전등에 대해 고민하지 않는다. pixel이라는 개념으로나 쓸까.
반도체 : (Control) 진공관 혹은 트랜지스터 : 다른 선에 전기가 통하냐 안 통하냐에 따라 본 선에 전기가 온오프 된다. (전기가 흐르는) 도체이기도 하고 아니기도 하다고 해서 반만 도체. ‘반도체’라 부른다. 이제 우리는 조건문을 만들 수 있게 됐다. 만일 A=1이며 동시에 B=1 이면 C = 1, 만일 A=1 이거나 B=1이면 C=1. 전기공학과 전자공학이 이 시점에서 분리된다. 오 게임 제작에 다가가고 있다. 바로 이 원리를 이용해서 마인크래프트 게임에서 전자계산기 등을 만들어대고 있다.
콘덴서 : (Data) 콘덴서는 전기를 저장하는 배터리이다. 전압이 높으면 전기를 저장하고, 낮으면 방출한다. 이 콘덴서를 통해 전기가 차있으면 1, 없으면 0이라는 ‘값을 저장한다’라고 믿게 된다. 콘덴서가 하나 있으면 1개의 값을 저장할 수 있다. 0과 1. 이를 1bit라고 부르고, 8개가 모이면 8비트를 1바이트라고 부른다. (우리가 윈도 32비트/64비트 버전을 가르는 것이 바로 이것이다. ) 00000000 ~ 11111111 = 1byte. 8개의 콘덴서로 구성된 1바이트는 00000000, 00000001, 00000010, 00000011 이런 식으로 2진수를 표현할 수 있게 된다. 그 종류가 256개이다. 그래서 컴퓨터는 2진수로 작동한다는 말을 하게 되고, 그래서 우리가 16비트니 64비트니 128메가니 1024 768이나 2048 해상도라거나 하는 등의 애매한 숫자들을 보게 된다.
가령 우리가 캐릭터 능력치는 100이 최대입니다.라고 말할 때는 이를 저장해놓기 위해서는 (참, 참, 빔, 빔, 참, 빔, 빔 1100100 상태의) 콘덴서가 7개가 필요하다는 소리랑 비슷하다.
이제 우리는 콘덴서라는 전자부품을 만드는 수고는 까먹고 1010111 같은 신호체계를 이진수 혹은 기계어라고 부르게 된다. 그리고 ‘메모리에 저장’ 한다고 말하고 콘덴서는 잊어먹게 되겠다.
Control-View-Data 이제 가질 수 있는 기본 체계는 다 가졌다. 이제 약속들을 모아놓기만 하면 된다. 애플의 MVC(모델 뷰 컨트롤)이나, 유니티의 컴포넌트 기반의 오브젝트 컨트롤이나, 클래스-오브젝트나 얼추 이 영역으로 들어온다.
콘덴서들이 앞서 반도체들과 결합하여 신호체계를 만들게 된다. 이게 연속적으로 주어질 수 있도록 기록을 해두는데, 과거에는 천공카드라는 OMR카드에 빵꾸를 뚫어서 '오르골'처럼 연주될 수 있게 해 놨다. 어찌 됐든 값이 연속적으로 저장되기만 하면 된다. SF영화 등에서 컴퓨터실에서 신나게 돌아가고 있는 거대한 필름 테이프들, 카세트테이프, 필름 디스크, 자기 디스크. 심지어는 롬팩 또는 USB 회로기판들.
메모리 : 컴퓨터 메모리가 4 GByte라는 뜻은 콘덴서가 그 안에 최소 320억 개가 있다는 말이 된다. 왜 최소냐면 그 320억 개 중에 어디에 저장했는지 표시하기 위해 ‘주소’가 필요하기 때문이다. 아이러니하게도 320억 번째라고 말하기 위해서는 320억이라는 숫자를 어딘가에 저장해야 할 필요가 있다.
코드와 픽셀 : 10001000 등의 신호로 프로그램을 짜기는 힘드니까 이제 사람이 알아볼 수 있도록 알파벳으로 바꿔놓게 된다. 우리가 A 버튼을 누르면 이는 미리 정한 코드에 의해 (가령 아스키코드) 10진수로 64. 콘덴서에 저장될 전압값이자 2진수 0100 0000이라는 신호로 바뀌게 된다. 이 신호가 흐르고 흘러 화면에 A를 표시하게 된다. 그러면 화면에 A가 찍히게 될 텐데 가로 8 세로 8개의 전등이 필요하다. 이 전등 하나를 pixel이라고 부른다. 더 멋진 폰트라면 더 많은 전등이 필요하겠지. 8 pixel이 아니라 16,32,64 pixel.
이건 view에 대한 이야기고, 이런 알파벳을 모아 static int i; printf(i); 등의 코드를 짜게 된다.
코딩 : 코드를 짜는 작업. 이것이 모여서 프로그램이 된다. 이제 어셈블리나 C언어라거나 C++, Basic이라거나 파이썬, 루아 같은 스트립트, HTML이나 자바스크립트 등의 각종 언어들이 나오고 프로그래머들이 프로그램을 짜게 된다. 물론 이들이 콘덴서 전압을 재가며 프로그래밍을 하는 것은 아니다. 프로그래머라고 해서 전기공학이나 전자공학을 다루는 것은 아니다. 이 추상화의 언덕에서 코드를 다루게 된다. 그것보다 더 추상화된 '기획서'라는 것이 있고.
코딩 툴 : 비주얼 스튜디오라거나 하는 코딩 툴을 다룬다. 초기 프로그래머들은 메모장에 가까운 것에 타이핑해서 코드를 만들고, 컴파일러라는 프로그램을 통해 기계어로 바꾸고, OS에 전달해주면 CPU와 메인보드와 메모리, 그래픽 카드의 메모리를 돌아다니며 콘덴서를 충전시키고 화면의 전등을 켜댄다. 지금은 비주얼 스튜디오 등의 괜찮은 코딩 툴 들이 더 높은 추상화를 이뤄낸다. 더 이상 프로그래머가 모든 것을 코딩하지는 않는다.
게임 스크립트 툴 : 이 단계까지 오면 코딩이란 말보다는 스크립트라는 말을 쓴다. 덕분에 예전에는 '코더:코딩하는 사람'이 프로그래머들에게 비하하는 표현이었는데, 이제는 '코더: (특정 툴 스크립터가 아닌) 코딩이 가능한 사람'으로 격조 높은 표현으로 바뀌고 있는 중. 엎어치나 매치나 '어차피 유니티'라서 프로그램 개발자들이 극도의 혹사를 당하기도 했는데, 이것도 잠깐인 것이, 게임은 경쟁이라 툴을 이용한 개발은 곧 시장 변화에 따라 툴 기능을 넘어야만 하는 상황이 온다.
하지만 아이디어로 승부하는 게임들이 점점 개발자들의 폭을 넓혀가는 것도 사실. 더더욱 '무엇을 만드느냐'가 중요해진다.
스프라이트 : 우리는 화면에 A를 찍듯 점을 찍을 수 있다. 점들이라면 더 좋을 것이고, 그 점이 하필이면 우주선 모양으로 생길 수 있겠다. 이것을 스프라이트라고 한다. 최초 검은 화면에 흰색 혹은 녹색의 빛을 가졌던 모니터에선 점을 찍으면 우주고, 선을 그으면 던전이라 SF와 판타지 천지라는 말이 있었다. 그 우주선 스프라이트가 움직이고, 총알 모양의 스프라이트를 화면에 그리고, 총알 스프라이트가 UFO 스프라이트에 ‘겹치면’ UFO 스프라이트는 소멸하고 폭발 스프라이트를 그린다. 이것이 기본적인 컴퓨터 게임의 화면이 된다. 여기서 UFO가 내구도가 있다고 기획한다면 UFO.HitPoint라는 값을 만들어놓고, Sprite.Bullet가 Sprite.UFO와 겹칠 때마다 총알. Power만큼 뺀 다음 UFO.HitPoint가 0 이하가 된다면 Sprite.UFO를 지우고, Sprite.Explosion을 표시해주는 스크립트를 통해 슈팅게임이 된다.
3D 오브젝트 : 점은 1차원, 가로와 세로가 있으면 2차원, 높이가 생기면 3차원이란 말은 수학 시간에 배웠을 것이고. 아까 A처럼 8x8 pixel에 점을 채우는 것이 2D이다. 2D 게임 들은 이렇게 면으로 된 그래픽을 가졌다는 뜻이다. 3D 게임들은 폴리곤이라고 부르는 형태로 점을 저장해놓고 계산을 통해 화면을 구성한다. 우리가 즐기는 멋진 3D 게임들은 쉬지 않고 이 계산들을 하고 있고, 이를 ‘랜더링‘이라고 한다. 이 처리를 위한 전용 장비인 ‘그래픽카드’가 생겼듯, 전용 프로그램들이 있다. 3D 맥스라던가 마야라던가.
게임 엔진/제작 툴 : 언리얼이라거나, 유니티라거나 하는 게임 개발 툴 혹은 게임 엔진 들이란 말을 들어봤을 것이다. 게임엔진이란 말로 통칭되는데, 컴퓨터 게임 특히 3D 게임들이 엄청난 계산을 해대고 그 계산을 처리하는 여러 가지 또는 높고 낮은 성능들이 큰 부분을 차지하기 때문에 ‘그래픽을 처리하는 기능’ 이 중심에 놓이고, 그 그래픽을 배치하는 뷰 부분을 다루는 툴, 그 뷰들이 움직일 규칙을 코딩하는 부분, 데이터를 처리하는 툴 등을 통칭하는 표현이 된다. 일단 '빈 오브젝트'가 있고, 여기에 스프라이트나 3D 모델(+매시) 등의 이미지 단계/애니메이션이나 새로운 오브젝트의 생성. 충돌 체크 영역, 조명, 전용 스크립트, 또는 모든 것과 분리되어 모니터에 바짝 붙어있는 UI 등의 각종 컴포넌트 세트가 붙어서 게임 오브젝트로서 기능하게 된다.
게임 : 최초에는 모니터가 없었기 때문에 ‘종이에 인쇄’를 했다. 그래서 초기 게임들 중에는 각도와 힘을 입력하면 ‘포를 쐈다고 가정하고’ 상대의 대포와 어느 정도 거리에 포탄이 떨어졌는지 -13 또는 +20 등으로 프린트해주는 게임이 있었다. 각도와 거리를 조정해 정확한 값을 넣었다면 명중이라는 값이 프린트될 것이다. 하지만 모니터가 있다면 더 멋진 게임을 만들 수 있겠지?
그것이 스프라이트든, 3D 모델 오브젝트든 크게 달라지는 것이 없는 추상화 단계가 있고, 그 특성을 절묘하게 사용하는 단계가 있다. 그리고 제작 툴에 적합한 기획을 고려하는 단계도 있겠다.
점들의 의미와 규칙 : 하필이면 우주선처럼 생긴 그 스프라이트 혹은 오브젝트는 그 게임의 목적에 따라 그려졌다. 게임은 여러 가지 목적들을 가지고 만들어질 수 있다. 가령 ‘최초의 컴퓨터 게임’군에 들어가는 ‘Spacewar!’는 대학교에 기증된 슈퍼컴퓨터 PDP1의 성능을 일반인들이 쉽게 체험하기 위해 제작되었다. 제작 의도야 어쨌든 간에 그곳은 우주라고 선언되고 점들은 별이 되었다. 우주선 모양의 스프라이트가 서로에게 총알이라는 점 스프라이트를 쏴대고 우주선은 ‘무중력 상태’에 걸맞게 반대방향으로 추진하지 않으면 정지하지 않는다. 정확히 반대방향으로 추진하기가 쉽지 않기 때문에 우주선은 힘의 작용으로 복합적인 형태로 움직이게 된다. 이제 우주선에 탄 둘이 우주에서 싸우는 게임이 만들어졌다. 그 안에는 무수한 콘덴서들이 있고, 중력값을 계산하고 화면에 표시한다. 하지만 우리는 그 모든 것을 잊고, 우주에서의 전투에 몰입할 수 있다. 그 슈퍼컴퓨터 PDP-1의 성능은 이미 스마트폰에게 따라 잡혔고, 우리는 이제 더 무지막지한 게임들을 만들기 시작한다. 점들은 더 선명해지고, 더 멋진 디자인의 우주선이 된다. 현대인의 스마트폰의 컴퓨팅 파워는 1960년대 나사의 모든 컴퓨팅 파워의 총합을 넘는다. 그래서 이런 농담이 있다. ‘ 1960년대에 나사는 사람을 달로 날려 보내고, 2000년대의 우리는 새를 돼지에게 날려 보낸다.’
게임 기획 : 우리는 이제 그 우주선에 탄 사람에 대해 궁금해 할 수 있고, 싸우는 이유를 궁금해 할 수 있다. 화면 너머에는 어떤 혹성이 우리를 기다리고 있을까. 기획에 따라 우주선은 혹성에 착륙하고, 우주복 차림의 조종사를 우리에게 보여줄 수 있을 것이다. 점의 의미를 만들고, 게임의 규칙을 만든다. 시대 배경과 설정, 세계관과 점에 붙인 의미에 따라 원화가 그려지고, 폴리곤으로 모델이 만들어지고, 오브젝트로 규정되어 규칙에 따라 체력이나 파워 등의 파라미터를 가지게 되고, 이벤트에 따라 폭발이나 죽음이 일어나고, 파라미터가 변동된다. 그 차이를 가진 다양한 업그레이드를 ‘모아 온 돈’으로 올리게 된다.
더 상위 단계에서는 우리는 파라미터는 일단 접어두고, 스토리에 집중하고 마왕과 싸울 '마을+부모님+할아버지 등등'을 잃은 소년/소녀의 열혈 대사를 작성하게 되고, 더 위에서는 이 모든 것이 이루어지는 세계의 정치, 경제, 지형, 역사, 종교/신, 거주자들의 식성과 사회에 대해 다루기도 한다.
물론 시작부터 '3개가 모이면 터진다'라는 '게임 규칙'에 집중해서 나머지들을 세우기도 하고.
각 단계의 구분에 따라 우리는 스프라이트/3D 모델링, 카메라 뷰 등을 고려한 기획을 하기도 하고, 게임엔진 제작 툴에 최적화된 기획을 하기도 하고, 시스템 퍼포먼스까지 고려한 기획을 하기도 한다. 하지만 더 높은 단계로 가기도 한다.
가령 레벨 디자인은 툴의 특성, 카메라 특성, 한 번에 비치는 폴리곤들의 양을 고려하고, 동시에 풍광과 불용 지역이라는 부분을 고려한다.
파라미터/밸런스 기획은 또 다르게 PC냐 모바일이냐에 관계없이 설계된다. (여기에 동적 파라미터를 변경시키는 활동을 하는 유저가 끼면 또 이야기가 조금 달라지지만.)
추상화의 더 상위단계 기획에서는 PC일 필요조차 없어지는 경우가 있겠다. PC든 보드게임이든 어쨌든 게임이 돌아갈 수 있다면. 가령 체스, 장기, 바둑은 어떤 기계로든 할 수 있을 테니까. 우리는 어느 단계에선가 기획을 하게 된다. 물론 앞에 예로 든 전기 단계에 대한 고민은 없겠지만, 그 윗 단계 어딘가와 연결된다. 기획서에 이 단계가 적용되어 콘셉트/콘텐츠/시스템/DB. 계산식/UI/작업 명세서 등이 차곡차곡 이루어진다.
추상화에 대한 긴 이야기가 여기까지 왔다. 각 단계들은 추상화되어 상위 단계에서는 고려되지 않는다. 하지만 결국 사랑하는 연인을 구할 ‘약’의 재료를 찾기 위해 혹은 지구를 구하기 위해 우주로 떠난 용기 있는 이들의 우주선은 오브젝트가 되고 스프라이트가 되고 파라미터가 되어 게임의 구성요소와 규칙이 된다. 마을의 습격으로 고아가 된 용사님의 위대한 마왕과의 싸움을 향한 위대한 여정은 유저의 조작 기능과, 추상화의 아랫단계에서 파라미터가 되고, 그래픽 스프라이트가 되고, 윗 단계에서 감동과 서사가 된다.
가령 우리가 기획하는 것이 컴퓨터 게임이 아니라면 추상화 단계는 하위 어느 시점에서 종이 말판이나, 운동장에 그려진 선과 플레이어 역할이 되게 될 것이다. 모노폴리는 컴퓨터로 구현되기 이전에 종이 보드, 가짜 돈, 건물들을 나타내는 작은 조각들로 구성되었으니까. 가령 바둑은 모눈판의 교차점에 놓이는 검 은원과 하얀 원으로 구성되어있는데, 그 재질이 합판/원목 나무와 2가지 색의 옥/유리/돌이기도 하지만, 종이 위에 연필로 색칠된 원으로 그려지기도 한다.
게임 기획은 이 추상화의 최상위 단계에서 시작하여, 프로그래밍, 드로잉, 사운드 콤 포징의 직전 단계에서 멈춘다. 앞서 설명한 역할 Role이 비록 1인 개발자 한 명이 모두 하게 되더라도, 게임 기획이라는 역할 Role은 이렇게 구분되기 시작한다.
물론 그 과정에서 추상화 아랫단계에 더 적합하게 설계된 게임 기획이 존재한다. 가령 컴퓨터이기에 가능한 기획들이 있을 것이다. 게임 기획은 의미부여의 영역에 있기도 하지만, 게임이 작동하는 ‘환경’을 고려하여 더 ‘디바이스 친화적’으로 설계되기도 한다. 모바일 기기에서 작동하는 게임과 PC에서 작동하는 게임은 유저의 환경과 접근성이 다르고 게임 기획에서도 고려되어야 한다.
여기까지가 게임 개발단계에서 기획을 추상화 단계별로 구분하기인데...
그다음 영역이 존재한다.
개발 단계에서 게임 개발이 커질수록 프로그래머/그래픽 디자이너를 '늘이는 것'이 아니라, 그들이 할 일을 정리해야 하는 작업들이 발생한다. 기획단계의 수정사항, 코딩, 툴 단계의 구현, 플레이 후 변경. 각종 요구사항들.
여기서 기획서 = 작업량 산정의 기준 = 구현해야 할 작업 목록 = 테스트의 기준이 되기 때문에 Task/일정 관리의 주요 데이터를 산출하거나,
Task가 툴 작업, 코딩, 코딩에 필요한 리소스/파라미터 등 제작 파트 간에 복합적으로 진행되기 때문에 코디네이션을 위해 주요 부서의 미팅을 진행하게 되는 것이 있고,
홍보/PR부서에서 관계사에 전달해야 할 자료, 원고 등을 작성하게 되고, 경영지원실 등의 사업 수립 및 퍼블리셔/투자자 계약에 필요한 자료 등을 작성하게 되기도 하고.
그러다 보면 프로젝트 매니지먼트 영역에 어느 정도 발을 들이게 되기 마련. 그렇다고 실제로 기획자가 매니지먼트 업무를 하는 것은 (보통) 아니다. 둘은 내가 제네럴/스페셜 (혹은 와이셔츠/티셔츠)라 구분하는 분류 영역이 달라서 기획자에게 극심한 과부하를 부른다. (프로그래머들은 이걸 종종 '콘텍스트 스위칭'이라고 부른다.)
오직 게임 기획자만이 업무로서 게임에 스페셜하게 다이브 한다. 일명 '오글거리는 영역'으로 핍진성을 흠뻑 흡수하기까지의 시간이 필요하다. 그 안에서 게임 세계를 바라보며 게임을 디자인한다. 유저의 머릿속에서 재생될 영역.
( https://www.facebook.com/whtdrgon/posts/1043826878983490 참조)
여기서 튀어나와 다시 현실에서 프로그램이 처리할 수식과 파라미터 구현을 고민하고, 또 여기서 튀어나와 일정과 스케줄을 처리하기가 쉽지 않다.
일을 피할 수 없다면 적어도 내가 이계와 현세 차원을 왔다 갔다 하고 있다는 사실 자체는 직시할 필요가 있다.
어쩔 수 없는 필요에 의해 공부하고자 한다면, 기획자에게는 프로그래머의 작업 주도를 위해 특화된 린/XP/스크럼/애자일보다는 PMP가 더 도움이 된다.
정리 :
이제 이 추상화의 단계를 게임 기획 입장에서 구분하고 그에 따라 어떤 요소가 기획 의도에 의해 더 강화되거나 약화될 수 있는지 따져 볼 수 있다.
이쯤 되면 도움이 되는 습관 하나가 있는데 (설사 모두 내가 하게 되더라도) 미리 '역할을 나눌 나'를 여럿 만들어두는 것이다. 혼자 습작이나 포트폴리오를 만들더라도 나를 나름의 기준으로 여럿으로 나누고 트렐로나 잔디 같은 협업 프로그램들을 사용하는 습관을 들여두는 편이 좋다.
160418
김동은WhtDrgon.
#게임기획자하얀용
표지: Photo by Michael Dziedzic on Unsplash
