프로토타입으로 재미 검증하기

프로토타입은 작은 실험이다

프로토타입은 게임의 첫 버전이 아니다. 출시할 게임을 작게 만든 것도 아니다. 프로토타입은 하나의 질문에 답하기 위한 실험이다.

가장 중요한 질문은 단순하다.

이 핵심 플레이가 실제로 해보면 재미있는가?

기획 문서에서는 모든 것이 그럴듯해 보인다. 한 문장 피치도 좋고, 핵심 루프도 명확해 보이고, 참고 게임도 설득력 있어 보인다. 하지만 게임은 읽는 것이 아니라 조작하는 매체다. 캐릭터가 움직이는 속도, 버튼을 눌렀을 때의 반응, 실패 후 다시 시도하고 싶은 마음은 문서만으로 확인할 수 없다.

그래서 프로토타입에서는 예쁜 화면보다 빠른 확인이 중요하다. 캐릭터가 임시 사각형이어도 된다. 배경이 회색 박스여도 된다. 효과음이 무료 임시 사운드여도 된다. 핵심은 플레이어가 무엇을 반복하고, 왜 다시 하려 하는지 확인하는 것이다.

초보자가 자주 하는 실수는 프로토타입을 데모처럼 만드는 것이다. 로고를 넣고, 메뉴를 만들고, 캐릭터 그림을 다듬고, 배경을 꾸민다. 하지만 정작 점프가 재미없는지, 퍼즐 규칙이 이해되는지, 적을 피하는 리듬이 살아 있는지는 늦게 확인한다. 이러면 문제가 발견되어도 이미 많은 리소스를 쓴 뒤라 방향을 바꾸기 어렵다.

프로토타입 단계에서는 못생겨도 된다. 느슨해도 된다. 대신 핵심 조작과 실패, 재시도는 반드시 있어야 한다.

AI 생성 이미지

회색 박스로 핵심 루프 만들기

회색 박스는 완성된 그래픽 대신 단순한 도형과 임시 오브젝트로 게임 공간을 구성하는 방식이다. 3D 게임에서는 큐브와 평면을, 2D 게임에서는 사각형과 원을 사용하면 된다. 목적은 미술 품질이 아니라 거리, 속도, 충돌, 시야, 반복 행동을 빠르게 확인하는 것이다.

첫 프로토타입은 다음 순서로 만든다.

1. 플레이어 오브젝트를 만든다.

2. 가장 중요한 조작 1~2개만 구현한다.

3. 목표 지점을 만든다.

4. 실패 조건을 만든다.

5. 즉시 재시작할 수 있게 한다.

6. 30초~3분 안에 끝나는 작은 공간을 만든다.

7. 플레이 후 바꾸고 싶은 값을 쉽게 조정할 수 있게 한다.

예를 들어 짧은 플랫포머라면 처음부터 캐릭터 애니메이션을 만들 필요가 없다. 사각형 캐릭터, 바닥, 발판, 구덩이, 도착 지점만 있으면 된다. 이 상태에서 먼저 확인할 것은 점프 높이, 이동 속도, 착지 감각, 실패 후 재시도 욕구다.

퍼즐 게임이라면 화려한 테마보다 규칙 이해가 먼저다. 블록, 스위치, 문, 목표 칸만 있어도 된다. 플레이어가 규칙을 설명 없이 이해하는지, 한 번 실패한 뒤 다른 방법을 떠올리는지 확인해야 한다.

생존 슈팅이라면 적 디자인보다 적의 등장 간격, 이동 속도, 공격 범위, 플레이어의 회피 공간이 더 중요하다. 원과 삼각형만으로도 압박감과 리듬은 충분히 검증할 수 있다.

임시 리소스를 쓸 때는 한 가지 원칙을 지켜야 한다. 임시 리소스가 핵심 판단을 방해하면 안 된다. 예를 들어 적과 아이템이 모두 같은 색 사각형이면 테스트 플레이어가 혼란스러워한다. 미완성 그래픽이어도 기능 구분은 명확해야 한다. 플레이어는 파란색, 적은 빨간색, 목표는 노란색처럼 최소한의 규칙을 정하자.

기본 사운드도 도움이 된다. 공격 성공, 피격, 점프, 클리어, 실패에는 짧은 임시 효과음을 넣어보자. 사운드는 완성도를 꾸미기 위한 장식이 아니라 행동 결과를 알려주는 피드백이다. 단, 음악과 분위기 연출에 시간을 오래 쓰지는 않는다. 프로토타입의 중심은 조작과 반복이다.

검증할 가설을 먼저 정한다

프로토타입을 만들기 전에 무엇을 확인할지 적어야 한다. 그냥 만들어서 해보면 대부분의 판단이 느낌으로 흐른다. 느낌도 중요하지만, 개발 방향을 정하려면 관찰 가능한 질문이 필요하다.

프로토타입 가설은 네 가지로 나누면 다루기 쉽다.

가설은 가능하면 행동으로 확인할 수 있게 써야 한다.

나쁜 가설은 이렇다.

• 전투가 재미있을 것이다.

• 퍼즐이 신선할 것이다.

• 분위기가 좋을 것이다.

좋은 가설은 더 구체적이다.

• 플레이어는 첫 전투에서 10초 안에 공격과 회피의 차이를 이해한다.

• 플레이어는 첫 퍼즐을 3분 안에 해결하지 못하더라도 다음 시도를 계속한다.

• 플레이어는 목표 설명 없이 화면 안의 문을 최종 목표로 인식한다.

가설이 구체적이면 수정도 쉬워진다. 전투가 재미없다는 말만 들으면 무엇을 고쳐야 할지 모른다. 하지만 플레이어가 회피 버튼을 거의 쓰지 않았다는 기록이 있으면 회피의 필요성, 입력 위치, 적 공격 예고, 보상 구조를 점검할 수 있다.

프로토타입 하나에 너무 많은 가설을 넣지 않는 것도 중요하다. 첫 실험에서는 핵심 조작과 반복성만 봐도 충분하다. 스토리 전달, 성장 시스템, 상점, 업그레이드, 수집 요소는 핵심 루프가 살아난 뒤에 확인해도 늦지 않다.

테스트는 말보다 행동을 본다

테스트 플레이어에게 물어보면 대부분 친절하게 대답한다. 재미있었다고 말할 수도 있고, 어렵지만 괜찮았다고 말할 수도 있다. 그러나 실제 행동은 다를 수 있다. 플레이 도중 멈칫하는 구간, 같은 실수를 반복하는 지점, 실패 후 바로 손을 놓는 순간이 더 중요한 정보다.

테스트할 때 개발자는 설명을 줄여야 한다. 옆에서 계속 말하면 플레이어가 게임을 이해한 것인지, 개발자의 설명을 따라 한 것인지 알 수 없다. 처음에는 간단히 이렇게만 말하면 충분하다.

• 아직 미완성이라 그래픽은 임시입니다.

• 생각나는 대로 플레이해 주세요.

• 막히면 바로 말하지 말고 잠시 시도해 주세요.

• 저는 옆에서 기록만 하겠습니다.

관찰할 항목은 많지 않아도 된다.

테스트 인원은 처음부터 많을 필요가 없다. 3명만 해봐도 큰 문제는 드러난다. 모두 같은 곳에서 막힌다면 플레이어 문제가 아니라 설계 문제일 가능성이 높다. 한 명만 특이하게 반응했다면 기록은 하되 바로 전체 구조를 바꾸지는 않는다.

테스트 후 질문은 짧게 한다.

• 처음에 무엇을 해야 한다고 생각했나요?

• 가장 헷갈린 순간은 어디였나요?

• 다시 한다면 무엇을 다르게 해보고 싶나요?

• 그만하고 싶어진 순간이 있었나요?

• 하나만 고친다면 무엇을 고치면 좋을까요?

주의할 점은 플레이어의 해결책을 그대로 따르지 않는 것이다. 플레이어는 문제를 잘 느끼지만, 항상 좋은 해결책을 제시하지는 않는다. 어떤 사람이 점프를 더 높게 해달라고 말했다면 실제 문제는 점프 높이가 아니라 발판 간격, 카메라 위치, 착지 판정일 수 있다. 말은 단서로 듣고, 행동을 근거로 판단해야 한다.

재미가 부족할 때의 판단 기준

프로토타입이 재미없게 느껴지는 것은 실패가 아니다. 오히려 빠르게 알았다면 성공에 가깝다. 문제는 재미없는 이유를 보지 않고 계속 꾸미는 것이다. 그래픽을 올리고 사운드를 넣고 스토리를 붙여도 핵심 루프가 약하면 오래 버티기 어렵다.

재미가 부족할 때는 세 가지 선택지가 있다. 수정, 축소, 폐기다.

수정은 핵심 아이디어는 가능성이 있지만 값과 규칙이 맞지 않을 때 선택한다. 이동 속도가 느리다, 적이 너무 빨리 나온다, 피드백이 약하다, 목표 표시가 부족하다면 수정 대상이다. 이 경우에는 수치를 바꾸고 다시 테스트한다. 한 번에 여러 요소를 바꾸지 말고, 가장 의심되는 요소부터 바꾸는 것이 좋다.

축소는 아이디어는 좋지만 현재 범위가 너무 클 때 선택한다. 전투, 퍼즐, 성장, 제작, 스토리를 모두 넣으려 해서 핵심이 흐려졌다면 하나만 남긴다. 예를 들어 던전 탐험 게임이 너무 복잡하다면 먼저 한 방에서 적을 피하고 열쇠를 얻어 탈출하는 구조로 줄인다. 작은 형태에서 재미가 살아나면 그때 확장해도 된다.

폐기는 핵심 행동 자체가 반복할 이유를 만들지 못할 때 선택한다. 여러 번 수정해도 플레이어가 목표를 이해하지 못하고, 실패 후 재시도하지 않으며, 개발자 본인도 더 개선할 방향을 찾지 못한다면 과감히 멈추는 편이 낫다. 버린 프로토타입은 낭비가 아니다. 잘못된 방향으로 몇 달을 쓰는 것을 막아준 결과물이다.

판단을 돕기 위해 다음 기준을 사용해보자.

중요한 것은 자존심보다 시간이다. 프로토타입은 작품 평가가 아니라 방향 평가다. 재미가 약하다는 결과는 개발자를 부정하는 말이 아니다. 현재 규칙 조합이 충분히 작동하지 않는다는 신호일 뿐이다.

프로토타입을 끝내는 기준

프로토타입은 영원히 다듬으면 안 된다. 어느 순간에는 본 제작으로 넘어갈지, 다시 만들지, 프로젝트를 접을지 결정해야 한다. 끝내는 기준이 없으면 프로토타입이 미완성 게임처럼 커진다.

첫 프로토타입의 종료 기준은 다음처럼 정할 수 있다.

• 핵심 조작 1~2개가 구현되었다.

• 시작, 실패, 재시작, 클리어가 가능하다.

• 3명 이상이 설명 없이 플레이했다.

• 관찰 기록이 남아 있다.

• 수정 후 다시 테스트한 결과가 있다.

• 계속 개발, 축소, 폐기 중 하나를 결정했다.

계속 개발하기로 했다면 다음 단계는 프로토타입을 그대로 키우는 것이 아니다. 먼저 기획 문서와 기능 우선순위를 업데이트해야 한다. 테스트에서 확인된 핵심 재미는 남기고, 효과가 약한 기능은 보류 목록으로 보낸다. 이때부터 본 제작에 들어갈 최소 완성 버전을 다시 정의한다.

프로토타입이 지저분한 코드와 임시 리소스로 만들어졌다면 버리고 새로 만드는 편이 나을 수도 있다. 프로토타입의 목적은 빠른 검증이지, 좋은 구조의 기반 코드가 아니다. 물론 코드 상태가 깔끔하고 확장 가능하다면 이어 써도 된다. 하지만 임시로 억지 연결한 구조를 본 제작까지 끌고 가면 나중에 더 큰 비용을 낸다.

작은 게임일수록 프로토타입의 힘이 크다. 한 번의 빠른 실험으로 몇 주, 몇 달의 낭비를 줄일 수 있다. 보기 좋은 화면을 잠시 미루고, 먼저 손맛과 반복성을 확인하자. 플레이어가 다시 시작 버튼을 누르는 순간이야말로 이 게임을 더 만들 가치가 있는지 알려주는 가장 현실적인 신호다.