안녕하세요.
15, 30일이 연재를 맡게된 이태성이라고 합니다.
제 소개를 드리자면 초등학교 때 파이널 판타지 7을 보고 그래픽 디자이너의 꿈을 키우다 친구집에서 우연히 한 블랙&화이트로 기획자를 해야겠다라고 마음먹은 갈대같은 남자 이태성이라고 합니다. (-_-);
제가 작성할 내용은 "화려한 기획서는 좋지 못한 기획서이다" 라는 주제입니다. 간단히 이야기하면 "기획서가 허전해 보인다고 이것 저것 그림 넣고 참고 자료 넣다 보면 화려해지고 가득 채워 진 듯 싶지만 그 만큼 위험해질 수 있다"라는 내용입니다. 자 그럼 자세히 알아 보도록 하겠습니다.
..........................
...............................어라?
(물론 농담입니다. ㅎㅎㅎㅎ)
자 이런 일도 있고 해서..
저는 다른 주제로 글을 쓰기로 마음 먹었습니다. (T.T)
기본기 탄탄하고 멋진 다른 분들이 기획에 대한 여러가지 뼈있는 글들을 쓸 것이라고 믿고, 저는 이번에 더욱 유연한 플레이를 할 수 있도록 순수 게임 개발 외의 관련 테스트에 대한 중요성에 대해 쓰려고 합니다. (어찌 보면 영양가가 없을 수 있습니다.) 유저 트래킹과 흡사한 내용이지만 제가 주장하는 내용은 유저 트래킹이 가기 전까지 기획자가 해당 역활을 미리 수행하여 생기는 문제를 막자입니다.
많은 회사에서 "유저 트래킹"시스템이 게임 내부에 설계 되어있지 않아 오프라인 테스트를 진행하여, 각각 테스터의 모니터를 녹화하여 분석하는 팀도 꽤나 있더군요. 그러나 저는 그 전에 개발자가 중점으로 해야하는 테스트가 바로 "게임 플레이 플로우 테스트"라 말합니다.
아시다 싶이 해당 테스트는 아래와 같은 상황을 막아주기 위해 있습니다.
그렇다면 유저들이 언제 게임을 떠나고 싶어할까요?
물론 모든 유저에게 만족스러운 게임을 만들기라는 매우 힘든 일이란 것을 잘 알고 있지만, 5~10분만에 접속을 끊는다는 것은 매우 위험한 요소가 초반에 있기 때문에 문제가 생기는 것 입니다. 개발자 역시 "5~10분안에 유저들이 이 게임을 떠날 것인지 더 플레이할 것인지 판단한다"라고 말합니다. 그러나 개발자가 해당 사항을 인지하면서도 왜 유저들을 떠나게 게임을 만들까요? 왜 놓칠까요. 여자친구 보다 소중한 유저들을 왜 놓칠까요?(전.. 여자친구가 더 좋습니다. 근데 없네요..)
게임 플레이 플로우 테스트의 정의는 무엇인가?
그렇습니다. 게임을 개발하다보면 아무것도 모르는 햇병아리와 같은 마음으로 테스트에 임하지 않습니다. 당연히 유저들도 이정도는 파악할 것이다. 익숙하기 때문에 괜찮다.라는 마음에 테스트는 단순히 개발에 대한 버그가 있는지에 중점으로 테스트 합니다. 초기 개발이나, 라이브 게임이나 시스템 혹은 퀘스트를 만들면 모든 개발자들이 사내 테스트를 거치게 됩니다. 그리고 완성이 되면 해당 구간은 잊어버리고 또 새로운 철로를 만들기 위해 기획하고 만들고 그립니다. 또 개발이 완료되면 테스트하고 문제 없으면 다시 잊어 버립니다.
바로 이 부분에서 일어나는 "개발 -> 테스트 -> 다음"이 반복될 때 입니다. 이 상황이 쉽게 발생할 수 있는 함정은 바로 "다음"에 있습니다. "개발" -> "개발" -> "개발" 사이의 유연한 연결고리를 이끌어 주는 것에 대한 것을 놓쳐 생기는 문제 입니다. 왜 놓치게 될까요?
대부분의 팀의 기획자는 1명이 아니기 때문입니다. 때문에 각각의 개성이 지닌 기획자들이 만든 시스템/퀘스트가 잘 어울려지게 묶는 것이 쉽지가 않습니다. 그렇기에 플레이 테스트가 필요한 것입니다. "과연 유연한가?"에 대해 끊임없이 고민해봐야 합니다. 프로그래머, 그래픽 디자이너가 놓쳐도 기획자는 절대 놓쳐선 안되는 중요한 핵심입니다.
정리하자면
저는 다른 주제로 글을 쓰기로 마음 먹었습니다. (T.T)
기본기 탄탄하고 멋진 다른 분들이 기획에 대한 여러가지 뼈있는 글들을 쓸 것이라고 믿고, 저는 이번에 더욱 유연한 플레이를 할 수 있도록 순수 게임 개발 외의 관련 테스트에 대한 중요성에 대해 쓰려고 합니다. (어찌 보면 영양가가 없을 수 있습니다.) 유저 트래킹과 흡사한 내용이지만 제가 주장하는 내용은 유저 트래킹이 가기 전까지 기획자가 해당 역활을 미리 수행하여 생기는 문제를 막자입니다.
많은 회사에서 "유저 트래킹"시스템이 게임 내부에 설계 되어있지 않아 오프라인 테스트를 진행하여, 각각 테스터의 모니터를 녹화하여 분석하는 팀도 꽤나 있더군요. 그러나 저는 그 전에 개발자가 중점으로 해야하는 테스트가 바로 "게임 플레이 플로우 테스트"라 말합니다.
아시다 싶이 해당 테스트는 아래와 같은 상황을 막아주기 위해 있습니다.
발로만들었냐?: "저 이게임 해봤는데 5분만에 지움ㅋ" |
그렇다면 유저들이 언제 게임을 떠나고 싶어할까요?
그것은 바로 “자신이 생각한 대로 게임의 내용이 흘러가지 않을 때” 라고 전 생각합니다. |
물론 모든 유저에게 만족스러운 게임을 만들기라는 매우 힘든 일이란 것을 잘 알고 있지만, 5~10분만에 접속을 끊는다는 것은 매우 위험한 요소가 초반에 있기 때문에 문제가 생기는 것 입니다. 개발자 역시 "5~10분안에 유저들이 이 게임을 떠날 것인지 더 플레이할 것인지 판단한다"라고 말합니다. 그러나 개발자가 해당 사항을 인지하면서도 왜 유저들을 떠나게 게임을 만들까요? 왜 놓칠까요. 여자친구 보다 소중한 유저들을 왜 놓칠까요?
게임 플레이 플로우 테스트의 정의는 무엇인가?
게임의 각각의 구간 (초반 유저가 꼭 거쳐야 할 길)들을 모두 테스팅해서, 지루한 부분이 생기는 곳, 그리고 답답한 곳, 헤매는 곳, 어이없이 사망하는 곳 등등 유저가 불편하고 필요 없는 요소를 체크해서, 유저가 유연하게 플레이 할 수 있도록 걸러내는 작업을 말합니다. |
그렇습니다. 게임을 개발하다보면 아무것도 모르는 햇병아리와 같은 마음으로 테스트에 임하지 않습니다. 당연히 유저들도 이정도는 파악할 것이다. 익숙하기 때문에 괜찮다.라는 마음에 테스트는 단순히 개발에 대한 버그가 있는지에 중점으로 테스트 합니다. 초기 개발이나, 라이브 게임이나 시스템 혹은 퀘스트를 만들면 모든 개발자들이 사내 테스트를 거치게 됩니다. 그리고 완성이 되면 해당 구간은 잊어버리고 또 새로운 철로를 만들기 위해 기획하고 만들고 그립니다. 또 개발이 완료되면 테스트하고 문제 없으면 다시 잊어 버립니다.
바로 이 부분에서 일어나는 "개발 -> 테스트 -> 다음"이 반복될 때 입니다. 이 상황이 쉽게 발생할 수 있는 함정은 바로 "다음"에 있습니다. "개발" -> "개발" -> "개발" 사이의 유연한 연결고리를 이끌어 주는 것에 대한 것을 놓쳐 생기는 문제 입니다. 왜 놓치게 될까요?
대부분의 팀의 기획자는 1명이 아니기 때문입니다. 때문에 각각의 개성이 지닌 기획자들이 만든 시스템/퀘스트가 잘 어울려지게 묶는 것이 쉽지가 않습니다. 그렇기에 플레이 테스트가 필요한 것입니다. "과연 유연한가?"에 대해 끊임없이 고민해봐야 합니다. 프로그래머, 그래픽 디자이너가 놓쳐도 기획자는 절대 놓쳐선 안되는 중요한 핵심입니다.
정리하자면
유저가 좀더 몰입할 수 있게 인터랙티브 요소를 유연하게 다가가게 하자, 귀찮게 하지말자
미야모토 시게루의 "밥상 뒤집기"라는 사건이 매우 유명하죠? 다 만들어놨더니 플레이해보고나서 "다시 만들자"라고 말하는 것이죠. 전 이 것이 "게임 플레이 플로우 테스트"라고 생각합니다. 게임을 개발할 때 버그 테스트가 아닌 플레이 테스트가 지속적으로 이루어지지 않는다면, 유저들이 밥상을 뒤집을 것 입니다. 중요한 것은 초반에만 테스트가 진행되다면 5~10분짜리가 1~2시간 더 지속되는 게임으로 남을지도 모릅니다. 지속적으로 컨텐츠가 될 때 마다 많은 고민을 하여 2~3시간, 100~ 영구!로 쭉쭉 늘립시다!
감사합니다. :)
미야모토 시게루의 "밥상 뒤집기"라는 사건이 매우 유명하죠? 다 만들어놨더니 플레이해보고나서 "다시 만들자"라고 말하는 것이죠. 전 이 것이 "게임 플레이 플로우 테스트"라고 생각합니다. 게임을 개발할 때 버그 테스트가 아닌 플레이 테스트가 지속적으로 이루어지지 않는다면, 유저들이 밥상을 뒤집을 것 입니다. 중요한 것은 초반에만 테스트가 진행되다면 5~10분짜리가 1~2시간 더 지속되는 게임으로 남을지도 모릅니다. 지속적으로 컨텐츠가 될 때 마다 많은 고민을 하여 2~3시간, 100~ 영구!로 쭉쭉 늘립시다!
감사합니다. :)
반응형
'기획' 카테고리의 다른 글
온라인게임 퀘스트 보여주기 (10) | 2012.01.13 |
---|---|
적절한 시스템 기획을 위한 추상화 이야기 (2) (22) | 2012.01.03 |
적절한 시스템 기획을 위한 추상화 이야기 (1) (28) | 2011.12.27 |
기획서는 어떻게 써야 할 까? (34) | 2011.12.26 |
온라인 게임 개발 "무어의 법칙" (24) | 2011.12.22 |