이번엔 데모가 무엇인지,
데모가 어떤 역할을 해야 하는지,
그리고 데모를 둘러싼 여러 용어들 (특히 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에서 한 진영만 제공하는 것
생존 크래프팅 게임에서 일부 테크트리만 제공하는 것 등...
핵심 메커닉은 전부체험하게 하고 콘텐츠만 제한합니다.
결론적으로,
데모는 게임을 팔기 위한 것입니다.
프로토타입은 아이디어를 검증하기 위한 것입니다.
좋은 데모는 장르 팬들이 가질 의심을 모두 해소해야 합니다.
만약 데모가 “이건 아직 구현 안 됐어요” “이건 나중에 나와요” 같은 식이라면
플레이어는 눈치챕니다.
그리고 장르 팬들은
당신보다 그 장르를 더 많이 플레이해본 사람들이죠
그 사람들을 속이려고 하면 게임은 끝입니다.
그리고 솔직히 말하면, 이미 게임은 너무 많은데,
이런 기본적인 것들조차 지켜지지 않는 게임들은 외면당할 수 밖에 없습니다
Copyright ⓒ 시보드 무단 전재 및 재배포 금지
