플레이테스팅 방법 안내

♪ 저는 게임을 좋아하고 ♪ ♪ 저는 게임 개발을 좋아해요 ♪ ♪ 어 ♪ ♪ 플레이테스팅 ♪ (남성 웃음) - 얼마 전, 저희는 어떻게 게임 잼(game jam)을 하는지에 대한 영상을 만들었습니다. 그리고 그 영상에서 플레이테스트가 얼마나 중요한지에 대해 이야기했습니다. 그리고 많은 분들이 더 많은 정보를 요청하셨습니다. 그래서 이 영상에서는 플레이테스팅에 대해 더 깊이 파고들어 볼 것입니다. 플레이테스팅은 게임 개발의 매우 중요한 부분입니다. 아무리 여러분의 아이디어와 디자인이 좋아도, 여러분의 게임이 플레이어의 손에서 어떤 느낌일지 완전히 예측할 수는 없습니다. 따라서 많은 플레이 테스트를 할 필요가 있습니다.

그리고 개발의 여러 단계에서 말이죠. 저는 또한 플레이테스팅이 정말 재미있다고 생각합니다. 결국, 여러분의 모든 노력이 살아 움직이는 것을 볼 수 있는 순간이니까요. 흥미진진하고 긴장되기도 합니다. 또한, 아마 대부분의 분들이 이 시점에서는 아시겠지만, 저는 게임 잼을 좋아합니다. 그리고 그 이유 중 일부는 그것이 여러 아이디어를 매우 빠르게 테스트해볼 수 있는 방법이기 때문입니다. 프로토타이핑과 플레이테스팅의 끊임없는 순환이며, 솔직히 말해서 이것은 제가 다른 모든 게임 프로젝트에 적용한 철학입니다. 자, 그럼 이제 플레이하고 테스트하는 것에 대해 들어가 봅시다.

예를 들어, 캐나다 게임 스튜디오인 Furion을 예로 들어보겠습니다. 그들은 단 3일 만에 전체 무기 시스템의 균형을 맞출 수 있었습니다. 그들은 1억 6,500만 번의 플레이와 맞먹는 것을 단 10번의 효율적인 시뮬레이션으로 압축하여 약 600시간의 개발 시간을 절약했습니다. 그러니 이것이 흥미롭게 들린다면, 더 많이 읽고 시작하려면 설명란의 링크를 확인해 보세요. 그래서 실제로 플레이테스팅에 들어가기 전에, 먼저 우리 게임을 언제 플레이 테스트할지 알아야 합니다. 그리고 저는 작동하는 프로토타입이 나오는 즉시 시작해야 한다고 말하고 싶습니다. 너무 일찍 테스트해서는 안 됩니다. 왜냐하면 현재의 게임플레이가 재미있지 않다는 것을 알아내기 위해 많은 시간을 낭비하고 싶지는 않을 것이기 때문입니다.

저는 제 게임잼 작품인 "Farm Alarm"에서 이런 실수를 저질렀습니다. 플레이테스팅을 마지막 순간까지 미뤘는데, 정말 최악의 생각이었죠. 다행히도 게임은 의도대로 작동했고 몇 가지 매개변수만 조정하면 되었지만, 완전히 재앙이 될 수도 있었고 수정하기에는 너무 늦었을 수도 있었습니다. 그러니 레벨 안에 움직이는 큐브와 적이나 퍼즐 같은 것이 생기는 즉시 진행하세요. 누군가에게 테스트하게 하거나 직접 시도해 보세요. 이것은 또한 '기본부터'라는 저의 철학에도 부합합니다.

이것은 제가 참여했던 모든 게임잼을 통해 배운 것입니다. 저는 항상 제 게임을 가장 필수적인 부분으로 간소화하고 그것에 먼저 집중하려고 노력합니다. 이렇게 하면 세부 사항에 집중하기 전에 게임이 어떻게 작동하는지 빠르게 아이디어를 얻을 수 있습니다. 게다가, 아직 많은 시간을 쏟지 않았기 때문에 방향을 바꾸는 것이 크게 손해를 입히지 않아 훨씬 쉽습니다. 하지만 누구를 선택해서 게임을 테스트하게 해야 할까요? 사실 이것은 제가 너무 걱정할 필요가 없는 부분입니다. 왜냐하면 거의 모든 사람이 당신의 게임을 플레이하고 가치 있는 피드백을 제공할 수 있기 때문입니다.

만약 그들이 당신의 게임 기본 조작(basic controls)을 다룰 수 있다면, 플레이 테스트를 할 수 있습니다. 그리고 가능한 한 폭넓은 사람들을 모으는 것이 좋습니다. 제작하는 장르에 능숙한 경험 많은 플레이어부터 좀 더 캐주얼한 사람들까지 모두요. 물론 게임에 따라 다르겠지만, 좋은 후보로는 아이들이 있습니다. 그들은 매우 가차 없이 솔직하고 반응이 즉각적이기 때문입니다. 하지만 당연히 당신 스스로도 게임을 많이 테스트해야 합니다. 다만, 자신이 플레이할 때 난이도가 딱 적절하다고 생각한다면, 아마 너무 어려울 가능성이 높다는 점을 명심하세요.

기억하세요. 당신이 게임을 만들었고 모든 것이 어떻게 작동하는지 알고 있습니다. 따라서 다른 플레이어들이 먼저 배워야 할 모든 팁과 트릭을 당신은 모두 알고 있습니다. 하지만 물론, 플레이테스팅이 단순히 플레이테스팅만을 의미하지는 않습니다. 게임을 다양한 방식으로 플레이하며 여러 측면에 초점을 맞출 수 있습니다. 과거에 제가 사용했던 몇 가지 플레이테스트 방법들을 소개합니다. 이 방법들은 대부분의 장르에서 효과적일 것입니다. 첫 번째는 '집중(Focus) 플레이테스트'입니다. 여기서는 게임의 특정 부분만을 테스트하는 것입니다. 움직임, 난이도, 적 등과 같은 것들이요. 만약 당신의 게임에서 점프가 어떤 느낌인지 알고 싶다면, 그 메커니즘을 완전히 분리한 레벨을 만들어 가능한 한 방해 요소 없이 느껴보게 할 수 있습니다.

두 번째는 '블라인드 플레이테스팅(Blind playtesting)'입니다. 여기서는 플레이어가 원하는 대로 하는 것을 관찰하기만 하면 됩니다. 이것은 매우 좋은 플레이테스트 방법인데, 왜냐하면 당신이 결코 생각지 못했을 만한 것들, 예를 들어 게임을 망가뜨리는 전술이나 악용(exploit) 같은 새로운 메커니즘을 발견할 수 있기 때문입니다. 제가 제작했던 잼 게임 'Soul Surge'를 테스트하던 중, 플레이어가 단순히 방에서 다음 방으로 도망치기만 해도 모든 적들을 무시할 수 있다는 것을 알아냈는데, 물론 이것은 의도된 것이 아니었습니다. 그래서 저는 플레이어가 방의 모든 적을 물리칠 때까지 문이 잠겨 있도록 만들었습니다.

그리고 세 번째는 '악용 사냥(Exploit hunting)'입니다. 여기서는 플레이테스터가 당신의 게임을 망가뜨리려고 시도하며 명백히 더 우수한 전술을 발견하려고 합니다. 여기서 벽과 문이 실제로 작동하는지 알 수 있습니다. 그리고 만약 게임에 물리 엔진(physics)이 있다면, 이것은 특히 중요한 단계인데, 아마도 제대로 작동하지 않을 가능성이 높기 때문입니다. 사실 저 자신조차 고치지 못했던 악용 사례들을 몇 가지 가지고 있습니다. 실제로는 거의 동일한 두 가지가 있는데, 제가 배우는 법을 모르기 때문이죠. 제 잼 게임 'Shrinking Planet'에서는 플레이어들이 직선으로 운전하는 것이 가장 우수한 전술이라는 것을 빠르게 알아냈는데, 왜냐하면 유성체가 바로 당신의 경로에 생성될 확률이 얼마나 될까요?

(귀뚜라미 소리) 이것은 보는 입장에서나 플레이하는 입장에서나 매우 지루한 게임플레이를 만듭니다. 그리고 플레이어가 계속 같은 방향으로 운전할 때 그 앞에 유성(meteor)을 던지는 것만으로도 쉽게 고칠 수 있었을 것입니다. 다른 예시는 또 다른 잼 게임인 "Sugar Warrior"에서 가져온 것입니다. 이 게임에서는 적들이 플레이어 주변 원형으로 스폰되는데, 이것이 AI 처리 방식과 결합되어 단순히 한 방향으로 운전하며 뒤로 사격하는 명확하게 우월하면서도 똑같이 지루한 전략을 초래했습니다. 이것은 레벨 경계나 장애물을 추가하거나, 이동 방향으로 스폰 원을 단순히 옮기는 등 수많은 방식으로 쉽게 고칠 수 있었을 것입니다.

그리고 고통스럽게도, 저는 마감일 이전에 실제로 이러한 문제들을 인지하고 있었지만, 수정하기에는 너무 늦었고, 이는 물론 더 철저한 초기 플레이테스팅을 통해 피할 수 있었던 일입니다. 그리고 기억하세요. 사람들이 당신의 게임을 할 때 대부분의 경우, 한 발 물러나 관찰하는 것이 좋습니다. 당신은 아마도 개입해서 돕거나 자신의 작업을 방어하고 싶은 충동을 느낄 것입니다. 왜냐하면 아직 완성되지 않았고, "오, 저 문은 나중에 빌드에서 작동할 거예요."라거나, "D 대신 E를 누르기만 하면 되는데,"와 같은 생각이 들기 때문입니다. 하지만 자신을 절제하려고 노력하세요.

당신이 개입할 때마다 플레이어는 그 경험에서 벗어나게 됩니다. 그리고 현실 세계에서는, 그들은 도움을 줄 안내자로서 당신을 갖지 못합니다. 최고의 결과를 얻으려면, 비록 그들이 아주 오랫동안 막힐 수도 있다는 것을 의미하더라도, 플레이어가 스스로 알아내도록 하는 것이 좋습니다. 그리고 만약 도와줘야 한다면, 그것을 직접 주는 대신 플레이어가 스스로 답을 생각해 내도록 유도해 보세요. "그래서 무엇을 달성하려고 하나요?" 또는 "저 주문은 무엇을 하나요?"와 같은 질문을 하는 것만으로도 플레이어가 스스로 알아내기에 충분한 경우가 많습니다.

그리고 그들의 사고 과정이 어떤지 좋은 아이디어를 얻을 수 있습니다. 물론 모든 것을 타임스탬프와 함께 기록해야 합니다. 플레이어가 어디서 막히는지? 이 섹션에서 얼마나 빨랐는지? 의도하지 않은 행동을 했는지? 메커니즘을 이해하는지? 여기서 충분한 데이터를 얻는 것은 정말 중요합니다. 그리고 어쩌면 나중에 그들을 인터뷰할 시간을 좀 가지세요. "가장 좋았던 부분은 무엇이었나요?" (웅얼거림) "흥미로운 것을 발견했나요?" 가장 좋았던 부분과 어려웠던 부분이 무엇이었는지요? 네.

수집한 모든 데이터를 사용할 수는 없을 수도 있지만, 때로는 모든 것을 바꿔놓는 단 하나의 것이 있습니다. 네. 메모를 하는 또 다른 방법은 그것을 게임에 프로그래밍하는 것입니다. 사실 현대의 도구들로라면 종류별 분석(analytics)을 모두 추가할 수 있습니다. 레벨당 소요 시간, 조준 정확도, 사용된 무기의 다양성, 사망 횟수, 발견한 숨겨진 보물 등 훨씬 더 많은 것들이요. 만약 Unity를 사용하고 있다면, Unity Analytics라는 내장 도구가 있어서 이 중 상당 부분을 자동으로 설정해 줍니다. 하지만 이것이 수동 테스트를 대체해서는 안 됩니다. 왜냐하면 주관적인 피드백 역시 똑같이 중요하기 때문입니다.

이제 때로는 테스터들이 원래 의도했던 것과 완전히 반대되는 의견이나 제안을 할 수도 있습니다. 이는 제가 "Detective Truth"를 디자인할 때 일어났던 일입니다. 사무실 주변 사람들은 죽을 때마다 처음부터 다시 시작해야 하는 것이 정말 좌절스럽다고 계속 말했습니다 (남성 끙 소리). 하지만 저의 초기 아이디어는 어려워서 짜증을 유발하는 일종의 레이지 게임(rage game)을 만드는 것이었습니다. 그래서 저는 그 의견들을 그냥 무시했습니다. 하지만 물론, 제출한 후 제가 받은 거의 모든 피드백은 게임이 너무 좌절스럽다는 내용이었습니다.

그러니까 아마 피드백을 듣고 어느 정도 절충점을 찾았어야 했을 겁니다. 예를 들어, 처음부터 다시 시작해야 하는 대신 체크포인트까지 이어지는 세 개의 생명을 갖도록 만들 수도 있었죠. 원래 의도를 유지하면서도 받은 피드백 중 일부를 고려할 수 있는 방법은 많았지만, 대부분의 경우 저는 그저 고집을 부리는 것을 멈춰야 했습니다. 플레이테스터들은 때때로 개발자가 예상치 못한 새로운 메커니즘을 발견하기도 합니다. 제가 만든 게임의 많은 멋진 기능들이 저 자신이나 다른 누군가가 우연히 발견한 흥미로운 버그에서 시작되어 결국 기능으로 자리 잡은 경우가 많습니다.

예를 들어, 카운터-스트라이크(Counter-Strike)에서의 부핑(bhopping)과 서핑을 보세요. 비스듬한 옥상으로 이상한 커스텀 맵을 만든 한 사람이 갑자기 서핑 전용 게임이 개발되고 말았습니다. 면책 조항을 밝히자면, 이것은 골드소스(Goldsource)를 기반으로 하는 구형 퀘이크 엔진(Quake engine)의 대폭 수정 버전이기 때문에 소스 엔진이나 발보브(Valve) 자체보다 앞선 버그라는 것을 알고 있습니다. 하지만 카운터-스트라이크에서 부핑에 대해 아는 사람이 20년 된 슈팅 게임에 대해 아는 사람보다 많기 때문에 좋은 예시가 됩니다. 예를 들어, 데이트 나잇(Date Night)을 플레이 테스트하면서 저는 많은 레벨들이 제가 의도하지 않은 방식으로 해결될 수 있다는 것을 빠르게 발견했습니다.

어쩌면 제가 고려하지 못한 플랫폼에 도달할 수도 있고, 단순히 제가 생각지 못한 방식으로 퍼즐을 풀 수도 있습니다. 그리고 그것은 저에게 정말로 두 가지 선택지를 남겼습니다. 강제(force)하거나 포용(embrace)하는 것입니다. '강제'한다는 것은 레벨을 되돌아가서 수정하고, 벽을 더 높게 만들고, 장애물을 치워 플레이어가 더 이상 도달할 수 없도록 하여 원래의 아이디어를 고집하는 것을 의미합니다. 다른 방법은 그것을 포용하여 어떤 식으로든 게임에 맞추려는 것입니다. 이것이 바로 '버그가 아니라 기능이다(It's not a bug, it's a feature)' 접근 방식입니다. 제 경우라면, 여러 해결책을 가진 레벨 그대로 유지하거나 이러한 대체 경로를 고려한 새로운 레벨을 만드는 것을 의미했을 겁니다.

제가 결국 한 가지씩 섞어서 진행했어요. 퍼즐 중 일부는 제가 원래 생각한 풀이 방식만 작동하도록 수정했고, 다른 경로들은 새로운 레벨로 만들어졌어요. 저는 이것을 일석이조라고 생각해요. 원래 아이디어도 유지되고 레벨 수도 늘어났으니까요. - [Both] 좋네요. - 플레이테스팅은 게임 개발 시 많은 시간을 절약해 줄 수 있어요. 직관적으로는 모순되게 들릴지 몰라도, 지금 시간을 투자하는 것이 장기적으로는 시간을 절약해 줍니다. 개발 초기에 발견된 디자인 결함들은 레벨이나 시스템을 그 주변으로 구축하지 않았기 때문에 항상 수정하기가 더 쉽거든요.

설명란의 링크를 클릭하여 게임 시뮬레이션을 디자인 흐름에 통합함으로써 수많은 개발 시간을 절약하세요. 이만, 시청해 주셔서 감사하고 다음 영상에서 뵙겠습니다. 아, 그리고 플레이테스트하는 것을 잊지 마세요. 지난 5월에 기부해주신 모든 멋진 후원자분들께 감사드리며, 특히 faisal marafie, Lost to Violence, Loved Forever, Replica Studios, Nubby Ninja, SRT Mike, Jason Uritescu, Leo Lesetre, Piano Sathornlak, Donatien Gascoin, Dante Sam, Jacob Sanford, Naoki Iwasaki, Marc-Antoine Girard, Gregory Pierce, Michail Korobov, TheMightyZeus, Owen Cooper, Alison the Fierce, Erasmus, 그리고 SiriusWolf 님들께 특별히 감사드립니다.

여러분 덕분에 정말 좋아요.