생태계는 한 가지 동물만
증가하거나 감소해도
생태계 전체가 울부짖는다고 합니다..
한 요소의 변화가
다른 모든 요소를
변화시키는 것이죠.
프로 출신들은 다들 아시겠지만,
게임 개발을 하다 보면
자주 일어나는 일입니다.
캐릭터의 이동 속도를 늘렸을 뿐인데
애니메이션이 어색해져서
다시 만들고,
뛰어넘으면 안되는 거리를 뛰어넘게 되어,
맵을 다시 만드는 일도 있습니다.
이런 불상사를 방지하는 방법에
대한 글입니다.
게임 기획은 수백 가지의 메카닉,
설정 요소, 서브시스템을 포함할 수 있다.
게임 아이디어 구상이 끝나도 개발자는
도전과제, 시스템, 인터페이스에
추가할 아이디어를 떠올려야 한다.
이렇게 많은 아이디어들이 있는데
무엇을 먼저 작업해야 할까?
가장 창의적인 부분?
가장 기본적인 부분?
가장 기술적인 부분?
이 질문에 답하려면
게임 개발의 의존성을 이해해야 한다.
의존성
의존성이란 기획의 두 부분의 관계이다.
한 부분의 변화가
다른 부분의 변화를 강제하는 관계이다.
예를 들어, 마리오의 점프 높이가
한 칸 높아진다면,
모든 맵이 수정되어야 한다.
게임 기획의 여러 부분은 상호의존적이다.
어떤 요소가 변하면,
그것에 의존하는 모든 요소가 변해야 한다.
의존성을 이해하는 것은,
의존된 것이 변경됨으로 인해
다른 부분이 변경되어야 하는 상황을 방지한다.
예를 들어, 세 번 때리는 스킬을 가진
캐릭터의 애니메이션을 완전히 제작했다고 해보자.
나중에 밸런스 문제로
그 캐릭터가 두 번 때리게 변경되면
애니메이션을 다시 작업해야 한다.
애니메이션 아트는
캐릭터의 스킬 시스템 기획에 의존했으며,
스킬의 변화는 애니메이션 콘텐츠로
파급을 일으켜 작업 리소스를 낭비해버렸다.
의존성은 그 기본이 되는
요소가 실패해야 의존 요소에
영향을 미친다는 것이 아니다.
기본이 되는 요소의 기획에서 변화가 있으면
의존하는 요소의 변화가 강제되는 것이다.
예를 들어, <림버스 컴퍼니>의 어떤 캐릭터는
세 번 때리는 모션을 가졌지만
두 번 때리는 판정인 스킬을 가졌다.
애니메이션 작업을 먼저 한 뒤
성능을 변경한 다음, 마감을 맞추지
못해 그대로 출시한 것으로 보인다.
의존성 탑
기획의 의존성은 마치 탑처럼 쌓여 있다.
그 형태를 그려서 의존성의 탑을 만들면
의존성의 구조를 이해할 수 있다.
의존성 탑은 기획 요소 간의
주요 의존성을 식별하는
간단한 방법이다.
우리에게 지금 무엇을 작업해야 하고
무엇을 나중에 남겨둘지 알 수 있게 해준다.
의존성 탑을 만드는 방법을 알아보자.
일단 게임을 개별 요소들로 분해한다.
메카닉, 컨트롤, 인터페이스, 서브시스템 등
그런 다음 이러한 요소들
간의 주요 의존성을 파악한다.
마지막으로, 모든 의존성의 관계를
그려서 시각화한다.
이것이 의존성 탑이다.
예를 들어보자.
우리가 <스타듀 벨리>같은
농사 시뮬레이션을 만든다고 가정해 보자.
많은 개발 초기가 그렇듯,
아이디어만 많고 입증된 기획은 부족하다.
현재 9개의 시스템이 구체화된 상태이다.
캐릭터: 캐릭터가 환경에 존재하고 움직임
친구: 캐릭터는 친구 관계를 가질 수 있음.
로맨스: 캐릭터는 서로 혼인할 수 있음.
가족: 캐릭터는 가족 관계를 가질 수 있음.
농사: 농사를 통해 자본을 늘릴 수 있음.
물 주기: 작물에 물을 주어야 작물이 자람.
계절: 계절이 농사, 건축에 영향을 미친다.
자본: 돈을 통해 농사를 시작하거나 건축을 할 수 있다.
건축: 돈을 내고 농장에 편의 시설을 건축할 수 있다.
이러한 요소 중 무엇에 먼저 집중할지는
어떻게 선택할까?
캐릭터, 친구, 가족부터?
농사, 자본, 건축부터?
의존성 탑은 결정하는 데 도움을 준다.
예를 든 게임을 의존성 탑으로 시각화하면
아래와 같다.
기획의 각 요소는
탑 아래층에 있는 요소에 의존한다.
그러므로 작업은 하단에서 시작해야 한다.
의존성 탑의 하단에서 시작하여
반복을 통해 상단으로 작업해 나가야 한다.
우리는 의존성탑을 미리 쌓아 본다.
그다음 의존하지 않는 바닥의 기획에서 시작한다.
그 기초가 몇 번 반복되고 플레이 테스트된 후에,
더 확실하고 확신을 가진 기초를 다진다.
그다음에는 그 기초에
의존하는 요소들을 제작할 수 있고,
아래에서부터 올라오는
후속 변경으로 인해
무너지지 않을 것이라는
확신을 가질 수 있다.
이런 식으로 탑을 따라
올라가며 작업을 한다.
여전히 예상치 못한 기획 문제 때문에
구조가 흔들릴 수도 있겠지만,
그 빈도와 영향을 압도적으로
줄일 수 있다.
다시 한번, <스타듀벨리>를
개발한다고 생각해 보자.
기본 캐릭터, 농사, 자본 시스템 만으로
기초 시스템을 만들 수 있다.
처음에는 농사를 지어
돈을 버는 게임일 뿐이다.
그리고 몇 번의 반복 후
잘 작동하는 수준으로 끌어올리면
우리는 계절 시스템을 넣을 수 있다.
그런 과정이 몇 번 반복된 후,
우리는 계절별 작물과 계절별
날씨를 추가할 수 있다.
이런 식으로 기초에서부터
의존성의 탑을 쌓아 올린다.
그리고 기획은 개발 도중에
변경될 수도 있다.
농사를 테스트한 후에
계절별 날씨가 필요 없다고 느꼈고,
계절별 해충 시스템을 추가하고 싶으면
쉽게 할 수 있다.
그래서 탑의 윗부분은
바닥이 공고해짐에 따라
다시 만들어질 수 있다.
무협물로 비유하자면
탑의 위부터 구현한 게임은
마교의 무공과 같다.
"마교는 기본공을 수련하지 않아서
고수가 적고 양산된 중수들밖에 없다."라는
언급이 나온다.
게임 개발도 무공과 마찬가지로 기초가
탄탄하지 않으면 높게 쌓을 수 없다.
불확실성의 연쇄
기획이 생각하는 대로 작동하지 않는 것은
이미 프로 출신이라면 알고 있을 것이다.
기획자는 회피 시스템이 어떻게 작동할지
문서를 작성할 수 있지만,
그것을 제작하고 테스트하기 전까지는
예상대로 작동할지 확신할 수 없다.
이러한 불확실성 때문에,
의존성에 주의를 기울여야 한다.
우리가 설계도로 자동차를 만든다면
타이어를 먼저 만들던
기어를 먼저 만들던 상관없을 것이다.
하지만 독창성을 가진 게임에서는
기획이 현실로 옮겨지지 않는
경우가 많다.
개발 중에 기획 요소를 변경해야 할
가능성이 어느 정도 있다.
이러한 불확실성 때문에
의존성에 대한 공부가 중요하다.
불확실성은 의존성을 통해
연쇄적으로 증가한다.
예를 들어, <팰월드>의 습격 시스템을
만든다고 쳐보자.
습격 시스템은 기획 묶음 어딘가에
두세 페이지 정도로 요약되어 있다.
그것은 습격자가 어떻게, 언제 생성되는지,
습격자의 전술, 능력, 물리치기 위한 전략을 다룬다.
이 기획이 가진 확실성이 자체만으로
80% 정도라고 해보자.
예상한 대로 80% 비율로 작동한다니
꽤 잘 만들어진 기획이다.
그러나 80% 수치는 습격 기획 자체의
불확실성만을 다룬다.
습격 시스템을 계획대로 구현하려면,
우리는 무기, 주변 팰, 방어 시설,
그리고 전투 시스템을 구현해야 한다.
이 시스템들 중 하나라도 바뀌면
변경사항이 의존성 탑을 통해
상위로 전파되어 습격 시스템의
변화를 강제할 것이다.
각 기초 요소가 80%라는
매우 높은 확실성을 가진다 해도
의존성 탑의 5층에 있는
습격 시스템이 예상대로 작동할 확률은
0.8의 5승 = 0.33 (33%)에 불과하다.
불확실성의 연쇄가 뜻하는 건
의존성 탑의 상위 요소들이 거의
항상 큰 재설계가 필요하다는 것이다.
이게 저번 글에서 과도한 기획 계획을
부족한 기획 계획 급이라고 한 이유이다.
기초 시스템들이 구현되거나
테스트될 때 거의 확실히 변경되고,
그러한 변경사항은 전파되어 변화를 강제한다.
코어 아이디어
코어 아이디어는 게임의 의존성 탑 바닥에 있는
더 이상 줄일 수 없는 메카닉에서 나오는 것이다.
게임을 감정적으로 가치 있게 만들고
제거할 수 없는 것을 말한다.
<스트리트 파이터>등 대전 격투 장르는
이동, 공격, 방어, 던지기가
코어 아이디어일 것이다.
이 부분만으로도 감정적으로
의미 있는 게임을 만들 수 있다.
매우 기본적이지만 플레이 가능한
게임을 형성할 것이다.
이런 코어 아이디어는
의존성 탑의 적절한 기초이며,
기획의 다른 모든 것이 의존한다.
핵심을 찾아냄으로써, 짧은 시간에
테스트 가능한 게임을 만들 수 있다.
이때 테스트 중심
반복의 진가가 드러난다.
빠른 반복으로 핵심이 구축되면
다른 아이디어를 바깥쪽에 추가하고
반복하면 된다.
만약 핵심을 찾을 수 없거나
핵심이 재미없다면
그 게임은 알맹이가 부족한 것이다.
막연하게 머리에있는거 또렷하게 정리되는듯
저 핵심이란게 유저가 느끼는 도파민이나 중독성 감정변화 여기에 초점 맞추는게 좋은듯. 솔직히 말하면 의존성에 걸쳐있는 콘텐츠들은 이름이나 형태만 바뀔 뿐이지 그놈이 그놈인 경우가 다반사. 물딜/마딜만 해도 그냥 데미지인데. 유저가 “힘들게 물딜 덱을 만들어냈다!” 느낌을 주기 위해 일부로 파밍을 힘들게 물딜/마딜로 나눈거고, 힘들게 모았기 때문에 도파민이 더 나오고 감정변화가 극적인 거라고 생각함.
본문에 추가할만한 통찰이네요
해당 댓글은 삭제되었습니다.
이런 분이 내용 흡수가 빠르거든요...
개추 예를 들어, <림버스 컴퍼니>의 어떤 캐릭터는 세 번 때리는 모션을 가졌지만 두 번 때리는 판정인 스킬을 가졌다. >> 또 당신 입니까 묘파우
림버스 인격 GOAT ㅋㅋㅋㅋ
ㄹㅇ 한 번 정하면 바꾸지 말아야 할 게 존재하는 듯
ㄹㅇ ㅋㅋ
개인개발 아니더라도 팀 협업할때도 명심해야할듯 개추