플레이테스트를 통해 더 짧은 시간에 더 나은 게임을 만들 수 있습니다.
관련 분야: 프로덕션
작성자: Casey Weeks
다음 글은 제 동영상 “더 짧은 시간에 더 좋은 게임을 만드는 방법”의 스크립트를 변환한 것입니다.
안녕하세요, 저는 10년 넘게 게임을 만들고 있는 Casey “Boz” Weeks입니다.
게임을 처음 만들기 시작했을 때, 저는 2년 동안 첫 게임의 모든 디테일을 고민했습니다. 맵, 스킬 트리, 보스전, 몇 시간 분량의 콘텐츠, 튜토리얼이 완성되고 나니 드디어 플레이 테스트를 할 준비가 되었습니다.
인디 개발자로서 마지막 문장이 마음에 들지 않으셨다면 이 글을 읽어보세요.
많은 인디 개발자, 특히 초보 개발자가 플레이 테스트의 진정한 가치를 과소평가하고 있습니다. 피드백을 받는 것의 중요성을 강조하고 접근 방법에 대한 몇 가지 아이디어를 제공하기 위해 이 글을 작성했습니다.
플레이 테스트를 해야 하는 이유에 대한 짧은 답변입니다: 플레이테스트를 하면 개발 시간당 게임 디자인의 품질이 향상됩니다.
즉, 더 짧은 시간에 더 나은 게임을 만들 수 있습니다.
시작하기 전에
플레이 테스트는 종종 품질 보증과 혼용되는 경우가 많으므로 구분을 명확히 하고자 합니다.
품질 보증 테스트(또는 QA)는 기능에 관한 것입니다. 버그, 오타 및 기타 오류를 찾는 것입니다.
반면 플레이 테스트는 새로운 플레이어 앞에서 게임을 플레이하여 마법이 일어나는 지 확인하는 것입니다. 플레이테스트는 매력을 증명하기 위한 것입니다.
플레이테스트를 하지 않는다면 이 글을 읽은 후 가장 먼저 플레이테스트 일정을 잡으셨으면 좋겠습니다. 그리고 플레이테스트를 하고 있다면 이 글이 플레이테스트를 더욱 열심히 하는 데 도움이 되었으면 좋겠습니다.
대부분의 인디 개발자는 플레이테스트를 해야 한다는 것을 알고 있는 것 같지만, 플레이테스트를 하고 있는지 물어볼 때마다 저를 포함해 많은 변명을 듣곤 합니다. 이런 변명은 대개 다음과 같은 이유를 중심으로 합니다: 시간이 없다!
하지만 가장 성공한 게임의 디자이너들이 게임 개발에서 플레이테스트를 최우선 순위로 꼽는다고 하면 어떨까요?
1부: 누구나 하는 플레이테스트
Valve의 전 수석 연구 과학자 마이크 앰빈더는 “우리에게 플레이 테스트는 게임 개발 프로세스에서 가장 중요한 부분입니다. 어떤 게임을 언제 출시할지 결정하는 데 가장 큰 영향을 미치는 요소입니다.”
이 주제에 대해 더 할 말이 있는지 알아보기 위해 그에게 연락을 취했습니다.
마이크 앰바인더:
모든 게임 디자인은 가설이며, 플레이 테스트는 실험입니다. 목표는 게임 디자인에 대해 가능한 한 많은 정보를 얻어 최대한 현명한 결정을 내리는 것입니다. 목표는 게임을 플레이하는 사람들에게 매력적인 게임을 만드는 것이며, 이를 위한 가장 좋은 방법은 여러분이 아닌 다른 사람들에게 게임을 선보이는 것입니다. 그런 다음 반복해서 게임을 개선합니다. 목표는 가능한 한 빨리 사람들에게 게임을 공개하고 올바른 방향으로 가고 있는지 확인하는 것입니다.
Mike는 플레이 테스트는 불확실성을 평가하는 과학적인 도구이며, 그 해답은 플레이어에게 있다고 강조합니다. 그 외에도 놀라운 이야기들이 많았으니 나중에 더 많은 이야기를 들어보겠습니다.
저는 종종 게임 디자인을 어둠 속에서 맹목적으로 앞으로 나아가는 것에 비유합니다. 이 비유에서 플레이 테스트는 멀리서 조명이 비추면 잠시 주변을 비춰 경로를 확인하고 조정할 수 있는 것과 같습니다. (또는 절벽에서 곧 떨어질 것임을 알릴 수도 있습니다.)
쉘 게임즈는 다음과 같은 원칙을 가지고 있습니다: “끊임없이 플레이테스트하세요. 그래야만 알 수 있습니다.”
2024 GDC 강연에서 쉘 게임즈의 수석 게임 디자이너인 프란시스코 수키는 게임의 성공 비결로 신속한 플레이어 테스트 워크플로우를 꼽았습니다. (이 워크플로에 대해서는 나중에 다시 설명하겠습니다.)
“지속적으로 플레이 테스트하세요. 그래야만 알 수 있습니다."라는 문구는 어둠 속에서 끊임없이 길을 확인한다는 아이디어를 잘 보여줍니다. 플레이 테스트는 플레이어가 공감할 수 있는 방향으로 개발 프로세스를 이끌어 줍니다. 쉘 팀은 플레이 테스트를 통해 직감만으로 너무 먼 미래를 계획하는 것을 방지할 수 있다는 사실을 깨달았습니다.
언차티드 시리즈의 공동 책임자인 리차드 르마르샹은 오늘날 게임 디자인에서 플레이 테스트에 중점을 두고 있지만, 플레이 테스트가 항상 중요한 도구로 여겨지지는 않았다고 말합니다.
그는 gamesuserresearch.com 인터뷰에서 “90년대와 2000년대 초반만 해도 플레이 테스트, 특히 유저 리서치가 널리 퍼져 있지 않았습니다.”라고 말했습니다.
사실 그는 2000년대 후반 Naughty Dog에서 일하면서 플레이 테스트의 중요성을 '깨달았다'고 말합니다.
플레이 테스트를 개발 프로세스의 일부로 만들기 위한 노력은 “게임의 비밀 과학”이라는 책에서 다뤄지고 있습니다. 저자 존 홉슨은 헤일로, 월드 오브 워크래프트, 오버워치, 데스티니, 포트나이트 등의 연구 책임자로 활동해 왔습니다.
그는 이 책에서 헤일로 개발 과정에서 번지가 처음에는 플레이 테스트를 도입하는 것을 망설였다고 이야기합니다. 하지만 긍정적인 결과를 확인하기 시작하면서 플레이 테스트가 개발 프로세스에 점점 더 통합되기 시작했습니다.
업계에서 플레이 테스트를 도입하는 데 수십 년이 걸렸다는 사실을 알고 나니 2년을 기다렸다가 게임 테스트를 시작한 것이 조금은 덜 바보 같다는 생각이 들었습니다.
업계에서 플레이 테스트를 받아들이는 데 왜 그렇게 오랜 시간이 걸렸는지 더 자세히 알고 싶어서 존에게 물어보니 출시 후 온라인 피드백의 증가를 꼽았습니다.
인터넷 리뷰가 등장하기 전에는 게임 개발자가 게임을 출시하고 플레이어의 피드백을 거의 듣지 못했습니다.
하지만 지금은 게임이 출시되면 인터넷을 통해 플레이어의 피드백이 쇄도합니다.
그는 오늘날에는 게임 개발자가 출시 초기에 보다 체계적인 플레이어 피드백을 반영하도록 설득하는 것이 더 쉬워져 출시 시 성난 플레이어의 문제를 피할 수 있다고 생각합니다.
이는 인디 게임보다는 AAA급 게임의 문제일 수 있지만, 출시 전에 피드백을 수집하여 쉽게 피할 수 있었던 게임에 대한 성난 리뷰가 쏟아진다고 상상해 보세요.
2부: 자신을 신뢰하는 방법
대니얼 카너먼은 심리학자임에도 불구하고 '행동경제학의 할아버지'로 불리는 노벨상 수상자입니다. 인지 편향에 대해 들어본 적이 있다면 그와 아모스 트래버스키가 인지 편향을 최초로 소개한 사람입니다.
카네만은 “직관은 틀렸을 때나 옳을 때나 똑같이 느낀다”고 말합니다.
카네만은 학계 연구자들이 전문가들이 동일한 데이터가 여러 차례 주어졌을 때 자신의 이전 판단과 모순되는 경우가 많다는 사실을 반복해서 확인했다고 말합니다. 카네만은 이를 “실력의 착각”이라고 부릅니다.
하지만 그렇다고 해서 직관을 믿을 수 없다는 뜻은 아닙니다. 실패에 직면하고, 적응하고, 효과가 있는 것을 찾아야만 신뢰할 수 있는 직관을 구축하기 시작할 수 있습니다.
플레이 테스트와 비슷하게 들리죠?
마이크 앰바인더:
Valve에는 세계 최고의 게임 디자이너들이 있습니다. 그들은 항상 틀립니다. 모든 사람이 항상 틀린 것처럼요. 우리가 그러기를 바라지만, 세계에서 가장 똑똑한 게임 디자이너도 플레이테스트를 통해 많은 도움을 받습니다.
저는 Valve에서 세계 최고의 디자이너들과 함께 일해왔고, 그들도 같은 생각을 가지고 있었습니다.
카네만은 그의 저서 '빠르고 느리게 생각하기'에서 직관은 실제 전문 지식에 기반해야 한다고 말합니다. 그리고 전문성을 개발하기 위해서는 경험만으로는 충분하지 않으며, 신속하고 명확한 피드백을 받을 수 있는 환경이 조성되어야 합니다.
이를 다음과 같은 알고리즘으로 표현할 수 있습니다:
직관에 대한 신뢰 = 경험을 쌓는 데 소요된 시간 * 피드백의 속도 * 피드백의 명확성
더 많은 피드백과 경험, 더 나은 직관.
각자의 분야에서 20,000시간의 경험을 쌓은 컴퓨터 프로그래머와 자산관리사가 있다고 상상해 보세요.
두 사람 중 누가 자신의 분야에서 가장 많은 전문 지식을 쌓았다고 생각하시나요? 추천 결과를 가장 잘 예측할 수 있는 사람은 누구일까요?
카네만은 25명의 자산관리사들을 대상으로 8년간의 데이터를 분석할 수 있는 흔치 않은 기회를 얻은 적이 있습니다.
그가 발견한 것은 다음과 같습니다:
“...실력 차이는 발견되지 않았습니다. 결과는 실력 대결이 아니라 주사위 굴리기 대회에서 기대할 수 있는 것과 비슷했습니다.”
그 이유는 무엇일까요? 피드백의 명확성.
주식 시장은 설계상 예측이 불가능합니다. 예측이 가능하다면 시장은 완전히 뒤바뀌게 될 것입니다. 피드백이 너무 모호해서 자신이 무엇을 잘못했는지, 옳았는지 정확히 알 수 없습니다. 적응할 여지가 거의 없습니다.
반면에 컴퓨터 프로그래머는? 컴파일러는 코드가 작동하는지 여부를 거의 즉시 알려줍니다. 그리고 코드 수정이 성능 데이터를 어떻게 개선하는지 측정할 수 있습니다.
데이터가 모호하지 않고 명확합니다.
그렇다면 누구의 전문성을 더 신뢰하시나요?
이 공식을 현재 게임 디자인에 적용해 봅시다:
알고리즘을 보면 테스트 횟수가 많고 피드백이 명확할수록 게임 디자인을 더 신뢰할 수 있다는 것을 알 수 있습니다.
플레이 테스트는 게임 디자인 시간당 인사이트 점수에 몇 배의 버프를 준다고 생각하면 됩니다.
반대로 너무 자주 테스트하면 게임 개발에 투자한 시간을 상쇄할 수 있습니다. (벼랑에서 떨어지기 직전에 번개가 치는 장면을 기억하시나요?)
다시 말해, 플레이테스트를 하면 게임 디자인 작업의 생산성을 높일 수 있습니다.
빠르고 명확한 피드백을 원한다는 것은 알지만, 그게 어떤 모습일까요?
파트 3: 속도와 명확성
얼마나 자주 테스트해야 할까요?
프로젝트의 진행 상황과 리소스에 따라 다릅니다.
앞서 쉘 게임즈와 그들의 빠른 플레이어 테스트 워크플로에 대해 언급했던 것을 기억하시나요?
프란시스코 수키는 자신의 팀이 매주 말일까지 빌드를 준비하는 것을 목표로 한다고 말합니다. 그런 다음 테스트 팀은 주말 동안 외부 테스터에게 빌드를 공개합니다. 매주 월요일에는 테스트 세션에서 배운 내용을 논의한 다음 한 주 동안 집중해야 할 사항을 계획합니다. 이 모든 과정은 금요일에 테스트할 준비가 된 새 빌드로 마무리됩니다.
다른 사람들은 기능의 마일스톤에 가까워질 때까지 기다렸다가 마지막에 최대한 빠르게 반복 작업을 진행합니다.
제 프로젝트에서는 종종 한 기능을 한두 달 동안 작업하는 마일스톤에 진입하고, 완료가 가까워지면 테스트 일정을 잡기 시작합니다.
그런 다음 플레이테스트 사이에 업데이트를 할 수 있는 한 자주 플레이테스트를 하는 것을 목표로 합니다. 한 시간 이내에 새로운 테스트를 하는 것부터 매일 테스트하는 것, 일주일에 걸쳐 더 심각한 변경을 하는 것까지 다양합니다.
물론 테스트할 수 있는 능력은 테스트하고자 하는 것을 구축하는 데 걸리는 시간에 따라 달라집니다. 하지만 플레이 테스트 관리에 소요되는 시간과 게임 빌드에 소요되는 시간의 균형을 맞추는 것도 고려해야 합니다.
쉘 게임의 경우, 테스트를 관리하고 디자이너를 위해 보고서를 작성하는 직원이 있지만 최상의 결과를 얻으려면 디자이너가 직접 테스트를 지켜보거나 참여해야 합니다.
자신에게 가장 적합한 스타일을 선택하되, 테스트하기 전에 모든 것이 완벽해야 한다는 생각에 사로잡히지 말라는 조언을 드리고 싶습니다. (자세한 내용은 나중에 설명합니다)
몇 명과 함께 테스트해야 하나요?
마이크 앰바인더:
짧고 만족스럽지 못한 대답은 가능한 한 많은 인원이면 됩니다. 주어진 제약 조건에 맞춰야 합니다. 더 많은 사람에게서 데이터를 얻을수록 더 많은 인사이트를 축적할 수 있지만, 4명만 테스트할 수 있다면 그 4명을 최대한 활용하면 됩니다. 많은 사람을 대상으로 설문조사를 하지 않았다면 데이터의 노이즈가 더 많을 수 있다는 점을 인지해야 합니다.
다행히도 테스트를 자주할수록 디자인에 더 많은 관점을 반영할 수 있습니다.
피드백의 명확성
주식 시장과 달리 게임 개발은 훨씬 더 명확한 피드백을 받을 수 있습니다. 하지만 여기에는 비결이 있습니다.
아드리안 드 종은 2017년 GDC 강연에서 '플레이 테스팅'이라는 주제로 이 주제를 다룹니다: 악의적인 데이터 피하기. 요약하자면, 쓸모없거나 혼란스럽거나 불완전한 데이터를 제공할 수 있는 테스트 방법에는 여러 가지가 있습니다. 이 강연에서 그는 플레이테스트를 최대한 활용하는 방법에 대해 설명합니다.
그는 분석을 수집하는 방법에 대해 이야기합니다:
설문조사, 게임 내 플레이어 데이터, 히트 맵에 대해 설명합니다.
이러한 데이터를 통해 플레이어가 어디에서 문제를 겪고 있는지 알 수 있고, 수집할 수 있는 좋은 피드백이지만 모든 것을 알려주지는 않습니다. 이 데이터가 알려주지 않는 것은 플레이어가 문제를 겪는 이유입니다.
명확한 피드백을 얻고 그 이유를 파악하는 가장 좋은 방법은 사람들이 게임을 플레이하는 모습을 지켜보는 것이라고 말합니다.
동영상 링크: https://youtu.be/6EUeYu0aPn4?si=N-Iw_EIRbjiN__hy&t=0s
아드리안에게 피드백의 명확성을 높이는 방법에 대한 조언이 더 있는지 물어보았습니다. 그는 두 가지 주요 팁을 강조했습니다:
- 피드백에 열린 자세로 임하세요
- 플레이어가 말하는 내용에 집중하지 말고 왜 그런 말을 하는지에 집중하세요.
이 팁은 강력한 팁이므로 각각에 대해 자세히 살펴보고자 합니다.
1 - 피드백에 개방적이어야 합니다.
여기에는 나만의 방식에서 벗어나는 것이 포함되는데, 이는 생각보다 훨씬 더 어려운 일입니다.
명확한 피드백을 받는다는 것은 자기 발견의 여정입니다. 경청, 공감, 플레이어 심리, 내면의 편견을 극복하는 기술을 쌓는 과정입니다.
아드리안의 말
“... 어떤 부분은 변하지 않아야 할 '핵심'으로 느껴질 수 있습니다.” 누군가의 플레이를 보고 그 핵심이 충분하지 않거나 기대했던 것과 다르다는 것을 인식하고 게임 경험을 개선하기 위해 (과감한) 변화를 주는 데는 진정한 용기가 필요합니다.”
디자인에서 원했던 것과 플레이어의 반응 사이에서 균형을 맞춰야 합니다. 이는 여러분의 비전과 시청자가 실제로 원하는 것 사이의 타협점입니다. 자존심과 좋은 결과물 사이에는 위험할 정도로 미세한 경계가 존재하며, 이 문제를 해결하는 데 도움이 되는 것은 경험과 데이터입니다.
마이크 앰바인더:
또 다른 방법으로 생각해 보면, 저는 제 아이디어가 좋은 아이디어인지 나쁜 아이디어인지 알아내는 것을 두려워하고 싶지 않다는 것입니다. 다른 사람들을 위한 게임을 만든다면 가능한 한 빨리 다른 사람들에게 게임을 선보이고 싶다는 생각을 해야 합니다. 그들에게 효과가 있는지 알아보기 위해서죠. 저에게 효과가 있다면 좋지만, 제가 관객이 아니라 다른 사람들이 관객입니다. 따라서 가능한 한 빠르고, 효과적이고, 효율적으로 알아보고 싶어야 합니다: 효과가 있나요? 그렇게 하는 것이 두렵다면 아마도 내 게임 디자인에 대한 두려움 때문일 것입니다.
2 - 플레이어가 말하는 내용에 집중하지 말고 왜 그런 말을 하는지에 집중하세요.
플레이 테스터가 말하는 모든 피드백은 소중하지만, 플레이어의 말에 현혹되지 않도록 그들의 피드백을 신중하게 받아들이는 것도 중요합니다.
마이크 앰바인더:
사람들은 자신이 하는 일을 하는 이유를 잘 설명하지 못합니다. 물론 사람들의 말은 큰 도움이 되기도 합니다. 하지만 저는 누군가가 말하는 모든 것을 게임 내 행동과 연관시키고 싶었습니다. “아니, 그건 쉬웠어!"라고 말하는 사람이 있다면요. 하지만 35번이나 죽었다면 그렇게 쉽지 않았을 수도 있죠.
누군가의 플레이를 지켜보면서 그들의 말을 듣는 것을 결합하면 모든 것이 맥락에 맞게 이해됩니다.
Adriaan은 이렇게 말합니다.
“가장 명확한 피드백을 얻을 수 있는 방법은 다른 사람이 게임을 플레이하는 모습을 보는 것입니다. 다른 모든 것은 산만해지기 쉽습니다.”
왜 플레이해야 하는지에 대한 테스트
여기서 민족지학적 인터뷰 방법론이 빛을 발합니다.
이 방법론은 테스트 세션에서 WHY를 최대한 끌어내기 위해 만들어졌습니다. 핵심적인 사고방식은 다음과 같습니다: 플레이 테스터는 교사이고 여러분은 학생입니다. 테스트 대상은 그들이 아니라 여러분과 여러분의 디자인입니다. 플레이테스터가 그 사실을 알도록 하세요. 플레이테스터가 교사가 될 수 있도록 권한을 부여하세요.
플레이 테스터가 멍청하다고 느낀다면 그것은 *나*가 멍청하기 때문입니다.
플레이 테스터가 게임을 할 때 자신의 생각을 큰 소리로 말하고 질문하도록 장려하되, 적어도 문제를 푸는 방법을 바로 알려주지는 마세요. 강의를 듣는 학생처럼 “음”이라고 말하고 메모를 하도록 유도하세요. 플레이어가 변경해야 할 사항을 말하면 왜 변경을 제안하는지 물어보고 그 이유를 이해해야 합니다.
플레이어가 플레이하는 동안 플레이어를 멈추고 몇 가지 질문을 할 수 있지만, 여러분의 주된 임무는 입을 다물고 지켜보는 것입니다. 질문은 매우 신중하게 하세요. “더블 점프에 대해 어떻게 생각하세요?"와 같은 질문은 하지 마세요. 대신 “그 동작에 대해 어떻게 느꼈나요? 어떤 문제가 발생했나요?"와 같이 질문하세요.
실수로 편견을 확인하기보다는 실제 문제를 이해하기 위해 정보를 캐내고 싶을 것입니다. 하지만 테스트가 끝났다고 생각되면 이러한 규칙에서 자유롭게 벗어날 수 있습니다. 플레이 테스트 과정과 팁에 대해 더 이야기하고 싶지만, 그건 다음 기회에 다룰 주제라고 생각해요.
이제 성공적인 게임 디자이너들이 플레이테스트를 '알 수 있는 유일한 방법'이라고 부르며 빈번하고 명확한 피드백을 목표로 하는 플레이테스트 프로세스를 기반으로 한다는 사실을 알게 되었습니다.
이제 “그래, 플레이테스트는 해야겠는데...”라고 생각하실 수도 있습니다.
파트 4: 변명하지 말고, 변명하지 말자
플레이테스트를 하지 않는 흔한 핑계는 이제 그만!
변명: “내 게임이 아직 플레이테스트할 준비가 되지 않았습니다.”
이 글을 시작한 예시에서 저는 게임 테스트를 시작하기까지 2년을 기다렸습니다.몇 번의 테스트 끝에 메커니즘의 핵심 가정이 명백히 잘못되었다는 것을 알게 되었고 완전히 다시 설계해야 한다는 것을 깨달았습니다. 당시 저는 게임을 테스트하기 전에 게임이 '완성'되어야 한다고 생각했습니다. 그 가정 때문에 개발 기간이 1년이나 늘어났습니다.
조기 테스트
게임을 디자인할 때 가장 먼저 해야 할 일은 게임을 테스트할 수 있는 장소에 가져가서 먼저 자신과 게임을 본 적이 없는 다른 사람에게 테스트하는 것입니다. 개발에 몇 달이 지났는데도 핵심 가정을 아직 테스트하지 않았다면, 직감에 의존하여 너무 먼 미래를 계획한 것입니다.
더 일찍 테스트하기
저는 디자인 아이디어를 3개월 동안 프로그래밍하다가 막상 실행했을 때 얼마나 끔찍한지 깨달은 적이 있습니다.
저는 그것을 버리고 종이로 옮겨서 데이터를 추적하는 작은 도구를 프로그래밍했습니다.
이틀 만에 훨씬 더 나은 디자인이 완성되었습니다.
일주일 만에 놀라운 디자인이 완성되었습니다.
저는 디버깅도 하기 전에 게임을 테스트하기도 합니다. 눈에 띄는 문제만 없다면 플레이어에게 버그를 안내할 수 있기 때문입니다.
초초기 테스트에서는 핵심 메커니즘과 게임 루프만 테스트하고 싶다면 플레이 테스트의 황금률을 깨고 게임 내 튜토리얼은 부끄럽게도 생략하고 테스트 세션 동안 보드 게임의 밤처럼 설명만 합니다. 이렇게 하면 디자인에 따라 튜토리얼을 업데이트하는 데 드는 개발 시간을 절약할 수 있어 반복 주기를 단축할 수 있습니다.
이 글을 쓰면서 인터랙션 디자인 재단에서 다음과 같은 인용문을 발견했습니다:
“사용자가 앱을 사용하고 싶어하는지 확인하세요. 나중에 사용 가능하게 만들 수 있습니다.”
여기서 핵심은 잘못된 아이디어를 쫓는 시간을 최대한 줄이고 최고의 아이디어를 육성하는 데 최대한 많은 시간을 할애해야 한다는 것입니다. 항상 스스로에게 물어보세요: 내 게임이나 기능의 테스트 가능한 최소 버전은 무엇인가요?
일찍 테스트하고 자주 테스트하세요.
“그래야만 알 수 있습니다.”
변명: 사람들이 내 아이디어를 가져갈 것이다
아무도 여러분의 아이디어를 원하지 않습니다. 아이디어는 무료입니다. 아이디어는 그 자체로는 쓸모가 없습니다. 누구나 자신의 아이디어가 더 낫다고 믿습니다. 중요한 것은 실행입니다.
더 좋은 아이디어가 없을까 봐 걱정된다면 이 두려움을 극복할 때까지 매일 50개의 새로운 아이디어 목록을 작성하는 연습을 해보세요.
그래도 걱정이 된다면 변호사를 통해 기밀유지계약서를 작성하고 테스터가 서명하도록 하세요.
여러분의 아이디어가 플레이어에게 가치가 있는지 확인하려면 일찍 그리고 자주 게임을 선보이세요.
변명: 아무도 내 게임을 테스트해주지 않아요!!!
테스터를 찾는 것은 생각보다 어렵지 않을 수 있습니다.
친구나 가족에게 30분 동안 게임을 플레이하는 모습을 지켜보게 해달라고 부탁하고 메모를 남길 수 있습니다.
게임 개발자 커뮤니티에 가입하여 서로의 게임을 테스트하는 일을 거래하세요.
매주 같은 시간에 정기적으로 테스트를 진행하는 Discord 서버를 시작하고 시간이 지남에 따라 서버를 구축하세요.
뉴스레터를 시작하고 가입 보너스로 초기 빌드 테스트를 제공하세요.
모바일 게임이라면 파티에 휴대폰을 가져가세요. 테스터가 술에 취하면 취할수록 더 솔직하고 개방적인 피드백을 주고 어려운 디자인에 대해 더 많은 고민을 할 것입니다.
비슷한 게임에 대한 리뷰를 작성한 사람을 찾아 친구로 추가하거나 연락을 시도해 보세요.
가능한 한 많은 사람에게 플레이 테스터가 되어 달라고 요청하세요. “그래야만 알 수 있습니다.”
변명: 피드백을 받는 것이 두렵습니다.
아무도 실제로 인정하지는 않지만 우리 모두의 마음속에 숨어 있는 공통적인 고민입니다. 앞서 설명한 핑계를 불러일으키는 핵심적인 우려일 수 있습니다. 심혈을 기울여 만든 결과물을 다른 사람에게 보여주는 것은 우리를 매우 취약하게 만들 수 있습니다.
하지만 기억하세요: 여러분은 자신의 작품이 아닙니다. 그리고 여러분의 작품은 세상과 공유하기 위해 만들어졌습니다. 다른 사람들의 삶을 풍요롭게 하기 위해서요. 자신을 위한 것이 아니라 다른 사람들과 소통하는 것이지만... 스스로 만족할 수 있는 방식으로, 자신에게 충실하세요. 여러분의 작업이 모든 사람을 위한 것일 필요는 없습니다.
“보드 게임 디자인 조언: 세계 최고로부터"라는 책에서 60명 이상의 게임 디자이너에게 나쁜 테스트 세션이 어떤 느낌인지 물었더니 모두 ‘좋아요!’라고 대답했습니다. 그때 정말 많은 것을 배워요."라고 답했습니다.
즉, “싫어한다!”라는 최악의 시나리오가 “개선할 점이 있다!”라는 최상의 시나리오로 볼 수도 있다는 뜻입니다. 진정한 최악의 시나리오는 피드백을 전혀 받지 못하는 것입니다.
자신을 보호할수록 스스로를 더 약하게 만들 수 있습니다.
충분하면 충분할 때
그렇다면 플레이 테스트를 해야 하느냐가 아니라 언제 플레이 테스트를 중단해야 하느냐가 더 중요한 질문입니다. 게임이 완성되었는지 어떻게 알 수 있을까요?
마이크 앰바인더:
게임이 끝났다는 것을 아는 사람이 있나요? 아니요, 아무도 모릅니다. 하지만 저희가 추구하는 것은 성공 가능성을 극대화하는 것입니다. 네, 영원히 반복해서 플레이테스트를 하고 아무것도 출시하지 않을 수도 있지만 결과는 좋지 않을 것입니다. 하지만 플레이 테스트를 통해 얻을 수 있는 것은 수정이 필요한 여러 가지 문제를 파악하고 사람들이 게임의 매력을 느끼는 요소를 이해하는 것입니다. 그리고 어느 순간부터 긍정적인 피드백을 훨씬 더 많이 듣고 부정적인 피드백을 훨씬 덜 듣기 시작할 것입니다. 그리고 훨씬 더 자신감을 갖게 될 것입니다. 그래서 저는 이것을 게이트키핑 장치로 생각하지 않습니다. 그저 꾸준히, 그리고 희망적으로 자신감을 높여주는 장치일 뿐입니다. “정말 큰 문제가 없다"는 피드백을 받는다면 꽤 좋은 이정표입니다.
알 수 있는 한 가지 방법이 있습니다:
플레이 테스트 후 사람들이 게임을 중단하고 싶지 않거나 언제 다시 플레이할 수 있는지 묻기 시작한다면 디자인이 잘 작동하고 있다는 것을 알 수 있는 좋은 방법입니다.
요약하자면, 플레이 테스트를 해야 하는 이유는 무엇인가요?
직감으로 너무 먼 미래를 계획하는 것을 방지합니다.
가설을 검증하고 플레이어에게 적응할 수 있습니다.
직관에 대한 신뢰 구축
게임 디자인 시간당 생산성을 높일 수 있습니다.
디자인에 대한 내면의 편견에 대한 자기 성찰을 강화하세요.
플레이어에 대한 공감 능력 향상
사용자 경험 모범 사례에 대한 직관적 이해 확보
마이크 앰바인더:
모든 사람의 목표는 사람들이 플레이하고 싶은 경험을 만드는 것입니다. 그러니 지금 만들고 있는 게임이 사람들이 플레이하고 싶은 게임인지 알아보세요. 그리고 사람들이 게임을 플레이하고 싶어하는 지점에 도달할 때까지 계속 반복해서 그렇게 하세요. 어떻게 해야 할지 잘 모르겠다면 더 많은 정보를 얻으세요. 데이터를 수집하세요. 플레이테스터들이 기꺼이 데이터를 제공할 것입니다.
이제 플레이테스트를 시작하세요!
* 원문:
'게임개발 > 가마수트라' 카테고리의 다른 글
Fastival에서 일하면서 커뮤니케이션 능력을 키운 방법 (3) | 2024.09.18 |
---|---|
플록(Flock)이 양을 젤다-풍 보물 상자로 바꾼 이유 (7) | 2024.09.18 |
'유머는 우리가 가진 전부입니다': <땡큐 굿니스 유어 히어! (Thank Good You're Here!)>의 부조리를 옹호합니다 (2) | 2024.09.01 |
책 발췌: 위대한 게임에는 위대한 리더가 필요하다 (6) | 2024.08.31 |
<택티컬 브리치 위저드>와 <인투 더 브리치>의 내러티브 디자인을 비교해 보겠습니다. (1) | 2024.08.31 |
댓글