플레이어가 게임 메커니즘을 이해하고 있는지 어떻게 알 수 있을까요?

이 메커니즘에서 “이해”가 무엇을 의미하는지 정의하기

누군가를 플레이에 초대하기 전에, 메커니즘의 의도된 규칙을 명확하고 쉬운 언어로 적어보세요. 그런 다음 해당 메커니즘에 의존하는 플레이어의 결정들을 나열하세요. 예를 들어, 어떤 가상의 플랫포머 게임에 주변 물체를 밀어내는 파동 기능이 있다고 가정해 보겠습니다. 유용한 테스트라면 플레이어가 파동을 발견할 수 있는지, 그것이 어떤 물체에 영향을 미치는지 식별할 수 있는지, 밀려나는 방향을 예측할 수 있는지, 그리고 이를 언제 사용할지 선택할 수 있는지를 물을 수 있을 것입니다. 이것들은 서로 분리된 관찰 항목입니다. 플레이어는 효과는 이해하지만 범위는 모를 수도 있고, 둘 다 이해했음에도 파동을 쓸 가치가 없다고 판단할 수도 있습니다.

이러한 분류는 실용적인 테스트 계획일 뿐, 검증된 보편적 척도는 아닙니다. 이는 게임을 메커니즘, 플레이 중에 발생하는 다이내믹스, 그리고 그 다이내믹스가 뒷받침하는 경험의 관점에서 설명하는 MDA 프레임워크를 기반으로 합니다. 이 프레임워크가 유용한 이유는 메커니즘의 구현이 디자인 질문의 전부가 아니기 때문입니다. 플레이어가 그것을 가지고 무엇을 하는지, 그리고 그 플레이가 어떤 느낌을 주는지도 확인할 필요가 있습니다.

세션을 시작하기 전에 간단한 예측을 작성하세요. ‘플레이어가 X를 이해한다면, Z라는 힌트 없이도 Y 행동을 보일 것이다.’ 파동 메커니즘의 경우 다음과 같을 수 있습니다. ‘물체가 움직이는 것을 본 후, 플레이어는 움직일 수 있는 다른 물체 근처에서 파동을 시도하고, 장애물 쪽으로 물체를 날려 보내기 위해 자신의 위치를 잡을 것이다.’ 이렇게 하면 테스트가 누군가 몰입해 보였다는 주관적인 인상이 아니라, 관찰 가능한 행동에 집중되도록 유지할 수 있습니다.

플레이어가 자신만의 모델을 보여줄 수 있는 테스트 구성하기

각 참가자에게 동일한 시작 조건을 제공하고, 정답을 알려주지 않은 채 해당 메커니즘이 유의미해지는 과제를 부여하세요. ‘파동을 사용하여 상자를 움직이세요’와 같은 지시는 피해야 합니다. 이는 단순히 지시를 따를 수 있는지를 테스트하는 것에 불과합니다. 대신 상자를 움직이는 것이 앞으로 나아갈 수 있는 그럴듯한 경로 중 하나인 상황을 만들고, 플레이어가 파동을 인지하고 이를 물체와 연관 짓는지 관찰하세요.

플레이어가 어떤 일이 일어나고 있다고 생각하는지 알고 싶다면, 플레이하는 동안 생각을 소리 내어 말해 달라고(think aloud) 요청하세요. Nielsen Norman Group은 이 방법을 대표성을 지닌 참가자가 대표적인 과제를 수행하면서 자신의 생각을 말로 표현하고, 진행자는 그들의 선택을 유도하기보다는 경청하며 계속 이야기하도록 격려하는 방식이라고 설명합니다. 이 지침은 일반적인 사용성 테스트에 관한 것이므로, 게임 메커니즘에 적용하는 것은 방법론적인 응용일 뿐 게임에 특화된 연구 결과는 아닙니다.

플레이어가 침묵하면 ‘어떤 생각을 하고 계시나요?’와 같은 중립적인 질문을 던지세요. ‘파동 버튼을 알아차리셨나요?’처럼 메커니즘이나 정답을 은연중에 암시하는 질문은 피해야 합니다. 후자는 자발적인 발견 테스트를 단순 인지 테스트로 변질시킬 수 있습니다. 플레이 중 말하는 것이 타이밍이나 집중력을 방해한다면, 먼저 짧은 시도를 완료하게 한 다음, 결정적인 순간에 어떤 일이 일어날 것이라 생각했는지 설명해 달라고 요청하세요. 사후 설명은 플레이 도중 일어나는 결정을 직접 보는 것보다 신뢰도가 떨어질 수 있다는 점에 유의하세요.

행동, 예측 및 대처 관찰하기

미리 기록해 둔 구체적인 가설에 맞춰 증거를 기록하세요. 유용한 기록 내용으로는 플레이어가 유도 없이 메커니즘을 시도했는지, 어떤 대상을 선택했는지, 어떤 결과를 예측했는지, 결과가 그 예측과 일치했는지, 예상치 못한 결과가 나온 후 어떻게 대처했는지 등이 있습니다. 플레이어가 우연히 파동을 성공적으로 사용했지만 두 번째 시도에서 결과를 예측하지 못한다면, 첫 번째 성공이 안정적인 멘탈 모델을 형성했다고 볼 수 없습니다.

잠시 멈춰도 안전한 상황이라면 다음 시도 전에 예측 질문을 해보세요. ‘여기서 사용하면 어떤 일이 일어날 것 같나요?’ 그런 다음 플레이어가 행동하게 하세요. 이는 플레이어가 단순히 시연된 동작을 반복하는 것이 아니라, 규칙을 새로운 상황에 연결할 수 있는지 확인해 줍니다. 질문은 개방형으로 짧게 유지하세요. 묻기 전에 규칙을 설명해 버리면 결과를 해석하기 어려워집니다.

메커니즘 이해와 다른 잠재적 방해 요소를 분리하세요. 플레이어가 규칙은 이해했으나 조작법을 놓쳤거나, 관련 물체를 보지 못했거나, 레벨 디자인 때문에 행동하지 못했을 수 있습니다. 이를 별도의 관찰 항목으로 기록하세요. 예를 들어 조작법이 명확하지 않다면, 해당 세션으로는 메커니즘 자체를 이해했는지 여부를 파악할 수 없습니다. 후속 빌드나 세션에서는 한 번에 한 가지씩만 변경하여, 어떤 변경 사항이 문제를 해결했는지 알 수 있도록 하세요.

간결한 증거 기록표 활용하기

각 세션이 끝난 후, ‘이해함’과 같은 모호한 점수를 매기기보다는 증거를 요약하세요. 이 작은 매트릭스는 표준화된 도구가 아니라 이해를 돕기 위한 예시입니다:

마지막 질문은 이해도와 분리하여 다루어야 합니다. 플레이어가 메커니즘을 이해하면서도 사용하는 것을 싫어할 수 있으며, 규칙을 이해하지 못하면서도 그 화려한 연출을 즐길 수도 있습니다. 두 발견 모두 중요할 수 있지만, 요구되는 디자인 결정은 서로 다릅니다.

디자인을 변경하기 전에 패턴 해석하기

반복되는 문제점과 그 맥락을 살펴보세요. 플레이어가 메커니즘을 시도조차 하지 않는다면 발견 가능성을 점검하세요. 즉, 조작 안내 프롬프트, 시각적 단서, 레벨이 실험해 볼 이유를 제공하는지 등을 확인해야 합니다. 시도는 하지만 결과를 잘못 해석한다면 피드백과 규칙의 일관성을 점검하세요. 정확히 예측하지만 선택 사항일 때 사용하지 않는다면, 그것이 결정에 의미 있는 변화를 주는지, 아니면 다른 행동이 단순히 더 유용한 것은 아닌지 고려해 보세요. 이는 진단을 위한 가설일 뿐 자동으로 도출되는 결론이 아니므로, 세션 중에 일어난 일과 대조해 확인해야 합니다.

소수의 세션 결과를 전체 플레이어를 대변하는 수치로 여기지 마세요. 정성적 관찰은 디자인의 혼란스러운 부분을 밝혀내고 무엇을 바꿔야 할지 제안할 수는 있지만, 그 문제가 모든 플레이어 사이에서 얼마나 흔한지를 자체적으로 입증할 수는 없습니다. 수정된 버전을 동일한 과제로 다시 테스트하고, 처음 문제를 드러냈던 상황뿐만 아니라 익숙하지 않은 상황도 확인하세요. 추후 비율이나 선호도를 비교해야 한다면, 적절히 모집된 더 넓은 표본과 해당 질문에 맞게 설계된 측정 방법을 사용하세요.

실용적인 중단 규칙

초기 프로토타입의 경우, 타겟 플레이어 여러 명이 유도 힌트 없이도 메커니즘을 발견하고, 보여주지 않은 최소 하나의 상황에서 그 효과를 예측하며, 목표를 위해 이를 사용할 수 있게 되었다면 설명 방식을 수정하는 것을 멈추세요. 단, 남아 있는 실패 원인이 메커니즘의 기능에 대한 혼란이 아니라 수정 가능한 구체적인 문제들을 가리키고 있어야 합니다. 정확한 세션 수는 프로젝트와 걸려 있는 의사결정에 따라 달라지며, 여기에 인용된 자료에서 확립된 보편적인 기준치는 없습니다.

테스트의 목적은 당신의 아이디어가 기발하다는 것을 증명하는 것이 아닙니다. 게임이 규칙을 제대로 전달하고 의도된 선택을 가능하게 만드는지 알아내는 것입니다. 플레이어가 메커니즘을 이해하고도 여전히 흥미를 느끼지 못한다면, 그 역시 유용한 증거입니다. 디자인에 다른 역할, 보상 또는 맥락이 필요할 수 있습니다.

이 주제 더 살펴보기