기획
게임 UX 기획 - 04. prototyping 上
알 수 없는 사용자
2012. 3. 2. 16:15
01. what
02. how
03. storytelling
04. prototyping 上
05. prototyping 下
참 지루하고 재미없던 4회짜리 연재가 드디어 끝나간다!! 다시한번 재미없는 중년남이라는 사실이 여실히 드러난 것에 조금 자괴감도 들긴 하지만, 애초부터 이 글을 쓰기 시작한 것이 잘못된 만남이였을지도 모르겠..
게다가 쓰다보니 전공 분야도 아닌;; 프로듀싱과 얽히는 내용까지 끄적이는 바람에 내용이 지루하게 길어져서;; 너무 길어지면 아무도 안읽을까봐 핑계삼아 프로토타이핑은 2번에 나눠 업데이트를 할 예정이다.
어쨌든 프로토타입. 게임으로도 동명의 게임이 출시된 바 있지만, 어떻게 보자면 참 공대스러운 단어일수도 있는데 우리가 참 여기저기서 많이 듣는 단어이기도 하다. 뭔가 만들때 실험삼아 먼저 만들어 본 목업(Mock-up)도 프로토타입이라고 하고, 테스트를 위해 제작된 여러가지 구동되는 샘플들도 프로토타입이라고 하고.. 사전을 뒤져보면 '원형(原型)'이라고 뜻이 뜨는데, 이걸 또 굳이 해석하자면 '본래의 모습' 정도이려나;; 어쨌든, 최종 단계에 이전에 어떤 목적을 갖고 구현된 구체적인 모습 정도로 생각해 볼 수 있을 것 같다.
게임 개발에 있어 프로토타입이라는 것도 사실 크게 다르지 않겠지만, 프리-프로덕션 단계에 한정해 프로토타이핑에 대해 이야기 하자면 앞에서 다룬 의미와는 조금 차이가 있을 것 같다. 왜냐하면 그 목적이나 만들어진 프로토타입의 수준이 최종 단계 이전의 구현된 구체적인 모습보다는 상상해보았던 기술적인 혹은 기능적인 메커니즘을 실제로 구현해 게임으로써의 가능성을 검증하거나 보완해내기 위한 정도이거나, 실제로 어떻게 플레이 될지 혹은 어떻게 보여질지를 스케치나 영상, 혹은 시뮬레이션으로 구체화 함으로써 구현 이전에 방향성을 확인하고 더 재미있는 쪽으로 정리하고 확장해내기 위한 정도로 하나의 완성 직전의 모습보다는 굉장히 '부분적'으로 나뉘어있는 특정 단위로 만들어질 경우가 더 많기 때문이다.
그렇다면 게임의 프로토타이핑을 유저경험의 시뮬레이션이라는 전제하에 진행한다고 가정했을 때, 그 프로토타입을 만드는 방법에는 어떤 것들이 있을까?
수많은 개발사나 프로젝트가 존재하는만큼, 정말로 다양한 방법이 있을 수 있겠지만 여기서는 그 중 개인적인 경험을 통해 체험했던 큰 두가지 정도만 다뤄보고자 한다.
하나는 최종 단계에서 사용될 각 기능과 규칙 요소들을 순차적으로 실제 구현해가며 게임의 뼈대부터 차근차근 올려나가는 'Low Level Game Design'의 방법이고, 다른 하나는 최종 단계에서 플레이 될 유저경험을 예상하고 이를 우선적으로 각각 동시에 시뮬레이션 해본 후 그 중 가능성이 있어 보이는 방법만을 선별 구현해 추후 하나의 형태로 합쳐나가는 'High Level Game Design'의 방법이다. (각 용어에 대한 사전적 정의는 위키피디아 http://en.wikipedia.org/wiki/High-_and_low-level 참고)
이 차이에 대한 관점은 아래 kotaku에 공개되었던 데몬즈소울 배급에 대한 소니의 일화에서 잘 드러난다.
(발번역 죄송..)
In Japan, assets for a game are developed in parallel; in the U.S. "game development is typically a vertical slice."
Thus the early build, "the team tried to create a small piece of the experience that resembles the final product."
일본에서는 게임의 요소들이 병렬로 개발된다. (반면) 북미에서의 게임 개발은 전형적으로 수직형 조각의 형태가 된다.
그러므로 (북미 개발의) 초기 빌드에서 개발팀은 최종 제품과 닮은 (유저)경험의 작은 일부를 만들어내려고 한다.
설명이 충분하진 못한 것 같지만.. 앞의 정의나 kotaku 기사에서의 요점은 일본을 위시한 Low Level 접근에서는 각각의 기능을 완성해가며 게임이 조금씩 형태를 갖추기 때문에 최종 모습의 구체적 확인에 시간이 걸리고 그조차 제공되는 순서대로 볼 수 밖에 없는 반면, 북미를 위시한 High Level 접근에서는 각 기능 단위가 아닌 어떤 유저경험의 특징(?) 단위로 그 모습을 먼저 시뮬레이션 해보고 들어가기 때문에 좀더 최종 모습을 먼저 확인할 수 있다는 점이다.
하지만 프로젝트의 특징이나 장르 혹은 팀의 상황 등을 고려해본다면, 두 방법 중 어느 것이 더 좋고 나쁘다로 단정하기는 어렵다. 최초에 제시된 비전 자체가 감성적인 유저경험보다는 어떤 로직적인 측면에서의 재미에 집중해야 하는 퍼즐 게임이나 아케이드 게임에서는 Low Level의 프로토타이핑이 더 효율적이고 유용하다. 반면, 다양한 행동을 통해 진행되는 어드벤처나 RPG 같은 게임들에서는 어떤 행동들로 어떤 플레이를 만들 것인가에 대한 High Level 접근이 좀더 개성있고 차별화되는 프로토타이핑을 도와줄 것이다.
물론 이런 RPG류의 게임이라도 논타게팅, 던전메이킹, 소셜네트워크 연동 같은 기능적 요소에 치중한 비전을 갖고 있다면 그 또한 기술적 검증과 그로부터 파생될 재미와 가능성을 먼저 확인해 볼 수 있도록 Low Level의 접근이 더 좋을 수도 있을 것이다.
국내의 일반적인 게임 개발에 있어서도 대부분 프레임워크를 만들고 렌더링, 컨트롤러, 로직 등 실제 구현에 필요한 요소들을 하나씩 쌓아올려가며 프로토타입을 만드는 Low Level 기반의 개발이 더 많은 것 같다.
아마도 최초의 프로토타입은 이동과 기본 전투, 두번째 프로토타입은 레벨 구성과 스킬 전투 등등으로 각 기능을 순차적으로 개발하며 쉐이더와 라이팅도 적용해보고, 엑셀 연동 데이터 구조도 만들고 하는 식으로 개발해 나갔을 것이다.
이런 방식은 처음 몇 번의 프로토타이핑은 매우 빠른 반복개발 속에서 점차 확확 달라지는 모습의 플레이 가능한 결과물을 도출해 몇 차례의 까다로운 초반 허들을 통과할 수 있게 도와줄 것이다.
하지만 이 방법의 맹점은 개발을 하면 할수록 기존에 완성된 기능에 새로운 기능을 추가해 나가는데 요구되는 시간과 자원이 계속적으로 늘어난다는 점이다. 각자가 어떤 요소에 대해서 같은 상상과 느낌을 갖고 개발하지 못하는 경우도 많아지고, 그럴 때마다 이미 프로그래밍되어 구현된 결과물이 기획에 맞네 다르네, 어쨌든 난 만들었으니 쓰는 사람이 값을 넣어서 수정해보던지 말던지 등등으로 사후 확인을 하는데 자원이 소모된다.
또, 기획이 변경되거나 피드백의 벽에 부딪히게 될 때마다 요청되는 요소들이 구현된 기능 기반의 환경에서 추가할 수 있는 것인지, 예외처리를 해야하는 것인지 등등까지 따지고 들어가다보면 프로토타이핑을 통해 검증하는데까지 소요되는 시간이 예측 불가능한 수준으로까지 달라질 수 있다.
이렇게 마일스톤의 일정이 지연되다보면 허들을 통과하기 위해 보여줘야 할 부담이 누적되어, 리더의 입장에서는 전에 없던 어떤 것, 더 많은 기능 등에 집착하게 만들기 쉽다. 프리-프로덕션 단계에서의 이런 변화는 사실 당연한 것일 수 있지만, 이미 구현된 시스템과 로직이 있는 상태에서는 허들의 피드백이나 팀이 당면한 상황에 맞춰 변경하고 빼버리고 전혀 다른 것을 추가하려는 시도의 반복 자체가 팀에 큰 부담을 안기게 된다.
시간이 충분하다면 프리-프로덕션에서도 플레이 데모 형태의 프로토타입을 만드는 것이 나쁠 것이야 없겠지만, 그렇지 못하다면 굳이 어떤 게임 플레이로 유저경험의 재미를 살릴 것인지를 찾기도 이전에 프로덕션과 다른 없는 단계로 개발을 하면서 부담을 키워나갈 필요는 없지 않을까..
프리-프로덕션 단계에서는 게임의 최종 버전을 예상하여, 어떤 플레이들이 유저경험으로 전달될 것인지를 먼저 쌓아두는 것이 낫지 않을까 하는 (지극히 개인적인) 생각이 든다. 팀이나 프로젝트의 규모가 충분한 기간과 버짓, 인력을 통해 순발력 있게 프로토타입을 뽑아낼 수 있는 형편이 되는 것이 아니라면 프리-프로덕션 단계에서 최소의 자원으로 최대의 준비를 먼저 해둘 필요가 있을 것이고, 그 과정에서 '사용자에게 직접적으로 어떻게 플레이될 수 있겠다'에 대한 감성적 경험을 시각화된 형태로 바라볼 수 있게 만드는 것이 이 지루한 연재에서 의미한 '비전'이라고 한다면, 마이크로소프트가 제시했던 프로덕티비티 퓨처 비전 같은 영상이 그 개념에 대한 감을 잡게 해줄 것이다.
원래 이번에 다루려했지만 괜히 잘 알지도 못하는 프로듀싱 얘기랑 엮느라 빼먹은;;;; 게임에서의 사전영상화(Pre-visualization)에 대한 얘기를 진짜로 다음에 꼭 좀 해보자.
02. how
03. storytelling
04. prototyping 上
05. prototyping 下
참 지루하고 재미없던 4회짜리 연재가 드디어 끝나간다!! 다시한번 재미없는 중년남이라는 사실이 여실히 드러난 것에 조금 자괴감도 들긴 하지만, 애초부터 이 글을 쓰기 시작한 것이 잘못된 만남이였을지도 모르겠..
게다가 쓰다보니 전공 분야도 아닌;; 프로듀싱과 얽히는 내용까지 끄적이는 바람에 내용이 지루하게 길어져서;; 너무 길어지면 아무도 안읽을까봐 핑계삼아 프로토타이핑은 2번에 나눠 업데이트를 할 예정이다.
어쨌든 프로토타입. 게임으로도 동명의 게임이 출시된 바 있지만, 어떻게 보자면 참 공대스러운 단어일수도 있는데 우리가 참 여기저기서 많이 듣는 단어이기도 하다. 뭔가 만들때 실험삼아 먼저 만들어 본 목업(Mock-up)도 프로토타입이라고 하고, 테스트를 위해 제작된 여러가지 구동되는 샘플들도 프로토타입이라고 하고.. 사전을 뒤져보면 '원형(原型)'이라고 뜻이 뜨는데, 이걸 또 굳이 해석하자면 '본래의 모습' 정도이려나;; 어쨌든, 최종 단계에 이전에 어떤 목적을 갖고 구현된 구체적인 모습 정도로 생각해 볼 수 있을 것 같다.
풍동실험을 위해 만들어진 2009 Tesla Roadster Sport의 프로토타입 목업. 갖고싶..
게임 개발에 있어 프로토타입이라는 것도 사실 크게 다르지 않겠지만, 프리-프로덕션 단계에 한정해 프로토타이핑에 대해 이야기 하자면 앞에서 다룬 의미와는 조금 차이가 있을 것 같다. 왜냐하면 그 목적이나 만들어진 프로토타입의 수준이 최종 단계 이전의 구현된 구체적인 모습보다는 상상해보았던 기술적인 혹은 기능적인 메커니즘을 실제로 구현해 게임으로써의 가능성을 검증하거나 보완해내기 위한 정도이거나, 실제로 어떻게 플레이 될지 혹은 어떻게 보여질지를 스케치나 영상, 혹은 시뮬레이션으로 구체화 함으로써 구현 이전에 방향성을 확인하고 더 재미있는 쪽으로 정리하고 확장해내기 위한 정도로 하나의 완성 직전의 모습보다는 굉장히 '부분적'으로 나뉘어있는 특정 단위로 만들어질 경우가 더 많기 때문이다.
그렇다면 게임의 프로토타이핑을 유저경험의 시뮬레이션이라는 전제하에 진행한다고 가정했을 때, 그 프로토타입을 만드는 방법에는 어떤 것들이 있을까?
수많은 개발사나 프로젝트가 존재하는만큼, 정말로 다양한 방법이 있을 수 있겠지만 여기서는 그 중 개인적인 경험을 통해 체험했던 큰 두가지 정도만 다뤄보고자 한다.
하나는 최종 단계에서 사용될 각 기능과 규칙 요소들을 순차적으로 실제 구현해가며 게임의 뼈대부터 차근차근 올려나가는 'Low Level Game Design'의 방법이고, 다른 하나는 최종 단계에서 플레이 될 유저경험을 예상하고 이를 우선적으로 각각 동시에 시뮬레이션 해본 후 그 중 가능성이 있어 보이는 방법만을 선별 구현해 추후 하나의 형태로 합쳐나가는 'High Level Game Design'의 방법이다. (각 용어에 대한 사전적 정의는 위키피디아 http://en.wikipedia.org/wiki/High-_and_low-level 참고)
| 전자의 경우는 의도하는 게임 플레이나 각 기능(우측 그림에서 수평적으로 배치된 각각의 Component)이 실제로 하나씩 완성되어가면서 개발되기에 시스템을 쌓아가며 비교적 일정을 준수하기 용이하다는 장점이 있지만, 그 시스템 완료 후 정상적으로 동작하는지 QA와 그에 컨텐츠를 대입한 게임 플레이를 만들어 적용한 후에나 유저경험의 감성적 품질을 확인할 수 있다는 단점을 가지고 있다. 후자의 경우는 영상데모나 로직데모 등 작은 단위의 컨텐츠를 시스템 구현과 별개로 쪼개서 만든 목업(우측 그림에서 수직적으로 도려낸 The Slice)을 통해 유저경험의 감성적 품질을 예측해본 후 좋은 것만 선별적으로 개발할 수 있는 장점이 있지만, 목업에 있어 개발 일정이 지연되기 쉽고 이러한 각각의 조각난 목업들에 포함된 각 기능 단위의 완성된 시스템을 만들어 통합할 때 부하가 커지는 단점이 있다. 일부는 스크럼을 비롯한 애자일 개발도 프로토타이핑 방법 중 하나 아니냐고 불만을 제기할 수도 있겠지만, 그는 위의 각 방법을 어떻게 진행하느냐의 과정에 대한 방법이 될 순 있어도 독립적인 하나의 전혀 다른 프로토타이핑 방법은 아니라 생각되어 여기서는 제외하였다. (위키피디아 http://en.wikipedia.org/wiki/Vertical_slice 이미지) |
|
이 차이에 대한 관점은 아래 kotaku에 공개되었던 데몬즈소울 배급에 대한 소니의 일화에서 잘 드러난다.
(발번역 죄송..)
In Japan, assets for a game are developed in parallel; in the U.S. "game development is typically a vertical slice."
Thus the early build, "the team tried to create a small piece of the experience that resembles the final product."
일본에서는 게임의 요소들이 병렬로 개발된다. (반면) 북미에서의 게임 개발은 전형적으로 수직형 조각의 형태가 된다.
그러므로 (북미 개발의) 초기 빌드에서 개발팀은 최종 제품과 닮은 (유저)경험의 작은 일부를 만들어내려고 한다.
Demon's Soul ⓒ From software
설명이 충분하진 못한 것 같지만.. 앞의 정의나 kotaku 기사에서의 요점은 일본을 위시한 Low Level 접근에서는 각각의 기능을 완성해가며 게임이 조금씩 형태를 갖추기 때문에 최종 모습의 구체적 확인에 시간이 걸리고 그조차 제공되는 순서대로 볼 수 밖에 없는 반면, 북미를 위시한 High Level 접근에서는 각 기능 단위가 아닌 어떤 유저경험의 특징(?) 단위로 그 모습을 먼저 시뮬레이션 해보고 들어가기 때문에 좀더 최종 모습을 먼저 확인할 수 있다는 점이다.
하지만 프로젝트의 특징이나 장르 혹은 팀의 상황 등을 고려해본다면, 두 방법 중 어느 것이 더 좋고 나쁘다로 단정하기는 어렵다. 최초에 제시된 비전 자체가 감성적인 유저경험보다는 어떤 로직적인 측면에서의 재미에 집중해야 하는 퍼즐 게임이나 아케이드 게임에서는 Low Level의 프로토타이핑이 더 효율적이고 유용하다. 반면, 다양한 행동을 통해 진행되는 어드벤처나 RPG 같은 게임들에서는 어떤 행동들로 어떤 플레이를 만들 것인가에 대한 High Level 접근이 좀더 개성있고 차별화되는 프로토타이핑을 도와줄 것이다.
물론 이런 RPG류의 게임이라도 논타게팅, 던전메이킹, 소셜네트워크 연동 같은 기능적 요소에 치중한 비전을 갖고 있다면 그 또한 기술적 검증과 그로부터 파생될 재미와 가능성을 먼저 확인해 볼 수 있도록 Low Level의 접근이 더 좋을 수도 있을 것이다.
국내의 일반적인 게임 개발에 있어서도 대부분 프레임워크를 만들고 렌더링, 컨트롤러, 로직 등 실제 구현에 필요한 요소들을 하나씩 쌓아올려가며 프로토타입을 만드는 Low Level 기반의 개발이 더 많은 것 같다.
아마도 최초의 프로토타입은 이동과 기본 전투, 두번째 프로토타입은 레벨 구성과 스킬 전투 등등으로 각 기능을 순차적으로 개발하며 쉐이더와 라이팅도 적용해보고, 엑셀 연동 데이터 구조도 만들고 하는 식으로 개발해 나갔을 것이다.
이런 방식은 처음 몇 번의 프로토타이핑은 매우 빠른 반복개발 속에서 점차 확확 달라지는 모습의 플레이 가능한 결과물을 도출해 몇 차례의 까다로운 초반 허들을 통과할 수 있게 도와줄 것이다.
하지만 이 방법의 맹점은 개발을 하면 할수록 기존에 완성된 기능에 새로운 기능을 추가해 나가는데 요구되는 시간과 자원이 계속적으로 늘어난다는 점이다. 각자가 어떤 요소에 대해서 같은 상상과 느낌을 갖고 개발하지 못하는 경우도 많아지고, 그럴 때마다 이미 프로그래밍되어 구현된 결과물이 기획에 맞네 다르네, 어쨌든 난 만들었으니 쓰는 사람이 값을 넣어서 수정해보던지 말던지 등등으로 사후 확인을 하는데 자원이 소모된다.
구현된 결과물을 함께 보고 기획자, 프로그래머, 그래픽디자이너 각각의 입장이 확연하게 갈리는 순간!!
또, 기획이 변경되거나 피드백의 벽에 부딪히게 될 때마다 요청되는 요소들이 구현된 기능 기반의 환경에서 추가할 수 있는 것인지, 예외처리를 해야하는 것인지 등등까지 따지고 들어가다보면 프로토타이핑을 통해 검증하는데까지 소요되는 시간이 예측 불가능한 수준으로까지 달라질 수 있다.
이렇게 마일스톤의 일정이 지연되다보면 허들을 통과하기 위해 보여줘야 할 부담이 누적되어, 리더의 입장에서는 전에 없던 어떤 것, 더 많은 기능 등에 집착하게 만들기 쉽다. 프리-프로덕션 단계에서의 이런 변화는 사실 당연한 것일 수 있지만, 이미 구현된 시스템과 로직이 있는 상태에서는 허들의 피드백이나 팀이 당면한 상황에 맞춰 변경하고 빼버리고 전혀 다른 것을 추가하려는 시도의 반복 자체가 팀에 큰 부담을 안기게 된다.
시간이 충분하다면 프리-프로덕션에서도 플레이 데모 형태의 프로토타입을 만드는 것이 나쁠 것이야 없겠지만, 그렇지 못하다면 굳이 어떤 게임 플레이로 유저경험의 재미를 살릴 것인지를 찾기도 이전에 프로덕션과 다른 없는 단계로 개발을 하면서 부담을 키워나갈 필요는 없지 않을까..
프리-프로덕션 단계에서는 게임의 최종 버전을 예상하여, 어떤 플레이들이 유저경험으로 전달될 것인지를 먼저 쌓아두는 것이 낫지 않을까 하는 (지극히 개인적인) 생각이 든다. 팀이나 프로젝트의 규모가 충분한 기간과 버짓, 인력을 통해 순발력 있게 프로토타입을 뽑아낼 수 있는 형편이 되는 것이 아니라면 프리-프로덕션 단계에서 최소의 자원으로 최대의 준비를 먼저 해둘 필요가 있을 것이고, 그 과정에서 '사용자에게 직접적으로 어떻게 플레이될 수 있겠다'에 대한 감성적 경험을 시각화된 형태로 바라볼 수 있게 만드는 것이 이 지루한 연재에서 의미한 '비전'이라고 한다면, 마이크로소프트가 제시했던 프로덕티비티 퓨처 비전 같은 영상이 그 개념에 대한 감을 잡게 해줄 것이다.
원래 이번에 다루려했지만 괜히 잘 알지도 못하는 프로듀싱 얘기랑 엮느라 빼먹은;;;; 게임에서의 사전영상화(Pre-visualization)에 대한 얘기를 진짜로 다음에 꼭 좀 해보자.
반응형