기능 정리의 흐름
이제 기능이 정리되는 흐름과 과정에 대해
살펴보자.
기능 정리는 게임 방향성에서 보이는 추상적인
기능으로 출발해,
구체적인 기능을 도출해 정리하는 것으로
마무리 된다.
예를 들어, '다양하고 재미있는 스킬' 과
같은 방향성으로부터
'액티브 스킬', '패시브 스킬' 등 필요한
기능들을 도출할 수 있다.
이중 '액티브 스킬'은 다시 '스킬 사용 조건',
'스킬 판정', '스킬 결과' 등의 '하위 기능'들이 필요하다.
이렇게 상위 개념으로부터 시작해서
점차 하위 개념으로
진행해 내려오는 방식을 '하향식' 방법
이라고 하며,
이런 하향식 정리 방법은 앞서 설명한
세 가지 기능 정리 방법에 모두 적용할
수 있다.
하향식 방법은 시스템 기획 전반에 걸쳐
계속 사용되기 때문에 잘 알아두자.
추상적 기능으로부터 구체적인 기능들을
정리하면
자연스럽게 정리된 기능들이 구조화 된다.
정리된 기능들이 구조화되어 있다면, 이후
시스템 명세도 체계적으로 할 수 있다.
이런 구조화 작업을 하지 않고,
단순히 기능을 나열하는 것으로 기능 정리를
마치면,
시스템 세부 명세를 할 때 구조화 작업을
추가로 하게 될 것이다.
따라서 브레인스토밍 같은 방법으로 빠르게
기능을 도출할 때는
단순히 나열하는 것이 편하더라도, 어느정도
도출이 끝나면
기능들을 구조화 하는 것이 바람직하다.
앞서 힘주어 말했지만, 벤치마킹은 여러모로
굉장히 유용하다.
벤치마킹은 실제 게임을 대상으로 분석하기
때문에,
구체적인 기능들을 바로 찾아낼 수 있으며,
장단점이나 개선점까지 같이 생각할 수 있다.
또한 역기획 작업을 수행하기 때문에,
일정 수준의 기획 작업을 하는 것과 비슷한
효과도 낸다.
따라서 방향성이나 주관에 따라 정리된 기능들에
대해서도 벤치마킹을 하는 것을 추천한다.
다만 이후 시스템 상세 기획을 할 때,
더 구체적이고 심도 있는 벤치마킹을 할 수
있기 때문에,
기능 정리 단계에 벤치마킹을 너무 깊이 할
필요는 없다.
기능 정리 이후
이렇게 정리한 기능들은 실제 게임의 기능으로
최종 결정된 것이 아니다.
게임 개발에는 다양한 직군의 작업자들이 있기
때문에,
기능과 관련 있는 사람들과 해당하는 기능을
개발할지 여부를 결정하는 것이 필요하다.
이 결정을 위해 반드시 논의를 함께 진행해야
하는 사람은 다음과 같다.
- 기능을 구현해 줄 개발자
- 최종 책임자인 디렉터
- 기능의 사용자
개발자는 실제 기획안을 구현하는 사람이기
때문에,
기획자가 제안하는 기능들이 게임에 적용 가능한지,
구현 난이도가 어떤지를 확인해준다.
개발자와 협의하지 않고 기획 중심으로
기능 정리를 한 다음에
개발 조직에 이를 전달하게 되면, 부실한 개발로
이어질 가능성이 높다.
예를 들어, 모바일 환경에서 대규모 유저가
참여하는 공성전이 필요하다고 기획이 주장한들,
이를 개발 조직이 구현할 수 없다면, 아무런
의미가 없다.
개발 조직에서 구현 가능성이 없다고
판단했음에도 강행하게 되면,
개발자들의 불만이 올라가게 되고,
겉보기에만 멀쩡해 보이는 부실한 개발로
이어질 수 있다.
따라서 실제 개발하게 될 기능 정리를
위해서는
충분한 시간을 들여 개발자와 논의하는
것이 반드시 필요하다.
기능에 대해 개발자들과 같이 이야기를
할 때,
개발 조직이 기능 구현이 어렵다고 하더라도
바로 포기하지는 말자.
방향성 달성을 위해 반드시 필요한 기능이라고
생각되면,
이에 대해 디렉터와 논의를 해야 하며,
방향성을 위해 정말 포기할 수 없는
기능이라면,
비싼 개발 비용을 들여서라도 구현을
해야 하기 때문에,
어떻게든 개발자들을 설득해야 한다.
드물지만 개발자들이 자신의 작업이
편하기 위해,
구현 난이도가 높은 기능들을 개발하지
않게끔
의도적으로 부정적인 의견을 내는
경우도 있으니 주의하자.
기능 도입 여부 말고도 개발 우선순위나
난이도를 고려한 순서나
기능의 대안 등에 대해 논의하는 것도
필요하다.
최종 책임자인 디렉터와의 논의는
기능 정리에 있어 매우 중요하다.
디렉터의 성향에 따라 논의의 양상이
다르기는 하지만,
방향성 결정 주체인 디렉터와 논의를
마쳐야
기능 정리가 비로소 끝났다고 할 수 있다.
디렉터와의 논의에서 가장 중요한 것은
기획자가 정리한 기능들을 디렉터에게
설명하고 최종 승인을 받는 것이다.
물론 최종 승인을 위한 논의를 하기 전,
기획자가 기능 선택을 하기 어려울 때,
디렉터와 논의를 해
기능 선택에 도움을 받을 수도 있다.
예를 들어, '액션성 향상'과 관련해서
2D 격투 게임의 액션성과 3D 격투 게임의
액션성은 큰 차이가 있다.
디렉터와의 협의 없이 2D 격투 게임의
액션성에 초점을 맞추었는데,
이후에 디렉터가 자신의 방향성과
다르다고 판단하면
기능 정리를 다시 해야할 수도 있다.
그렇기 때문에, 기획자가 결정하기 힘든
내용이 있으면,
디렉터와 같이 논의해서 결정하는 것이
바람직하다.
또한 개발자와 협의를 할 때 나오게 되는
기술적인 어려움이나,
개발 우선순위에 대해서도 디렉터와 논의할
필요가 있다.
기획적 우선순위와 중요도가 개발적 우선
순위와 중요도는
항상 일치하지는 않기 때문에,
개발자, 디렉터, 기획자가 같이 이야기 해야 한다.
기능의 사용자가 따로 있는 경우에는
이들과도 논의하는 것이 좋다.
콘텐츠 개발을 위해 고안되는 시스템의 경우,
콘텐츠 기획자나 제작자와 협의를 하는
것이 필요하다.
'시네마틱 연출' 기능이 필요하다고 판단했을 때,
연출 담당 기획자(아티스트)가 어떤
연출을 하고싶어 하는지 들어봐야 한다.
그리고 이를 통해 연출 담당 기획자가
필요한 기능들을 정리해야 한다.
그렇지 않으면 실제로 시네마틱 연출을
제작할 때,
연출에 필요한 기능을 계속 추가 개발하게
될 것이다.
시스템 개발 이후에 기능을 덧붙이게 되면,
처음에 이를 고려해 기능을 만드는 것보다
완성도나 개발 비용 면에서 좋지 않다.
물론 기능 정리 작업은 게임 개발의
초반부에 이루어지기 때문에
당시 개발 조직 내 관련 작업자가 없을
수도 있다.
이런 경우는 시스템 기획자가 미리 예측을
해서 기능을 정리하거나,
이후 문제 발생의 소지가 있지만,
관련 기능들에 대한 결정을 일단 보류해둬야
한다.
기능과 관련된 사람들과 논의가 모두 끝나면,
기능들을 다듬는 작업을 해야 한다.
간단한 기능들은 시스템 기획이 아니라,
간단한 요구사항 정리만으로도 개발이
끝나기도 하고 더 효율적일 수 있으므로,
시스템 기획을 하게 될 기능들을 선택하는
것이 필요하다.
만약 모든 기능들에 대해 시스템 기획을
하려고 마음 먹는 다면,
시스템 기획의 작업량이 과중해지고,
그로 인해 기획이 질적으로 하락하게 될
수 있다.
논의를 거쳐 확정된 기능들이라고 하더라도
100% 변경되지 않는 것은 아니다.
게임 개발을 해보면 계획대로 진행되지
않는 경우가 많기 때문에,
지금의 정리된 기능들을 맹신하면 안 된다.
구현된 기능이 만족스럽지 않을 때는
대안 기능을 찾기도 하고,
심지어 게임의 방향성이 바뀌는 경우도 있다.
오히려 처음 구상했을 때의 게임의 모습과
최종 개발이 끝난 게임의 모습은 다를 때가
더 많다.
현재 필요하다고 판단한 게임의 기능들이
게임 개발이 끝날 때까지도
그럴 것이라는 기대는 하지 않는 것이 좋다.
또한 기능 정리 작업은 본격적인 시스템
기획 전에 하는 것이 일반적이지만,
시스템 기획을 마치고 난 뒤에도 하는
경우가 있다.
온라인 게임들은 라이브 단계에서도
업데이트를 통해
쉼 없이 기능 추가가 이루어지기 때문에
기능 정리 및 도출 작업은 게임의 수명이
다할 때까지 하는 작업이라고 생각하면된다.
그럼에도 불구하고 최초의 방향성은
게임 개발에 있어 매우 중요하며,
이로부터 도출된 기능들 또한 중요한
역할을 하게 되는 것도 사실이다.
참고 및 출처
 |
|
