마지막 수정일 : 2021년 12월 19일 일요일

인과율 개발 포스트 모템

- 개발자 코멘터리 -

작성자 : Creta Park, WAFFLE, Giventicket

인과율이 오랜 공백을 깨고 드디어 출시가 됐습니다.
이후에 많은 패치를 위해 바쁜 시간을 보내다가 여유가 생기고, 개발팀이 모여 함께 포스트 모템 글을 쓰게 됐네요...
그간 있었던 저희 인과율 개발팀의 경험을 정리해보려고 합니다.

목차

1. 소개

인과율은 술래잡기의 순수한 경험을 서바이벌 호러로 각색한 공포 게임입니다.
현재 Steam 에서 판매 중이며, 한국어, 영어, 일본어로 출시되었습니다.
작성한 시기 기준으로, 차후에 모바일 버전도 제공될 예정입니다.

1.1. 개발 초기

인과율은 본래 이 다음 프로젝트를 제작하기 전 팀의 역량을 체크하고 개발 경험을 쌓기 위해 기획했던 작은 프로젝트였습니다.
그러나 제대로 만들어 보자는 생각이 들어 게임에 살을 붙이고 규모가 커지게 되면서 지금의 인과율이 탄생하게 되었습니다.

1.2. 게임의 특징

인과율은 기존의 전통적인 RPG Maker로 제작된 공포 게임들이 가지는 게임플레이 경험 중, 다소 부족하다고 느꼈던 추격전 의 경험을 극대화하기 위해 추격전을 중심으로 게임을 제작하고 여러 실험적인 기믹을 적용하였습니다.

플레이어는 이러한 귀신의 추격과 변화하는 상황 속에서 생존하고 학교에 갇힌 3명의 학생들을 무사히 구해내야 합니다.

2. 프로젝트 정보

2.1. 게임 엔진

인과율은 RPG Maker MV 로 제작되었습니다.
이런 결정을 하게 된 이유는, 개발 초기 당시에 프로그래머의 부재로 인해서였죠.

실제로 프로그래밍을 담당하셨던 Creta Park님은 산업기능요원을 마무리 하기 전까지 개발에 참여하지 못했었습니다.
그래서 저희는 선택의 요지가 충분하지 않았었기 때문에 RPG Maker MV를 사용하게 됐습니다.

2.2. 개발 기간

인과율이 본격적으로 기획되고 개발되기 시작한 것은 2019년 말부터였습니다.

본래 2020년 12월에 출시하고자 하였으나, 후술할 일정 문제로 인해 연기되어 2021년 4월 16일에 출시됐습니다.

2.3. 개발팀 규모

인과율의 개발팀은 총 3명입니다.

인디게임 개발 특성 상, 크게 역할은 서로에게 피드백을 주고받는 과정이 많았기 때문에 특정할 수는 없지만, 크게 보면 아래와 같은 역할로 구성되었습니다.

^{* 이름을 클릭해서 개인 페이지를 확인해보세요!}

• WAFFLE : 기획, 연출 및 그래픽 디자인

  반갑습니다. 게임 개발과 드로잉이 좋은 와플게임즈 대표 와플입니다.

  과거 만화와 애니메이션을 전공했고, 현재는 인디 게임을 개발 스튜디오인 와플게임즈를 운영하고 있습니다.

• Creta Park : 게임 디자인, 테크 디렉션, 네트워크 개발

  안녕하세요, 저는 게임을 만드는 것을 좋아하는 프로그래머 크레타입니다.

  어린 시절에 플래시 ActionScript로 프로그래밍을 처음 시작했으며,
  현재는 C#(.NET)을 필두로 유니티를 사용해 White Spirit이라는 게임을 개발하고 있습니다.

• Giventicket : 작곡

  안녕하세요. 게임 음악을 작곡하는 기븐티켓입니다.

  고등학교에서 국악 작곡을 전공하고 있습니다.

3. 잘된 점

3.1. RPG Maker 게임의 전통적인 문법에서 벗어난 시도

개발이 시작되기 전, 저희는 세상에 술래잡기 챔피언십이라는 대회가 있음을 알게 됐습니다.
여기에 영감을 얻게 되고, RPG Maker 게임들의 쫓기는 게임을 넘어서 좀 더 입체적인 형태로 보강하기 위해 여기에 해당하는 테마를 합치게 되었습니다.

귀신은 플레이어를 단순히 쫓아오는 것을 넘어 탐색, 추적, 포기라는 세가지 패턴을 두고, 여기에 소리에 민감하거나 사물을 뛰어 넘는 등 귀신마다 고유한 행동들을 추가하여 각자의 개성을 부여하였습니다.

폴터가이스트 현상은 맵에 임의적으로 극적인 변화를 주어 플레이어가 예측할 수 없는 변수를 만들고, 플레이어로 하여금 상황마다 새로운 전략을 세우도록 기획했습니다.

3.2. 아트와 작곡가, 그리고 프로그래머가 함께하는 연출 기획

종합 문화 컨텐츠라고 말해도 될 정도로, 비디오 게임을 만들기 위해서는 정말 다양한 분야의 기술을 요구합니다.
다행히도, 개발에 사용한 RPG Maker의 버전은 내부적인 코드까지 고쳐 쓸 수 있을 정도로 열린 상태였기 때문에 연출적인 면으로도 많은 시도를 할 수 있었죠.

요소들의 움직이는 동작, 포스트 프로세싱, 유동적인 카메라, 적응형 음악과 같은 연출을 위해 수많은 코드들을 수정하고 추가하는 작업들을 진행했습니다.

적응형 음악을 표현할 수 있는 덕분에 음악의 흐름이 끊기지 않고 계속해서 분위기가 변화하는 것을 표현할 수 있었고, 또한, 화면에 효과를 주는 포스트 프로세싱 덕분에 시각적인 표현에도 큰 힘이 되어 좋은 연출들을 많이 만들 수 있었습니다.

3.3. 유연한 현지화 기능 제공

게임의 내용을 수정하지 않고도 외부 파일을 통해 현지화를 할 수 있도록 확장 기능을 개발했습니다.
RPG Maker 프로그램의 특성 상, 프로젝트를 수정하지 않고 현지화를 하는 방식은 꽤 효과적이였죠.

워크플로우는 게임에서 텍스트를 데이터로 추출해 csv로 바꾼 다음, 번역 작업을 마친 후, 다시 데이터로 되가져와 게임 폴더 안에 놓기만 하면 끝났습니다.

이렇게 현지화 하기가 간단하도록 개발한 덕분에, 실제로 출시 직전에 도착한 일본어와 영어 번역본을 게임에 적용하고 검수하기까지 단 2일이 걸렸죠.

여기에 리소스 또한 언어별로 지정할 수 있었기 때문에 지역 별로 높은 수준의 현지화 퀄리티를 제공할 수 있었습니다.

3.4. 빠른 프로덕션 제공을 위한 빌드 자동화

RPG Maker MV에는 배포 기능을 제공해주고 있습니다.
여기에서 나오는 파일들을 압축해 다른 사람에게 보내면 바로 플레이가 가능한 구조였죠.

하지만, 실제로 배포된 파일에는 내부 데이터가 텍스트 편집기로 열기만 해도 볼 수 있을 지경으로 노출이 된 형태인데다가, 개발 단계에서만 쓰여야 할 기능들이 프로덕션에 함께 포함되서 만들어지는 문제점이 있었습니다.

Creta Park님이 이를 해결하기 위해 .NET 5를 이용해 내부 개발 데이터는 숨기고 읽기 힘들도록 프로덕션에 실제로 보낼 게임을 만들 파이프라인을 개발했습니다.

이후에 스팀 API, 포스트 프로세싱 셰이더 코드 압축 등의 처리를 포함하는 등의 기능이 부가적으로 추가되었습니다.

프로덕션을 위한 파이프라인 프로그램을 개발한 덕분에, 게임의 문제점을 수정한 후, 바로 프로덕션에 보내는 데에 큰 역할을 하고 있습니다.

3.5. 성공적인 스팀 출시

Steam의 기능과 게임을 연동하기 위해 게임 내의 변수를 감시(Observing)해 업적의 달성 여부를 처리하는 기능도 개발하게 됐습니다.

다만, 모바일 플랫폼에서도 동일시하게 개발하고자 했기 때문에, 데이터를 감시하는 기능과 업적 달성 여부를 처리하는 기능은 서로 분리했으며, 스팀 버전에는 스팀 API와 연동되는 기능을 넣고, 모바일에서는 구글 플레이 게임 API와 연동되도록 유연하게 만들었습니다.

^{스팀 개발자 콘솔에서 볼 수 있는 빌드 목록과 게임 내에 표기되는 버전, 설명에 git 해시값을 달아 버전 추적이 가능하도록 했다.}

그리고 빌드된 게임은 우측 하단에 빌드된 당시의 git 해시값을 표시하도록 했습니다.
여기에 더해 파이프라인 프로그램의 도움을 통해 게임에 치명적인 버그를 발견했을 시, 발빠른 패치가 가능해졌죠.

덕분에 큰 문제없이 작성일 기준으로 한국지역 Steam에서 인기 출시 게임 차트에 오른 상태입니다.

4. 잘 되지 않은 점

4.1. 일정 관리

^{@Chris McCormick - this is the way}

인과율은 본래 2020년 12월 출시를 목표로 제작했습니다.
그러나 1년 정도의 짧은 개발 기간과 개발하면서 필요로 하게 된 새로운 기능의 추가와 수정으로 인해 게임을 완성하는 데 있어서 더 많은 시간이 필요해졌고, 여기에 코로나 바이러스의 발생으로 인한 악재가 겹쳐 원래 구상했던 퀄리티의 게임을 만들어 내기 위해 결과적으로 기존 대비 1.5배가 넘는 시간이 필요하게 되었습니다.

결국 기존에 발표했던 12월 출시를 번복하고 3월 출시로 미루게 되었으나, 이마저도 개발 외의 부가적인 업무로 인해 4월 16일에 출시하는 것으로 또 한번 연기를 하게 되었습니다.

4.2. 엔진의 한계로 인한 매몰 비용 증가

RPG Maker 프로그램은 게임을 너무 쉽게 만들 수 있는 만큼, 한계도 굉장히 명확했습니다.

RPG Maker 프로그램이 모바일 플랫폼에서도 원활하게 동작한다고 소개되어 있었으나, WebGL에서 동작하는 게임임에도 불구하고 UI에 무수히 많은 동적 텍스쳐를 사용하는 등 최적화의 상태가 좋지 않았습니다.
무려 메뉴를 열었다 닫았다를 반복하는 것만으로도 iOS에서는 버티지 못하고 크래시가 나는 등의 문제 ^GitHub 가 있을 정도였죠.

인과율은 처음부터 모바일 플랫폼을 상정하고 개발을 시작했지만, 상기한 기술적인 문제가 많은 상황에 더해 시간이 없었기 때문에 극단적으로 낮은 해상도를 사용하게 되었습니다.

^{실제 게임의 해상도, 가로 320픽셀, 세로 180픽셀이다.}

해상도를 낮춤으로서 모바일에서도 어느정도의 동작을 보장할 수 있게 되었습니다.
하지만 그에 대한 대가로서 또다른 문제에 직면하게 됐죠.

• 낮은 해상도에서 표현되는 흐린 글자

  
  ^{원래 의도(좌)와 모바일에서 표현되는 글자(우, 예시)의 모습.}

  모바일 플랫폼을 지원해야 하는데, 트루타입 폰트로 렌더링하는 RPG Maker MV 특성 상 당연하게도 모바일에서 흐려진 글자가 표시되는 문제가 발생했습니다.

  
  ^{[RPG MV] L10nMV.js all features workflow test}

  저희는 이를 해결하기 위해 비트맵 폰트를 표시할 수 있는 기능을 개발했고, 대다수 비트맵 폰트의 라이센스 문제를 피하기 위해 한글 조합 특성을 이용해 게임에 사용할 수 있는 폰트 개발 도구 ^GitHub를 만들기도 했죠.

• 해상도가 바뀌어 디자인을 바꿔야 했던 수많은 기존의 UI들

  
  ^{네이티브 해상도를 줄인 직후의 모습}

  RPG Maker MV의 기본 해상도는 가로 816픽셀, 세로 624픽셀 이며, 게임의 UI 역시 해당 해상도를 기준으로 제작됐습니다.

  인과율은 극단적으로 낮은 해상도를 채택하면서 RPG Maker MV가 제공하는 UI 레이아웃을 정상적으로 표시할 수 없었고, 이를 해결하기 위해 UI 시스템 전체를 재구성해야 했습니다.

• 극단적으로 제한된 시야 범위

  
  ^{실제로 보이는 타일의 영역이 기존보다 무척 좁은 모습을 보여준다.}

  해상도가 낮아지면서 한 화면에서 보이는 시야 또한 극단적으로 ^{(가로 11칸, 세로 7칸)} 줄어들게 됐습니다.
  저희는 이를 해결하기 위해 유동적인 카메라 시스템을 만들어야 했죠.
  다행히도, 유동적인 카메라 시스템은 충분히 연출용도로써도 활용가치가 높았기 때문에 특정 요소에 가까우면 한 화면에 담아내기 위한 카메라 워크 등의 표현을 할 수 있었습니다.

• 보호되지 않는 게임 데이터

  이 문제는 상술했던 빠른 프로덕션 제공을 위한 빌드 자동화 항목에서도 언급했듯이...

  실제로 배포된 파일에는 내부 데이터가 텍스트 편집기로 열기만 해도 볼 수 있을 지경으로 노출이 된 형태인데다가, 개발 단계에서만 쓰여야 할 기능들이 프로덕션에 함께 포함되서 만들어지는 문제점이 있었습니다.

  그래서 저희는 이 문제 또한 해결하기 위해 프로덕션 파이프라인 프로그램이 게임의 데이터들을 한번 더 숨기도록 만들어야 했었죠.

4.3. 오래 생각해야 하는 퍼즐, 그렇지 않게 만드는 귀신들

인과율의 각 파트 대부분은 추리를 요구하는 퍼즐로 구성되어 있습니다.
그러나 일부 퍼즐들은 플레이어들이 오랜 시간동안 찾고 파악하며 풀어야 하지만, 귀신이 이러한 텀을 방해하면서 플레이가 늘어지는 현상이 발생했습니다.

특히 퍼즐을 풀기 위한 키 아이템들의 대다수가 맵의 모든 면을 조사하지 않으면 찾을 수 없었기 때문에, 이러한 상황에서 귀신이 끊임없이 괴롭히는 상황이 벌어졌죠.
오히려 그림자 복도, 아웃라스트와 같이 눈에 보이고 쉽게 진행할 수 있도록 1차원적인 수준의 퍼즐을 설계하는 것이 낫지 않았을까 합니다.

이로 인해 저희는 출시 이후 이러한 퍼즐에 대해 난이도를 낮추는 패치를 작업해야 했습니다.

4.4. 부족했던 QA 작업

대부분의 QA 작업은 주변 지인과 같이 한정된 인원으로 진행됐습니다.
이로 인해 출시 이후에도 미처 파악하지 못한 문제점이 산재했고 게임의 내용, 퍼즐, 연출, 스토리에 대해 보다 다양한 피드백을 받지 못했습니다.

4.5. 체계화되지 않은 기획

개발 초기 인과율은 기획이 빈약한 상황에서 시작되었습니다.
학교의 층을 각 스테이지로 구분한 뒤, 한 스테이지에 대한 기획이 모두 완료되면 이를 개발하고, 개발이 완료되면 그 다음 스테이지에 대한 내용을 기획했습니다.

이 과정에서 리뷰를 통하여 특정 스테이지나 파트에 대한 결함이 확인될 경우 이를 수정하는 작업까지 혼재했습니다.
결국, 체계화되지 않은 기획이 결과적으로 개발 과정에 혼선을 야기했죠.

시간이 부족해지는 개발 후기로 갈수록 특정 스테이지의 진행 흐름을 지루하게 만들어버린 실수는 물론, 문제를 수습하기 위해 귀중한 시간을 허비하게 되는 결과를 초래했습니다.

5. 결론

인과율은 그간 1인 개발에서 벗어난, 와플게임즈의 첫 팀 단위 개발 프로젝트였습니다.
1인 개발과는 또 다른 유형의 장점과 단점들이 있었고, 팀원 모두에게 소중한 경험을 만들어 줬습니다.
또 앞으로 다른 게임을 만들고자 할 땐 어떻게 해야 하는지, 어떤 실수를 하지 말아야 하는지 많은 교훈을 주기도 했습니다.

저희 개발팀은 각자의 위치에서 서로 교류하며 좋은 결과물을 낼 수 있도록 많은 노력을 기울였습니다.
그렇게 인과율은 역량을 체크하기 위한 작은 프로젝트에서부터, 개발팀의 열정을 쏟아낸 자랑스러운 대표작이 되었습니다.

인과율을 즐겨주시는 여러분께 모두 플레이 해주셔서 감사합니다!