[💬] 데모와 플레이테스트, 그 미묘한 차이

[익명(medal3029)]

https://youtu.be/1vtqBTX2Lzc

이번엔 데모가 무엇인지,

데모가 어떤 역할을 해야 하는지,

그리고 데모를 둘러싼 여러 용어들 (특히 vertical slice와 좀 덜 쓰이긴 하지만 horizontal slice)

그리고 플레이테스트용 데모와 판매용 데모의 차이에 대해 이야기해보려고 합니다.

요즘 게임 생태계에서는 “데모”라는 말이 굉장히 혼란스럽게 쓰이고 있어서,

개발자분들이 데모를 만들려고 할 때 헷갈리는 경우가 많습니다.

먼저 좋은 사례 하나로 시작해보겠습니다.

제가 최근 채널에서 플레이했던 Underboard라는 게임이 있습니다.

이 게임은 itch.io에 더 이른 빌드가 올라가 있었고,

브랜딩도 조금 달랐습니다.

이 개발자들이 한 방식이 굉장히 좋았다고 생각하는데요,

itch.io를 테스트 베드로 사용했습니다.

그냥 사람들한테 플레이해달라고 하고,

재밌는지 아닌지만 확인하는 단계였죠.

그 다음에야 Steam에 올렸습니다.

왜 좋은 사례냐 하면,

이 초기 개발 단계와,

상업적 제품으로 다루는 단계가

명확하게 분리되어 있기 때문입니다.

아직 재밌는지 확인도 안 된 상태에서

“위시리스트 눌러주세요!” 이런 얘기를 하지 않았다는거죠

제가 리뷰 스트림에서 어떤 게임에 꽤나 혹평을 한 적도 있습니다.

그 이유는 그 게임이 이미 상업용 데모처럼 포지셔닝되어 있었기 때문입니다.

위시리스트를 모으려는 단계였는데,

저는 아직 그 단계가 아니라고 느꼈습니다.

좋은 관행이라는 건 이런 겁니다.

충분히 플레이테스트를 거쳐 피드백을 받고,

사람들이 재밌다고 느끼는지 확인한 다음에

그때 비로소 “데모”가 되는 것.

초기 빌드를 플레이한 사람들은

개발자에게 호의를 베푼 것입니다.

그 사람들은 돈을 준 게 아니라, R&D 시간을 준 것이죠

초기 알파 단계에서 사람들이 해주는 일은

제품을 사는 게 아니라

게임을 개선하도록 도와주는 것입니다.

플레이테스트는 과학 실험 같은 거에요

그레이박스 프로토타입을 보여주고

“이 중에 뭐가 매력적으로 느껴지나요?”라고 물을 수 있습니다.

하지만 이미 방향을 어느 정도 정한 상태라면

플레이테스트의 목표는

플레이어가 가장 문제를 느끼는 지점을 찾는 것이어야 합니다.

그리고 이미 인지하고 있는 문제를 그대로 둔 채 테스트하면

쓸모없는 피드백만 쌓입니다.

이미 고쳐야 할 걸 알고 있다면,

먼저 고치세요.

90년대에 “데모”는 굉장히 명확했습니다.

게임은 완성되어 있었고,

그 일부를 잘라서 무료로 배포했습니다.

그리고 플레이한 사람이 “이거 재밌네, 돈 내고 사야겠다”라고 생각하게 만드는 것이었죠.

그 데모에서 플레이한 내용은 본편과 동일한 품질이었습니다.

마침 제가 지금 작업 중인 게임이 하나 있는데

12월에 퍼블릭 알파를 낼 계획입니다.

메인 루프를 플레이할 수 있는 공식 공개 알파죠.

공개 목적은 정보 수집입니다.

사람들이 뭐가 재밌는지,

뭐가 짜증나는지 알고 싶어서 말이죠

물론 그 단계에서도 “이건 무조건 상품이다”라고 가정하지는 않을 것이구요

아직은 상업적 가능성 검증 단계입니다.

이미 디스코드에서 플레이테스트를 진행했고,

플레이 영상을 보내주신 분도 계셨습니다.

그걸 통해 제가 못 보던 문제를 봤습니다.

예를 들어 열쇠를 모아서 문을 열 때 소비하고 그 다음 방을 카드 덱에서 고르는 구조였는데,

테스터는 “열쇠 소비 = 문 열기”가 1:1 관계라는 걸 이해하지 못했죠

그래서 열쇠를 사용할 때 애니메이션을 추가했습니다.

6개월 개발한 뒤에야 테스트한 게 아니라,

몇 분 정도 재밌게 돌아가는 시점에 바로 플레이테스트를 시작한거에요

다시 질문으로 돌아가보죠. 데모란 무엇인가?

저는 이렇게 구분합니다.

• 데모는 게임을 판매하기 위한 것
• 프로토타입은 아이디어를 검증하기 위한 것

말장난하려는건 아니에요

단지 이 구분을 의식하면 더 나은 개발자가 된다는 거죠

그럼 Vertical Slice란 무엇일까요?

대부분 사람들이 “데모”에서 기대하는 건 vertical slice입니다.

게임 전체를 하나의 시간선으로 생각해보세요.

처음부터 10시간, 100시간, 1000시간까지 이어지는 가로 타임라인입니다.

vertical slice는 그 타임라인을 세로로 잘라서

전체의 5% 정도를 보여주는 겁니다.

하지만 그 5%는 최종 품질과 동일해야 합니다.

그래야 사람들이 “아, 이게 완성판의 느낌이구나”라고 느낍니다.

많은 인디 개발자들이 하는 실수 두 가지는

첫째, 아직 프로토타입인데 상업 데모처럼 행동하는 것과

둘째, vertical slice를 너무 좁게 만드는 것 입니다

예를 들어, 튜토리얼 레벨만 보여주면서 인벤토리, 마법 시스템 같은 걸

암시만 하고 실제로는 사용해볼 수 없게 하는 경우.

그건 설득력이 없습니다.

사람들은 “이거 실제로 구현돼 있는 거 맞아?”라고 의심하죠.

그럼 Horizontal Slice란 무엇일까요?

vertical slice는 한 구간에서 모든 시스템이 다 보이는 방식입니다.

하지만 진행이 느리고, 해금 중심이고,

빌드업 중심인 게임은 vertical slice가 적합하지 않을 수 있습니다.

이럴 때는 horizontal slice가 더 적절합니다.

horizontal slice는

게임 전체 구조를 보여주되 콘텐츠 범위를 제한합니다.

예컨대, 샌드박스 게임에서 캠페인 없이 샌드박스만 제공하거나 (프리즌 아키텍트의 예시)

RTS에서 한 진영만 제공하는 것

생존 크래프팅 게임에서 일부 테크트리만 제공하는 것 등...

핵심 메커닉은 전부 체험하게 하고 콘텐츠만 제한합니다.

결론적으로,

데모는 게임을 팔기 위한 것입니다.

프로토타입은 아이디어를 검증하기 위한 것입니다.

좋은 데모는 장르 팬들이 가질 의심을 모두 해소해야 합니다.

만약 데모가 “이건 아직 구현 안 됐어요” “이건 나중에 나와요” 같은 식이라면

플레이어는 눈치챕니다.

그리고 장르 팬들은

당신보다 그 장르를 더 많이 플레이해본 사람들이죠

그 사람들을 속이려고 하면 게임은 끝입니다.

그리고 솔직히 말하면, 이미 게임은 너무 많은데,

이런 기본적인 것들조차 지켜지지 않는 게임들은 외면당할 수 밖에 없습니다

[211214(tomatoss)]

음.. 어렵군

[불타는키보드(1bnmaker)]

[아침빵(lobster7304)]

개인적으로도 이거 진짜 중요한 부분이라고 생각함. 데모랑 플레이테스트는 취지부터가 다름

[아침빵(lobster7304)]

비슷한 맥락에서, '리뷰를 통해 피드백을 받기 위해서' 데모 페이지를 별도로 만드는 것도 나는 좀 회의적임. (애초에 스팀 리뷰 본연의 취지는 피드백 수집이 아니라서..) 그래서 플레이테스트 진행하는 사례들 보면 구글폼으로 피드백 따로 받는 경우가 대부분임. 물론 그 외의 다른 이유 때문에 별도로 데모 페이지 만드는 거라면 상관없고.

[비월(lunar1228)]

데모 공개 범위를 어떻게 제한하는지도 정말 중요한것 같음...