*제대로 된 게시판에 올리는 것이길 바랍니다. 아니라면 알려주세요. 아직 Reddit에는 좀 서툰 아저씨입니다 :D *

저는 Steam 데모를 리뷰합니다. 플레이(Play), 아마도(Maybe), 또는 건너뛰기(Skip). 이것이 제 시스템의 전부입니다.

피드백을 요청하며 저에게 찾아온 몇몇 데모들을 살펴본 후 리뷰를 시작했습니다. 매일 얼마나 많은 데모가 쏟아져 나오는지, 품질의 범위가 얼마나 넓은지, 그리고 각 데모 뒤에 있는 개발 주기(dev cycles)가 얼마나 다른지를 깨달았습니다. 그래서 리뷰를 시작했습니다. 현재까지 주당 4~5개씩, 총 50개가 넘는 리뷰를 진행했습니다.

사이트에 올라온 51개의 리뷰 중 '건너뛰기(Skip)'는 3개뿐입니다. 이 비율은 관대해 보일 수 있습니다. 하지만 그렇지 않습니다. 무언가가 대기열(queue)에 들어가기 전에 이미 많은 필터링이 일어나며, 그 대부분은 처음 5초 안에 결정됩니다. 이 글은 바로 그 부분, 그리고 그 이후에 일어나는 모든 것에 관한 것입니다.

개발자들을 위해 작성되었습니다. 한 리뷰어의 관점으로 받아들여 주십시오.

1. Steam에서 발견되는 법

어떤 날은 Steam에 30개의 새로운 데모가 출시됩니다. 저는 그것들을 스크롤하며 빠르게 결정을 내립니다. 대부분은 플레이조차 해보지 못합니다.

필터링 순서는 다음과 같습니다: 캡슐 아트(capsule art), 프리뷰 영상의 첫 5초, 태그(tags), 설명(description). 그게 전부입니다. 이 중 하나라도 실패하면 저는 떠납니다. 여러분의 잠재적 관객 대부분도 마찬가지입니다.

제가 관찰한 몇 가지 구체적인 사항은 다음과 같습니다:

게임 내 아트와 일치하지 않는 캡슐 아트는 즉시 거부감을 줍니다.

시각적으로 독특한 무언가가 없다면 포화 상태인 장르들은 건너뛰게 됩니다. 불릿 헤븐(Bullet heaven) 게임들이나 흔한 80년대 픽셀 아트(pixel art) 같은 것들 말이죠. 저는 다른 게임을 다시 선택해야 할 이유가 필요할 정도로 그런 게임들을 충분히 많이 플레이해 봤습니다. 만약 여러분의 게임이 혼잡한 장르에 속해 있다면, 여러분의 캡슐 아트와 설명은 다른 모든 이들보다 더 강력하게 작용해야 합니다.

프리뷰 영상의 훅(hook)은 움직이는 캡슐 아트와 같습니다. 자동 재생 영상의 첫 5초는 썸네일을 통과한 사람들에게 결정적인 지점입니다. 움직임, 혼돈, 또는 설명이 필요한 무언가로 시작하십시오. 로고, 메뉴, 또는 느린 팬(pan) 장면으로 시작하지 마십시오.

2. 소셜 미디어를 통해 제 데모의 20%를 발견했습니다.

제가 리뷰하는 내용의 약 80%는 Steam을 직접 스크롤하며 찾아낸 것입니다. 나머지 20%는 소셜 게시물(social posts)을 통해 유입되었습니다. Reddit, X, TikTok 등이 그 통로였습니다.

20%는 과반수는 아닙니다. 하지만 의미가 있습니다. 적절한 타이밍의 게시물 하나, 크리에이터 한 명의 선택, 적절한 위치에서의 스레드(thread) 하나만으로도, 그대로 묻혀버렸을 게임이 사람들의 눈길을 끌 수 있습니다. 데모 출시를 앞두고 소셜 미디어에서 활동하는 데는 비용이 거의 들지 않습니다. 이는 초기 트랙션(traction) 수치를 유의미하게 움직일 수 있으며, Steam 출시 후 첫 며칠 동안의 초기 트랙션은 여러분의 게임이 어떤 페이지에 노출될지에 영향을 미칩니다.

주의할 점: 소셜 미디어의 존재감(social presence)을 데모 출시 당일이 아니라, 출시 전에 구축해 두어야 합니다. 데모에 관한 첫 게시물이 출시를 알리는 게시물이라면, 여러분은 최악의 순간에 제로(zero) 상태에서 시작하는 것입니다. 이미 프로젝트를 팔로우하고 있는 사람들이 빠르게 움직여 초기 수치를 끌어올려 줄 사람들입니다.

3. 데모 출시를 알리십시오. 그다음 모든 업데이트를 알리십시오.

대부분의 Steam 데모 페이지는 공지사항 및 이벤트(announcements and events) 섹션을 사용하지 않습니다. 이것은 실수입니다.

데모가 라이브(live) 상태가 되면 메인 Steam 페이지에 이를 공지하십시오.

그다음 모든 패치(patch)와 모든 업데이트에 대해서도 동일하게 진행하십시오. 대부분의 데모는 전혀 업데이트되지 않거나, 조용히 업데이트됩니다. 많은 데모가 정식 게임으로 출시되지 못합니다. 플레이어들도 이 사실을 알고 있습니다. 만약 여러분의 페이지가 조용해 보인다면, 사람들은 프로젝트가 중단되었다고 가정할 것입니다. 작더라도 눈에 보이는 업데이트 주기(update cadence)는 누군가가 여전히 이 게임을 작업하고 있다는 신호를 보냅니다.

만약 계획하지 않았던 게시물이 소셜 미디어에서 바이럴(viral)된다면, 데모가 여전히 작동하고 있어야 합니다. 페이지가 살아있는 것처럼 보여야 합니다. 그런 순간이 언제 찾아올지는 아무도 모릅니다. 계속 라이브 상태를 유지하십시오.

4. 찾아온 사람들을 위해 실제로 무언가를 할 준비를 하십시오.

데모는 공개적인 등장입니다. 일단 데모를 선보였다면, 여러분은 문을 하나 연 것입니다. 사람들이 그 문을 통과한 후 갈 곳이 없다면, 그 기회는 대부분 낭비됩니다.

누군가 여러분의 데모를 플레이하고 프로젝트를 팔로우하고 싶어 한다면, 그들은 어디로 가야 합니까? Discord인가요? 여러분은 그곳에 있습니까? X인가요? 그곳에 게시물을 올립니까? 기본 설정된 빈 Steam 포럼이 아닌, 어딘가에 커뮤니티가 존재합니까?

만약 게임 출시까지 아직 1년이 남았는데, 소셜 미디어(Socials)도 없고, Discord도 없으며, 피드백을 수집하거나 응답할 방법도 없다면, 데모를 너무 일찍 출시했을 수도 있습니다. 게임의 품질 측면이 아니라, 데모가 불러오는 관객과 소통할 준비가 되었는지의 측면에서 말입니다. 위시리스트(Wishlist)를 쌓아두고 나서 아무런 반응이 없는 데모는 출시 전에 그 모멘텀(Momentum)의 대부분을 잃게 됩니다.

Steam 토론(Discussions)에서 활발하게 활동하세요. Discord 링크를 거세요. 하나를 정해서 그곳에 모습을 드러내세요. 저는 개발자가 피드백을 명확히 읽고 그에 대응하여 패치를 배포하는 것을 보고, 리뷰를 작성하던 도중에 내용을 바꾼 경험이 있습니다.

5. 자격을 갖출 수 있는 모든 페스티벌에 참여하세요. 하지만 당일에 준비하지 말고, 그전에 미리 준비하세요.

이것은 새로운 조언이 아닙니다. 하지만 말할 가치가 있습니다. Next Fest와 유사한 이벤트들은 실제 트래픽 급증(Traffic spikes)을 만들어내며, 초기의 플레이어 급증은 여러분의 게임을 Steam의 더 많은 발견 페이지(Discovery pages)에 노출시킬 수 있습니다. 초기에 모멘텀을 확보한 상태로 페스티벌에 들어가는 게임이, 페스티벌을 첫 마케팅 순간으로 취급하는 게임보다 더 좋은 성과를 거둡니다.

페스티벌이 시작될 때 빠르게 움직일 준비가 된 관객을 구축하기 위해, 그 전 몇 주 동안 소셜 미디어를 활용하세요. 이미 관계를 구축해 온 사람들로부터 오는 초기의 급증은, 생소한 발견을 통해 천천히 흘러들어오는 것보다 훨씬 가치 있습니다.

6. 데모가 끝날 때 플레이어에게 다섯 가지 일을 해달라고 요구하지 마세요.

그것은 너무 많은 요구입니다. 플레이어는 한 번에 다섯 가지 결정을 내리지 않습니다. 한 번에 하나, 많아야 두 개를 내립니다.

지금 여러분에게 가장 중요한 CTA(Call to Action, 행동 유도)를 하나 선택하고 그것에 집중하세요. 위시리스트가 필요하다면, 위시리스트 추가를 쉽고 명확하게 만들고 목록 속에 묻어두지 마세요. 피드백이 필요하다면, 그것을 단 하나의 요구 사항으로 만드세요. 메뉴 화면 또한 엔딩 화면뿐만 아니라, 마찰이 적은(Low-friction) 위시리스트 유도를 하기에 좋은 장소입니다.

7. 데모의 길이는 게임의 느낌을 파악하는 데 얼마나 걸리느냐에 따라 달라집니다.

저는 15분 동안 지속되고

두 경우 모두 게임을 느낄 수 있게 해주었기 때문에 효과적이었습니다. 기준은 길이가 아니라, 게임을 느끼게 해주는가입니다.

짧은 데모는 경험이 무엇인지 빠르게 전달하는 긴밀하고 명확한 루프 (Loop)를 가진 게임에 효과적일 수 있습니다. 반면, 층층이 쌓인 시스템 (Layered systems)을 가진 게임에는 보통 더 긴 데모가 필요합니다. 그 안에 담긴 가치를 실제로 감상하기 전, 학습 곡선 (Learning curve)을 넘어서는 데 시간이 필요하기 때문입니다.

복잡한 게임을 짧은 데모로 제공할 때의 위험은 플레이어가 게임에 매료되기도 전에 붙잡히는 것입니다. 게임이 제대로 전달되기도 전에 플레이어는 이탈하며, 다시는 돌아오지 않습니다.

스토리 중심이 아닌 게임의 경우 스포일러 (Spoilers)를 걱정하지 마세요. 게임이 반복 플레이를 통해 숙달되도록 설계되었다면, 스포일러 될 만한 것은 없습니다. 스토리 중심 게임이라면 초기 챕터나 프롤로그 (Prologue)가 적절합니다. 플레이어는 보상 (Payoff)을 잃지 않으면서도 게임의 매력 (Hook)을 느낄 수 있습니다.

8. 플레이어가 자연스럽게 해금하기 전에 게임의 흥미로운 요소를 보여주세요.

데모에는 유기적인 진행 (Organic progression)을 기다려줄 시간이 없습니다. 만약 플레이어가 보통 몇 시간 후에 해금할 것으로 예상되는 동작, 능력, 또는 메커니즘 (Mechanic)이 게임에 있다면, 데모 초반에 배치하세요. 그것을 시도해 볼 수 있게 하세요.

어떤 특정 메커니즘이 새로운 플레이어의 마음을 사로잡을지는 아무도 모릅니다. 한 사람에게 게임을 팔 수 있는 요소가, 일반적인 진행 순서를 따르는 데모에서는 다른 플레이어가 결코 발견하지 못할 수도 있는 것입니다. 좋은 요소들을 빠르게 경험하게 하세요. 데모의 역할은 게임을 판매하는 것이지, 일반적인 속도로 전체 게임을 시뮬레이션하는 것이 아닙니다.

9. 메커니즘을 하나씩 도입하세요.

모든 것을 보여주는 것의 반대 급부: 모든 것을 한꺼번에 도입하지 마세요.

저는 데모를 위해 네 가지 시스템을 처음부터 배우고 싶지 않습니다. 만약 튜토리얼 (Tutorial)이 처음 10분 안에 여러 가지 새로운 것들을 이해하고 종합하도록 요구한다면, 저는 게임이 재미있어지는 단계에 도달하기도 전에 그만둘 것입니다. 제가 흥미가 없어서가 아닙니다. 아직 제가 투입한 노력에 비해 시간 투자 (Time investment)가 비례하지 않기 때문입니다.

가장 효과적인 게임들은 저를 서서히 몰입하게 만듭니다. 기분 좋게 느껴지는 메커니즘 하나, 그다음 또 다른 하나. 더 깊은 내용이 나올 것이라고 깨닫기도 전에 저는 이미 즐기고 있습니다. 그것이 올바른 순서입니다.

게임을 추천할 이유를 적극적으로 찾고 있는 리뷰어가 튜토리얼 도중에 포기한다면, 충동적으로 게임을 다운로드한 사람은 분명 그 지점에 도달하기도 전에 그만둘 것입니다.

10. 멀티플레이어 (Multiplayer) 데모는 어렵습니다. 계획이 없다면 하지 마세요.

PvP 데모는 리뷰 관점에서 거의 항상 고전하게 됩니다. 텅 빈 로비는 제가 이 게임을 즐길 수 있을지 여부에 대해 아무런 정보도 주지 않습니다. 게임이 마음에 드는지 결정하기도 전에 함께 플레이할 사람을 찾기 위해 Discord 서버에 가입해야 한다는 것은 너무 큰 마찰 (Friction)입니다.

저에게 실제로 효과가 있었던 옵션들은 다음과 같습니다: 실제 경험을 보여주는 봇 (Bots), 사전에 적극적으로 홍보된 정해진 플레이 시간대, 또는 매치메이킹 (Matchmaking)이 실제로 작동할 만큼 출시 시점에 충분한 플레이어가 배치되어 있는 경우입니다. 게임을 켜자마자 텅 빈 로비에 앉아 있게 되는 멀티플레이어 데모는 데모가 아예 없는 것보다 나쁩니다. 왜냐하면 되돌리기 어려운 첫인상을 심어주기 때문입니다.

11. 버그는 괜찮습니다. 하지만 핵심 루프 (Core loop)가 망가진 것은 안 됩니다.

데모가 완성될 필요는 없습니다. 저는 제가 개발 중인 무언가를 플레이하고 있다는 것을 알고 있습니다. 제가 높은 점수를 준 게임 중 일부는 명백한 버그가 있었습니다.

제가 용납할 수 없는 것은 핵심 경험을 망가뜨리는 버그입니다. 저는 어떤 게임에 대해 '건너뛰기 (Skip)'를 주었는데, 이는 컨셉이 나빠서가 아니라 버그가 주요 메커니즘을 막아버려 게임이 실제로 무엇인지 경험할 수 있을 만큼 진행할 수 없었기 때문입니다.

기준은 이렇습니다: '내가 이것을 실제로 플레이할 수 있는가?'

12. 제안된 해결책이 아니라, 문제점을 파악하기 위해 피드백을 읽으세요.

플레이어들은 무엇이 제대로 작동하지 않는지 식별하는 데 능숙합니다. 하지만 그것을 어떻게 고쳐야 하는지 아는 데는 대개 능숙하지 않습니다.

피드백이 들어오면, 먼저 감정적인 언어를 걷어내세요. 그중 일부는 표현이 잘못되었을 수 있습니다. 그 밑바닥에서 그 사람이 실제로 설명하고 있는 것이 무엇인지 찾으세요. 그들이 무엇을 할 수 없었나요? 무엇이 잘못되었다고 느꼈나요? 어디에서 막혔나요?

문제를 가져오세요. 그들이 제안한 해결책을 가져오지 마세요. 당신은 개발자입니다. 당신은 게임을 알고 있습니다. 그들은 자신들의 경험을 알고 있습니다.

모든 긍정적인 리뷰에 응답하세요. 부정적인 리뷰의 경우, 진정으로 유용한 말을 할 수 있거나 의미 있는 변경 사항을 알릴 수 있는 경우에만 응답하세요. 모든 피드백에 공개적으로 대응할 필요는 없습니다.

13. 위시리스트 (Wishlist) 수치뿐만 아니라, 콘텐츠 크리에이터들이 당신의 데모에 대해 무엇을 만들었는지 추적하세요.

위시리스트 (Wishlist) 수치는 명백한 지표입니다. 하지만 그것만이 유일한 신호는 아닙니다.

데모를 중심으로 어떤 콘텐츠가 생성되었는지 살펴보세요. 쇼츠 (Shorts), 영상, 서면 리뷰 등입니다. 몇 개의 콘텐츠가 만들어졌나요? 해당 크리에이터의 평소 콘텐츠와 비교했을 때 성과는 어떠했나요? 평소 평균 조회수가 500회인 크리에이터가 당신의 게임을 올렸는데 2,000회를 기록했다면, 당신의 게임이 그들의 시청자들에게 기대 이상의 성과를 낸 무언가가 있다는 뜻입니다. 절대적인 수치가 작더라도 이는 주목할 만한 신호입니다.

해당 콘텐츠에 참여하세요. 리트윗 (Retweet)은 비용이 들지 않습니다. 댓글 (Comment)도 비용이 들지 않습니다. 채널을 처음부터 구축해 나가는 독립 크리에이터에게 개발자의 인정은 대부분의 개발자가 깨닫는 것보다 관계 형성에 더 큰 도움이 됩니다. 이를 알아채는 개발자는 정식 출시 때 다시 리뷰를 받게 됩니다.

나는 누구인가

피드백은 그것이 누구로부터 오는지 알 때만 유용합니다.

나는 35~40세 연령대입니다. 영국 출신이며, 세 명의 아이가 있습니다. 12살 정도부터 게임을 해왔습니다. 예전만큼 시간이 많지 않아서 선택적으로 즐깁니다. 아무 생각도 하고 싶지 않은 저녁에는 소위 '브레인 롯 (brain-rot, 뇌를 비우고 하는)' 게임이라고 부르는 것들을 합니다. Battlefield 6, League of Legends, WoW Hardcore 같은 것들이죠. 이미 어떻게 플레이하는지 알고 있고, 영상을 보면서 자동 조종하듯 플레이할 수 있는 게임들입니다.

나의 시청자층은 나와 거의 동일합니다. 여러 플랫폼에 걸쳐 거의 전적으로 남성 중심이며, 영국/유럽/미국 지역의 30~40대 연령층이 대부분입니다. 따라서 당신이 여기서 읽고 있는 피드백과, 내 콘텐츠의 리뷰 및 댓글을 통해 전달되는 피드백은 그러한 관점을 통해 필터링된 것입니다. 만약 당신의 게임이 다른 인구 통계학적 특성을 가진 층을 위해 만들어졌다면, 이 내용 중 일부는 덜 적용될 수 있습니다.

이를 하나의 데이터 포인트 (data point)로 받아들이십시오. 아마도 이것들을 아주 많이 플레이해 보았고, 앞으로도 훨씬 더 많이 플레이할 사람으로부터 얻은 유용한 정보가 되기를 바랍니다.