선택형 대화 게임은 화면만 보면 대사 세 개와 결과 한 장면의 반복입니다. 하지만 무대 5개, 배역 2개, 루트당 10컷과 각 컷의 오답 장면을 함께 관리하면 조건문은 빠르게 복잡해집니다. 각본대로의 구조를 설명할 때 핵심은 화면 수가 아니라 진행 상태와 수집 상태를 분리하는 것입니다.
장면 데이터를 실행 코드에서 떼어내기
컷마다 필요한 값은 대체로 같습니다.
- 현재 대사와 화자
- 선택지 세 개
- 선택별 정답 여부
- 오답일 때 보여 줄 엔딩 ID와 문구
- 정답 뒤 이동할 다음 컷
이 정보를 클릭 처리 코드 안의 조건문으로 만들면 대사를 수정할 때 로직도 건드려야 합니다. 대신 루트 데이터를 배열이나 JSON에 두고 실행 코드는 “현재 컷을 읽고 선택 결과를 적용한다”는 한 가지 역할만 맡기는 편이 안전합니다.
고유 ID는 화면에 보이는 제목과 분리합니다. 엔딩 이름은 나중에 바뀔 수 있지만 저장된 도감 키까지 바뀌면 이용자의 수집 기록이 끊깁니다. stage-role-cut-choice처럼 충돌하지 않는 안정적인 키가 필요합니다.
세 종류의 상태를 분리하기
1. 현재 판 상태
현재 무대, 배역, 컷, 남은 힌트와 이어하기 횟수입니다. 새 루트를 시작하면 초기화됩니다.
2. 영구 수집 상태
이미 본 배드엔딩 ID와 완료한 루트입니다. 판이 끝나도 브라우저 저장공간에 남아야 합니다.
3. 화면 상태
선택지가 잠겼는지, 결과 애니메이션이 재생 중인지, 모달이 열렸는지 같은 임시 상태입니다. 저장할 필요가 없고 새로고침 뒤 복원 대상도 아닙니다.
이 셋을 하나의 객체에 섞으면 이어하기가 화면 애니메이션까지 되살리거나, 새 루트를 시작하며 도감이 지워지는 오류가 생기기 쉽습니다.
저장은 선택 직후에
도감 추가를 결과 화면의 닫기 버튼에 연결하면 이용자가 탭을 닫거나 새로고침했을 때 본 엔딩이 저장되지 않을 수 있습니다. 오답 선택이 확정되는 순간 엔딩 ID를 수집 상태에 추가하고 저장한 뒤 결과 연출을 시작하는 순서가 안전합니다.
저장 데이터에는 버전을 함께 둡니다. 업데이트로 구조가 바뀌면 이전 데이터를 읽어 새 구조로 변환하거나, 변환할 수 없는 항목만 제외할 수 있습니다. 저장 전체를 예고 없이 초기화하는 것보다 유지 가능한 범위를 명시하는 편이 낫습니다.
콘텐츠 검수도 데이터 단위로
모든 루트에서 선택지 수가 세 개인지, 정답이 정확히 하나인지, 오답 엔딩 ID가 중복되지 않는지는 손으로 플레이하기 전에 자동 검사할 수 있습니다. 대사가 많아질수록 재미 검수와 구조 검수를 분리해야 합니다. 자동 검사는 데이터 누락을 찾고, 사람은 선택지가 실제로 웃기고 맥락에 맞는지 판단합니다.
이 글의 관련 게임: 게임 소개와 플레이 페이지로 이동