게임 기획서 어떤 내용이 들어가야 할까?

게임 기획서(이하 기획서) 에 반드시 들어가야 하는 요소가 무엇인지를 알아 보고 어떤 내용을 채우면 될지 알아 보자.

 게임을 만들려면 어떤 게임을 만들지를 알아야 한다

 

 기획자는 어떤 게임을 만들지 생각하고, 생각한 것을 문서 등의 전달 가능한 형태의 매체로 가공하여 개발팀에 전달하고

전달 받은 매체를 기준으로 프로그램팀과 아트팀이 각자의 일을 진행한다.

이때 기획서는 기획자의 생각을 가능한 정확하게 전달하는 역할을 담당한다.

 

 

이 과정에서 가장 중요한 것은 물론 기획자가 하는 생각이다.

하지만 본 포스팅에서는 생각하는 방법을 다루고자 하지는 않는다. (지루하니까)

 

본 포스팅에서는 전달 가능한 매체로 생각을 가공할때 최소한 들어있어야 하는 항목을 정리하고 예시를 보여줄 생각이다.

 

1. 당연한 이야기지만 어떤 게임을 만들고자 하는지에 대한 내용이 들어가야 한다.

기획자의 생각이 개발팀에 전달 될때 가장 많이 일어나는 문제는 전달가능한 매체로 가공하는 단계에서 일어나기 마련이다.

 아무리 좋은 아이디어를 구체화해서 게임을 기획한다고 해도 전달하고자 하는 매체에 개발팀이 알고자 하는 정보가 없다면, 그 공백을 개개인의 경험으로 채우기 때문에 최종적으로 원하는 모습이 나오지 않기 마련이다.

 

내가 만들고자 하는 게임은

 1) 이러한 규칙을 갖고 있고

 2) 이러한 비쥬얼을 보여줘야 한다.

 3) 사용자의 행동은 이러하다.

 

라는 최소 3가지를 만족시키면 기본적인 게임의 형태를 유추할 수 있다.

 

그렇다고 해서 위에 3가지만 적어서 주면 될까?

아니다. 하지만 맞다.

위에서 나열한 3가지 항목만이라도 정확하게 전달 된다면 남은 디테일은 개발자 스스로 경험으로 그 공백을 채워나가며 게임을 만들 수 있다.

 그렇게 만들어진 결과가 기획자의 생각과 크게 다르지 않을 수 있다는 말이다.

 

하지만, 모든 개발자들이 그렇게 할 수 있을까?

그 전에 위의 3가지를 정확하게 전달 할 수 있을까?

아마 높은 확률로 어려울 것이다.

 

기획서를 "문서"의 형태로 한정 짓는다면 말이다.

 

기획서는, 특히나 게임 기획서는 기본적으로 문서의 형태를 갖는 것이 맞으나, 정확한 정보를 전달하기 위해서는

수단과 방법을 가리지 않아야 한다고 생각한다.

 

내가 작성한 글로 내 생각을 전달하기 어렵다면, 동영상이든, 그림이든 무엇이든 동원해야 한다. 그것은 창피한것이 아니다.

 머리속으로 온갖 상상을 하고, 정확히 생각을 전달하지 못해 혼자 실실 웃으면서 "이거 너무 재미있지 않아요?" 하는게 더 창피한 일이다.

 

2. 기획의도

기획의도는 쉽게 말하면 기획자가 사용자에게 느끼게 해주고 싶은 감정을 말한다.

게임은 기본적으로 "즐거움" 이라는 감정을 기반으로 한다.

게임이 재미가 없다면? 그건 게임이 아니라는 것이 내 기조이기도 하다.

 

기획 의도에서 말하는 사용자에게 느끼게 해 주고 싶은 감정이란,

다양한 형태의 재미 중 어떠한 형태의 재미를 줄 것이냐는 것에 대한 답변이라고 볼 수 있다.

 

어떤 사람은 정원을 가꾸면서 즐거움을 느낀다.

또 어떤 사람은 전율미궁 같은 공포 체험을 통해 재미를 느낀다.

 

명작으로 일컬어지는 화이트데이 역시 공포(두려움)에서 오는 재미를 기획의도로 갖고 있다.

 

제일 무서운건 경비 아저씨.

 

그렇다고 해서 기획의도에 감정을 나타내는 특정 단어로 표현할 필요는 없다.

틀린 예시 (X) > 공포감에서 오는 재미 옳은 예시 (O) > 긴장을 유지하며, 미로를 빠져나가는 쾌감

 

기획의도는 게임이 만들어지면서 지켜져야 하는 절대 불변의 원칙, 기준을 말한다.

따라서 기획자가 구상한 게임의 주요 재미 요소를 사용자가 느끼게 하기 위해서 절대 바뀌면 안되는 부분을 정의해 놓는 것이 옳다.

 

3. 흐름도

흐름도(Flow Chart)는 게임이 어떤 구조로 흘러가는지에 대해서 가장 빠르게 이해 가능한 도표를 말한다 .

 

보통 이런 기호를 사용한다.

 

이런 기호를 써서 흐름도를 그려주면 된다.

하지만, 정확히 이해하지 못했다면, 모든 기호를 다 사용할 필요는 없다.

 

하지만 최소한 처리, 판단 두가지 기호는 꼭 사용하도록 하자

진행 되는 단계를 나타날 때는 처리, 현재 상황에서 2개 이상의 분기가 발생 할때는 판단.

이 두가지만 잘 써도 욕 덜 먹을 수 있다. 

 

어떻게 쓰는지 간단한 예시를 살펴 보자

 

<버그 리포팅 흐름도 예시>

 

각 단계별로 어떤 일들이 일어나고, 선택지에 따라서 상황을 쪼개서 정리하면 된다. 

조금 더 풀어서 설명하자면

 

앉아 있는 자리에서 문 밖으로 나가기 라는 행동을 흐름도로 나타내기 위해 단계를 쪼개면

 

1. 자리에서 일어난다 2. 문 방향으로 몸을 튼다 3. 1m/s의 속도로 문을 향해 이동한다. 4. 문고리를 돌린 상태에서 문을 민다. 5. 문고리를 돌린 상태에서 문을 끝까지 민다 6. 문 밖으로 걸어 나간다.

이런 식이라고 볼 수 있다.

 

물론 저기에서 더 상세하게 나누자면 더 나눌 수 있다.

특히나 판단(분기) 항목에서는

 

분기 처리

 

다음과 같이 확장할 수 있다.

 

이 정도로 표현이 가능하다면 표현 하는 것이 좋으나, 반드시 그럴 필요는 없다.

하지만, 분기 처리 예시 이상으로 자세하게 고민하면 고민할 수록 기획은 더욱 촘촘해 진다.

 

4. 상세 기획

흐름도를 작성하면서 구상된 각 단계에 필요한 조건들과 규칙, 액션을 적어 넣는다.

 

- 현재 단계를 진행 하기 위한 조건

- 조건을 만족하지 못할 경우의 처리

- 조건을 만족했다면 이어지는 규칙

- 무엇인가 결과값을 얻기 위한 공식

- 결과값을 받았을 때 발생되는 액션

 

등을 모든 단계를 가능한 잘게 쪼개서 모든 단계에 발생할 일들을 적어 넣는다.

 

이 단계에서는 각 각 조건, 규칙, 액션을 적으면서 예외 처리도 함께 진행해 주면 좋다.

 

- 돌발적으로 발생되는 현상이 있을 경우 처리 방식

- 빈번하게 발생할 것으로 예상되만 해당 시스템이 돌아가는데에 필수적이지 않은 FLOW

 

여기까지 작성되면 기획서의 기본적인 형태는 모두 완성된 형태이다.

 

5. UI

상세 기획 단계에 포함하는 경우도 있지만 본인의 경우 가독성을 이유로 별도의 섹션으로 분류 하는 편이다.

 

- 예시 UI (이미지)

   눈에 보이는 모습을 예시로 그려준다.

   앞 단계 (상세 기획) 에서 언급한 버튼의 형태와 갯수. 그 위치 등을 고려해서 UI 를 배치한다.

 

- UI 설명

   각 UI 가 어떤 역할을 하는지 설명한다.

 

- UI 액션

  UI 에 배치된 액션 키 (일반 버튼, 라디오 버튼, 드랍다운 리스트 등) 를 눌렀을 대 어떤 액션이 발생하는지 설명한다.

 

- UI 예외 처리

  UI 역시 일반적인 상황에서는 발생되지 않으나, 예외 상황에서 어떻게 처리 할지에 대해서 설명한다.

 

 

여기까지 작성이 되면 하나의 기획서가 작성 된다. 

게임 전체를 하나의 기획서로 작성하게 된다면 세부 내용은 조금씩 바뀔 수 있지만, 최소한 위에 내용을 챙겨 놓는다면, 개발팀에서 문서를 읽고 자기 마음대로 해석하는 경우는 거의 없을 것이라고 본다.

 

다음엔 실제 서비스 중인 게임을 예시로 샘플 기획서 작성 예시를 보여줄 예정이다.

 

끗.