궤도
[게임 기획] '별들 사이' 기획 과정 본문
이 글은 2020년 6월부터 12월까지 진행한 프로젝트 '별들 사이'의 기획 과정을 정리한 글이다.
6월부터 8월까지는 동아리의 공식 여름방학 프로젝트 기간이었고, 그 이후 팀원들과의 회의를 통해 출시를 결정한 뒤 12월까지 프로젝트를 이어나갔다.
play.google.com/store/apps/details?id=com.king42.star42
별들 사이 - Google Play 앱
반짝이는 별들 사이 단 하나의 별을 향한 모험. 별을 사랑하는 인공위성 카이트 42호는 어느 날 웜홀 설계도를 발견합니다. 설계도를 토대로 웜홀을 만들어 별에 가겠다고 결심하지만, 카이트 42
play.google.com
별들 사이는 현재 구글 플레이 스토어에서 다운받을 수 있고, 아쉽게도 ios는 지원하지 않는다.
(홍보) 게임을 다운받아 플레이 해보면서 어떤 기획이 어떻게 구현됐는지 찾아보는 재미를 느껴보는게 어떨까 하하
초기 기획
이 게임의 주제의식부터 이야기 하자면 내 고등학교 시절까지 거슬러 올라가는 길고 재미없는 tmi의 향현이므로, 거두절미하고 내가 처음 기획서를 작성한 2019년 11월부터 시작해보자.
당시 우주를 주제로 1인 1기획을 준비해야 했던 나는 1호선을 타며 아이디어를 구상하고 있었고
마침 악뮤의 작은별을 듣고 있었다.
대충 여기에 아이디어를 얻어서 생각을 하던 중 여고생 둘과 인공위성 하나가 주인공인 게임에 대해 생각하기 시작했다.
왜 여고생이냐면 그때 그냥 떠오른 이미지가 그랬어서 였고...원래 진짜 초창기 기획은 별을 사랑하는 인공위성에 대해 알게된 학생 둘이 그 인공위성을 돕는 정말 거의 순수한(?) 스토리 게임이었던 것 같다.
포커스도 인공위성보단 조력자인 학생들에게 맞춰져 있었고...게임의 분위기도
투더문을 생각했기 때문에 그래픽도 도트고 뭐 그랬었는데...
아무리 생각해도 2달짜리 프로젝트에서 스토리 게임을 만들기는 힘들 것 같았다. 그리고 내가 그런 스토리를 쓸 역량을 갖추지 못했다는 것도 이유 중 하나였다.
며칠 고민을 하다가 얼레벌레 그럼 텍스트 로그라이크 장르로 만들자는 생각이 들었는데, 그 이유를 설명하겠다.
스토리 게임은 기-승-전-결이 명확하게 이어져야하고 대부분의 경우 스토리를 선형적으로 작성하게 된다. 프로젝트 이전까지 스토리를 전부 작성하지 않는 이상 프로젝트를 진행하면서 스토리를 계속 써야한다는 건데, 이런 진행방식은 업무 분담을 까다롭게 만든다.
스테이지형 게임이라면 A에게 1~3스테이지 구현, B에게 4~6스테이지 구현을 맡기는 식으로 분담하면 되겠지만 초반부의 스토리를 작성하면서 중반부, 후반부의 스토리를 동시에 작성하기는 힘들기 때문에 스토리가 완성될 때까지 다른 팀원들은 할 일이 없어진다.
하지만 텍스트 로그라이크 장르의 게임이라면 시작과 결말을 정해둔 뒤 게임의 설정에 맞춰 다양한 이벤트(스토리)들을 동시에 작성할 수 있다. 그리고 다른 부분의 기획을 진행하면서 생각날 때마다 이벤트를 추가해도 큰 문제가 없고 아무튼 협업을 해야하는 프로젝트에는 적절한 장르인 것 같았다.
그리고 이렇게 장르를 변경하며 기존에 있던 학생 둘을 지우고 인공위성에 집중하기로 했다.
오랜만에 보니 지금과 달라진 부분들이 먼저 보인다.
생각해보면 이 기획안을 썼을 때는 내가 '앨리스, 추락해도 괜찮아'팀에 합류하기 전이었으니 이게 내가 처음으로 작성한 기획안인 셈이다. 아무튼~ 이걸로 팀원 모집발표를 했으나, 팀원이 모이지 않았고...그렇게 앨리스팀에 합류하게 됐다.
솔직히 말해서 아쉬웠지만 당시에는 더 준비해서 다음 기회에 다시 도전하자는 마음으로 앨리스팀에서 열심히 일했다.
왜 그때 팀원이 모이지 않았을까 지금 다시 생각해보자면...
1. 급하게 완성된 기획이라 허술한 부분이 많았음
2. 스케일이 커보일 수 있었음
3. 모집발표자가 프로젝트 경험이 없음
등이 있겠다. 텍스트 로그라이크라도 어쨌든 스토리가 주가 된다는게 부담스러웠을 수 있을 것 같았고, 그런 것에 비해 내가 준비한 것이 적기도 했고, 당시에 나보다 매력적인 기획들이 많이 나왔었다.
아무튼 강해져서 돌아오겠다고 결심한 나는
기획 준비 그리고 팀 구성
'앨리스, 추락해도 괜찮아'가 끝난 뒤 심심할 때마다 조금씩 기획을 준비했다.
그리고 그래픽이나 사운드에 대한 것도 정했다.
내가 원하는 그래픽 스타일을 명시해야 그래픽을 하시는 분들한테도 좋고, 사운드는...어차피 내가 구하게 되겠지만 어쨌든 게임의 전반적인 분위기를 알 수 있으니 내가 정해둔건 최대한 알려줘야 팀원 모집이 수월할 것이라고 생각했다.
괜히 신비주의 추구하다 아무도 안모이면 쓸쓸히 기획서를 휴지통에 넣어야 한다.
배경을 우주, 우주정거장으로 잡았고, 우주 영화보면 옷들이나 기체들이 다 허옇기도 하고...전반적으로 삭막한 분위기를 원했다. 그래서 그래픽은 흑백으로 정했고 그림체(?)를 정해야 했는데, 흑백+도트는 유저가 보기에 불편할 것 같았다. 구분도 잘 안되고 어쨌든 우리 게임은 텍스트가 메인이기도 해서 이와도 어울리지 않을 것 같았다. 그렇다고 너무 화려한 그래픽보다는 최대한 간단한 그림체였으면 했다. 공백이랑 여백이 많아보이는? 그냥 쓸쓸하고 삭막한 분위기를 최대한 잘 나타낼 수 있는 그래픽을 찾았던 것 같다.
이런 느낌?
결과물을 보면 알겠지만 난 이번에도 내 능력에 과분한 그래픽 팀원을 만났다.
이렇게 첫 기획안을 작성하고 약 반년 뒤 새로 작성한 1인 1기획ver2로 난 5명의 팀원을 모을 수 있었다.
이게 당시 모집발표를 할 때의 기획서인데 지금의 게임과 크게 달라진 부분이 없다. 허허 뿌듯하구만
역할 분배
우리 팀은 나 포함 총 6명이고 기획2/코더3/그래픽1의 구성이다. 스케일이 작은 편은 아닌 프로젝트였고, 기획서의 양도 많을 수밖에 없었기 때문에 각 팀원이 맡은 분야에 따라 기획서를 각각 작성하기로 했다. 그니까 4개+a를 작성한 거다.
그리고 역할 분배도 해야했는데, 유니티의 씬이 분리될 수 있는가와 업무의 정도를 고려해서 역할을 나누었다.
우리 게임은 크게 탐사-기체-보고서로 게임을 구분할 수 있다. 그렇다고 세분에게 각각 탐사, 기체, 보고서를 단순하게 맡기기에는 보고서 파트에 큰 일이 하나 있었다. 바로 이벤트(스토리)부분이었는데 난 이 파트가 아주 복잡할거라고(실제로도 그렇게 됐다) 생각했어서 한 사람은 이 부분만 맡아도 충분할 것이라고 생각했다. 그래서 한 분배는
탐사 / 기체 + 보고서(이벤트파트 제외) / 보고서(이벤트 파트)
가 됐다.
기획도 역할을 나누어야 했는데 스토리를 작성하는게 주가될 이벤트 파트는 둘이 함께 작성하기로 하고 나는 기체와 보고서 파트의 기획을 맡고 다른 기획분은 탐사파트의 기획을 맡으셨다. 근데 뭐 사실 기획서 작성할 때만 이렇게 한 셈이지 둘이 같이 자주 만나며 전체적인 기획에 대한 아이디어를 주고 받았다.
그래픽 기획서
기획 초반 그래픽과 관련해 빠르게 정해야 하는 것은 '그래서 도대체 어떤 그래픽 리소스가 얼마나 필요할 것인가'이다.
작업의 대략적인 스케일을 알아야 작업 일정을 정하는 것에도 용이할 것이고 다 한 줄 알았는데 계속해서 추가되면 좀...슬플 것 같았다.
필요한 리소스는 크게 배경과 아이템으로 나눌 수 있다. 아이템은 대충 ppt 그림으로 대체할 수 있기도 하고, 참고 자료도 빠르게 구할 수 있는 반면에 배경은 구도도 정해야 하고 참고자료를 아무리 많이 가져와도 어쨌든 새롭게 창작해서 그려야 하는 부분이 더 많기도 하고 여러모로 시간도 걸리는 편이라 배경먼저 부탁드렸다.
배경
배경 작업에 참고할 만한 이미지를 여러 개 찾아봤고, 구도도 2종류를 제시했다. 그래픽 팀원께서 첫번째 구도를 선택하셨고, 간단하게 구도만 잡은 스케치를 보내주셨는데, 아이템을 배치하기엔 좁다는 생각이 들어서
이렇게 피드백을 드렸다.
다른 배경에 대한 기획서도 비슷하게 작성하여 서로 피드백을 주고 받았다.
아이템
아이템 그래픽 기획서는 나말고 다른 기획분이 작성해주셔서 나에겐 없지만
먼저 함께 각 아이템의 참고 자료를 수집했고
다른 기획분이 이런식으로 정리하셨다. 이건 실제 사용한 기획서는 아니고 내가 작성했던 아이템 기획서 초안이다.
UI
UI 그래픽 기획서는 이렇게 작성했고, 분리할 수 있는 리소스는 전부 분리했다.
근데 지금보니 네모모양의 UI에도 왜 크기표시를 동그라미로 했는지 모르겠다. 왜그랬지...?
코더 기획서(탐사)
기획서는 내가 작성하지 않았으므로...그냥 회의 과정에서 나눈 이야기를 주로 써보겠다.
먼저 나는 아이템 파밍 난이도 조절을 시간제한으로 하는 게임들이 맘에 들지 않았다. 그래서 시간 제한 말고 난이도를 조절할 수 있는 방법에 대해 고민하던 중 무게 제한을 떠올렸다. 각 아이템에 무게를 부여하고 사용자가 가져갈 수 있는 최대 무게를 정해두면 전략적으로 아이템을 선택할 수 있을거라고 생각했다. 참 괜찮은 아이디어였으나
아이템의 무게-가져갈 수 있는 총 무게-게임당 탐사 횟수-아이템에 따른 기체/웜홀 증감 수치-게임의 전체적인 밸런스....가 전부 톱니바퀴처럼 연관된 형태였던지라 어디 하나라도 삐끗해서 계산을 잘못하면 게임의 전체적인 밸런스가 무너지는 상황이었다. 이거때문에 둘이서 머리를 엄청 싸맸고 고생한 보람이 있던건지 큰 수정없이 밸런싱을 마칠 수 있었다.
배경 그래픽을 최대한 재활용하기 위해 기본 배경을 3종류 만들었고, 각 배경마다 환경을 3개씩 만들었다. 그니까 총 9종류의 탐사지를 만든 셈이다.
각 탐사지에 등장하는 아이템의 정보는 이렇게 따로 엑셀로 정리했다.
코더 기획서(기체)
사실 기체 자체에는 크게 기획할 부분이 없다. 그냥 보고서 열람하기 전 배경같은 존재?
그래도 그냥 두면 너무 심심하니까 탐사에서 얻은 아이템을 기체에 배치하기로 했다.
이게 끝이다.
코더 기획서(보고서)
보고서 기획서의 일부이다.
이건 당연히 알지 않을까? 싶은 것도 다 써야 기획서를 보는 코더분들이 혼란 없이 작업하실 수 있다.
스크롤 유무 / 페이지 배치 / 증감 수치 등등 알고 있는 모든 것들을 작성한다고 생각해야 한다.
시스템의 디테일한 기획은 워드로 따로 정리했는데 이건 영업비밀이니까 공개하지 않는다.
코더 기획서(이벤트)
우리 게임의 메인이라고 할 수 있겠다...
각 이벤트들은 하나하나 스크립트를 작성했다. 그냥 막 쓴건 아니고
나름의 형식을 갖춰 작성했다.
작성한 이벤트들은 한 눈에 볼 수 있게 목록화 했다.
이건 이벤트 발생 확률에 대한 문서이다.
처음엔 이런저런 조건이 많았는데 그냥 최대한 심플하게 만들었다. 뭐 발생확률이 0.5%라던가...이런 이벤트는 없다.
물론 ppt로 정리한 것도 있다. 저기 돌발이벤트의 발생확률이 20%라고 써있는데, 뭐 나중에 가서 수정했으니 저정도는 안가려도 될 것 같다.
코더 기획서(기타)
양이 많을 거라고 생각은 했는데 정말 많아서 좀 힘들다...언제 다쓰지
이런 게임은 튜토리얼이 필요하니 튜토리얼 기획도 했고
엔딩 연출도 기획하고...솔직히 내가 기획했지만 우리 엔딩 연출 참 잘만든 것 같다.
UI도 기획하고...당시에 메인화면 배경 그래픽이 없던 때라 내가 그렸다. 그니까 저걸 보고
이걸 그리신거다.
폰트 & 사운드 기획
폰트 기획은 이렇게 어울릴만한 폰트들을 다 가져와서 팀원들과 투표로 정했다.
그리고 고통스러웠던 사운드 기획 작업...마음에 드는 소리를 찾기가 정말 어려웠다.
우주공간이니 sf스러우면서도 삭막한 사운드를 원했는데 정말 찾기 힘들었다...
창고 bgm은 맘에 드는 걸 찾지 못해 결국 내가 저작권이 없는 사운드들을 모으고 겹쳐서 새로 만들었다.
그럼 이제 기획이 할 일이 끝났을까? 아니다.
테스트
당연히 배포전 게임의 모든 요소들을 테스트해봐야한다.
밸런스는 괜찮은지...버그는 없는지...
문제는 우리 게임이 로그라이크 게임(aka 운빨겜)이라는 건데...특정 이벤트가 잘 작동하는지 확인하려면 그 이벤트가 나올 때까지 테스트를 해야 했던 것이다.
일전에 만들어둔 이벤트 목록을 그대로 가져와 하나하나 체크하며...버그를 확인했고
우리 이벤트가 130개 정도 있던가...아무튼 다 확인했다
다양한 조건에서 테스트하며 밸런스도 확인했다
버그도 기록하며 고쳐나가구...
그럼 테스트하고 버그픽스 하면 정말 끝인가?
피드백
아니다. 피드백 받고 수정해야 한다.
프로젝트 직후 동아리 내에서 1차 배포를 했을 때, 튜토리얼이 직관적이지 않아 게임 방법이 와닿지 않는다는 의견이 있었다. 튜토리얼시 클릭할 오브젝트를 화살표로 나타냈었는데, 이 화살표가 검은색이라 배경처럼 보였나보다.
그래서 저 화살표를 검은색에서 빨간색으로 수정했다.
시작 부분의 글도 조금 다듬어 정보값을 늘리고 가독성도 늘렸다.
근데 의외로 다들 저걸 잘 안읽어서 많이들 놓치는 것 같았다 ㄸㄹㄹ
버그 사이
이렇게 피드백 받고 버그 수정하고 피드백-버그수정-밸런싱-피드백-버그수정-밸런싱을 반복하다 보면
출시를 할 수 있다.
TMI
1. 게임에 등장하는 모든 인물들은 성별지칭을 하지 않았다.(실제 인물 제외) 그니까 마음대로 상상하면 된다.
인물의 성격, 대사를 구상할 때 성별에 제약 받고 싶지 않아서 그랬다. 그/그녀 표현을 쓸 수 없어 힘들었다.
2. 카이트 42호는 kite(연)+42(삶 우주 그리고 모든 것에 대한 궁극적인 질문에 대한 해답)이다. 연날리기를 할 때
마지막에 연줄을 끊는 것을 보고 우리 인공위성의 목표랑도 비슷하지 않나 싶어 이걸로 정했다.
3. 기획 초창기 이후 사라진 두 명의 학생들은 아주 없어지지는 않은 것 같다...의도한 건 아닌데 특정 등장 인물들이
그 둘을 떠오르게 하는 것 같기도 하고...그렇다고 걔네가 여성이라는 건 아니다.
4. 시국이 시국인지라 프로젝트 내내 우리 팀 6명이 다같이 오프라인으로 모인 적은 한 번도 없다.
5. 나름 이스터 에그 같은게 있다.
6. 그래도 현실적인(?) 해피엔딩(?)이라고 생각한다.
7. 구글 플레이스토어 게임 설명 좀 잘 쓴 것 같다.
참고한 게임들
