솔로/인디 게임 개발을 준비하는 방법

어떤 아이디어를 가지고 게임을 개발하다 보면, 점점 아이디어가 바뀌게 되는 경우가 있다. 작은 아이디어들이 종종 바뀌는 건 문제가 아니고 오히려 필요한 부분이지만, 게임의 핵심 알고리즘이나 메커니즘 자체가 바뀌어버리는 경우도 있죠. 이 경우 게임을 더 낫게 만들 수도 있지만, 그동안 만들어 온 수많은 코드나 설정들을 바꿔야 하는 일이 생길 수도 있습니다. 이런 일이 자주 생긴다면 게임개발 가능성에 안 좋은 쪽으로 영향을 줄 수 있습니다.

 

그래서 우리는 게임개발 도중에 길을 잃지 않기 위해 개발 개발 준비를 확실하게 해야합니다. 이 포스팅에서는 대게 솔로/인디 개발자들이 만드는 중/소규모 프로젝트에 적용할 수 있는 게임 개발 준비방법을 설명합니다. 

1. GDD(Game Design Document)

---

먼저 내 게임 혹은 아이디어를 정리해야합니다. GDD는 내가 머릿속으로만 생각하던 모든 아이디어들을 글이나 그림으로 뱉어내는 것입니다. 머릿속에서 추상적으로만 존재하던 아이디어 파편들을 글이나 그림으로 뱉어내어 정리하는 것이죠.

GDD에 필요한 정보들

앞서 말했듯이 솔로/인디 개발에서의 GDD는 나의 아이디어를 정리한 문서이기 때문에 너무 형식적이거나 딱딱할 필요는 없습니다. 하지만 GDD에는 대략적으로 아래와 같은 정보들이 포함됩니다. 

• 개요 (concept, genre, target audience, project scope...)
• 게임플레이 (objectives, game progressions, GUI...)
• 메커니즘 (rules, combat, physics...)
• 게임 요소 (world map, story, characters, locations, level design...)
• 에셋/리소스 (music, sound effects, 2D/3D models...)

GDD를 쓰는 방법

• 가볍게 써라 : 게임의 디테일한 부분은 언제든지 바뀔 수 있기 때문에 너무 디테일한 부분까지 모두 적으려고 하지 마세요. 
• 게임과 함께 발전시켜라 : GDD는 게임 개발 전에 작성하지만 개발 도중에도 수정하고 발전시켜야 합니다. 실제 게임 개발 과정에서 수정된 사항들이 GDD에 반영이 안 된다면, GDD는 쓸모없게 됩니다. 항상 게임과 함께 발전시키세요. 
• 레퍼런스 이미지를 써라 : 텍스트로만 이루어진 GDD는 실제 개발될 게임의 모습을 상상하기 힘들 수도 있습니다. 적극적으로 레퍼런스 이미지(플로우 차트, 콘셉트아트 등등)를 사용하세요.

아래의 링크에서 실제 게임개발회사의 GDD를 볼 수 있습니다. 

GDD of Fallout: Brotherhood of Steel 2    

GDD of Silent Hill 2

2. 작업보드(Task Board)

---

작업 보드는 말 그대로 해야 할 작업(Task)을 정리해 놓은 보드입니다. 일종의 To-do List라고 할 수 있습니다. 작업 보드는 보통 세 가지 단계(Phase)로 나누어집니다.

• To-do: 아직 시작하지는 않은 해야 할 일들입니다.
• In progress : 현재 작업 중인 일들입니다.
• Complete : 작업이 완료된 일들입니다.

작업 보드를 만들 때 가장 중요한 것은 어떤 작업을 할 것이냐인데, 이는 몇 가지 단계를 통해 정할 수 있습니다. 

1. 작업할 큰 카테고리를 정한다. 예를 들어 플레이어로 정했다고 하자.
2. 그 큰 카테고리(플레이어) 안에서 작업할 일을 정한다. 
3. 그 작업할 일을 더 작은 작업으로 나눌 수 있는지 보고 나눌 수 있다면 나눠라
4. 2번 3번 과정을 더 이상 작은 작업으로 나누는 게 힘들 때까지 반복한다.
5. 이제 이 작업을 To-do영역이나 In progress영역에 추가한다

작업 보드에서 작업은 최대한 작을수록 좋습니다. 작업의 규모가 작으면 게임 개발이 진행되고 있다는 것을 눈으로 확인할 수 있습니다. 또한 작업이 얼마나 걸릴지 예측하기 쉬워지기 때문에 In progress 영역에 있는 작업들을 모두 소화하는데 얼마나 걸릴지 계산하기도 쉬워집니다. 

 

작업보드를 만드는 툴을 많이 있지만, 개인적으로는 Notion이나 Codecks을 추천합니다.

3. 개발 준비 시 주의해야 할 점

---

너무 큰 스케일의 프로젝트

만약 내가 초보게임개발자라면 큰 프로젝트는 뒤로 미루세요. 내가 만들고 싶은 게임이 MMORPG같이 스케일이 크고 많은 개발시간을 필요로 하는 게임일 수도 있지만, 만약 내가 사회적으로나 금전적으로 안정되어 있는 상태라 남는 게 시간이고 돈이라면 상관없겠지만, 그게 아니라면 현실적으로 게임하나에 5년 이상의 시간과 수백/수천 만원의 돈을 투자하기란 쉽지 않죠.

 

만약 내가 많은 프로젝트를 경험해 본 게 아니라면, 최대한 작은 스케일의 프로젝트를 많이 만들어보는 것이 더 좋습니다.

플레이어가 익숙할 거라고 생각하기

내가 만드는 게임의 장르는 나에게는 익숙하기 때문에 처음 그 장르의 게임을 접하는 플레이어들의 입장을 간과하기 쉽죠. 게임은 항상 직관적이고 간단할수록 플레이하기 좋습니다. 플레이하기 전에 알아야 할 것들이 많은 "발더스게이트" 같은 게임들에 유입이 적은 걸 생각해 보세요. 

특정 아이디어에 너무 집착하기

아무리 재미있을 것 같은 아이디어라 하더라도 실제로 만들어보면 생각만큼 재미있지 않은 경우가 있습니다. 사실 이 부분이 게임 준비와 프로토타입 개발이 같이 이루어져야 하는 이유입니다. 아이디어가 실제로 재미있을지 없을지 알아보는 방법은 실제로 간단하게나마라도 만들어보는 것입니다. 실제론 재미가 없는데도 이 아이디어를 밀고 나가는 경우가 있습니다. 집적 만들어보고 더 재미있는 방향으로 변경해 나가는 것이 좋습니다. 

디테일 작업 간과하기

어떤 아이디어의 로직과 그래픽을 모두 만들었다고 해서 끝이 아닙니다. 플레이어의 행동에 반응하는 인터페이스 애니메이션이라던지, 플레이어가 피격당했을 때 생기는 카메라 이펙트 등등 게임을 더욱더 재미있게 만들어 주는 디테일한 요소들이 있습니다. 게임 개발시간의 50%는 사실 이 디테일 작업에 할애되어야 한다는 말도 있습니다. 게임을 빨리 사람들에게 공개하고 반응을 보고 싶은 마음은 알지만 이 과정을 스킵한다면 사람들의 이목을 끌지 못할 수 있습니다. "게임 개발 시간일 길어지는 것은 좋은 결과를 가져올 수 있지만, 서두르는 것은 항상 나쁜 결과를 가져온다."

너무 많은 기능 넣기

여러 게임을 하면서 "이 기능이 내 게임에 있으면 좋을 것 같은데?", "이 아이디어도 재밌다!" 등등 이런 생각으로 무아지경으로 내 게임에 어울리지도 않는 것들을 집어넣을 때가 있습니다. 아무리 따로 떼어놓았을 때 재미있는 것도 전체적으로 보면 오히려 재미를 떨어뜨리는 경우가 있습니다. 

Reference

Planning Your First Video Game

What is Agile Project Management (APM)? | Definition from TechTarget