01. what
02. how
03. storytelling
04. prototyping 上
05. prototyping 下

요즘 이곳저곳에서 스토리, 호은 스토리텔링이라는 단어를 참 많이 사용한다. 스토리를 우리말로 번역하면 '이야기'라는 뜻임을 모르는 사람은 없을테지만, 스토리텔링을 우리말로 옮겼을때 무엇일지는 바로 확 떠오르지는 않는 것 같다.
그래서 네이버 사전님을 찾아보니.. 스토리텔링은 구연동화 할 때의 그 '구연'이라는 뜻이라고 한다. 구연이라면.. 이야기 그 자체보다는 사람들에게 이야기를 '전달'하는 과정 자체에 초점이 맞춰져 있는 행동(아래 그림)일텐데, 그렇다면 듣는 이가 제대로 상상하고 몰입할 수 있도록 하는 효과적인 방법에 대한 것이 그 본질이 아닐까 싶다.

게임의 유저경험을 기획해 보자는 이 글에서 다루는 스토리텔링은 '완결되는 하나의 이야기에 대한 것'이 아니라 '게임을 관통하는 주제(테마)로써의 내러티브를 만들어 효과적으로 전달하는 방법'에 대한 것이다. 그래서 이전 2회의 what & how 내용을 통해 만들고자 하는 게임을 구체적인 내러티브로 만들어내는 것을 우선 다뤄보고자 했고, 이제는 그렇게 구상해 본 내러티브를 어떻게 기획 과정에 적용해 들어갈지에 대해 이야기 해보자.


일반적으로 우리가 스토리라 말하는 것은 기-승-전-결의 선형적이고 서사적 구성을 갖는, 사전 그대로 '이야기'이다. 소설, 영화, 만화, 게임 등 모든 이야기들은 대부분 이러한 구성 속에 인물과 사건, 그리고 배경이 등장한다. 이 요소들이 의도된 주제를 관통하여 흘러가고 완결되어짐으로써 보는 사람으로 하여금 감성적 대리 경험의 재미를 전달한다.

이 구성를 게임만의 관점에서 보자. 가장 크게 차이날 수 있는 부분은, 게임의 유저는 플레이어가 되어 등장인물의 행동을 조작하고 그를 통해 배경과 사건에 상호작용함으로써 조금씩 다른 선택지를 통해 여러가지 결과를 볼 수 있는 특징을 가질 수도 있다는 점이다. 이것은 의도된 이야기일지라도 반드시 하나의 선형적 단방향성으로 끝나지 않는 경우가 있다는 것이고, 특히나 끊임없이 업데이트 되어야 하는 온라인 게임 같은 경우라면 더더욱 기존의 이야기 구성과는 다른 작업을 요구하게 된다.
이 때문에 게임에 있어서의 스토리는 제작을 하며 부딪힐 수 있는 기술적인 변경사항이나 일정 상의 한계, 레벨디자인 등의 컨텐츠 제작 과정에서 발생할 수 있는 재미 문제 등을 고려한다면 전혀 바뀌지 않는 완전히 마무리 되어있는 형태로 짜놓고 들어간다는 것이 매우 어려워진다.
그렇다보니 온라인 게임의 초기 기획 단계에서는 어떤 완결된 스토리를 쓴다기보다 Look&Feel 및 목표점을 지정하기 위한 세계관과 전투(혹은 주요 플레이 행동) 플레이 구성을 위한 직업(혹은 종족)을 중점으로 접근하게 된다. 그런데 바로 여기에서 많은 기획자들이 오해하고 실수하는 부분이 발생한다. 그것은 자신이 전달하고자 하는 이야기에 너무 집중한 나머지 그 유래와 유구한 역사, 지역과 인물 등등을 WoW급으로 구축하고 설명하는데 온갖 열정을 쏟아부어 수십장에 이르도록 장엄한 스토리 기획서를 작성하게 될 경우가 많다는 것이다.
덕분에 몇 개월에 걸쳐 머리를 짜내어가며 쓰여졌을 그 이야기들은 실로 엄청나게 방대한 세계를 제시하지만, 대다수의 경우 개발자의 관점에서 보았을 때조차 쉽게 몰입해 읽기 힘들 정도로 길고, 지루하며, 복잡하다. 개발자는 자신이 맡을 요소가 아니라면 귀찮아지는 탓도 있겠지만, 플레이어라 해도 당장 실제적으로 내 아바타가 직접 부딪히게 될 사건과 할 일에 관심을 갖게 되지, 200년 전 왕위 찬탈 사건의 음모와 그에 관계된 몇대 후손의 불타오르는 복수심이 왕국을 무너뜨리려 어쩌구 등등 따위의 게임에 당장 드러나지도, 경험되지도 않는 백과사전식 인물/사건/배경에 감정을 대입하기란 어렵기 때문이다.
이런 점을 두고 바이오쇼크 시리즈를 만든 Ken Levine은 GDC에서 아래와 같이 말하기도 했다.

물론 전체 개발 과정에서 본다면 지속적으로 업데이트 될 때의 일관된 방향성을 유지하기 위해 이런 사전적 기획이나 소설 같은 이야기도 필요할 수 있겠지만, 프리-프로덕션 단계에서부터 이런 결과물은 오히려 유저경험의 감성적 재미를 상상하고 만들어가는 것에 오히려 혼동을 일으킬 수 있다. 차라리 '왜 그렇게 되었는가, 그래서 무엇을 해야 하는가' 정도로 정리된 내러티브에서 시작해 확장하는 것이 더 쉽게 공유할 수 있는 기반이 될 수 있다.
즉, 스토리텔링으로 기획하고 커뮤니케이션 하자는 것은 완전히 마무리 되어진 이야기를 쓰자는 것이 아니라 테마를 관통하는 상황을 전제하고 그를 통해 (앞으로의 전개 상황까지 포괄할 수 있는 형태로) 플레이어가 맞닥뜨리게 될 경험을 다루자는 것이다.

그렇다면, 어떤 식으로 접근해 본 사례가 있을까.


위의 테마는 그라나도에스파다의 개발 초기 모티브로, 길지 않지만 하나의 좋은 스토리텔링 내러티브의 사례라 볼 수 있다. 오히려 방대한 양의 텍스트보다 이렇게 잘 짜여진 강력한 내러티브 하나가 더 쉽고 효과적으로 유저경험을 기획하는데 도움이 된다. 여기에서부터 플레이어가 놓여질 상황에 대한 전제(신대륙 개척 판타지)가 확실하기 전달되어 어떤 배경이 등장해야 할지, 어떻게 에픽 퀘스트 등을 구성할지, 어떤 미시/거시 목표를 갖도록 만들어야할지 비교적 쉽게 추론할 수 있게 만들고, 거기에 초기부터 기획된 큰 특징인 3인 MCC (Multi Character Control)나 개성적인 NPC 영입 같은 고유의 요소가 플레이어의 '가문'이라는 개념을 통해 용병들을 고용한 모험이라는 기능 요소까지 포괄할 수 있게끔 설정되어 있기 때문이다.

GranadoEspada ⓒ IMCgames

그런데 여기서 우리가 퍼즐이나 보드 게임 같은 것이 아닌, 캐릭터 기반 게임의 내러티브를 정리해나갈 때 주의할 점이 하나 있다. 콘솔 머신이나 스마트폰으로 출시되는 싱글 플레이 기반의 게임들과 비교해 보았을 때, 아직까지 개발자 다수가 몸 담고 있을 온라인 기반의 게임들에 있어서는 그 캐릭터를 사용하는 유저경험의 허용 한계가 다르다는 것이다.

싱글 게임은 대부분 엔딩이 존재하는 완결된 이야기를 갖기 때문에 등장인물 또한 놓여진 상황 속에서 주변인물들과 함께 대화하고 행동하는 입체적인 성격의 표현과 능동적인 행동으로 플레이어에게 이야기에 대한 감정 몰입을 유도하는 것이 가능하지만, 온라인 게임에서의 등장인물은 플레이어의 아바타일 뿐 스스로 상황에 녹아들어 혼자 혹은 어울려 말하거나 연기하지 않고 플레이어의 입력과 선택에 의해서만 행동하는 피동적 성격을 갖기에 스토리에 대놓고 감정 몰입을 유도하기가 어렵다는 것이다.

이것은 통상적인 온라인 게임의 기획 단계에서 캐릭터의 성격과 어투, 주변인물들과의 관계에 의한 이야기적 설정보다는 직업/종족 같은 전투나 액션 플레이 스타일의 차이를 설정하는 것부터 시작하는 경우가 많다는 것을 의미한다. 때문에 '궁수 = 원거리 공격형 딜러' 같은 기능적 요소에서 출발함으로써 캐릭터에 어떤 감정적 개입을 유도하는 장치를 넣지 않거나, 시그니처 캐릭터화 하여 '악마에게 부모를 잃은 19세 소년 샘 윈체스터' 같이 이야기를 포함해 넣더라도 게임 내에서는 액션 플레이 차이 이외엔 어떤 캐릭터이던 진행분기에 영향을 주지않게되어 실질적으로는 스토리텔링과는 거리가 멀어지게 된다.

이렇듯 인물에게 부여된 기획 동기가 평면적이 되면 플레이어는 아바타가 놓인 이야기에 감정적으로 개입하는 것이 어려워지게 된다. 전투 상황 같은 부분에 있어서는 아바타에 쏟아부은 시간과 노력만큼 보여지는 데미지나 소요시간 같은 구체적 결과로 감정적 만족이나 욕구를 발생시킬 수 있지만, 이는 스토리 자체에 대한 몰입과는 분명 구분되는 유저경험이다.
이렇게 전투에서의 감정 몰입이 스토리의 그것보다 상대적으로 훨씬 재미있는 경험으로 인식될수록, 나머지는 그를 위한 귀찮은 과정이라고 여겨지기 쉽다. 이렇게 굳어지다보면 대화창에 뜨는 길디 긴 텍스트라던지 별로 재미도 없으면서 시간만 끄는 강제 연출씬 같은 '스토리를 통해 전달하려고 하는 기획적 의도' 따위는 빨리 스킵하고 싶은 귀찮은 것일 뿐으로 여겨지게 되고, 플레이어는 그저 빨리 저널 UI에 퀘스트 리스트와 요구조건만 띄우고자 하거나 빠른 성장을 위한 매크로질에 집중하게 된다.

이쯤 되면 사실 게임의 스토리를 제대로 전달한다는 것은 기획자에게 크나큰 부담이자 난관으로 다가오게 된다. 하지만 이를 반영해 스토리의 비중은 덜어내고 장르적 특성을 살릴 수 있는 게임 플레이 혹은 기능적 측면에 더 집중해 기획하게 되면 오히려 몰개성하게 보이거나 너무 쉽게 소모되고 질려버리는 악순환을 맞이하게 되기 쉽다.
때문에 근래의 대작 지향형 게임들에서는 이를 극복하고자 하는 방법으로써 '의도된 게임의 내러티브'에 적절한 스토리를 여러 방법으로 전달해 전투 이외 감성적 경험의 재미를 높이는 방법을 시도하고 있다.

물론 스토리라는 것이 꼭 반드시 정해진 이야기만을 강요할 필요는 없기 때문에, 이런 방법이 아닌 게임의 기능이나 규칙에 의해서 자신이 길드장이나 길드원이 되어 서버 최초로 거대 용을 쓰러트린다던지 자꾸 PK를 하는 악질 유저를 누군가가 대신해 처단해주었다던지 하는, 창발적이면서도 감동적인 우화가 생겨날 수도 있다.
하지만 창발적으로만 발생할 수 있는 이러한 부분은 일반적인 다수의 유저나 혼자 노는 유저에게 전달될 수 있는 평균적인 경험으로 보기는 어렵다. 때문에 기획 단계에서는 내러티브가 부여한 상황을 끌어낼 수 있는, 호칭이나 도전과제 등의 추가 보상요소를 통해 쉽게 참여를 유도할 수 있는, 좀더 의도적인 창발성을 고려할 필요가 있다.


위에서 말한 내러티브가 부여한 상황을 기획적으로 풀어내 유저경험으로 만들고, 그를 통해 시스템이나 컨텐츠를 만들자는 스토리텔링 기획 과정은 다음과 같은 순서로 정리할 수 있다.

1. 게임이 지속적으로 관통할 내러티브 / ref. what 2. 테마가 부여할 수 있는 상황, 키워드 / ref. how 3. 해당 상황이 요구하게 되는 게임플레이(행동) 아이디어 도출 4. 해당 게임플레이를 만들기 위해 필요한 시스템기획 아이디어 도출 5. 해당 행동으로 만들어낼 수 있는 컨텐츠(레벨)기획 아이디어 도출 6. 그 중 적절한 아이디어들을 구체화하고 엮어가며 각각 프로토타이핑/시뮬레이션 후 선별 채택

게 임의 주 내러티브를 정하고 거기에서 키워드를 뽑아 게임 플레이화 하고, 그를 통해 시스템과 레벨을 기획한다는 것, 그를 통해 '의도된 기획을 온전한 감성적 재미의 유저경험으로 만들어보자'가 이번 UX 연재를 통해 함께 공유하고자 하는 주제이다.
그럼 위의 순서에 맞춰 한시간 정도 머리를 굴려본;; MMORPG의 구체적인 기획 사례를 한번 보자.

1. 내러티브
   멀지 않은 미래, 엄청난 과학기술로 무장한 외계인들이 자원을 노리고 지구를 침공해 와 대부분의 인류가 절멸한 세계.
   국가와 경제는 붕괴되었고, 생존자들은 살기 위해 외계인에게 투항하거나 은밀히 세력을 규합해 저항해 나가야 한다.

2. 키워드
   근미래SF, 생존, 세력, 저항, 탈환, 인질, 외계기술, 배신, 투항, 스파이, 갈등, 외계인 ...

3. 게임플레이
   근미래SF - 모듈화 되어 개조 가능한 총기/장비/탈것 등이 가능하다. 근미래니까 레이저건이나 워프 같은건 배제한다.
   생존/세력 - 지속적으로 자원과 무기를 확보해 세력이 힘을 잃지 않고 전투하며 기지를 방어할 수 있도록 해야 한다.
   저항/탈환 - 비교적 안전한 지역을 확보하고 외계인이 점령한 지역을 탈환해 거점을 넓혀나가야 한다.
   인질/외계기술 - 잡혀있는 인질을 구하고 기술을 탈취함으로써 인력, 기술, 자원 등의 인프라를 확보해야 한다.
   투항/배신 - 투항함으로써 안전과 생존을 확보하되, 저항군과 대립하며 그들의 인프라를 파괴하고 재탈환해야 한다.
   갈등 - 저항세력과 투항세력이 중립거점이나 상호 점령지탈환을 위해 직접적으로 대규모 전쟁을 치뤄 그 이익을 취한다.
   외계인 - 그 안에서도 파벌을 나뉘어있어 투항/저항 세력 모두에 영향을 주는 균형 장치로써 조커 역할까지 하게끔.
   등등...

4. 시스템
   플레이어는 생존자로써 일단 개인적인 저항자로 시작하지만 일정 레벨이 되면 저항 혹은 투항 세력에 속할 수 있다.
   세력에 속한다해도 다시 배신하고 다른 세력으로 갈 수도 있다. 이 경우 일정한 패널티가 부과될 것이다.
   세력 간 특정 지역에서 PvP 및 RvR이 가능하다. 별도의 모드로써 상위 UI 단에서 접근 가능하게 하는 것도 고려해볼만.
   각 세력마다 기지라는 개념의 큰 도시가 각각 존재하고, 그 안에서의 경제과 거래는 인력, 기술, 자원을 통해 이루어진다.
   소속된 세력이 갖는 인프라에 대가를 지불하고 이용할 수 있고, 퀘스트와 보상을 통해 인프라를 더 강화할 수 있다.
   총기/장비/탈것을 아이템으로 조합/분해 할 수 있게 하고, 제작물은 세력 인프라로 테크트리 타 강화할 수 있게 한다.
   PvE가 이루어지는 일반 지역 이외에, 특정 세력이 차지할 경우 그 이용자에게 세금을 걷어주는 PvE 지역이 존재한다.
   등등...

5. 컨텐츠
   캐릭터 레벨보다는 스토리에 의해 출입 가능 지역이 확장되게 하되, 에픽별 스토리 끝 보스의 난이도를 성장에 맞춘다.
   에픽퀘 주요흐름을 탐색-정찰-점령/탈환으로 깔고, 구출/잠입/탈취/파괴 같은 연출 포함 퀘 첨가해 스토리를 강화한다.
   비단 연출씬 뿐만 아니라, 레벨에 있어 동적으로 반응하거나 움직이는 지형지물을 활용해 상황적 몰입을 유도한다.
   메인/서브퀘를 통해 의뢰된 내용의 연계 인물이나 사건을 협력/추적/회수하도록 해 인물 간 관계적 몰입을 유도한다.
   서브퀘의 결과 분기를 다양화, 그에 따라 다른 효과가 걸려있는 호칭을 취득하게 해 창발적 재참가를 유도한다.
   에픽퀘에 있어서 저항세력과 투항세력이 확연히 갈려 진행되는 루트가 존재하고, 그 끝에 서로 PvP 하게끔 유도한다.
   몬스터의 레벨 내 등장 타입을 퀘의 특성에 맞게 바꿔쓸 수 있도록 일반/로밍/습격/포위/전선/추척 등으로 정리한다.
   등등...

위의 기획을 한꺼번에 본다면 각자 기획한 일반적인 방법과 크게 달라보이지 않을 수도 있고 3, 4, 5번이 유사해 보일 수도 있지만, 디렉터 혹은 기획으로부터 명확히 의도된 비전으로써 내러티브를 끌어낸 후 이 스토리텔링의 방법을 사용해 순차적으로 접근/기획해 간다면 분명 일관성을 가진 흐름에서 각자의 특징을 가진 게임 플레이 요소를 도출해 낼 수 있을 것이고, 그를 통해 좀더 의도적인 유저경험을 떠올려가며 실제 개발에서 커뮤니케이션 해 나갈 수 있을 것이다.
이를 통해 유저경험의 감성적 재미를 고려해 기획하고, 모든 팀/파트 간 협업에 있어 '왜 만드나? 굳이 그렇게까지 해야하나? 무슨 연관이 있나?' 같은 소모적인 과정의 피로를 조금이나마 줄여갈 수 있다면 좋겠다.

다음 연재에서는 지금까지의 내용들을 바탕으로 실제 플레이 모습을 구체적으로 끌어내어 개발/비개발 영역으로부터 피드백을 받아 감성적 재미에 대한 부분을 검증하고 시행착오를 줄일 수 있는 방법으로 사용될 수 있는 사전영상화 프로토타이핑(pre-visualization prototyping)에 대해 이야기 해보자.

안녕하세요. 한 타임 게시를 하지 못한 랩좀비입니다. DOD - Data Oriented Design - 에 대해서 열심히 글을 쓰다가, 실무에 직접 적용해 보지 않고 마냥 좋은 거라고 쓰는 것은 어디서나 찾아 볼 수가 있어서, 지금 회사에서 열심히 DOD를 적용하려고 작업중인 일이 끝나면 회고도 하면서 올리겠습니다. ...언제가 될지는 약속 드릴 수가 없네요. 요즘에 이것 저것 하다보니 적용할 시간이 없더군요. 올해 전반기에는 반드시 할 수 있도록 노력하고 있습니다.

그건 그렇고, 여러분의 프로젝트는 메모리 릭이 얼만큼 발생하십니까? 프로그램이 종료되면 릭이 발생하지 않습니까? 제가 하고 있는 프로젝트도 프로그램이 종료될 때에는 모두 해지가 되어서 메모리릭이 발생하지 않습니다. 하지만, 게임에 들어가면 미친듯이 릭이 발생하고 있었어요. 종료할 때는 메모리릭이 표시되지 않지만 게임중에서는 해지 되지 않는 불편한 상태가 진행되고 있었습니다.

지금까지는 늘어나는 양이 눈에 띄지 않아서 무시해도 될만한 수준이었는데, 최근에 이 문제가 표면에 드러나서 - 무려 시스템 메모리를 2기가 이상까지 올려버려 new에서 badalloc Exception을 보내는 상태까지 가더군요.- 이것을 추적하기 위해 UMDH라는 툴을 사용했습니다. 해당 툴에 대해서 알려주신 모님께 감사를. 프로그래머의 실력은 디버깅에 있다는 생각이 문득 들더군요. 뭐 이건 개인적이 견해이니 넘어가구요...
 
오늘은 UMDH의 맛만 보도록 하겠습니다. 맛만 봐도 어지간한 메모리릭은 잡을 수 있어요.

UMDH는 메모리를 캡쳐하는 기능을 가지고 있습니다. 그리고 캡쳐된 2개의 로그를 비교해서 변화량을 알려주는 기능도 있지요. 그렇다면 이걸로 어떻게 메모리 릭을 잡느냐... 그냥 게임 시작하면 캡쳐(1)를 하고 여기 저기 돌아다니면서 메모리릭이 발생하는 곳을 찾아서 캡쳐(2)를 한 후, 1번과 2번을 비교해서 그 동안 할당된 로그를 뒤져보는 것입니다. 물론 할당되고 해지된 녀석은 나오지 않습니다. 

UMDH는 WinDBG가 있는 툴셋에 포함되어 있습니다. WinDBG짱좋아요잘쓰면님은나와다른초보 그럼 어떻게 사용하는지 한 번 봐볼까요?

1. 먼저 어플리케이션을 실행한 다음 UMDH가 적용될 프로그램에 '이놈에게 UMDH를 쓰겠소' 라며 알려줍니다.
저는 개발중인 클라이언트에 적용해 보겠습니다. 파일명만 있으니 보안에 접촉되지 않겠지.우리사장님은대범하시니까.
 

2. 그리고 캡쳐를 합니다. 캡쳐할 때 프로세스의 ID를 알아와야 하는데 이것은 tlist 명령어를 통해서 알아올 수 있습니다.

심볼이 없다고 하는데, pdb파일이 있다면 무시하셔도 됩니다만, 정확한 체크를 위해서는 심볼 패스를 지정하는 게 더 좋긴 합니다. 심볼이 없으면 안나오는 정보도 있습니다.

3. 비교를 위해 프로그램을 조금 돌리다가 캡쳐를 합니다.

4. 이제 비교한 파일을 뱉어 달라고 UMDH에 요청합니다.

5. 만들어진 log를 열어봅니다. 굉장히 긴 파일이 만들어지는데, 이게 그 동안 할당된 메모리를 나타냅니다.
노란색으로 색칠해진 부분이 16진수로 표현된 바이트입니다.

이 툴을 이용해서 지난 1주일간 꽤 많은 릭을 잡아 냈습니다. 대부분이 스크립트에서 발생한 것이었지만, 프로그램 쪽에서도 해지 않고 있었던 메모리가 있었지요. UMDH 외에 LeakDiag라는 툴도 있습니다. 이쪽도 한번 구글링해서 테스트 해 보는것도 추천합니다. 무려 메모리 변화를 그래프로 출력해 주지요. 하지만 사용해 보니 프로그램의 상태를 툴에서 인젝션할 때 자주 다운되더군요.

암튼, 오늘도 가벼운 주제를 긁고 저는 이만 물러가겠습니다. 좋은 하루 되세요. 

이 글은 2012/02/02 - [프로그래밍] - 게임 오브젝트 설계.. 나도 잘하고 싶다! #1 에서 이어지는 글입니다.

게임 오브젝트 설계.. 나도 잘하고 싶다! #1에서는 계층 구조를 사용한 오브젝트 설계를 설명하였습니다. 그런데 시간이 흐르면서 게임이 점점 복잡해짐에 따라 게임 오브젝트의 타입도 많아지고 하는일도 많아지고 요구사항들이 늘어나면서 계층 구조 설계 방식으로 게임 오브젝트를 만드는것에 어려움이 생기기 시작하였습니다.

옛날의 게임

요즘 게임들

그럼.. 무엇이 어렵지?!

일단 설명을 위해 저번 글에서 쓰였던 게임 오브젝트의 구조를 사용하여 설명을 해보려 합니다.  위와 같은 그림처럼 게임오브젝트들을 만들었다고 가정해봅시다. 여기에 Camera를 추가한다면 어떻게 해야 할까요?

카메라는 화면에 그려지는 오브젝트가 아니니까 이렇게 추가하면 되는 것일까요? 카메라는 화면에 그려지는 오브젝트는 아니지만 움직일 수는 있습니다. 

그럼 움직일 수 있는 오브젝트니까 이렇게 추가하면 되는 것일까요? 안타깝게도 카메라는 화면에 그려지는 오브젝트가 아닙니다.. 그려지진 않지만 움직일 수 있는 오브젝트가 생기니 약간 골치가 아파졌습니다. 어쩔 수 없이 Prop과 Trigger에게는 미안하지만 GameObject에서 움직임 처리를 하고 Prop과 Trigger에서는 사용하지 않기로 해봅시다.

 

이렇게 만들고 보니 클래스 계층 구조만 보면 웬지 깔끔해진 것 같습니다. 하지만 사실은 GameObject의 비중이 커져버린겁니다. 대두가 되버린 느낌인거죠.. 아쉽지만 이 정도로 타협을 보고 다른 오브젝트를 추가해봅시다.
생각해보니 Player와 Monster는 피격을 받을 수 있고 죽을 수도 있는 공통점이 있네요. 이 공통점을 묶어서 하나의 계층을 추가하는게 좋을것 같습니다. 이름은 죽을 수 있으니까 멋지게 Diable(Die + able!!) 라고 해봅시다! (그래요.. 저 영어 못해요.. Orz)

그런데 어느날 기획서를 받아보니 부서질 수 있는 Prop이 있어야 한다고 합니다. 이걸 어쩌죠 못만든다고 싸워야 할까요?! 마음을 가다듬고 새로운 계층을 추가하여 Prop에 부서질 수 있는 속성을 추가해봅니다..

그렇다면 이렇게 만들면 되는걸까요?! 하지만 BreakableProp과 DiableObject의 역활이 상당히 비슷해보입니다.

그럼 이렇게?! 이렇게 만들게 되면 Prop에 대한 기능이 Prop과 BreakableProp에 중복으로 들어가게 되버리겠네요..
안타깝지만 데미지 관련 처리도 역시 각자 알아서 하던지 GameObject에서 처리할 수 밖에 없습니다. 각자 넣게 되면 코드 중복이 심해지니 GameObject에 넣기로 하겠습니다.

언뜻 문제점들이 모두 해결된것처럼 보이지만 GameObject의 비중은 점점 더 커져만 갑니다. 이런 문제는 만들면 만들수록 다양해질수록 복잡해질수록 계속 나타나게 됩니다. 애니메이션 기능이 필요하지 않는 Prop이 존재한다면? 물리 시뮬레이션이 되어야 하는 오브젝트? 애니메이션은 하지만 물리 시뮬레이션은 하지 않고, 물리 시뮬레이션은 하지만 애니메이션은 하지 않고.. 이런 경우에는 어떤 기능을 어디에 넣어야 할까요?

오브젝트의 타입이 늘어나면 늘어날수록 기능이 추가될수록 점점 더 설계는 복잡해지고 상위 계층은 비대해집니다.

이 미래의 인간도 계층 구조로 설계되었나봅니다.. 그래서 이렇게 뇌 계층에 기능이 계속 추가되어 비대해진것이 아닐까요?


두번째.. 컴포넌트 기반 게임 오브젝트 설계!

컴포넌트 기반 설계는 게임 오브젝트가 해야 할 기능들을 각각 별도의 객체로 생성하여 게임 오브젝트에 연결하는 방식으로 게임 오브젝트의 클래스 폭발과 비대화 등의 문제점들을 해결할 수 있는 설계 방식입니다. 오브젝트마다 필요한 기능이 있다면 그 기능을 하나의 컴포넌트로 만들고 게임 오브젝트에 연결하여 게임 오브젝트가 해당 기능을 사용할 수 있도록 하는 것입니다. 실제 게임 오브젝트 클래스는 주로 컴포넌트들의 관리를 하게 됩니다.

[-] Collapse

class ComponentBase;
class GameObject
{
public:
     GameObject( entity_id entityID );
    ~GameObject();

    void Update( float elapsedTime );

    entity_id GetEntityID() const;

    void SetPosition( const Vector3& position );
    const Vector3& GetPosition() const;

    void SetOrientation( const Quaternion& orientation );
    const Quaternion& GetOrientation() const;

    bool InsertComponent( ComponentBase* pComponent );
    ComponentBase* GetComponent( const component_id& componentID );
    const ComponentBase*GetComponent( const component_id& componentID ) const;

private:
    entity_id m_entityID;

    Vector3 m_position;
    Quaternion m_orientation;

    boost::unorderd_map<component_id, ComponentBase*> m_components;
};

게임 오브젝트가 컴포넌트들을 관리 할 때에는 컴포넌트마다 고유 식별자가 필요합니다. 그리고 이 식별자를 GetComponent함수의 인자로 받아 해당 컴포넌트를 얻어올 수 있도록 합니다.

컴포넌트 기반 설계에서는 게임 오브젝트가 하는 거의 모든 일들이 각각의 컴포넌트들에서 이루어지기 때문에 역시 컴포넌트가 가장 중요한 요소라고 할 수 있습니다. '화면에 그려지는 기능', '생명치 관련 처리', 'AI', '물리 시뮬레이션', '전투에 대한 처리' 등등 따로 떼어낼 수 있는 모든 기능들이 컴포넌트로 만들어질 수 있습니다.

[-] Collapse

class GameObject;
class ComponentBase
{
public:
    ComponentBase() : m_pOwner( NULL ) {}
    virtual ~ComponentBase() = 0 {}

    virtual const component_id& GetComponentID() const = 0;
    virtual const component_id& GetFamilyID() const = 0;

    virtual void Update( float elapsedTime ) {}

    void SetOwner( GameObject* pOwner );
    GameObject* GetOwner() const;


private:
    GameObject* m_pOwner;
};

컴포넌트들은 계층 구조로 설계할 수 있습니다.

게임 오브젝트를 계층구조로 만드는 것이 아닌 하나의 기능을 담당하는 컴포넌트를 계층 구조로 만들어 복잡도를 낮추고 효율적으로 만들 수 있습니다.

이때 상속 관계에 있는 컴포넌트들은 서로 연관된 처리를 하는 것일테고, 이렇게 연관된 컴포넌트들은 게임 오브젝트가 두 개 이상 가질 필요가 없는 경우가 존재합니다. 이것을 분간하기 위해 '패밀리 식별자' 라는것을 사용합니다. (패밀리 라는 이름은 GPG6-게임 구성요소 시스템에 사용된 용어를 그대로 가져왔습니다.)
이 패밀리 식별자를 사용하여 게임 오브젝트에서 실제 연결된 컴포넌트를 얻을 수 있습니다.

예를 들어 RenderComponent를 만든다고 가정해보겠습니다. RenderComponent는 화면에 그려지는 기능을 하는 컴포넌트일 것입니다. 화면에 그리기 위한 모델데이터를 가지고 있거나, 외부에서 호출될 Render 함수를 제공하거나 또는 Render에 필요한 데이터들을 설정하거나 반환하는 함수가 있을 것입니다.

이 컴포넌트를 게임 오브젝트에 추가를 해주면 게임 오브젝트는 화면에 그려질 수 있습니다.

[-] Collapse

GameObject* pGameObject = new GameObject();
RenderComponent* pRenderComponent = new RenderComponent();
pGameObject->InsertComponent( pRenderComponent );

...

ComponentBase* pComponent = pGameObject->GetComponent( "render" );
if( pComponent != NULL )
{
    RenderComponent* pRenderComponent = static_cast<RenderComponent*>( pComponent );
    pRenderComponent->Render();
}

그런데 만약 파일에서 읽은 모델을 그려야 하는 경우도 있고, 프로그램 내부에서 만든 지오매트리 모델을 그려야 하는 등 RenderComponent를 나눠야 한다면..

ModelRenderComponent와 GeometryRenderComponent를 만들고 RenderComponent를 상속받는 이런 형태로 만들 수 있을 것입니다. 그런데 이 경우에 패밀리 식별자로 관리를 해주지 않는다면 게임 오브젝트가 ModelRenderComponent와  GeometryRenderComponent를 모두 가질 수 있게 됩니다. 같은 기능을 하는 컴포넌트이기 때문에 의도한것이 아니라면 로직이 복잡해지거나 이상해질 수 있습니다.
 
[-] Collapse

GameObject* pGameObject = new GameObject();
ModelRenderComponent* pModelRenderComponent = new ModelRenderComponent();
pGameObject->InsertComponent( pModelRenderComponent ); // ?
GeometryRenderComponent* pGeometryRenderComponent = new GeometryRenderComponent();
pGameObject->InsertComponent( pGeometryRenderComponent ); // ?

...

ComponentBase* pComponent = pGameObject->GetComponent( "model_render" );
if( pComponent != NULL )
{
    ModelRenderComponent* pModelRenderComponent = static_cast<ModelRenderComponent*>( pComponent );
    pModelRenderComponent->Render(); // ?
}

pComponent = pGameObject->GetComponent( "geometry_render" );
if( pComponent != NULL )
{
    GeometryRenderComponent* pGeometryRenderComponent = static_cast<GeometryRenderComponent*>( pComponent );
    pGeometryRenderComponent->Render(); // ?
}

물론 일부러 이렇게 작업해야할 경우도 있겠지만 의도하지 않은 경우라면 문제가 생길 수 있는 부분입니다. (사실 마땅한 예제가 떠오르지 않아서..)
패밀리 식별자를 사용하면 이런 문제를 해결할 수 있습니다. 같은 기능을 하는 컴포넌트들을 묶어서 같은 패밀리 식별자를 부여하고 패밀리 식별자를 이용하여 얻어오는 것입니다.

[-] Collapse

GameObject* pGameObject = new GameObject();
ModelRenderComponent* pModelRenderComponent = new ModelRenderComponent();
pGameObject->InsertComponent( pModelRenderComponent );

...

ComponentBase* pComponent = pGameObject->GetComponent( "render" );
if( pComponent != NULL)
{
    RenderComponent* pRenderComponent = static_cast<RenderComponent*>( pComponent );
    pRenderComponent->Render();
}

이런식으로 하나의 기능을 컴포넌트 단위로 구현하여 게임 오브젝트에 연결해 나가는것이 컴포넌트 기반 설계입니다.


그리고.. 컴포넌트 하면 빠질 수 없는 메시지 통신!

컴포넌트 하나가 자기 혼자서 하나의 기능을 모두 처리할 수 있으면 좋겠지만 아쉽게도 게임이 이렇게 간단한 기능들만 요구하지는 않습니다. 하나의 기능을 처리하기 위해 여러 컴포넌트가 서로를 참조하여 서로에게 데이터를 얻어 실행되어야 하는 기능들이 굉장히 많이 존재하게 되죠. 이렇게 컴포넌트끼리의 의존성이 증가하게 되면 이것 역시 개발을 힘들게 하는 요소가 됩니다. 참조하는 컴포넌트의 인터페이스가 수정되거나 해당 기능을 하는 컴포넌트가 교체되거나 할 때 참조하는 모든 컴포넌트들을 찾아서 일일히 다 수정해야 하는것부터 컴포넌트를 설계할때에도 이 의존성때문에 더 어렵고 복잡하게 설계하게 되기도 하게 되죠.. 다른 컴포넌트와의 연관성을 직접적으로 관리를 해주어야 할테니까요

이러한 컴포넌트끼리의 의존성을 없앨 수 있는 방법으로 제안된 것이 메시지 통신 입니다. 메시지 통신을 사용하여 컴포넌트가 다른 컴포넌트를 참조할때 직접 접근하지 않고 느슨하게 접근하게 됨으로써 인터페이스의 변경이나 컴포넌트의 교체 등의 수정이 이루어져도 영향을 받지 않게 되고 또 설계를 할 때에도 명확하게 구분이 가능해집니다. 그리고 멀티쓰레드의 도움도 더 쉽게 얻을 수 있습니다.

메시지 통신의 설명은 간단한 예시를 가지고 설명을 해보면 좋을것 같습니다. 게임 오브젝트가 A와 B라는 컴포넌트를 가지고 있고, A는 B에게 종이를 가져와서 종이학을 접는 일을 한다고 가정해보도록 하죠.

 
메시지 통신을 하지 않는 경우에는 A가 B에게 직접 종이를 달라고 말하고 그렇게 종이를 받아와서 종이학을 접는 형태가 될 것입니다. 따라서 B가 없어지고 종이를 줄 수 있는 컴포넌트가 C로 변경된다거나 또는 B에게 종이를 받기 위한 인터페이스가 달라진다면 B를 사용하고 있는 A도 역시 수정을 해야 합니다. 이것이 대표적인 문제점으로 지적되는 컴포넌트끼리의 의존성입니다.

그렇다면 메시지 통신을 이용하면 어떻게 될까요?
 
메시지는 편지나 쪽지와 같다고 생각하면 이해하기가 편합니다. B에게 직접 가서 "종이를 내놓으시지 B군" 이라고 말하는 것이 아니라 "나는 필요하다 종이" 라고 쪽지를 남겨놓는 것입니다. 그리고 그 쪽지를 본 컴포넌트들 중 종이를 줄 수 있는 컴포넌트가 있다면 종이를 쪽지에 넣어 남겨둬서 A가 종이를 쓸 수 있도록 하는 것입니다.

이렇게 만들면 A는 종이가 있으면 종이를 가져와서 종이학을 접고 종이가 없으면 쪽지를 남겨놓고 다른 일을 하거나 기다리는 형태가 될 것입니다. B나 C가 어떤 수정이 일어나던 A에게 아무런 영향을 주지 않습니다. 물론 아무도 종이를 줄 수 없다면 A는 시간낭비만을 하게 되겠지만요.. 이렇게 의존성이 사라진 것입니다. 

[-] Collapse

class GameObject
{
    ...

    void HandleMessage( Message message )
    {
        컴포넌트들 돌면서
        {
            컴포넌트->HandleMessage( message );
        }
    }
};


class ComponentBase
{
    ...

    virtual void HandleMessage( Message message ) = 0;
};

위 코드가 메시지통신을 하는 컴포넌트의 기본적인 형태입니다. (물론 이렇게만 만들지는 않겠지만요..)
간단하게 설명해보자면 컴포넌트들을 알고 있는 게임 오브젝트 또는 메시지 통신을 중개하는 특정 객체에 메시지를 보내면 메시지를 받아야 할 컴포넌트들을 돌면서 각 컴포넌트들에게 메시지를 전달하고 컴포넌트들은 메시지를 확인하여 자신이 처리할 수 있는 메시지인지 확인 후에 해당 메시지를 처리하는 형태입니다.

그럼 다시 위의 예제로 돌아가서 B는 어떤식으로 메시지를 처리하게 될지 살펴보도록 하겠습니다.

[-] Collapse

class ComponentB
{
    ...

    virtual void HangleMessage( Message message )
    {
        switch( message.GetType() )
        {
        case eGOCMessage::나는 필요하다 종이:
            {
                종이를 메시지에 싸서 던진다.
            }
            break;

        case eGOCMessage::나는 필요하다 풀:
            {
                풀을 메시지에 싸서 던진다.
            }
            break;
        }
    }
};

이런식으로 B에서는 자신이 처리할 수 있는 메시지이면 그에 맞는 처리를 해주고 아니라면 무시해주는 형태입니다. 또는 HandleMessage() 이전에 처리할 수 있는것인지를 먼저 확인하는 함수를 하나 더 두어서 처리 가능한지 아닌지 여부를 미리 확인받을수도 있구요.

어쨌든 이렇게 하면 컴포넌트끼리 직접 접근을 하지 않고도 서로 메시지를 통해 복잡한 처리가 가능해집니다. 그렇기 때문에 어떤 컴포넌트의 인터페이스가 변경되거나 삭제되거나 하더라도 해당 컴포넌트를 사용하던 모든 코드를 뒤져서 수정해야 하는 문제도 없습니다. 그리고 다른 컴포넌트와 직접 연결되는 부분이 없기 때문에 메시지를 던지고 받는 부분만 신경써주면 멀티쓰레드의 활용도 수월해집니다. 따라서 컴포넌트 기반 설계의 장점이 더욱 빛나게 되는 것이지요.


그렇다면.. 계층 구조를 사용한 오브젝트 설계방식은 버려야 하는것인가?!

절대 아닙니다!! 만들어야 하는 게임을 고려하여 게임 오브젝트의 종류와 복잡도에 따라서 결정해야 할 문제입니다!! 만약 게임 오브젝트의 수가 많지 않고 복잡하지 않는 게임이라면 컴포넌트 기반으로 만드는것이 오히려 게임 구조를 복잡하게 만들 수 있습니다. 컴포넌트를 이용하는 설계 방식이 아무래도 기본적으로 고려해야 할것도 많고 기본적인 코드의 양도 많기 때문이지요..

굉장히 다양하고 복잡한 게임 오브젝트가 요구되는 게임이라면 계층구조 설계 방식을 사용하는것보다 컴포넌트 기반으로 만드는것이 좋다고 확신합니다.

다양하고 복잡한 게임 오브젝트를 계층 구조만으로 만드는 것은 4인치짜리 갤X시s를 안방 TV로 사용하는 것처럼 불편한 일입니다..

하지만 간단하고 단순한 게임 오브젝트가 요구되는 게임이라면 컴포넌트 설계 방식을 사용하는 것이 오히려 불편해질 것입니다.


요즘 많은 분들이 말씀하시는 것이지만.. 저도 마찬가지로 게임을 만들때 중요한 것은 기술을 만드는것이 아니라 게임을 만드는 것이라고 생각합니다. 안해본것 새로나온것 다른 회사에서 쓰는것을 우리 게임에 적용하는것보다 자신이 만들고 있는 게임 자체를 이해하고 게임을 재밌게 만들기 위해서 필요한 것이 무엇인지를 고민하고 그것을 위한 코드를 만드는 것이 제일 중요한 일이니까요..

우리 모두 재밌는 게임을 만들어 봅시다!!

다음 연재에서는 오늘 설명한 컴포넌트 기반 방식을 기준으로 제가 사용하고 있는 것들을 몇 가지 소개해보려고 합니다.
아마도 컴포넌트의 ID를 템플릿을 이용하여 사용하거나 객체의 컴포넌트 내용들을 xml 로 저장하거나 읽어올 때의 매크로 활용 등이 되지 않을까 생각해봅니다.. 자세한건 그때 컨디션과 여러가지 요인에 따라서..

0. 

http://www.venturesquare.net/1975 

우선 제 글은 이 글에 대한 답변으로부터 시작합니다. 
'투자유치시에 지분율에 너무 연연해하지 말라.'는 아주 vc 입장에 가까운 이야기가 저 글이군요.

물론 이 글 내부를 읽어보시면, 내용은 명확합니다. 투자 안받으면 회사가 망할지도 모르는 상황이라면!! 이라는 중요한 단서가 달려있습니다.  물론 그런 상황에서 물불 가릴 처지는 아닙니다.  그렇지만 그런 상황을 만들지 않으려고 열심히 사업하는건데, 애당초 처음 마음 가짐부터 투자 유치시에 지분율 연연하지 말라니.. 좀 위험한 발언이네요.  정말 그 말 그대로 믿고 투자 계약서에 싸인하시면 여러분은 나중에 투자 계약서 볼때마다 이런 모습을 지으실 껍니다.

오히려 저는 이렇게 이야기하고 싶습니다.  '지분 나눌때는 꺼진 불도 다시 볼만큼 신중! 신중! 또 신중!'
 
1.   이 전 글에서도 말씀드렸지만, 지분은 회사의 실소유와 관계된 사항이고, 회사를 운영하는데 중요한 부분이기때문에 어떻게 나눌지를 신중하게 판단하셔야 합니다. 그리고 지분율을 어떻게 해놨느냐에 따라서 추후에 투자를 받을 때도 영향을 많이 받을 수 있기때문에 애초에 지분율을 잘 정해두는 것이 아주 중요합니다.   

당연히 한사람이 100% 다 가지고, 회사 다 책임지고, 회사의 열매도 다 먹겠다는게 가장 분쟁은 없습니다만, 요새 게임 회사가 한두푼 들어가는 것도 아니고, 이것이 쉬운 일은 절대 아닙니다. 그래서 대부분 공동으로 창업하게 되기 마련이고, 제가 추천했었던 것은 한사람이 60% 이고 나머지가 40%이라고 한 부분은 바로 이 책임소재를 확실히 해두고, 이후에 투자를 받을때도 잘 진행할 수 있기때문에 정해드리는 부분입니다. 

여기서 잠깐 퀴즈

Q1.  일반적으로 vc들이 투자를 하면 어느 정도 선의 지분을 요구할까요?

일단 그 기준은 애매합니다.  그렇지만 한국의 케이스를 기준으로 제가 애매한 것 딱 정해드리겠습니다.

FI(재무적 투자자)의 관점에서 첫번째로 투자가 들어오는 회사라면, 저는 10-15% 정도의 지분이 적당하다고 생각됩니다.

물론 SI(전략적 투자자)라면 좀 다릅니다만, 일단은 FI에 관해서만 말씀드리도록 하겠습니다.

대략 저정도 지분이 들어올때 회사에 들어오는 돈은 10-15억 사이입니다.  그렇다면 회사는 투자후밸류로 100억을 받게 되는 것이죠.
자기 회사가 송재경급의 스타개발자가 만드는 회사가 아니다? 그럼 우리 이거 기준으로 밸류에이션 조율하는 것입니다. 딱 정해드리겠습니다.

저는 VC의 첫번째 허들을 넘으셔서 투자를 받으시는 분에게는 회사 입장에서도, VC 입장에서도 깔끔하고 이상적인 밸류라고 생각합니다.
VC도 투자를 해서 돈을 벌어야 하는데, 일단 퍼블리싱 정도까지 갈 수 있는 회사 정도의 밸류는 저정도가 적당하다고 보입니다.  그래서 게임이 성공하면 3-500억대의 밸류의 회사로 가는 것이고, 그 결과를 볼 때까지 3-4년 정도가 걸릴 것입니다.  그렇다면 성공한 게임을 고른 VC는 연평균 35-50%의 수익률을 거두게 되는 것이죠.  적당해 보입니다.  실패할 수도 있으니까요.

자 그렇다면 다시 두번째 질분

Q2.  15%의 지분을 신주배정방식으로 증자한 이후라면, 60%의 지분율인 사람은 어떻게 되나요?

자 그럼 이렇게 됩니다.
대주주 A= 51%,  그외 주주=B는 34%, 그리고 VC=C는 15%

제가 늘 주장하는 외통수! 황금 비율 주주 구성이라고 하는 내용이 됩니다.

자 이게 왜 이럴까요?

이 지분 구조에서 일단 최종 결정권자는 누구일까요?

대주주-51% 인간입니다.

단 이 주주 비율에서 누구 맘대로 정관을 바꾸거나 주주총회의 특별결의를 특정인 맘대로 할 수 있을까요?
삐!!익!!!  불가능합니다.

왜냐면 말이죠.  주주총회 특별 결의 사항의 조건에 아무 서로 애매하게 걸려있기 때문입니다. 바로 이것이 구조의 핵심입니다.

주주총회 특별 결의가 통과되려면, 1/3 이상의 주주가 주주총회에 참석해서 참석한 주주의 2/3이 찬성을 해야 합니다.
정관을 변경하려면 바로 주주총회 특별 결의로 통과를 시킬 안건이랍니다.

이 경우에 B가 주총에 참석한다면, A가 맘대로 정관을 함부러 바꿀 수 없습니다.

마찬가지로 B,C가 한편을 먹는다해도 A가 반대하면 정관을 바꿀 수 없습니다.

또한 A,C가 편을 먹어도 B가 반대하면 정관을 바꿀 수 없습니다. 

고로, 서로 견고하게 견제하면서 회사의 운영은 A가 중요한 결정을 드라이브해 나가는데 힘을 합하고, 서로 한 방향을 위해 딴 맘 안먹고 열심히 일 할 수 있는 지분 구조라는 사실입니다. 


2.  자 그렇다면 도대체 정관이 뭐길래 저리 중요하고, 함부러 바꾸거나 하면 안될까요?
그리고 도대체 저번에 말한 동반매도권과 우선매수권은 뭔가요?

요건 다음 시간에. -_-;;

2월은 아실분들은 아시겠지만, 참 바쁜 달이여서요.  ㅠㅠ  한가해지면 좀 더 길게 쓰겠습니다.

ps. 지도편달받아 짤방 넣어봤는데 아직 영 감이 안오는.

안녕하세요. 새롭게 기획 필자가 된 돼지홍입니다. 제가 훌륭한 기획자는 아니지만 각자의 다양한 생각을 공유하고 초보 기획자분들에게 작게나마 도움이 될 수 있을 것 같아 시작하게 되었습니다. 미천한 지식이지만 시작해보도록 하겠습니다.

 

첫 주제는 기획 의도에 대한 것입니다. 본격적인 내용은 편의상 경어를 사용하지 않았으니 양해 부탁 드립니다.

 

 

기획자라면 누구나 기획 의도가 중요한 것은 알고 있다. 하지만 지금까지 많은 기획자들과 같이 일해오면서 살펴본 결과! 의외로 기획 의도를 잘 살린 기획은 많이 보지 못했다. 중요하다고는 알고 있지만 그 것이 어떤 것이고 왜 필요한지를 모르는 것 같단 생각이 많이 들었고 그래서 첫 주제를 기획 의도로 결정하게 되었다.

 

 

A.    우선 기획 의도란 무엇인지 살펴보자.

기획 의도는 해당 시스템이나 컨텐츠 등을 만드는 이유나 목적 또는 목표 정도로 볼 수 있다. 한 마디로 누군가 “이건 왜 만드는 거에요?” 라고 물어봤을 때 대답할 내용이다. 간단하게 예를 통해 살펴보도록 하자.

※ 좀 더 세부적으로 용어를 나누어 구분할 수도 있지만 설명을 쉽게 만들기 위해 기획 의도를 좀 더 큰 의미로서 접근하였다.

 

< FPS 게임 튜토리얼 모드 기획 의도>   1.     게임 초반 적응을 돕기 위해서 추가 게임 초반에 기본적인 조작 방법을 알려줘서 유저가 좀 더 게임을 쉽게 적응할 수 있도록 도와준다. -       FPS를 처음 접하는 유저도 대상에 포함 게임의 주 타겟층에 FPS 게임을 처음 접하는 유저도 포함이 되어 있기 때문에 이를 고려하여 기본적인 컨트롤 방법(이동, 사격 등)에 대한 튜토리얼도 포함시킨다.   2.     차별화 시스템 강조 초반에 게임의 차별화된 특징을 유저에게 확실히 인식시키기 위해 튜토리얼 시스템을 활용한다.

-       각 시스템의 기획 의도는 게임 전체의 기획 의도를 포함해야 함

하나의 큰 게임에 각 세부적인 시스템들이 추가되는 것이기 때문에 게임의 기획 의도를 반드시 확인 한 후 각 시스템의 기획 의도를 설정해야 한다.

 

B.     그러면 어떤 경우를 봤길래 그러는가?

초보 기획자가 직접 만든 시스템 기획서를 다른 팀에게 설명해주는 과정에서 보통 이런 질문을 많이 듣게 된다 “이 시스템은 왜 추가돼나요?” 그러면 초보 기획자는 이렇게 말한다. “음. 흠… WOW에도 있는 시스템입니다. WOW에서 유저들이 재미있게 즐기고 있습니다. 우리 게임에도 추가되면 좋을 것 같습니다.” 그럼 다른 팀은 그냥 “아.. 네..”하고 보통 대화는 끝난다.

-       하지만 그들의 속 마음은?

야! 저거 봐 기획자 아무나 한다니까 아씨!~ 나도 기획자나 해볼까? 내가 더 잘할 수 있는데 안 그러냐?

-       기획자가 무시 받는 주된 이유 중 하나

초보 기획자의 답변은 “저 아무 생각 없어요”라고 해석될 수 있다. 현재 게임 업계 사람들에게 기획자는 누구나 할 수 있는 직업이라고 착각하고 있는 경우가 많은데 그 이유를 제공하는 주범 중 하나가 저런 경우 때문이다.

-       그렇다면 초보 기획자는 어떤 대답을 해야 했을까?

현재 우리 게임은 무엇이 부족한데 그 것을 보충해줄 시스템으로 유저는 이런 재미를 느끼게 되고 이런 효과도 얻을 수 있습니다.

※ 다른 게임을 참고하는 것이 나쁘다는 의미는 절대 아니다. 기획 의도를 완전히 파악하고 참고했다면 위와 같은 답변을 했을 것이란 의미이다.

 

C.     기획자는 명령하는 것이 아니다. 납득시키는 것이다.

누구나 일할 때 의욕을 가지고 일하면 스트레스도 덜 받고 좀 더 훌륭한 결과물을 만들게 된다. 그런 의욕을 기획자는 다른 팀에게 줄 수 있다. 그 의욕을 줄 수 있는 것이 기획 의도이다. 작업하는 사람이 기획의도를 파악해 이 것이 꼭 필요하고 왜 들어가는지 알고 납득한다면 그 것이 의욕이 되는 것이다. 하지만 기획의도를 파악하지 못하고 왜 추가되는지에 대한 의문을 가지게 된다면 그 것은 명령이 된 것이고 불만으로 이어지게 되는 것이다.

 

 

A.    큰 기획 의도만 중요한 것은 아니다.

보통은 기획서를 작성할 때 초반에 기획 의도를 강조하여 보여주는 경우가 많다. 하지만 해당 시스템의 전체적인 방향성을 보여주는 큰 기획 의도뿐 아니라 세부적인 내용에 대한 기획 의도도 중요하다. 간단하게 예를 통해 살펴보도록 하자.

< FPS 게임 친구 시스템 일부 기획 내용 >   친구 추가 요청을 상대가 수락했을 경우에만 친구 추가가 완료된다. -       기획 의도 친구는 인원이 제한되어 있고 친구 시스템의 기능(친구방 입장 등)을 악용해 상대를 괴롭힐 수도 있기 때문에 상대도 수락해야지만 친구 추가가 완료되게끔 기획하였다.

-       세부적인 기획 의도도 기록하는 것은 추천!

기획서는 다른 팀뿐 아니라 다른 기획팀원 그리고 자신도 보게 된다. 하지만 그 기획서를 봤을 때 각 세부 내용에 대해 왜 그렇게 기획했는지가 명확히 기록되어 있지 않으면 보는 사람은 작성자에게 물어볼 수밖에 없다. 하지만 한 사람이 기획서 하나만 쓰는 것이 아니다. 수 많은 기획서를 쓰는데 모든 내용을 기억하기란 힘들다. 나중에는 자신도 까먹는다. 꼭 기록하는 것을 추천한다.

-       당연한 것도 꼭 기록하자!

자신이 당연하게 생각하는 부분을 다른 사람도 당연하게 생각하는 것은 아니다. 기획서가 너무 복잡해지는 상황이 아니라면 최대한 기록하여 서로의 오해를 줄이도록 하자.

 

B.     기획 의도를 적용해야 하는 경우인지 모르는 경우도 있다.

초보 기획자가 밸런스를 만들 때 확실한 기획 의도를 포함시키지 않는 경우를 많이 보았다. 심지어 가장 중요한 밸런스 중 하나인 경험치 밸런스를 만들 때도 마찬가지이다. 그래서 아래와 같이 수치(또는 공식)와 그래프만 포함된 밸런스 기획서가 나오는 경우가 많다.

-       상상한 그림(기획 의도)이 완성한 상태에서 밸런스를 만드는 것이 중요

가끔 일부 기획자에게 기획을 어렵게 하지 말라는 이야기를 개인적으로 많이 한다. 왜냐하면 밸런스를 만드는데 자신이 생각하는 그림이 없는 상태에서 공식이나 수치부터 만들기 때문이다. 완성품을 어떻게 만들지도 모르는데 부품부터 만들고 있는 것이다. 기획자라면 누구나 게임을 많이 해봤을 것이고 결과물적인 그림은 의외로 상상하는 것이 어렵지 않다. 먼저! 내가 만들고자 하는 그림을 확실히 정한 다음에는 의외로 그에 부합하는 공식이나 수치를 만드는 것은 어렵지 않다. 쉽게 생각하자!

< 경험치 밸런스 기획 의도 일부 내용 >   1.     최고 계급은 충분한 플레이 타임 요구 필요 계급은 중요한 목표 컨텐츠이기 때문에 다른 목표 컨텐츠가 제공되지 않는 상황에서는 최고 계급 에 도달한 것은 목표가 상실되는 것이기 때문에 유저의 흥미가 반감될 수 있다. 그래서 최고 레벨은 충분한 플레이 타임이 요구되어야 한다.   2.     못하는 유저도 초반 성장 가능하게끔 지원 못하는 유저가 성장도 너무 느리다면 게임에 대한 흥미를 더 잃을 수 있기 때문에 초반에는 못하는 유저도 충분히 성장할 수 있는 시스템 및 공식을 지원한다.   3.     잘하는 유저는 초반 성장 빠르게 유도 너무 잘하는 유저가 초보자와 오랜 시간 전투하는 것을 방지하기 위해 잘하는 유저는 다른 좀 더 빠르게 성장할 수 있도록 시스템 및 공식을 지원한다.   실제 경험치 밸런스에는 위와 같이 큰 기획 의도(물론 위에 3개 보다 많습니다.)뿐 아니라 필요할 경우 특정 계급 또는 구간별 기획 의도가 필요하겠지만 너무 많기 때문에 여기에서는 생략합니다.

-       잘 모르면 다양한 게임을 분석해 보는 것이 도움

밸런스를 처음 기획하게 되면 막연한 것이 사실이다. 그렇다면 다양한 게임에 적용된 사례를 파악하고 각각 왜 다르게 적용되고 있는지 기획 의도를 분석해 본다면 우리 게임에 맞는 그림을 상상하는데 큰 도움이 될 것이다.

-       기획 의도가 없으면 테스트도 힘들다.

밸런스 테스트는 단순히 액셀에서 시뮬레이션된대로 나오는지를 테스트하는 것이 아니다. 어떠한 상황이 나오길 원했는지 그 방향(기획 의도)이 중요한 것이다. 하지만 기획 의도가 없는 상태에서 테스트가 진행되면 단순히 수치가 맞게 나오는지 정도의 테스트만 진행되거나 테스트한 사람들의 주관적인 의견에 휘둘려 밸런스의 중심이 흔들리게 되는 경우도 발생한다.

 

C.     기획 의도는 있지만 제대로 적용시키지 못하는 경우도 있다.

랜덤을 활용하는 시스템을 기획할 때 기획 의도를 제대로 실제 결과물에 적용시키지 못하는 경우를 많이 보았다. 그래서 아래와 같이 퀘스트를 기획하였어도 원하는 결과물을 얻지 못하는 경우가 있다.

< RPG 게임의 퀘스트 >   고블린을 처치해 고블린 이빨 1개를 구해와라! 고블린 이빨 획득 확률: 10%

-       확률은 유저별 격차가 아주 크다.

기획자는 10%란 확률을 설정하였지만 실제로는 유저마다 그 격차가 아주 크게 나타난다. 어떤 유저는 1마리 잡아서 바로 고블린 이빨을 획득할 수도 있고 어떤 유저는 100마리를 잡아야 획득할 수도 있다. 과연 이런 경우를 기획 의도대로 적용됐다고 볼 수 있을 것인가? 나는 아니라고 생각한다.

-       퀘스트 아이템 확률 시스템 자체를 의도대로 움직이게끔 변경

기획자가 원하는 방향에 따라 다르겠지만 여기에서는 운이 좋은 유저는 그대로 유지하고 너무 퀘스트 아이템이 나오지 않아 스트레스를 받을 수 있는 상황만 보완하기 위해 아래와 같은 시스템을 추가하였다.

※ 아래 시스템은 예를 들기 위해 간단히 만든 것이기 때문에 일부 문제 있는 부분이 있습니다. 그냥 참고 용도로만 봐주세요.

 

< 퀘스트 아이템 확률 시스템 >   1.     퀘스트 수행 회수를 저장 고블린을 처치할 때마다 그 횟수를 저장   2.     평균 획득 확률에 획득하지 못할 경우 +1회마다 확률 2배 증가 고블린 이빨은 10%이기 때문에 10번 잡아서 나오지 않으면 11번째 잡을 때는 20%확률로 나오고 12회 때는 40%확률로 나오게 만든다.

 

 

모든 기획 내용에 대해서 자신이 확실한 의도를 가지고 만들었다면 다른 사람이 어떤 질문을 하더라도 납득할 수 있는 답변을 할 수 있을 것이고 그렇다면 충분히 다른 사람에게도 인정 받을 수 있는 기획자가 될 수 있을 것이다.

 

 

A.    기획 의도가 자체가 틀릴 수도 있다.

기획자가 여러 상황을 고려하고 긴 시간을 고민하여 내린 기획 의도도 틀릴 수 있다. 기획자가 신은 아니다. 기획 의도에 대한 변경이 필요할 때는 틀린 것을 인정하고 과감하게 기획 의도 자체를 변경해야 한다.

 

B.     나의 기획 의도를 상대는 납득하지 못할 수도 있다.

기획자가 고민을 통해 만든 기획 의도를 상대는 납득하지 못하는 경우도 많다. 하지만 이런 경우에도 충분한 예시나 관련 자료를 통해 상대를 납득을 시켜야만 한다.

 

C.     시스템 기획에만 기획 의도가 필요한 것은 아니다.

시스템뿐 아니라 레벨 디자인, UI, 퀘스트 등 모든 기획은 각각의 의도가 필요하다. 의도가 필요 없는 것이 아니라 의도를 생각하지 않고 바로 작업을 진행한 것이 아닌지 다시 한번 생각해보자.

 

D.    기획 의도를 잘 세우는 방법도 수련이 필요하다.

이 글은 모든 기획에 의도가 필요하고 그 것을 잘 적용시킨 기획이 나와야 한다는 것을 강조하기 위해 만든 것으로 어떻게 하면 기획 의도를 잘 만들지에 대해서는 다루지 않았다.

 

 

작성하면서도 생각하지만 기획은 정말 쉽지 않습니다. 저도 아직 매일 매일 새로운 것에 대해 고민하고 있습니다. 정말 게임 구석구석 고민해보고 어떤 것이 더 좋을지 생각해야지 좋은 기획서가 나올 수 있으니 ㅠ.ㅠ 힘들군요 ㅠ.ㅠ 모든 기획자 여러분 힘내세요!~ 기획자 파이팅!~

 

그리고 좀 여담이지만 희망은..

 

기획자는 게임 개발에 있어서 아주 핵심적인 역할을 합니다. 하지만 아직까지 인정받지 못하는 경우가 허다하죠. 하지만 이런 분위기는 한 두 명이 잘한다고 해결될 일이 아닙니다. 모두가 인정받아 기획자의 연봉 테이블좀 팍!팍!올립시다!~ 아자!~아자!~

 

정말 마지막으로..

 

부족한 부분이 많고 주관적인 부분도 상당히 포함되어 있습니다. 저와 다른 생각을 하시는 기획자분들도 많을 것입니다. 하지만 “아!~ 이런 생각과 방법을 가진 기획자도 있구나.”라고 생각하고 봐주시면 감사하겠습니다. 부족한 글 읽어주셔서 감사합니다.