Esoteric Ebb가 Steam을 휩쓸고 있습니다. 하지만 이와 같은 분기형 서사 CRPG(Computer Role-Playing Game)는 어떻게 만들어질까요? 이번 게스트 블로그에서 Christoffer Bodegård는 복잡한 내러티브 디자인 (Narrative Design) 결정 사항들과, 진정으로 비선형적이고 대화 기반인 이야기를 만드는 법을 배워온 8년간의 여정을 풀어냅니다.

2023년 Esoteric Ebb의 첫 공개 플레이테스트(Playtest) 이후, 저는 한 가지 단순한 질문을 반복해서 받아왔습니다. “이 모든 것을 어떻게 추적하나요?” 이는 좋은 질문이자, 어려운 질문입니다. 아마도 저는 지난 몇 년간 여러 가지 방식으로 답변해 왔겠지만, 정말 만족스러운 방식은 없었습니다. … 그럼 한번 시도해 봅시다.

(하지만 먼저, Esoteric Ebb에 대한 약간의 배경 설명을 드리겠습니다)
Esoteric Ebb는 거대하고 서사에 집중한 비선형 CRPG입니다. 전통적인 전투는 없으며, 거의 전적으로 대화 기반(Dialog-based)으로 이루어져 있습니다. 플레이 타임은 45분에서 50시간 사이이며, 정말, 정말 많은 선택지가 존재합니다… 엔딩 크레딧이 올라갈 때까지 당신의 경험을 근본적인 방식으로 능동적으로 변화시키는 실제적인 선택지들 말이죠. 네, 바로 그런 게임 중 하나입니다. 그리고 제작에는 시간이 꽤 걸렸습니다. 시작부터 끝까지 약 8년이 걸렸는데, 그중 절반은 방에 홀로 앉아 상호작용적 글쓰기(Interactive Writing)를 하는 법을 배우며 아무것도 하지 않은 채 보냈습니다.

상호작용적 글쓰기의 세 가지 제약 조건
저는 상호작용적 글쓰기를 다소 임의적인 세 가지 제약/목표 내에서 정의합니다. 그것은 다음과 같습니다:

1. 높은 선택지 대비 텍스트 비율 (Choice-to-text ratio)
2. 콘텐츠의 50% 이상이 동적(Dynamic)일 것
3. 개방형 설계 (Open-ended design)

원하는 대로 받아들이거나 무시해도 좋지만, 이 세 가지를 충족한다면 강렬하고 (잠재적으로) 긍정적인 플레이어 에이전시(Player Agency)를 위한 레시피를 갖춘 셈입니다. 하지만 이것을 보자마자 즉시 수천 가지의 문제에 직면할 수도 있습니다.

그 내용들을 살펴보겠습니다.

선택지 대비 텍스트 비율을 통한 플레이어 참여(Engagement) 최적화
왜 높은 선택지 대비 텍스트 비율이 중요한가
높은 선택지 대비 텍스트 비율은 듣기에는 아주 좋습니다. 우선, 플레이어를 깨어 있게 하고 몰입하게 만드는 훌륭한 도구이기 때문입니다. 만약 플레이어에게 너무 많은 텍스트 블록을 읽도록 강요한다면, 평균적인 플레이어의 눈은 그저 흐릿해질 뿐입니다.

하지만 만약 당신이 플레이어를 계속해서 자극하고 쿡쿡 찌른다면 — 흥미로운 질문에 답하게 만들거나, 어려운 결정을 내리도록 몰아붙이거나, 혹은 그저 무례한 비난에 반응하도록 강요한다면 — 그것은 마치 그들의 혈관에 에너지 드링크를 주입하는 것과 같습니다. 그들은 번쩍 정신을 차리고, 실제로 텍스트에 몰입하게 될 것입니다. 적어도 통계적으로는 그렇게 할 가능성이 더 높아집니다. 하지만 여기서 문제는 간단합니다. 대화에 그 정도 수준의 분기 (Branching)를 추가하고 싶어 한다면 당신은 제정신이 아닐 것입니다. 그것은 엄청난 작업량을 요구하며, 더 구체적으로는 매우 특정한 도구 세트 (Toolset)가 필요합니다. (물론 기술 (Skills)도 필요하겠지만, 분기 과정이 인내력 테스트로 변하지 않으려면 도구가 유연하고 빨라야 합니다).

적절한 도구 선택하기
제가 사용하는 도구는 Inkle 스튜디오에서 만든 장대하고 믿을 수 없을 정도로 멋진 ink 스크립트입니다. 참고로 Unity에서 완벽하게 작동하는 이 오픈 소스 도구를 만듦으로써, 그들은 말 그대로 제 커리어를 만들어 주었습니다. 저는 그들에게 큰 빚을 졌습니다. 그리고 ink는 다른 멋진 기능들을 제외하더라도, 빠르고 민첩한 분기 (Branching) 작업에 매우 적합한 도구입니다.

ink로 대화를 작성할 때, 저는 선형적 콘텐츠 (Linear content)를 작성할 때와 동일한 속도로 작성합니다. 느슨한 설계 개요 (Design outline)만 준비되어 있다면, 저는 마음껏 써 내려갈 수 있습니다. 플레이어의 표현을 추가하거나, 비주얼을 관리하거나, 주사위 판정 (Dice checks)을 처리하는 것 모두 몇 초밖에 걸리지 않습니다. 모든 것이 일반적인 (그리고 잘 설계된) ink 함수와 함께, 기본적인 (대부분 Ebb에 맞게 맞춤화된) 태그 (Tags) 및 커스텀 코드 (Custom code)를 통해 처리되기 때문입니다.

가변성을 위한 계획: 동적 콘텐츠와 개방형 설계
그렇다면 우리의 제약 사항 목록 중 두 번째 항목인("콘텐츠의 50% 이상이 동적이어야 함")은 어떻게 될까요? 동적 콘텐츠 (Dynamic content)와 개방형 (또는 비선형) 설계는 모두 플레이어의 입력에 기반한 가변성 (Variability)을 창출한다는 유사한 목표에서 비롯됩니다.

그들이 원하는 것은 무엇이든 하게 두세요! 마음껏 하게 하세요! 어느 방향으로든 갈 수 있는 오픈 월드 (Open world)를 만드세요! 뭐, 그것도 하나의 방법이긴 합니다.

하지만 여기서 중요한 차이점은 상호작용적 글쓰기 (Interactive writing)가 항상 저자의 의도에 기반한 설계 (Authorial-intent-driven design)에 집중한다는 것입니다. 다시 말해, 모든 것이 작가에 의해 통제됩니다. 시스템적 설계 (Systematic design)를 수행할 수도 있고 두 영역 사이에는 큰 중첩이 존재하지만, 상호작용적 글쓰기의 실질적인 기술은 창발적 스토리텔링 (Emergent storytelling)이 제멋대로 흘러가도록 내버려 두지 않는 것에 특화되어 있습니다.

제가 의미하는 바는 이렇습니다. 당신은 반드시 변수 (Variables)를 가져야 합니다. 그리고 그것들을 추적해야 합니다. 캐릭터 생성 중에 선택한 능력치(Stats)든, 고블린 추장에게 얼마나 못되게 굴었든 간에, 플레이어가 내리는 모든 선택은 에이전시 (Agency, 주체성)라는 현상을 불러일으키기 위해 어떤 형태의 피드백을 필요로 합니다. 그것이 게임 끝부분에서의 역동적인 농담이든, 혹은 완전히 갈라지는 플롯 라인 (Branching plotline)이든, 이러한 피드백의 순간들은 선택 그 자체만큼이나, 어쩌면 그보다 더 중요합니다.

변수 추적하기
변수를 추적하는 저의 방법은 단순하고 유연합니다. 저는 이를 스토리 변수 (Story Variable, SV) 시스템이라고 부릅니다. 태그 시스템 (Tag system)을 사용하여, 태그가 문장 부호로 시작할 때마다 그것은 변수의 사용을 나타냅니다. 만약 해당 변수가 이전에 발견된 적이 없다면, SV는 하나의 거대한 리스트에 생성됩니다. 그렇지 않으면 이미 존재하는 SV에 접근하여 명령에 따라 값을 설정하거나 확인합니다. 문자열 (String)과 정수 (Int) 형식을 사용하며, 보통 불리언 (Boolean)으로 사용되지만 필요할 때마다 값을 증가시키거나 감소시키도록 확장됩니다. 제가 Ebb를 위해 구현한 명령어는 “==”, “=”, “>=”, “<=”, “+=”, “-=”였습니다.

그다음 문제는 조직화 (Organization)의 문제입니다. 진행하면서 이 부분에 능숙해졌지만, 각 SV는 위치나 퀘스트를 기반으로 한 접두사 (Prefix)를 사용합니다. 이 경우 “TE”는 찻집 (Tea Shop) 구역을 의미합니다. “Q” 접두사가 붙은 SV는 퀘스트 (Quest)를 나타내며, “QP”는 퀘스트 포인트 (Quest Point)를 나타냅니다. 즉, 퀘스트 저널인 퀘스팅 트리 (Questing Tree)의 로그 항목을 의미합니다.

내러티브 디자인의 이점
이것은 투박한 시스템이지만, 한 가지 커다란 생산성 이점이 있습니다. 바로 그냥 계속 글을 써 내려갈 수 있다는 점입니다. 역동적인 대화 선택지를 위한 새로운 변수가 필요하신가요?

그냥 추가한 다음, 설정이 필요한 파일에 복사해서 붙여넣기만 하면 됩니다. 프로젝트 전체 CTRL+F를 통해 변수 사용 여부를 쉽게 확인할 수 있고, 기본적인 텍스트 관리 방식을 통해 광범위한 변경 사항을 관리할 수 있습니다. 관리해야 할 데이터베이스(Database)도 없습니다. 목록 자체가 그저 시간 순서대로 나열되어 있을 뿐입니다. 변수 이름이 기억나지 않나요? 관련 영역이나 퀘스트 접두사(Prefix)를 검색하여 목록을 훑어보기만 하면 됩니다. 처음에는 이것이 제대로 작동할 것이라고 예상하지 못했습니다. 일반적인 플레이 한 번으로 게임이 끝날 때쯤이면 해당 목록에 3,000개 이상의 스토리 변수(Story Variables)가 쌓일 수 있기 때문입니다. 하지만 — Esoteric Ebb에서 제가 했던 대부분의 작업과 마찬가지로 — Unity는 이를 그냥 처리해 냈습니다. 그리고 ink의 Unity 통합(Integration) 기능은 거의 10년 동안 사용해 온 지금까지 단 한 번도 저를 실망시킨 적이 없습니다. ink 파일의 재컴파일(Recompile)은 몇 초밖에 걸리지 않습니다. Esoteric Ebb의 취향에 맞게 기능을 커스터마이징하는 작업은 언제나 매우 효율적이었습니다. 이상하게 들릴 수도 있겠지만, 수년이 지난 지금도 이 모든 과정이 그저 매끄럽게 흘러간다는 사실에 여전히 놀라곤 합니다. 가능하다면 앞으로도 수년간 이 파이프라인(Pipeline)을 계속 발전시켜 나가고 싶습니다.

그 외에도, 저는 Esoteric Ebb의 모든 글쓰기에 Notepad++를 사용합니다. 물론 당연히 선호하는 어떤 텍스트 에디터(Text Editor)든 사용할 수 있겠지만, 가볍고 빠른 상태를 유지하는 것이 훨씬 더 매끄러운 경험을 제공합니다. 순식간에 수백만 단어를 검색할 수 있는 능력 덕분에 이토록 방대한 게임을 작성하고 (또한 버그 수정도!) 할 수 있었습니다.

마지막 생각: 버그 수정과 분기(Branch)를 받아들이는 법
하지만 이것이 이 시스템의 가장 큰 단점이기도 합니다. 바로 버그 수정입니다. 논리 오류나 구문(Syntax) 오류에 대한 기술적인 해결책에 더 많은 시간을 투자했어야 했지만, 결국 저는 플레이테스트(Playtesting)를 통해 이 모든 시련을 무식하게 밀어붙이는(Brute-forcing) 방식으로 해결하고 말았습니다.

Esoteric Ebb가 1.1 패치를 받는 과정에서, 저는 철자 오류든 코드 관련 오류든 약 704개의 '텍스트 오류'를 4일 미만의 작업 시간(그것도 아주 여유로운 날들이었습니다) 만에 수정할 수 있었습니다. 이 역시 시스템이 매우 민첩하기 때문입니다. 그럼에도 불구하고, 이러한 버그들은 바로 여기와 같은 설정 방식 때문에 Esoteric Ebb를 출시할 당시에도 존재했습니다.

그것은 말도 안 되는 양의 텍스트이며, 터무니없을 정도로 많은 분기 (branching)를 포함하고 있습니다. 하지만 만약 저에게 ink가 축복처럼 주어지지 않았더라면, 최종 단어 수의 4분의 1조차 쓰지 못했을 것이라고 확신합니다.

후기: 내러티브 디자이너 (narrative designers)를 위한 추가 추천 도구들

저에게 있어 ink는 상호작용적 글쓰기 (interactive writing)라는 실무적인 예술을 빠르게 만들어 줍니다. 저는 항상 비주얼 스크립팅 (visual scripting)에 어려움을 겪어왔지만, 많은 작가들이 정확히 그 반대의 문제를 겪고 있다는 것을 알고 있습니다. 따라서 저는 여러분과 여러분의 팀에 가장 잘 맞는 솔루션을 찾기 위해 다른 해결책들도 함께 살펴보는 것을 항상 권장하며, 그 예시로는 articy:draft, Arcweave, 그리고 Yarn Spinner 등이 있습니다.

Esoteric Ebb는 현재 Steam에서 만나보실 수 있습니다. 저희 Steam 큐레이터 페이지에서 더 많은 Made with Unity 게임들을 탐색해 보시고, Unity 블로그와 리소스 허브 (Resource hub)에서 Unity 개발자들의 더 많은 이야기들을 확인해 보세요.