변수가 많다고 더 전문적인 것은 아니다: 관계·증거·자원·세계 상태를 계층으로 나누는 법

변수의 가치는 개수가 아니라 플레이어의 행동을 설명하고, 이후 콘텐츠를 바꾸며, 팀이 안정적으로 유지·관리할 수 있는지에 달려 있다. 제작을 통제할 수 있는 인터랙티브 영상 게임에는 보통 관계, 증거, 자원, 세계의 사실이라는 네 가지 상태 계층만 있으면 된다. 모든 변수에는 하나의 명확한 의미, 명시적인 기록 지점, 눈에 보이는 피드백, 최종적인 회수가 있어야 한다. 이를 충족하지 못하는 변수는 합치거나 삭제해야 한다.

관계 상태는 “누가 주인공을 어떻게 바라보는가”에 답한다. 소원함, 협력, 신뢰 같은 이산적인 단계로 표현할 수도 있고, 작은 범위의 수치로 표현할 수도 있다. 증거 상태는 “플레이어가 무엇을 획득하고 이해했는가”에 답하며, 불리언 값이나 집합이 적합하다. 자원 상태는 “플레이어가 앞으로 무엇을 지불할 수 있는가”에 답하며, 시간, 돈, 횟수, 핵심 아이템을 포함한다. 세계 상태는 “객관적으로 무엇이 일어났는가”에 답한다. 예를 들면 경보가 작동했는지, 특정 인물이 퇴장했는지다.

이 네 계층은 서로를 대신해서는 안 된다. 녹음 하나를 얻는 것은 증거이며, 동료가 주인공을 더 신뢰한다는 뜻은 아니다. 익명 전화 기회를 한 번 소모하는 것은 자원 변화이며, 세계에서 이미 경보가 울렸다는 뜻은 아니다. 계층을 나누면 작가는 인과관계를 설명할 수 있고, 프로그래머도 하나의 만능 점수가 모든 줄거리를 통제하는 일을 피할 수 있다.

0부터 100까지의 관계 수치는 정교해 보이지만, 설명할 수 없는 임계값을 만들기 쉽다. 플레이어는 59와 60의 차이를 알 수 없고, 작가도 각 점수에 의미를 부여하기 어렵다. 촬영 콘텐츠에는 보통 세 개에서 다섯 개의 관계 단계면 충분하다. 적대, 경계, 협력, 신뢰가 그 예다. 여러 작은 행동을 누적해야 하고, 인터페이스나 피드백을 통해 플레이어가 추세를 느낄 수 있을 때에만 연속 수치가 존재할 가치가 있다.

《零点回拨》에서는 기자와의 관계를 reporter_trust의 세 단계로, 핵심 녹음을 evidence_recording 불리언 값으로, 익명 전송 기회를 burner_uses 정수로, 경찰서의 봉쇄 여부를 station_locked 세계 상태로 표현할 수 있다. 이름은 의미를 직접 드러내며, flag7이나 scoreB는 사용하지 않는다.

변수 표에는 최소한 여섯 개의 열을 적는다. 이름, 타입, 기본값, 수정할 수 있는 주체, 읽는 노드, 플레이어가 인지하는 방법이다. 여기에 “폐기 조건” 열을 추가해, 역할을 다한 뒤에도 잘못 사용되는 일을 막는다.

예를 들어 station_locked의 기본값은 false이며, 4A의 경보 또는 5C의 추격에서만 true로 기록할 수 있고, 6A와 6B에서 읽는다. 플레이어는 셔터가 내려가고 지도가 봉쇄되는 것을 통해 이를 인지한다. 최종장이 시작된 뒤 모든 경로가 봉쇄 상태로 들어간다면, 장의 진입점에서 상태를 통일해 이전 분기에서 같은 판단을 반복하지 않게 한다.

변수를 열 곳에서 기록하면서 한 곳에서 무관한 대사 한 줄만 만들어 낸다면, 유지·관리 비용이 가치보다 크다. 반대로 한 번만 기록해도 경로, 인물의 반응, 결말 설명을 바꾸는 핵심 사실은 매우 효율적이다. 검토할 때는 변수별 기록 횟수, 읽기 횟수, 눈에 보이는 피드백 횟수를 집계한다. 읽기가 0회인 것은 죽은 변수, 피드백이 0회인 것은 유령 변수이며, 기록이 지나치게 많은 변수는 역할이 뒤섞였을 수 있다.

분석용 이벤트 추적을 위해 모든 클릭을 서사 변수로 만들지 말라. 분석 데이터는 이벤트를 별도로 기록하면 된다. 이후 줄거리에 영향을 줘야 하는 내용만 저장 상태에 포함한다.

노드 진입 조건이 “신뢰가 63보다 크고 A 또는 B가 있지만 C는 없거나, 두 번째 플레이인 경우”처럼 적혀 있다면, 누구도 안전하게 수정할 수 없다. 복잡한 조건을 can_confront_director처럼 이름이 있는 파생 판단으로 나누고, 어떤 기본 상태에서 도출되는지 설계 문서에 설명한다. 기본값이 바뀐 뒤 서로 모순되지 않도록 파생 판단은 중복 저장하지 않는다.

같은 사실에는 하나의 기준 정보원만 둔다. “인물이 녹음을 알고 있는가”를 이미 지식 매트릭스로 관리한다면, heard_recording, knows_audio, audio_seen이라는 비슷한 뜻의 변수를 따로 세 개 만들지 말라.

모든 수치를 표시할 필요는 없지만, 플레이어는 연기, 인터페이스, 새로운 기회를 통해 변화를 이해할 수 있어야 한다. 관계가 좋아지면 호칭과 눈빛이 달라질 수 있고, 획득한 증거는 단서 보드에 추가할 수 있다. 자원 소모는 카운터나 아이템이 사라지는 것으로 보여 줘야 하며, 세계 상태 변화는 환경을 보여 주는 숏으로 확인시켜야 한다. 피드백이 늦을수록 회수 시점에 계기가 된 원인을 다시 알려 줄 필요가 있다.

“호감도 +1” 팝업으로 사실적인 분위기를 깨는 것도, 아무 반응도 없는 것도 피하라. 인물의 멈칫하는 반응, 휴대전화 프로필 사진의 변화, 다음 장면에서 먼저 걸려 오는 전화로 같은 정보를 전달할 수 있다. 스타일은 표현 방식을 결정하고, 시스템은 읽을 수 있어야 한다.

네 가지 상태 계층은 조합 수를 늘리므로, 각 장에는 그 장에 실제로 영향을 주는 변수만 남긴다. “노드 × 변수” 매트릭스를 만들어 읽기, 기록, 무관함을 표시한다. 한 행에서 읽는 상태가 대여섯 개를 넘으면 장의 진입점에서 상태를 종합하는 방안을 고려한다. 한 열이 작품 전체에 걸쳐 있지만 효과를 내는 경우가 드물다면 삭제를 고려한다.

저장 데이터 마이그레이션도 미리 고려해야 한다. 변수의 이름이나 타입을 바꾸거나 기본값을 조정한 뒤, 이전 저장 데이터는 어떻게 해석할 것인가? 정식 출시 이후에는 모든 플레이어가 처음부터 시작한다고 가정할 수 없다. 상태 표에 버전 번호를 추가하고, 이전 값을 새 값으로 변환하는 규칙을 유지한다.

다음 단계: 기존 변수를 모두 관계, 증거, 자원, 세계의 네 계층으로 분류하고 상태 계약을 완성한다. 분류할 수 없거나 읽는 노드를 찾을 수 없는 변수는 대본에 계속 가져가기보다 먼저 삭제 후보에 넣는다.