인터랙티브 영상 게임의 핵심 루프: 시청, 판단, 선택, 피드백은 어떻게 이어지는가

인터랙티브 영상 게임의 핵심 루프는 ‘영상 재생—버튼 표시—재생 계속’이 아니라 ‘정보 획득—판단 형성—행동 실행—피드백 확인—다음 판단 갱신’이다. 버튼은 입력 방식일 뿐이다. 정보, 판단, 피드백 중 하나라도 빠지면 플레이어는 영상을 대신해 다음 페이지를 클릭하고 있다고 느낀다.

핵심 루프를 설계할 때는 먼저 3분짜리 프로토타입으로 한 차례의 완전한 변화를 검증하고, 분기 수를 늘리는 데 서두르지 않아도 된다. 버튼이 몇 번 등장하는지보다 플레이어가 무엇을 근거로 결정했는지, 선택 후 어디에 변화가 생겼는지 설명할 수 있는지가 더 중요하다.

정보는 대사, 연기, 장면, 소품, 시스템 기록, 이전 선택에서 얻을 수 있다. 핵심은 플레이어가 결정하기 전에 그 정보를 접할 수 있어야 한다는 것이다. 결말을 본 뒤에야 ‘정답을 고르려면 한 번도 등장하지 않은 단서가 필요했다’는 사실을 알게 해서는 안 된다.

《零点回拨》의 첫 번째 정보는 다음과 같을 수 있다. 미래에서 걸려 온 전화가 10초 뒤 발생할 정전을 정확히 예측하지만, 발신자는 신원을 밝히기를 거부한다. 이에 따라 플레이어는 ‘믿는다’를 뒷받침하는 증거 하나와 ‘의심한다’를 뒷받침하는 이상 징후 하나를 갖게 된다.

배경 설정을 의사결정에 필요한 정보로 착각하지 말자. 회사의 설립 연도나 인물의 생일은 세계를 풍성하게 만들 수 있지만, 서버실을 열어야 할지 판단하는 데 반드시 도움이 되는 것은 아니다.

한 선택지는 명백히 선하고 다른 선택지는 명백히 어리석다면, 플레이어는 판단하는 것이 아니라 설계자가 무엇을 누르기를 원하는지 추측하는 것이다. 유효한 불확실성은 가치의 충돌, 증거의 충돌, 자원의 부족에서 생긴다.

예를 들어 플레이어는 즉시 경찰에 신고할 수 있지만, 그러면 내부 전화를 감시하는 사람에게 들키게 된다. 먼저 전화 내용을 검증할 수도 있지만, 사람을 구할 시간을 놓칠 수 있다. 두 방안 모두 이유와 대가가 있어야 선택에서 플레이어의 우선순위가 드러난다.

불확실성은 규칙을 숨기는 것과 다르다. 플레이어가 모든 결과를 알 필요는 없지만, 자신이 어떤 종류의 위험을 감수하는지는 이해해야 한다.

상태가 반드시 수치일 필요는 없다. 태그, 알고 있는 정보, 되돌릴 수 없는 사건일 수도 있다. 동료를 믿기로 선택하면 ‘출입 권한 공유 완료’를 기록할 수 있고, 로그를 복사하면 증거의 완전성을 높일 수 있으며, 경찰 신고를 미루면 남은 시간을 줄일 수 있다.

주요 선택마다 최소한 세 가지 질문에 답해야 한다. 어떤 상태를 기록하는가, 누가 그 상태를 읽는가, 늦어도 언제 피드백을 제공하는가. 한 번도 읽히지 않는 상태는 기록일 뿐, 시스템이 아니다.

즉각적인 피드백은 인물의 반응, 인터페이스 변화, 단서 획득, 자원 상실일 수 있다. 지연된 피드백은 이후 장면이나 결말에서 나타날 수 있다. 둘을 결합하는 것이 좋다. 먼저 작은 피드백으로 입력이 반영되었음을 확인하고, 큰 피드백으로 장기적인 결과를 보여 준다.

예를 들어 플레이어가 천모에게 출입 권한을 넘긴 직후 그의 말투가 달라지는 것은 확인에 해당한다. 15분 뒤 그가 서버실에 들어가 사람을 구할 수 있게 되는 것은 장기적인 결과다. 후자만 있으면 피드백이 너무 늦고, 전자만 있으면 선택에 무게가 없어 보인다.

핵심 루프가 루프인 이유는 결과가 다음 판단을 바꾸기 때문이다. 천모가 위험을 감수하려는 모습은 신뢰도를 높일 수도 있고, 다른 속셈이 있음을 보여 줄 수도 있다. 증거가 삭제되면 선택 가능한 경로가 줄고, 남은 시간이 줄어들면 플레이어의 위험 감수 수준이 달라진다.

매번 선택한 뒤 모든 정보와 선택지가 원래대로 돌아온다면, 게임은 서로 독립된 문답 여러 개에 불과하다. 최소한 인물, 자원, 지식, 경로 중 하나는 지속적으로 변화하게 해야 한다.

표의 빈칸은 모두 의심해 볼 필요가 있다. 특히 ‘이후 상태 참조’가 비어 있으면 대개 실제로 작동하지 않는 상태를 뜻하고, ‘플레이어가 보는 것’이 비어 있으면 대개 정보 없이 고르는 선택을 뜻한다.

테스터에게 ‘재미있나요?’라고 묻지 말고, 플레이하면서 판단 근거를 말하게 하자. 어느 단계에서 정보가 부족했는지, 선택지를 어떻게 이해했는지, 피드백이 나타났을 때 자신과 관련이 있음을 알아차렸는지 기록한다.

테스트 후에는 세 가지를 묻는다. 방금 주로 무엇을 판단했나요? 어떤 정보가 선택에 가장 큰 영향을 주었나요? 어떤 결과가 당신 때문에 발생했나요? 답변이 설계 표와 다르면 먼저 정보, 선택지, 피드백을 조정하고, 설명문으로 전체 시스템을 해설하려 하지 말자.

테스트할 때는 실제 진행 경로의 로그도 저장해야 한다. 어떤 노드에 들어갔는지, 어떤 정보를 보았는지, 무엇을 선택했는지, 어떤 변수가 변경되었는지를 남긴다. 플레이어가 ‘피드백을 보지 못했어요’라고 하면 로그와 대조하여 피드백이 발동하지 않았는지, 너무 늦게 나타났는지, 표현이 충분히 명확하지 않았는지 판단할 수 있다. 로그가 없으면 팀은 프로그램 문제를 서사 문제로 오인하거나, 그 반대로 오인하기 쉽다.

한 차례의 루프가 통과하는 최소 기준은 다음과 같다. 대다수 테스터가 판단 대상을 말할 수 있고, 작품 속 정보 중 최소 하나를 근거로 들며, 선택 후 변화 하나를 지목할 수 있고, 그 변화가 다음 차례에 영향을 주어야 한다. 네 가지 중 하나라도 빠지면 새 노드를 추가하기 전에 루프부터 고쳐야 한다.

안정적인 루프를 완성한 뒤에는 다음 글에서 상호작용의 빈도를 결정한다. 빈도는 판단과 피드백을 위한 것이어야 하며, ‘더 게임처럼 보이게’ 하려고 모든 연기 구간을 끊어서는 안 된다.