게임 기획서는 빈 페이지에서 쓰는 문서가 아니라 질문을 정리하는 문서다
게임 기획서를 처음 쓰려 하면 많은 사람이 같은 벽에 부딪힌다. “무엇부터 적어야 하지?”라는 질문이다. 캐릭터 설정부터 써야 할 것 같고, 세계관도 정리해야 할 것 같고, 시스템 표도 만들어야 할 것 같다. 그러다 보면 문서는 길어지는데 정작 게임은 선명해지지 않는다.
문제는 기획서를 완성된 답안처럼 대하기 때문이다. 실제로 기획 문서는 처음부터 모든 것을 확정하는 문서가 아니라, 팀이 같은 질문을 보고 같은 방향으로 실험하게 만드는 문서에 가깝다. 그래서 좋은 기획서는 화려한 표현보다 무엇을 만들고, 무엇은 아직 검증되지 않았는지를 또렷하게 구분한다.
MDA 프레임워크는 메커닉(Mechanics), 다이내믹(Dynamics), 에스테틱(Aesthetics)의 약자로, 게임 규칙과 플레이 과정, 플레이어가 느끼는 경험을 함께 보게 만드는 틀이다. 이 관점에서 보면 시스템 표만 늘어놓는다고 플레이 경험이 자동으로 설명되지는 않는다. 반대로 감성적인 설명만 길다고 구현 방향이 명확해지는 것도 아니다. 기획서는 이 둘 사이를 번역하는 문서여야 한다.
빈 페이지에서 시작하지 말고 레퍼런스와 질문에서 시작하자
새 게임을 만든다고 해서 정말로 아무것도 없는 곳에서 출발하는 경우는 드물다. 장르 관습이 있고, 레퍼런스 게임이 있고, 플레이어가 이미 기대하는 상호작용 방식이 있다. 그래서 기획의 첫 단계는 “완전히 새로운 문서 쓰기”보다 어떤 질문에 답하려는 게임인지 정리하는 일에 가깝다.
이때 유용한 출발점은 다음 네 가지다.
- 이 게임의 핵심 플레이 감각은 무엇인가
- 플레이어는 반복해서 어떤 행동을 하게 되는가
- 무엇이 성공과 실패를 가르는가
- 어떤 기존 게임과 비슷하고, 어디서부터 달라지는가
예를 들어 로그라이크 덱빌더를 만든다면, 처음부터 카드 200장 목록을 쓰는 것보다 이런 질문이 먼저다.
- 전투의 핵심 재미가 조합인가, 리스크 관리인가
- 덱이 강해지는 속도는 빠른가, 느린가
- 실패했을 때 플레이어가 다시 도전하고 싶어지는 장치는 무엇인가
- 전투 밖의 메타 진행은 어디까지 허용할 것인가
이 질문이 있어야 이후 문서의 범위가 정리된다. 질문 없이 쓰는 기획서는 대개 설명은 길지만 우선순위가 없다.
기획서의 첫 버전은 길수록 좋은 게 아니라 읽힐수록 좋다
심시티 시리즈 작업으로 알려진 게임 디자이너 Stone Librande가 게임 개발자 콘퍼런스(GDC)에서 소개한 원페이지 디자인(one-page design)은 이 점을 잘 보여준다. 핵심은 정말로 “무조건 한 장만 써라”가 아니라, 팀이 지금 봐야 할 핵심 관계를 한눈에 보이게 만들라는 데 있다. 전통적인 장문의 게임 기획 문서(GDD, Game Design Document)가 실패하는 이유도 대부분 여기에서 나온다. 필요한 사람은 끝까지 읽지 않고, 읽어도 무엇이 중요한지 바로 보이지 않는다.
그래서 첫 기획 문서는 한 장 혹은 아주 짧은 문서여도 충분하다. 처음 버전에 꼭 들어가야 하는 것은 보통 아래 정도다.
- 한 문장 요약: 이 게임은 무엇을 하는 게임인가
- 플레이어 약속: 플레이어는 어떤 감각을 기대해야 하는가
- 핵심 루프: 반복 행동과 보상 구조
- 핵심 제약: 무엇은 하지 않을 것인가
- 가장 큰 미해결 질문: 프로토타입으로 검증해야 할 항목
이 정도만 있어도 팀은 “무엇을 당장 만들어 봐야 하는지”를 공유할 수 있다. 반대로 이 단계에서 세계관 백과사전처럼 문서가 커지면, 대개 구현보다 상상력이 앞서기 시작한다.
레퍼런스 게임은 베끼는 대상이 아니라 분해해서 읽는 대상이다
초기 기획에서 레퍼런스 게임을 보는 일은 매우 중요하다. 다만 “이 게임처럼 만들자”라고 모호하게 말하는 순간 문서는 약해진다. 레퍼런스는 감탄의 대상이 아니라 구조를 해체해서 읽는 자료가 되어야 한다.
실무적으로는 다음 네 층으로 나눠서 보면 도움이 된다.
1. 플레이어가 실제로 반복하는 행동
- 이동
- 조준
- 공격
- 회피
- 수집
- 선택
- 배치
이 층은 게임의 동사 목록이다. 기획 문서는 추상적인 분위기보다 이 동사들이 먼저 분명해야 한다.
2. 그 행동이 바꾸는 상태
- 체력, 자원, 위치
- 적의 상태
- 맵의 위험도
- 퀘스트 진행도
- 경제 수치
여기는 시스템 설계와 직접 연결된다. 플레이어의 행동이 어떤 상태를 바꾸는지 모르면 구현 우선순위도 흐려진다.
3. 그 상태 변화가 만들어내는 긴장
- 더 밀어붙일지 물러날지
- 지금 자원을 쓸지 아낄지
- 안전한 선택을 할지 높은 보상을 노릴지
이 층이 바로 메커닉이 다이내믹으로 바뀌는 지점이다. 시스템만 적어서는 부족하고, 그 시스템이 어떤 판단을 강제하는지를 같이 적어야 한다.
4. 플레이어가 최종적으로 느끼길 바라는 감각
- 몰입
- 압박
- 성장감
- 즉흥성
- 숙련감
- 발견의 즐거움
이 층이 빠지면 기획 문서는 체크리스트로만 남는다. MDA가 강조하는 것도 바로 이 연결이다. 시스템은 결국 플레이 경험을 위해 존재한다.
좋은 기획 문서는 ‘모든 것의 명세서’가 아니라 ‘시트들의 입구’다
한 장짜리 문서로 시작했다고 해서 상세 설계가 불필요하다는 뜻은 아니다. 다만 상세 문서는 한 번에 다 쓰는 것보다 필요한 종류별로 쪼개는 것이 훨씬 낫다.
보통은 이런 식으로 분리된다.
- 핵심 기획 문서: 게임의 방향과 우선순위
- 시스템 시트: 전투, 경제, 성장, 퀘스트 같은 규칙
- 콘텐츠 시트: 적, 아이템, 스킬, 스테이지 목록
- 구현 메모: 상태 전이, 예외 처리, 데이터 구조
- 테스트 메모: 무엇을 플레이테스트로 검증할지
이렇게 나누면 문서의 역할이 선명해진다. 핵심 기획 문서는 방향을 잡고, 세부 시트는 구현과 밸런싱을 돕는다. 처음부터 모든 걸 한 문서에 욱여넣으면, 수정할 때마다 어디가 최신인지부터 헷갈리기 쉽다.
프로토타입은 문서를 증명하는 단계가 아니라 질문을 줄이는 단계다
기획 문서만으로는 게임이 되는지 알 수 없다. 그래서 프로토타입이 필요하다. 하지만 여기서도 흔한 오해가 있다. 프로토타입을 “초기 버전의 완성품”처럼 만들려는 것이다.
인디 게임 개발자이자 강연자로 잘 알려진 Rami Ismail은 프로토타입과 버티컬 슬라이스의 목적을 분리해서 설명한다. 그의 정리는 실무적으로 꽤 유용하다. 프로토타입은 이 게임을 만들어야 하는지를 판단하기 위한 실험이고, 버티컬 슬라이스는 이 팀이 그 게임을 실제로 만들 수 있는지를 확인하는 제작 실험이다.
이 구분을 기획 문서에 적용하면 훨씬 명확해진다.
-
프로토타입 단계의 문서 질문:
- 이 핵심 루프가 재미있는가
- 이 조작이 성립하는가
- 이 시점의 난이도 곡선이 너무 가파르지 않은가
- 이 콘셉트가 서로 충돌하지 않는가
-
버티컬 슬라이스 단계의 문서 질문:
- 이 아트 파이프라인으로 콘텐츠를 반복 생산할 수 있는가
- 이 툴 체계로 레벨과 데이터를 관리할 수 있는가
- 이 품질 수준을 일정 안에 계속 낼 수 있는가
기획서가 강해지려면 “확정된 내용”만 쓰는 것이 아니라, 아직 검증되지 않은 가설을 명시해야 한다. 그래야 프로토타입이 무엇을 답해야 하는지 분명해진다.
공략본과 위키는 기획자의 사고보다 플레이어의 인식 구조를 보여준다
기존 글에서 공략본 분석을 강조했던 방향은 완전히 틀린 건 아니다. 다만 공략본을 “기획자의 정답지”처럼 보는 건 위험하다. 실제로 공략본, 위키, 빌드 가이드가 잘 보여주는 것은 개발 내부 문서보다 플레이어가 무엇을 중요하게 받아들이는가에 더 가깝다.
이 자료들을 볼 때는 다음처럼 읽는 편이 좋다.
- 플레이어가 어떤 규칙을 핵심 정보로 인식하는가
- 어떤 정보가 없으면 막히는가
- 어떤 수치나 상성이 실제 전략을 바꾸는가
- 플레이어가 시스템을 어떤 언어로 설명하는가
예를 들어 위키에서 적 공략이 “패턴 5종”보다 “이 타이밍에 피하라”로 요약된다면, 플레이어에게 중요한 건 내부 상태 머신 구조보다 체감 가능한 신호일 가능성이 크다. 반대로 아이템 공략이 드롭 위치보다 조합 시너지를 길게 다루고 있다면, 그 게임에서 플레이어가 기억하는 핵심은 수집보다 조합일 수 있다.
즉, 공략본 분석은 유효하다. 다만 그것은 플레이어 관점의 역설계 자료이지, 개발 문서를 대체하는 자료는 아니다.
처음 쓰는 사람일수록 ‘전부 설명하려는 문서’보다 ‘결정과 보류를 구분한 문서’가 낫다
기획이 어려운 가장 큰 이유 중 하나는 아직 정하지 못한 것까지 정한 척 쓰려 하기 때문이다. 하지만 실제 프로젝트는 초반일수록 미정이 많다. 그래서 더 중요한 것은 완벽함보다 구분이다.
- 이미 결정된 것
- 프로토타입으로 확인할 것
- 레퍼런스가 필요한 것
- 구현 이후 밸런싱으로 넘길 것
이 네 칸만 잘 나눠도 문서의 품질이 크게 올라간다. 팀이 불안해하는 이유는 정보가 부족해서만이 아니라, 무엇이 확정이고 무엇이 아직 가설인지 모르기 때문이다.
핵심 정리
게임 기획서는 빈 페이지에서 문학 작품처럼 써 내려가는 문서가 아니다. 레퍼런스를 분해하고, 플레이 경험을 언어로 바꾸고, 지금 당장 검증해야 할 질문을 정리하는 작업에 가깝다. 그래서 첫 기획 문서는 길고 완벽할 필요가 없고, 오히려 한눈에 읽히는 방향 문서일수록 강하다.
레퍼런스 게임은 메커닉, 상태 변화, 긴장 구조, 플레이 감각의 층으로 분해해 읽는 편이 좋고, 세부 명세는 시스템 시트와 콘텐츠 시트로 나눠 관리하는 편이 안정적이다. 공략본과 위키는 플레이어가 중요하게 인식하는 정보를 역으로 보여주는 자료로 쓸 수 있지만, 개발 문서 자체를 대신하지는 않는다.
무엇보다 중요한 것은 기획서를 “확정 사항 목록”이 아니라 “질문 관리 도구”로 보는 관점이다. 그 관점이 있어야 프로토타입도, 버티컬 슬라이스도, 플레이테스트도 제대로 연결된다.
마치며
좋은 기획서는 처음부터 두꺼운 문서로 태어나지 않는다. 짧은 방향 문서에서 시작해, 프로토타입으로 질문을 줄이고, 플레이테스트로 표현을 바꾸고, 필요할 때만 세부 시트를 늘려가면서 자란다.
빈 페이지가 두려운 이유는 쓸 내용이 없어서가 아니라, 무엇을 아직 모르는지 정리되지 않았기 때문이다. 기획서를 잘 쓴다는 것은 모든 답을 아는 일이 아니라, 지금 필요한 질문을 정확히 적는 일에 더 가깝다.
참고 자료
- Hunicke, LeBlanc, Zubek, MDA: A Formal Approach to Game Design and Game Research: https://www.cs.northwestern.edu/~hunicke/MDA.pdf
- GDC Vault, Stone Librande, One-Page Designs: https://www.gdcvault.com/play/1012356/One-Page
- Unity Learn, Game Design: https://learn.unity.com/pathway/game-development/unit/planning-a-game/tutorial/game-design
- Unity Learn, Plan and scope your prototype: https://learn.unity.com/tutorial/670fc376edbc2a231e2ec1db
- Rami Ismail, Prototypes & Vertical Slice: https://ltpf.ramiismail.com/prototypes-and-vertical-slice/