📚 지식 노트

아이디어 내기와 개념화

모든 게임은 아이디어 하나에서 시작하지만, 아이디어 자체는 가장 싼 재료다. 실제 일은 많이 내고, 고르고, 손에 잡히는 게임의 모양으로 바꾸는 데 있다. 풀러턴의 교재는 이 단계를 개념화(conceptualization)라 부르고 한 장을 들여 다룬다. 셸은 아이디어보다 먼저 풀려는 문제를 문장으로 적으라고 권한다(문제 진술 렌즈). “재미있는 우주 게임”보다 “10분 안에 끝나는, 둘이 한 화면에서 하는 협동 게임”이 훨씬 많은 아이디어를 걸러 주고 또 불러온다.

• 브레인스토밍(brainstorming): 광고인 알렉스 오즈번(Alex Osborn)이 널리 퍼뜨린 방법으로(위키백과), 판단을 미루고 양을 먼저 낸다. 비판이 끼어들면 엉뚱하지만 쓸 만한 생각이 입 밖으로 나오지 않는다.
• 펼쳐 놓고 잇기: 마인드맵(mind map)처럼 한 낱말에서 가지를 뻗거나, 동사·소재·장소를 적은 카드를 무작위로 짝지어 본다. 어색한 조합이 새 질문을 낳는다.
• 고르고 다듬기: 낸 것을 모두 만들 수는 없다. 만들 수 있는가, 누가 하고 싶어 하는가, 우리 팀이 잘할 수 있는가를 기준으로 몇 개만 남기고, 남은 것을 한 문단의 게임 설명으로 써 본다.

어디서 시작하든 결국 나머지를 채워야 한다. 경험에서 시작했으면 동사를, 메커닉에서 시작했으면 그 동사가 낳을 경험을 찾는다. 막막한 백지에는 제약이 연료가 된다. 주제, 기간, 버튼 수, 색 수를 묶으면 고를 것이 줄어 생각이 빨라진다. 아래의 7일 프로토타입과 게임 잼이 이 원리를 행사로 만든 것이다.

재미는 머릿속이 아니라 손에서 확인된다

게임 디자인의 가장 큰 함정은 문서로 읽을 때 재미있는 아이디어가 실제로 해 보면 재미없다는 것이다. 반대로 말로 설명하면 시시한 규칙이 손에 잡히면 멈출 수 없을 때도 있다. 그래서 거의 모든 제작 방법론은 같은 순서를 권한다. 크게 만들기 전에 가장 싼 방법으로 재미부터 확인한다. 트레이시 풀러턴(Tracy Fullerton)의 교재 『Game Design Workshop』은 이 태도를 “플레이 중심”(playcentric) 설계라 부르며, 플레이어가 느낄 경험 목표를 먼저 정하고 개발 내내 플레이테스트로 그 목표를 확인하라고 가르친다.

프로토타입은 질문 하나에 답하는 실험이다. “이 점프가 기분 좋은가”를 묻는 프로토타입에 메뉴와 저장 기능은 필요 없다. 질문에 답하고 나면 코드는 버려도 된다. 손맛을 다듬는 구체적인 기법은 손맛 노트에, 그레이박스 이후의 레벨 작업은 레벨 디자인 노트에 있다.

빨리 많이 만들기: 7일 프로토타입

카네기멜런 대학교 엔터테인먼트 기술 센터의 대학원생 네 명이 한 학기 동안 진행한 Experimental Gameplay Project는 프로토타입을 얼마나 빨리 만들 수 있는지 보여 준 사례다. 이들은 「How to Prototype a Game in Under 7 Days」(2005)에서 세 가지 규칙을 소개했다. 게임 하나는 7일 안에, 한 사람이 만들고, 모두 같은 주제(중력, 떼 지어 움직이기 같은)로 만든다. 그렇게 한 학기에 50개 넘는 게임이 나왔고, 그중 하나인 Tower of Goo는 뒤에 World of Goo로 이어졌다.

이 방식이 주는 교훈은 제약이 결정을 빠르게 한다는 것이다. 7일이면 완벽하게 만들 수 없으니 핵심 하나에만 집중하게 되고, 실패해도 잃는 것이 일주일뿐이라 과감한 아이디어를 시험할 수 있다. 한편 예스퍼 율(Jesper Juul)은 블로그 글에서 일주일 규칙이 조작감과 기본 메커닉을 시험하기엔 좋지만 “게임”이라 부를 만한 완성된 구조까지 가기는 어렵다며 2주·2인 변형을 제안했다. 무엇을 시험하느냐에 따라 기간을 고르면 된다.

설계는 가설이고, 플레이테스트는 실험이다

밸브(Valve)의 실험심리학자 마이크 앰바인더(Mike Ambinder)는 GDC 2009 발표 「Valve's Approach to Playtesting: The Application of Empiricism」에서 밸브의 관점을 이렇게 요약했다. 게임 설계는 가설이고, 플레이테스트는 그 가설을 확인하는 실험이며, 이 고리를 계속 반복한다. 플레이테스트의 목적은 버그 찾기나 밸런스 조정, 시장 반응 조사가 아니라 재미를 확인하는 것이라고 했다.

밸브의 이런 문화는 1999년 켄 버드웰(Ken Birdwell)이 쓴 「The Cabal: Valve's Design Process for Creating Half-Life」에 자세하다. 하프라이프의 첫 버전은 재미가 없다는 판단 끝에 버려졌고, 팀은 프로그래머·레벨 디자이너·작가·애니메이터가 함께 앉는 “캐벌”(cabal)이라는 소그룹으로 설계를 다시 했다. 외부 참가자 한 명이 두 시간 동안 게임을 하고 개발자들이 뒤에서 지켜보는 플레이테스트를 200번 넘게 열었고, 의견이 갈리면 플레이테스트 결과로 결정했다. 반복 고리의 속도는 기술에도 달려 있다. 고치고 다시 해 보는 데 몇 분이 걸리느냐가 하루에 몇 바퀴를 도는지를 정하므로, 빠른 빌드와 실행 중 값 바꾸기 같은 도구가 디자인 품질에 직접 영향을 준다(엔진 노트).

플레이테스트: 묻지 말고 본다

플레이테스트에서 가장 믿을 수 없는 자료는 참가자의 말이고, 가장 믿을 만한 자료는 참가자의 행동이다. 사람은 왜 막혔는지 정확히 말하지 못하고, 만든 사람 앞에서는 좋게 말하려 한다. 캐벌 글에 따르면 하프라이프 플레이테스트에서 지켜보는 개발자는 게임을 켜거나 멈춘 게임을 다시 시작하는 일 말고는 말도 힌트도 할 수 없었다.

이 원칙들은 개발 초반의 거친 프로토타입에도 똑같이 적용된다. 오히려 고치는 비용이 쌀 때 자주 하는 편이 이득이다. 참가자의 감정과 동기를 해석하는 틀은 플레이어 심리 노트에 있다.

규칙의 구멍 찾기: 기능성과 완결성

재미를 묻기 전에 먼저 확인할 것이 있다. 규칙이 돌아가는가다. 풀러턴은 플레이테스트로 확인할 성질로 기능성(functionality), 완결성(completeness), 밸런스(balance)를 차례로 든다. 규칙이 모든 상황에 답을 주는가, 플레이어가 빠져나갈 틈은 없는가, 아무도 앞으로 갈 수 없는 상태는 없는가를 보는 단계다.

• 일부러 깨 본다: 이기려고만 하는 사람, 규칙을 가장 유리하게 읽는 사람, 게임을 망치려는 사람의 역할을 정해 놓고 플레이한다. 평범한 테스트에서는 보이지 않는 틈이 드러난다.
• 극단을 시험한다: 자원이 바닥나거나 넘칠 때, 인원이 가장 적거나 많을 때, 가장 빨리 이기는 길을 찾을 때 규칙이 버티는지 본다.
• 상태를 세어 본다: 디지털 게임이라면 진행에 필요한 물건과 문을 표로 만들어, 어떤 순서로 하든 막다른 길이 생기지 않는지 확인한다. 열쇠와 자물쇠 구조의 확인은 레벨 디자인 노트와 이어진다.

구멍이 막히고 나서야 밸런스를 볼 차례다. 숫자를 맞추는 방법은 시스템 디자인 노트에 있다.

지표와 텔레메트리: 무엇이 일어났는지는 숫자가, 왜는 사람이

참가자가 많아지거나 출시 뒤에는 관찰만으로 부족하다. 게임이 플레이 기록을 남기게 하는 텔레메트리(telemetry)를 심어, 어디서 죽는지, 어느 단계에서 그만두는지, 어떤 무기를 고르는지를 모은다. 자주 쓰는 형태는 다음과 같다.

• 히트맵(heatmap): 죽은 위치, 머문 시간, 지나간 경로를 지도 위에 겹쳐 그린다. 아무도 가지 않는 길, 모두가 죽는 모퉁이가 한눈에 보인다.
• 깔때기(funnel): 튜토리얼 단계나 퀘스트 진행을 순서대로 놓고 단계마다 몇 명이 남는지 센다. 갑자기 많이 빠지는 단계가 문제 지점이다.
• 선택 분포: 무기·캐릭터·전략의 선택률과 승률. 한쪽으로 쏠리면 “늘 같은 답”이 생겼다는 신호다.

숫자는 무엇이 일어났는지는 정확히 말해 주지만 왜 일어났는지는 말해 주지 않는다. 한 구간에서 많이 죽는 것이 너무 어려워서인지, 길을 몰라서인지, 일부러 위험을 즐겨서인지는 영상이나 관찰로 확인해야 한다. 그래서 정량 자료로 문제 지점을 찾고 정성 관찰로 원인을 찾는 식으로 둘을 짝지어 쓴다. 지표만 보고 최적화할 때 생기는 문제는 플레이어 심리 노트의 “재미와 참여” 절을 참고한다.

프리프로덕션과 버티컬 슬라이스

프로토타입으로 재미가 확인되면 곧바로 대량 생산에 들어가고 싶어지지만, 그 사이에 단계가 하나 더 있다. 출시 품질에 가까운 작은 조각을 실제로 만들어 보는 것이다. 게임의 모든 층(조작, 레벨, 아트, 소리, UI)을 한 구간만큼 끝까지 완성한 것을 버티컬 슬라이스(vertical slice)라 한다. 케이크를 세로로 한 조각 잘라 모든 층을 보여 주는 데서 온 이름이다.

버티컬 슬라이스는 세 가지를 알려 준다. 완성된 모습에서도 재미가 남는가, 한 구간을 만드는 데 실제로 얼마나 걸리는가, 그리고 팀과 투자자가 같은 게임을 떠올리고 있는가. 두 번째 답이 특히 중요하다. 한 구간에 걸린 시간에 구간 수를 곱하면 전체 일정의 현실적인 추정이 나온다.

마크 서니(Mark Cerny)가 D.I.C.E. 2002에서 발표한 “Method”는 같은 생각을 프리프로덕션 전체로 넓힌다. 프리프로덕션은 혼란스러워도 되는 탐색의 시간이고, 그 끝은 만들려는 게임을 그대로 보여 주는 출시 가능한 품질의 레벨이다. 그것이 나오기 전에는 본격 생산 일정을 짜지 않고, 끝내 나오지 않으면 그만두는 것도 선택지다. 위험을 프리프로덕션에 몰아넣어 생산 단계를 예측 가능하게 만드는 것이 목적이다.

개발 단계: 콘셉트부터 출시 이후까지

상업 게임은 대개 비슷한 단계를 거친다. 이름과 경계는 회사와 퍼블리셔마다 다르지만, 뒤로 갈수록 바꿀 수 있는 것이 줄어든다는 흐름은 같다. 풀러턴의 교재도 이 단계를 따라 디자이너의 일이 어떻게 바뀌는지 설명한다. 아래 정의는 위키백과 Video game development 문서의 일반적인 설명을 따랐다.

위의 버티컬 슬라이스는 프리프로덕션과 프로덕션 사이의 문이다. 서니의 “Method”가 말하듯 그 문을 통과하기 전에는 양산 일정을 짜지 않는다. 요즘은 출시가 끝이 아니라 중간 지점인 게임이 많다. 앞서 해보기(early access)로 프로덕션 도중에 팔기 시작하는 방식은 보드게임·시리어스 게임·비즈니스 노트에 있다.

계획 지평: 모르는 것이 많을수록 가깝게 계획한다

실베스터는 『Designing Games』의 과정 부분을 계획 지평(planning horizon)으로 연다. 얼마나 먼 미래까지 자세히 계획할지는 프로젝트에 모르는 것이 얼마나 많은가에 맞춰 정해야 한다는 것이다. 재미가 확인되지 않은 게임에 1년짜리 상세 일정을 세우면, 첫 플레이테스트가 일정의 앞부분을 쓸모없게 만든다. 반대로 이미 검증된 구조에 레벨만 더하는 일이라면 멀리까지 계획해도 맞는다.

소프트웨어 공학에는 같은 현상을 그린 불확실성의 원뿔(cone of uncertainty)이 있다. 배리 보엠(Barry Boehm)이 1981년 책에서 소개하고 스티브 맥코널(Steve McConnell)이 이름을 붙인 그림으로, 프로젝트 초반의 추정은 실제보다 네 배 크거나 4분의 1로 작을 수 있고, 일을 해 나가며 알게 될수록 그 폭이 좁아진다는 것이다. 게임은 여기에 “재미”라는 가장 큰 미지수가 하나 더 있다.

폭포수라는 말이 흔히 가리키는 순차 모형은 윈스턴 로이스(Winston Royce)의 1970년 논문 그림으로 알려졌지만, 로이스 자신은 시험을 끝에 몰아 두는 그 모형이 위험하다고 지적하며 되먹임을 더한 형태를 제안했다(위키백과). 짧은 주기를 앞세운 애자일 선언(2001)과 스크럼 같은 방법은 그 반대편에서 나왔다. 실제 게임 개발은 대개 섞어 쓴다. 프리프로덕션은 며칠에서 몇 주 단위의 짧은 지평으로 프로토타입을 돌리고, 뼈대가 굳은 프로덕션에서는 콘텐츠 양에 맞춰 더 멀리 계획한다. 중요한 것은 방법론의 이름이 아니라, 지금 모르는 것이 얼마나 많은지 솔직하게 세고 그만큼만 멀리 약속하는 것이다.

지식 만들기: 플레이테스트만이 아는 방법은 아니다

실베스터의 책은 과정 부분에 지식을 만드는 일(knowledge creation)을 따로 한 장으로 둔다. 디자인 결정의 질은 그 결정을 받치는 지식의 질을 넘지 못한다. 그런데 지식을 얻는 방법마다 드는 비용과 믿을 만한 정도가 다르다. 싸고 빠른 방법으로 먼저 거르고, 중요한 질문에만 비싼 방법을 쓴다.

팀이 커지면 지식이 한 사람 머릿속에 갇히는 것도 문제다. 플레이테스트에서 본 것, 버린 아이디어와 버린 이유를 짧게 적어 두면 같은 실험을 두 번 하지 않는다. 지식이 결정권과 어떻게 이어지는지는 팀·산업·디자이너의 길 노트에 있다.

의존 관계: 무엇이 무엇 위에 서 있나

실베스터의 책은 과정 부분에 의존(dependencies)을 따로 한 장으로 다룬다. 게임의 요소들은 서로 위에 쌓여 있다. 레벨의 간격과 높이는 캐릭터의 이동 속도와 점프 높이 위에 서 있고, 적의 체력은 무기 피해량 위에, 경제의 가격은 보상량 위에 서 있다. 아래 요소를 바꾸면 그 위에 쌓은 작업이 한꺼번에 틀어진다.

• 아래부터 굳힌다: 점프 높이가 정해지지 않은 채 레벨을 다듬으면 그 다듬기는 버려질 가능성이 높다. 조작, 핵심 규칙처럼 많은 것이 기대는 요소를 먼저 확정한다.
• 불확실한 바닥은 먼저 시험한다: 많은 것이 기대는데 아직 맞는지 모르는 요소가 가장 위험하다. 그런 요소를 프로토타입의 첫 질문으로 삼는다.
• 위쪽은 늦게 다듬는다: 연출, 대사, 세밀한 수치처럼 아무것도 기대지 않는 요소는 바닥이 굳은 뒤에 다듬어야 덜 버린다.
• 의존을 끊는 설계도 있다: 수치를 한곳의 표에서 읽게 하거나, 레벨을 캐릭터 능력의 배수로 재게 하면 아래가 바뀌어도 위를 덜 고친다.

앞의 계획 지평과 함께 보면, 멀리 계획해도 되는 것은 바닥이 이미 굳은 부분뿐이다. 개발 단계에서 앞쪽일수록 큰 변경이 싼 이유도 위에 쌓인 것이 적기 때문이다.

문서: 두꺼운 기획서에서 한 페이지로

전통적인 게임 디자인 문서(game design document, GDD)는 게임의 모든 규칙과 콘텐츠를 적은 수백 쪽짜리 책이었다. 캐벌 글에 나오는 하프라이프 설계 문서도 200쪽이 넘었다. 문제는 아무도 다 읽지 않고, 개발이 진행되며 금방 낡는다는 것이다.

스톤 리브랜드(Stone Librande)는 GDC 2010 발표 「One-Page Designs」에서 디아블로 3, 스포어 등의 작업에 쓴 한 페이지 설계를 보여 주었다. 시스템 하나를 그림과 주석이 들어간 큰 종이 한 장에 담아 벽에 붙인다. 한 장에 들어가야 하니 핵심만 남고, 눈에 띄는 곳에 붙어 있으니 사람들이 실제로 본다. 오늘날의 문서 관행은 대개 그 중간이다.

• 한 장짜리 개요: 게임이 무엇이고 무엇이 아닌지, 핵심 경험, 기둥(아래 절), 대상 플레이어.
• 살아 있는 시스템 문서: 위키처럼 시스템마다 따로 두고, 결정이 바뀌면 그날 고친다. 왜 그렇게 정했는지를 함께 적어 두면 같은 논쟁을 되풀이하지 않는다.
• 문서보다 빌드: 손에 잡히는 프로토타입이 있으면 설명은 짧아진다. 문서는 빌드가 답하지 못하는 의도와 이유를 적는 곳이다.

디자인 기둥: 무엇을 하지 않을지 정하는 기준

디자인 기둥(design pillars)은 플레이어가 이 게임에서 반드시 느껴야 할 핵심 경험을 짧은 문장 몇 개로 적은 것이다. Game Developer의 한 블로그 글은 기둥을 “이 게임은 무엇인가”라는 질문의 답으로 보고, 초점을 잃지 않도록 3~5개 정도로 두라고 권한다. 기둥은 기능 목록이 아니라 경험이다. “제작 시스템”이 아니라 “버려진 것으로 살아남는 긴장”처럼 쓴다.

기둥의 진짜 쓰임은 거절에 있다. 회의에서 좋은 아이디어가 나와도 “이것이 기둥 중 어느 것을 받치는가”에 답하지 못하면 보류한다. 기둥이 있으면 그 판단이 누구의 취향이 아니라 팀이 미리 합의한 기준에 따른 것이 되어, 다툼이 줄고 결정이 빨라진다. 기둥이 열 개를 넘으면 사실상 아무것도 거르지 못하므로 기둥이 아니다.

범위 다루기: 자르는 것이 만드는 것이다

게임 개발이 실패하는 가장 흔한 이유는 아이디어가 나빠서가 아니라 끝내지 못해서다. 기능은 만들 때보다 서로 엮일 때 비용이 커지므로, 범위는 시간이 갈수록 저절로 커진다. 시드 마이어는 GDC 2012 강연에서 아이디어의 3분의 1 이상은 재미가 없어서 결국 빠진다고 했고(정리 기사), 스펠렁키의 데릭 유는 꾸준히 끝내는 능력을 인디 개발자의 첫째 기술로 꼽는다(디자이너의 생각 노트).

• 꼭 있어야 할 것부터: 기능을 “없으면 출시 못 함 / 있으면 좋음 / 다음 기회에”로 나누고, 앞 칸만으로 게임이 성립하는지 먼저 확인한다.
• 아끼는 것도 자른다: 글쓰기 조언에서 온 “네가 아끼는 것을 죽여라”(kill your darlings)는 게임에도 그대로 통한다. 만든 사람이 애착을 가진 기능일수록 플레이테스트 결과가 나빠도 남기고 싶어진다. 기둥과 플레이테스트가 그 결정을 대신 내려 주는 기준이다.
• 한 번만 쓰이는 것을 경계한다: 캐벌 글은 게임의 한 장소에서만 쓰이는 일회성 기술 작업을 피하라고 했다. 여러 곳에서 다시 쓰이는 시스템 하나가 일회성 연출 열 개보다 오래 간다.
• 자른 것은 기록한다: 왜 잘랐는지 남겨 두면 같은 아이디어가 다시 올라왔을 때 논의를 처음부터 하지 않아도 된다.

포스트모템: 끝난 뒤에 배우기

포스트모템(postmortem)은 프로젝트가 끝난 뒤 무엇이 잘됐고 무엇이 잘못됐는지 정리하는 회고다. 게임 업계에서는 Game Developer 잡지가 “잘된 점(What Went Right)”과 “잘못된 점(What Went Wrong)”을 나란히 적는 형식을 오래 실어 이 장르를 대중화했다. 블리자드의 「Postmortem: Blizzard's Diablo II」가 그 형식의 대표적인 예이고, 사이트에는 꼭 읽어 볼 포스트모템 목록도 있다.

GDC의 “고전 게임 포스트모템”(Classic Game Postmortem) 강연은 오래된 게임의 결정을 만든 사람이 직접 돌아본다. 데이비드 브레빅(David Brevik)의 「'Diablo': A Classic Game Postmortem」(2016)은 디아블로가 원래 턴제 게임으로 기획되었다가 지금의 모습이 되기까지를 다룬다. 게임의 뼈대가 개발 도중에 바뀌어도 된다는 것, 그리고 그 변화가 장르를 만들 수도 있다는 것을 보여 주는 사례다.

좋은 포스트모템은 남 탓 대신 구조를 본다. “누가 늦었다”가 아니라 “무엇 때문에 늦어질 수밖에 없었나”를 묻고, 다음 프로젝트에서 바꿀 행동 몇 가지로 끝낸다. 출시 직후에 쓰면 기억이 생생하고, 몇 달 뒤 다시 보면 감정이 걷힌 판단을 얻는다.