7. 게임 시스템 기획 컨셉의 구체화와 기능 분리

시스템 기획 시작하기

대부분의 시스템 기획은 필요 기능 정리, 요소 확립, 데이터 설계 과정을 거쳐 진행된다. 하지만 프로젝트 상황에 따라 다양한 환경에서 프로젝트 오더가 시작되며, 대부분 2가지 형태중 하나로부터 시작된다.

 

▶. 게임 콘셉트에 따른 기획
보통 게임은 콘셉트가 정해진 상태로 개발이 시작되지만 대부분의 콘셉트는 매우 함축적인 의미를 가지고 있기 때문에 명확한 단어를 사용했다 하더라도 이를 표현할 수단(시스템)을 구성하기에는 불특정 한 부분이 많다. 시스템 기획을 시작하기 위해서는 필요한 기능을 도출하고 이를 정리해야 하기 때문에 초기 기획의 콘셉트를 보다 구체화하여 명확하게 설명 가능한 수단(시스템)을 찾는 과정이 필요하다.

<콘셉트가 설정되어 있더라도 이를 구체화하는 과정을 통해 방향성 표현을 위한 기능을 도출해야 한다.>

 

▶. 콘텐츠 구성에 대한 기획
개발 초기 단계가 아닌 이상 대부분의 시스템 기획은 프로젝트 오더를 통해 한정된 콘텐츠의 기능 목록을 작성하고 규칙과 데이터 설계를 통해 개발이 진행된다. 게임 콘셉트보다 구체화된 기능에 대한 언급이 포함되는 경우가 많지만 이 단계 또한 추상적인 기획 의도를 가지고 있기 때문에 구체화 과정을 통해 규모와 의도를 명확하게 확인할 필요성이 있다.

<프로젝트 오더를 통해 특정 콘텐츠의 시스템을 구성해야 할 경우에도 추상적 기능 구체화는 필요하다.>

 

※. 기획 콘셉트에 대한 구체화 과정은 시스템 기획만이 아닌 대부분의 기획 업무에서 포괄적으로 진행되어야 한다. 특정 콘셉트는 함축적인 의미를 가지고 있기 때문에 해석의 차이에서 오는 괴리감을 줄여야 한다.

프로젝트의 규모와 개발 환경에 따라 다르지만 모든 기획의 시작 단계에서 프로젝트 오더에 대한 구체화된 정보를 확인할 필요가 있다. 이 과정이 완료되었다면 시스템 기획을 위한 다음 단계를 진행하게 된다. 아래 순서는 글을 통해 설명하기 위해 작성된 내용이며, 실제 업무에서는 절차적으로 진행되지 않고 모든 과정이 병렬로 진행되는 것을 기억해야 한다.

<설명을 위해 도표는 절차적으로 표시되지만 실제 업무는 모든 사항이 병렬로 진행된다.>

※. 물론 이러한 단계를 항상 따라야 할 필요는 없다. 개인 적으로 현업에 근무하는 동안 콘셉트로부터 시작해 최종 시스템 기획까지의 과정을 설명하기 위해 정리되었다. 상황에 따라서 데이터 설계 이후 또는 방향성(게임 콘셉트) 검토 없이 시스템 기획을 진행될 수 있다. 기획자라면 항상 자신의 현재 상황에 따라 업무를 어떻게 진행해야 할지 유연한 결정을 내릴 수 있어야 한다.

 

기능 정리

방향성(게임 콘셉트) 확인이 완료되었고 콘셉트가 어느 정도 구체화되었다면 필요한 기능의 윤곽이 보이기 시작한다. 하지만 아직 정리된 기능은 추성적인 부분이 있어 이를 보다 구체적으로 한번 더 기능을 정리할 필요가 있다. 앞서 추상적 기능 구체화를 통해 스킬 시스템의 필요성이 확인되었고 스킬을 어떻게 구성해야 하는지에 대한 보다 구체적인 기능 정리가 필요하다.
※. 그림과 같은 형태로 정리하는 것을 계층형태의 구체화 과정인데 이렇게 정리할 경우 요소 확립 단계에서 보다 명확하게 내용을 유추할 수 있는 장점이 있다. 단 꼭 이렇게 구체화 과정을 진행할 필요는 없다.

<기능 정리는 아직은 추성적인 개념에서 각 항목을 보다 상세하게 구체화시키는 작업이다.>

 

이런 식의 기능을 찾아내는 방법은 아무것도 없는 상황에서 시스템 기획에 필요한 내용을 찾기에 적합하다 하지만 기능 정리만으로 확실하게 요소를 확립하기보다는 전체적인 시스템 구성의 틀을 만들어 내는 것이 중요하다.

 

벤치마킹을 통한 기획

많은 경험을 가지고 있다면 기능 정리 이후 요소, 동작 원리, 규칙을 설계할 수 있지만 그렇지 못한 경우 다른 게임을 참고하여 시스템 기획에 필요한 내용을 정리할 수 있다. 이미 많은 게임이 시장에 나와있으며, 개발 중인 프로젝트와 유사하거나 동일한 형태의 시스템을 가진 게임을 찾을 수 있다. 아니면 유사 기능을 보유한 게임을 참고할 수 있다. 이러한 게임을 벤치마킹하여 시스템을 역으로 분석하고 그에 따라 필요한 기능과 동작 원리 그리고 규칙을 확립할 수 있다.
-. 이미 완성된 시스템이 구동되고 있기 때문에 다양한 상황을 실험하고 필요에 따라 규칙과 동작 원리를 정리하는데 유용하다.
-. 벤치마킹은 매우 유용하지만 초반에 이야기했듯이 정도가 지나칠 경우 콘텐츠의 경쟁력을 떨어트릴 수 있다.
※. 벤치마킹은 실무에서도 매우 유용하다. 전체 시스템 또는 일부 시스템을 벤치마킹할 필요성이 있는데 이를 위해서는 평소 게임에 대한 지식이 상당히 필요하다. 때문에 게임을 개발하고 싶다면 장르의 구분 없이 다양한 게임을 평소에 즐기는 것을 권장한다.

<이미 유사 시스템의 게임이 있다면 이를 참고하여 시스템 기획을 진행할 수 있다.>

 

■. 시스템&콘텐츠 벤치마킹
▶. 개발 프로젝트의 방향성(게임 콘셉트)이 명확해야 한다.
-. 자신의 프로젝트 방향성(게임 콘셉트)이 명확하게 풀이되지 않았다면 유사 게임을 벤치마킹할 수 없다. 잘못된 벤치마킹은 게임의 전체 방향성(게임 콘셉트)과 다른 형태의 시스템(또는 콘텐츠)을 양산할 수 있기 때문에 벤치마킹 이전에 프로젝트가 추구하는 목표가 무엇인지 명확하게 확인해야 한다.

▶. 기존에 존재하는 방향성(게임 콘셉트)이나 기능이어야 한다.
-. 기존 게임을 통해 확인할 수 없는 기능이라면 이미 정말 새로운 기능이기 때문에 벤치마킹 의미가 없다. 높은 수준의 벤치마킹을 원한다면 평소 다양한 게임을 플레이하고 개발 단계의 정보를 수집해야 한다.

▶. 벤치마킹 범위 설정
-. 게임에 이미 완성된 시스템을 제공하기 때문에 자신이 원하는 형태의 기능을 가지고 있더라도 내부적으로 생각하지 못한 또는 눈에 보이지 않는 추가 시스템이 포함되어 있을 수 있다. 이러한 기능을 함께 포함할지 아니면 일부 기능만을 선택할지에 대한 결정이 필요하다.

▶. 객관성 유지
-. 개인의 주관에 따라 결정되는 경우가 많기 때문에 취향이 많이 반영될 수밖에 없다. 때문에 논리적으로 기능에 대한 객관성, 대중성, 프로젝트의 방향성(게임 콘셉트)에 적합한지에 대한 부분을 고려해야 한다.

벤치마킹은 매우 유용한 기획 방식이며 특정 게임 시스템을 역으로 기획 형태로 문서가 생산되기 때문에 일정 수준 이상의 기획 문서 작업의 결과물이 나올 수 있다. 단 초기 벤치마킹에서는 방향성(게임 콘셉트)에 맞는 기능들에 대한 탐색을 중심으로 하고 상세 기획시점에 보다 구체적인 벤치마킹이 필요하다.

※. 게임에 필요한 기능은 프로젝트의 방향성(게임 콘셉트)에 적합해야 한다. 기획자의 개인 취향과 선호도는 시스템에 반영되어서는 안 된다. 기능은 항상 중립적이어야 하며, 특정 시스템이 더 우월하다는 생각보다는 프로젝트에 적합한지 그리고 필요한지에 대한 객관적인 판단이 중요하다.

<시장의 성공 여부와 상관없이 각자 장점과 단점을 가지고 있다. 어느 게임이 우월하다고 판단해서는 안된다.>

 

시스템 그룹

방향성(게임 콘셉트)과 기능 정리를 통해 구체화된 내용이 파편화되어 있을 경우 유사 기능끼리 그룹화하여 하나의 시스템 덩어리로 만드는 과정이 필요하다. 이미 계층구조 형태로 기능을 정리했을 경우 이와 같은 작업을 할 필요는 없지만 데이터 설계 단계를 보다 쉽게 진행하고 싶다면 미리 정리해 놓는 것이 좋다.
※. 단일 시스템(콘텐츠)의 경우 기능 구체화 목록에서 별도 시스템으로 분리되지 않는 경우도 있다. 시스템 규모에 따라서 필요할 때 진행하면 되는 선택사항 정도로 이해하고 넘어가자.

<다양한 기능이 구체화되었고 이러한 기능을 유사 기능으로 그룹화하면 별도 시스템으로 분리될 수 있다.>

 

복합 시스템 분리

유저가 게임에서 이용할 때는 하나의 시스템이지만 내부적으로 시스템이 두 개 이상으로 분리되는 형태의 시스템이 있다. 이러한 시스템은 각자 고유 정보를 가지고 필요에 따라 정보를 교환하며 시스템이 동작하도록 한다 주의할 부분은 시스템을 구성할 때 정보(기능)를 어느 시스템에서 보유하고 있어야 하는지 결정해야 한다.
-. 복합 시스템의 경우 시스템 구성단계에서 기능을 사용하거나 보유해야 하는 주체가 어느 시스템인지 결정해야 한다. 예를 들어 스킬의 레벨은 스킬 시스템에서 보유하지만 레벨을 상승시키기 위한 정보는 스킬 레벨업 시스템이 보유하는 형태이다.
-. 스킬 레벨 정보의 주체는 스킬 시스템이지만 레벨을 변화시키는 기능은 스킬 레벨업 시스템이 주체가 된다.

<스킬 성장이라는 하나의 시스템으로 보이지만 내부 시스템은 두 개로 분리될 수 있다.>

 

스킬의 레벨은 스킬 시스템 고유 정보이지만 스킬 레벨을 성장시키기 위해서는 이벤트와 인풋 조건이 필요하며, 이러한 조건을 발생시키는 별도 시스템이 스킬 레벨업 시스템이 된다. 스킬 레벨업 시스템에서 이벤트와 인풋을 발생시켰다면 아웃풋은 스킬 시스템의 레벨의 상태가 변경되는 것으로 완료된다.

<스킬 레벨업 요청 후 서버는 아웃풋으로 변경되는 스킬 레벨을 제공하고 서버 역할에 따라 DB에 정보 저장>

 

※. 복합 시스템 분리의 내용이 이해되지 않는다면 시스템 기획 개념 항목을 다시 한번 확인해 보자 시스템이 동작하기 위해서는 이벤트(System Event)와 인풋(Input) 그리고 아웃풋(Output)이 필요하다. 그리고 스킬의 레벨이 변화(증가)하는 것은 스킬 레벨 상태(Condition)가 변화하는 것이다.

 

시스템 분리

파편화된 기능 명세에서 그룹화를 통해 시스템을 구성할 수도 있지만 일부 시스템의 경우 하나의 시스템이 여러 하위 기능들로 구성될 수 있다. 각 하위 기능의 규모가 너무 크거나 복잡한 경우 시스템을 분리하여 개별로 시스템 기획이 진행되어야 한다.

<시스템이 하위 시스템 보유하고 다른 시스템 또한 하위 시스템을 보유하는 계층 구조를 가질 수 있다.>

 

캐릭터 시스템은 캐릭터 데이터에 관련된 시스템만을 포함하지만 연관된 다양한 시스템을 하위 시스템으로 보유할 수 있다. 그리고 포함된 하위 시스템 또한 다른 시스템을 보유할 수 있기 때문에 기능에 따라 시스템을 분류할 수 있어야 한다.

-. 시스템 분리 작업은 복합 시스템과는 다소 차이가 있다. 복합 시스템의 경우 시스템이 동작하기 위해 기능을 분리했다면 시스템 분리는 하위 계층별 역할의 차이를 가지고 있기 때문에 별도 시스템으로 분리된다.
-. 이미지에서는 간단하게 분리했지만 상세하게 분리하기 시작하면 더 많은 시스템이 계층 구조를 가질 수 있다.

※. 시스템 규모가 너무 큰 경우 기획과 개발 담당자는 고려해야 하는 항목이 너무 많고 복잡해질 수 있다. 다른 성향의 시스템은 분리하여 적당한 시스템 규모를 구성해야 한다.

---

여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.

질문이 있으시면 방명록에 글을 남겨주세요.

---