<게임 콘셉트 기획의작성 1-2게임기획의범위>
김동은WhtDrgon160923#게임기획자하얀용
개요
이 글은 2016년 9월 23일 페이스북에 포스팅했던 글입니다. 벌써 5년 전 글이라 많은 것이 달라졌지만 그래도 이 방식은 게임 기획의 기술적 접근보다는 심상의 개념에 접근하고 있어서 '게임식'이라는 것을 연구하는 비게임 전문가들에게 도움이 되실 수도 있다고 생각했습니다.
2021년의 지금은 아래처럼 복잡하게 설명 안 하고, 기획 업무와 '게임 디자인' 업무를 갈라서, 기술적 부분인 콘텐츠 기획부터 밸런스 기획까지를 가르고, 사업기획과 콘셉트 기획은 기획업무에 둡니다. 중요한 건 그냥 구분만 그렇게 할 뿐 게임 기획자 업무에서 그리 멀리 벗어나지 않았다는 것이죠. 결국 누군가는 전부 해야 합니다.
본문
사업 기획
서비스 기획
콘셉트 기획
콘텐츠 기획 / 스토리보드 -> UI
시스템 기획 /
레벨 디자인 / 콘텐츠 데이터 디자인
밸런스 기획
운영 기획
사업 기획 : 진짜 사업기획을 이야기하는 것이 아니다. 이 포스팅은 '개발 제안을 위한 게임 콘셉트 기획서의 작성'에 목적을 두고 있다. 경영에는 전담자가 따로 있다. 게임 기획자로서 신경 써야 하는 부분은 프로젝트의 구체적인 방향성을 파악하는 것이다. 대표적으로 대상 유저가 있다. 자칫하면 게임 기획의 풍부한 상상력이 사업기획과 어긋나 '남의 돈으로 예술하기'가 발생한다. 또한 사업기획의 이해는 너무도 자유로운 영혼인 콘셉트 기획의 가이드 역할을 해준다. 키워드를 뽑아내고 각 키워드들의 비중을 설정해두면 되겠다.
서비스 기획 : 회사의 목적은 돈을 버는 것이라고들 하지만, 탐욕은 파멸의 지름길이다. 우리가 조폐 프로젝트라도 하지 않는 이상 프로젝트로 돈을 직접 만들 방법은 없다. 요즘은 앱 기획 스토리보드 작성을 서비스 기획이라고 부르지만, 좀 더 사업에 가까운 형태라고 생각해서 이쯤에 배치해놓고 있다. 사업 기획에서 정한 방향의 서비스를 포괄적으로 설계해놔야 한다. 물론 게임 기획자 입장에서는 서비스 기획 자체보다는 서비스 기획을 서포트할 작업들의 분류 정도로 충분한 경우가 많다. 게임에서 우리는 사업/서비스를 디바이스+장르 하에 정형화된 관례를 정해놓고 하는 경우가 많은데 앞으로의 게임 개발은 그렇게 흐르지 않을 것이다. 게임은 이미 대중의 손에 쥐어졌고, 엔터테인먼트들 완구, 사용절차와 구분하기 힘들어질 것이다. 가령 기기를 작동시킬 때 AI가 가미되어 사용자의 조작 의도를 예측하는 순간, 그 예측 메커니즘과 사용자가 의사소통하기 위해 '대화형 시스템'이 도입될 수 있는데, 여기에 게임의 형식이 도입되지 말라는 법이 없는 것이다. 게임은 사용자의 수준에 맞추어 반복, 도전, 보상의 메커니즘을 가지고 있어서 각지에서 활용도가 매우 높다. 곧 매우 적극적으로 이용될 것인데 이게 게임인지 아닌지 구분하기 힘들어질 것. 즉 다양한 유형의 사용처가 등장할 텐데, RPG는 이렇다. 내지는 슈팅은 이렇다는 식의 접근 위의 기획이 뚜렷하게 존재하게 될 것이다. 그 영역을 서비스 게임 기획이라고 붙였다. 물론 구글에 올려서 인앱 결제로 수익을 올리는 슈팅게임을 만들 겁니다라고 한다면 앞의 두 기획이 매우 구체적으로 정해진 것이 된다.
콘셉트 기획 : 보통은 사업/서비스에서 정해지기 마련이다. 가령 커피숍 프랜차이즈 B2B 사업을 하기 위해 선주문 시스템을 고객이 어떻게 사용할지 서비스 기획을 해놓는다고 해도 여전히 콘셉트 기획이 필요하다. (#1 은 https://www.facebook.com/photo.php?fbid=1254748184558024 참조) 앞서의 단계가 프로젝트 수립을 위한 레퍼런스의 확보 단계라면 이 단계에서부터 본격적으로 프로덕트. 제작물의 영역으로 들어간다. 영화 만화 등의 엔터테인먼트 콘텐츠들이 그렇듯 창의력이 뿜어질 공간은 무궁무진하다. 그러기에 그 방향성을 유지해줄 사업과 서비스에 대한 이해가 필요하다. 콘셉트 단계에서는 서비스의 형태를 포함하여 각 부의 담당자들이 그 규모를 짐작할 수 있는 밑그림이 제시되어야 한다. 향후 필연적으로 수정될 것이기에 전 분야를 다루긴 하지만 너무 디테일할 필요는 없지만, 콘텐츠와 시스템, 데이터, 산출물의 예시 등이 모두 제시되어 앞으로 제작될 것들의 필연성을 부여하게 된다.
콘텐츠 기획 : 콘텐츠란 단어도 여러 용도로 사용되지만 이 경우는 게임에 대한 이야기이다. 게임에서 구현되는 각종 기능들을 분류 가능한 형태로 나눠놓는다. 가령 캐릭터 클래스, 육성, 전투, 필드, 아이템의 획득, 가공, 착용이라거나, 스테이지 맵, 퍼즐 레벨, 아이템 사용, 랭킹, 구매. 등등 여러 콘셉트에 따라 고객과 제작자들의 분과를 중심으로 항목들이 나눠지게 될 것이다. 콘셉트에서 '이 게임은 생존자들이 좀비들을 물리치고 물자를 모아 자급자족하는 캠프 운영 게임입니다.'라는 선언에 의해 물자 획득, 캠프 운영, 좀비 전투. 인력관리. 물자관리 등등의 콘텐츠가 나눠지게 된다. 이 단계에서 스토리보드가 만들어지기도 한다. (게임이 아닌 분야에서 긴 스토리보드는 더 엄격한 형태를 가지긴 하지만, 그 용어도 원류가 스토리보드인지라, 어느 정도 구체화된 형태의 콘셉트로 이해해도 될 것 같다.) 콘텐츠가 나오면 시스템 기획과 DB파라미터들을 설계할 수 있다.
시스템 기획 : 각 콘텐츠들이 어떻게 작동할 것인가? 어떤 파라미터를 사용하고 어떤 UI와 형식을 거 치는가 같은 것들. 프로그래머를 위해 흔한 플로우 차트나 도메인 랭귀지를 사용하기도 하는데, 내 경우엔 엔지니어링은 엔지니어에게 맡겨두고 기획 의도를 이해시키고, 수많은 파라미터들의 혼동을 방지하는 정도에서 멈추는 편. 구체적인 설계를 엔지니어가 맡은 경우에도 엔지니어가 설계한 도식도를 기획자가 깊이 이해할 필요가 있는데 이 ERD 등의 도식도조차 노출을 거부하는 수준 이하의 경우를 본 적이 많은 것이 현실이다. 기획은 프로젝트의 산출물을 기획하고, 일정을 창조하게 되는 이유로 매니지먼트의 영역을 넘나들지만 프로젝트와 산출물의 소유자도 구루도 아니다. 엔지니어들 역시 마찬가지인데도 업무의 사유화가 이루어진 경우도 있고, 다루는 산출물이 완벽히 본인의 것이 아닌 탓에 제대로 된 도식도가 없는 경우도 있고. 이런 수준 미달의 이유로 매니지먼트가 디자인에게 어설프게 부여되서는 안 되는 것인데 겪은 사례로 보건대 조금 요원하다.
레벨 디자인, 콘텐츠 데이터 기획 : 몬스터, 아이템, 지역 등의 소모적인 콘텐츠 데이터들과 콘텐츠/시스템 기획 사이에 레벨 디자인이 있다. 오늘 원래 하려던 이야기가 바로 이 레벨 디자인. 뒤에서 좀 더 다뤄보자.
밸런스 기획 : 전투 공식, 유저 관리 파라미터 등을 다루는데 무엇보다 게임이 진행되며 이루어지는 유저 데이터 영역을 다루게 된다. 각 콘텐츠, 콘텐츠 데이터들. 즉 게임 내의 자원들은 비교가치를 가지게 되는데 플레이타임, 모티베이션, BM 등의 핵심 축이 된다. 밸런스 시스템을 설계하는 것과, 밸런스 데이터를 넣는 것. 그 데이터의 의도를 설계하는 것. 잘 작동하는 규칙들, 공식들을 만드는 것들이 통합되어 있다. 운영기획과 결합하여 로그 분석을 통한 파라미터 변경 계획을 포함한다.
운영 기획 : 제작과 운영은 기획이 다르다. 개발은 프로젝트이고, 운영은 프로그램이다(코딩 말고). 게임 기획에서도 운영을 위한 각종 툴과 파라미터, 기능 등을 만들지만, 제작 단계에서 게임 밸런스 등에 라이브 서비스의 영역을 함부로 끼워 넣어서는 안 된다. 거꾸로 운영기획에서 수집되는 데이터를 바탕으로 보정을 할 다이얼을 만드는 기획이 필요하다. 이 운영기획 단계에서 서비스 데이터가 수집되어야 하고, 향후 다음 사이클에서 사업/서비스/콘셉트 업데이트에 대한 근거자료가 제공되어야 한다. CS는 말할 것도 없고. 이렇게 다시 사업기획으로 사이클을 이루게 된다.
---
김동은WhtDrgon.
20160923
표지 : Photo by Nubelson Fernandes on Unsplash
