정명 ~ Borderless ~ 게임 개발을 하며.

2024년 9월 9일 현재, 1년동안 출시 준비를 해왔던 퍼즐, 슈팅 게임인 정명(定命) ~Borderless~의 제작을 완성했고, 테스트 또한 끝마쳐 현재 심의 검수에 들어간 상태이다. 2023년 6월부터 2024년 9월까지. 1년 3개월, 15개월이라는 긴 시간동안 고생한 나에게, 그리고 같이 제작해준 팀원 HJH에게 감사를 먼저 표한다.

<정명(定命) ~Borderless~>

나는 서브컬쳐가 인생이다. 초등학교 저학년 시절부터 애니와 만화를 봤으며, 사실 그것도 기억나는 시점에서나 그렇지··· 그 이전, 유치원 시절부터 만화나 애니를 즐겨왔던 것도 같다. 동시에 중학교 시절부터는 여러 행사나, 정말 열렬히 각종 장르들을 좋아해왔으며.

소비자가 창작자가 되는 과정이 으레 그렇듯이, 나도 이런 걸 만들어보고 싶다! 라는 생각에서 시작된 것 같다. 또, 공교롭다면 공교로운 거고 어떻게 보면 필연이라면 필연이라고도 할 수 있는데 내가 프로그래밍을 하는 것도 그에 대한 의욕을 더더욱 부추겼던 것 같다.

다만, 문제가 하나 있었다.

어떻게 의기투합한 팀원 한 명을 구하긴 했으나. 둘 다 프로그래밍만 해보았지··· 게임을 출시할 때 들어가는 아트, 음악, 도트(우리 게임은 도트게임이다.), 기획, 스토리에 관한 경험이 거의 없었다. 물론 내가 이전에 소설을 집필해보았고, 어느정도 성공을 거두었던 전적(기대했던 것보다는 그랬다.)이 있기도 하고, 나름대로 구상해두었던 것도 있어서 괜찮았다. 같이 하는 친구도 나름대로 자신의 세계관을 가지고 있기도 했고.

다만, 아트와 음악. 그리고 도트에 관련해서는 정말 답이 없었다. 외주를 구하는 건 자금사정상 불가능하고, 애초에 우리가 좋아하는 게임을 만드는데 그런 걸 바라지도 않았다. 그래서 결국 우리가 다 하기로 했다. 나는 보스 및 시스템 프로그래밍, 그림, 음악, 스토리를 맡았고, 팀원인 HJH은 필드 및 퍼즐 기믹 프로그래밍, 도트, 음악을 맡았다.

진짜 막막하고, 어떻게 해야하는 지 모르겠지만. 진짜 말 그대로 박치기 했다.

그림은 몇 번 그려본 적이 있긴 해도, 이게 그림인가 싶었나 할 정도였으며. 음악이라곤 10살 즈음 피아노를 치긴 했지만 다 까먹어서 장조 단조도 모르는 상태였다. 친구도 거의 그 수준에서 벗어나지 않아서, 진짜 우리는 말 그대로 헤딩을 했다.

그냥 그리고 만들었다. 당연히 결과가 좋을리가 없고, 우리도 그걸 예상하고 있었다. 또 그리고 만들었다. 조금 더 좋아지고, 여전히 만족스럽지 못했다.

그래서 유튜브를 보았다. 수많은 참고 자료와 여러 강의 자료들을 찾아보고 또 나름대로 공부를 하고 또 연구했다.

게임에 들어가는 수십 개의 그림, 수십 개의 음악을 만들면서 프로그래밍을 하고, 기획 회의를 하면서 또 수정사항이나 버그를 고치는 일은 정말 만만치 않았다.

메인화면? 게임을 키면 로고가 띄워진 이후 가장 먼저 보이는 화면이다. 두 주인공인 키나시와 모로사가 보이며 중앙에 이번 작품의 가장 메인인 월목이 보인다.

비록 인디이라는 걸 감안해도, 내 스스로 아쉬운 점이 없는 메인화면은 아니지만 그래도 나름대로 제작 당시엔 급히 일정에 쫒겨가며 만든 것 치고는 만족스러운 디자인이라고 생각되었다. 물론 지금도 이 이상 더 퀄리티를 뽑아내려면, 내 실력으로는 더 많은 고심과 노력이 필요하겠지만.

그래도 이번 작품인 정명(定命) ~Borderless~로서 생각한 의미가 드러나는 작품이라고 생각하면 마음에 든다.

간단히 작품을 소개해보자면, 필드에서는 퍼즐. 그리고 보스전에서는 슈팅 게임 요소를 섞은 게임이라고 보면 된다. 난이도는 일반인 기준으로 한 번에 깨기는 어렵겠지만, 몇 번 익숙해지면 충분히 깰 수 있는 난이도라고 생각이 든다.

필드전. 필드의 간단한 조작. 그리고 대화 시스템은 내가 구현하였지만, 이외의 도트나 맵 기믹 설계, 레벨 디자인은 팀원인 HJH이 도맡아서 전부 다 해주었다. 많은 기획안을 만들고, 수많은 생각을 해온 결과 내 스스로 생각하기에 꽤 재미있고 마음에 드는 기믹이 나온 것 같으며, 또 난이도 조절또한 그렇게 어렵지 않게 나왔다고 생각한다.

모두 ‘기믹의 파훼법’을 알게 되면 쉽게 풀 수 있는 것이며, 파훼법을 알아내는 것 또한 그리 어렵지 않게 설계했다. 필드 하나는 늦어도 5~10분 안에 깰 수 있도록 설계했다. 테스트 하는 도중 테스터들이 고민을 하는 모습이 꽤 재미있어서, 몇 번이고 새로운 테스터들에게 시켜보곤 한 기억이 난다.

다만 기술적으로 문제가 있긴 했는데, 처음 기획상으로. 그리고 개발 중간단계 까지만 해도 해상도가 1800x900으로 설정이 되었는데, 유니티 자체의 버그인지는 모르겠지만 도트가 깨져 나오는 에러가 있었다. 그걸 고치는 여러가지 방안이 있었는데, 결국 최종적으로 선택한 것은 FHD(1920 x 1080)해상도로 변경하는 작업을 해주었다. 그렇지 않으면 여러가지 그래픽상 에러가 나기 때문이었다.

물론 지금도 간헐적으로 그래픽 이슈가 있긴 하지만, 거의 나지 않기도 하고… 왜 나는 건지 알 수가 없어서 여러모로 곤란한 상황이다. 여튼, 해상도를 개발 중간에 바꾸는 작업때문에 UI나 여러가지 도트가 여러 설정들을 갈아 엎는 바람에 1주를 허비한 기억이 난다.

아무튼 당당히 게임의 주요 요소 중 하나! 라고 말할 만큼 많은 노력을 들였으니, 게임을 해주시는 분들이 많이 흥미로워 해주셨으면 좋겠다.

전투. 즉 보스전이다. 내가 직접 모든 부분을 프로그래밍하고 만들었으니만큼 정말 많은 노력을 들였고, 그에 대한 기교나 최적화에 대해 많은 공부가 된 파트이다. 기본적으로 일반적인 비행 슈팅 게임(탄막 슈팅)의 틀을 가지고 있으나, 마냥 탄막 슈팅은 아니고 미니게임적인 요소를 조금 넣어서 보스 전이 마냥 단조로워지지 않게끔 했다.

5면까진 퍼펙트로 진행을 하였는데, 6면은 퍼펙트로 깰 수가 없었다는 게 패턴 제작자로서 조금 부끄러운 일일지도 모르겠지만… 아무튼 내가 깼으니까 상관없는 것 같다.

일반 패턴들은 기믹이 단순하거나, 한 번에 움직이는 오브젝트가 수십 개에 불과하지만, 몇몇 개의 패턴은 한 번에 움직이는 오브젝트가 수백 개 이상이 될 때도 있으므로 C#으로 움직이는 유니티 상에서는 최적화 이슈가 있을 수 있다. 특히 고사양 컴퓨터를 대상으로 하는 게 아니라, 가벼운. 누구나 즐길 수 있는 사양으로 출시하는 우리에게는 혹시나 모를 최적화 이슈를 염려해야만 했다.

그래서 나름대로 최적화에 많은 신경을 썼다. 고수 분들에겐 아무것도 아닐지 모르겠지만…

일단 나중에 제대로 포스트 할 수도 있지만 간단히 읊어 내려가면…

첫 번째로 오브젝트 풀링을 한다. 패턴이 실행되고, 패턴이 끝날 때마다 수백 개 이상의 오브젝트들을 일일히 생성하고 Destroy해주는 것이 아니라, 단순히 활성화 비활성화만 해둔다. 씬 상에서 미리 생성해 두어서, 소모되는 자원이 큰 생성과 삭제를 최소화 한다.

두 번째로 매니저를 두어서 관리한다. 이 말이 무슨 말이냐면, 수백 개의 오브젝트마다 전부 다 스크립트를 두는 게 아니라, 그 수백 개의 오브젝트를 한 번에 관리하는 패턴 매니저를 두어서 거기서 한 번에 움직임을 관리한다. 당연히 유니티 내부 상에서 수많은 스크립트를 돌아다니는 것보다, 한 스크립트 내부에서(코루틴이던 Update던) 전부 처리하는 편이 속도가 빨라지므로 이 또한 최적화에 필수적인 요소라고 생각하였다.

세 번째로 코루틴을 최소화한다. 코루틴은 생성할 때마다 가비지를 생성한다. 생성과 삭제는 꽤 비싼 작업이다. 그러니 당연하게 그걸 최소화 해야한다. 대부분의 패턴들은 한 번 패턴을 진행 할 때 많아봤자 3개의 코루틴 내부에서만 돌아간다. 수십 초의 패턴이 진행되고, 수백 개의 오브젝트를 움직이는 동안 3개 이하의 코루틴만 사용하여 최대한 가비지의 생성과 삭제를 최소화 하였다.

또 곁다리 팁이라면…

yield return new WaitForSecond(1.0f); 

이거였나? 아무튼 지금 당장 써서 맞는진 모르겠는데. 한 코루틴 내부에서 주기적으로 잠시 멈춰야 할 때 저 코드를 쓰는 건 옳지 않다.

차라리

var wait1Second = new WaitForSecond(1.0f);

이렇게 미리 선언 해둔 뒤에,

yield return wait1Second; 

이렇게 하면 불필요한 가비지가 생성되는 걸 최대한 막을 수 있다.

그 이외에도 쉐이더 쪽이나, UI 최적화, 텍스쳐 최적화. 그리고 효과음 재생(Manager 사용. 그리고 내부적인 코드 최적화), 대화 시스템(csv파일 사용)가 있으나 가장 핵심적으로 시간을 줄였던 기본 설계는 저 3가지 기법이라고 생각이 되었다.

저 3가지 연구를 하며, 정말 많이 배웠고. 정말 많이 공부를 하였으며… 또 수많은 개발자들이 존경스럽다고도 생각이 되었다.

##정명 개발에 대한 간단한 포스트를 마치며.

힘들었다. 프로그래밍, 아트, 기획, 스토리 등등… 기존에 했던 일도 있고, 처음 배우는 일도 있었다. 그리고 정말 힘들었다.

1년동안 하루도 안 바쁜 날이 없었고, 학교 공부를 하고 가끔 대외 활동을 하는 날에도 새벽에 집에 돌아와서 그림을 그리고, 프로그래밍을 하고, 음악을 만들었다.

그리고 즐거웠다. 개발이 즐거웠고, 그림이 즐거웠고, 음악이 즐거웠다. 게임 개발을 하는 것이 너무 즐거웠다. 늘 게임 개발을 하면서 느끼는 것이지만, 상상에 불과했던 것에 뼈대를 세우고 근육을 만들며, 살점을 붙여나가는 그 과정에 재미있고. 내가 만든 아이가 온전히 움직이고 활동하는 것에 감격하지 않을수가 없었다.

Hobby 카테고리 내 다른 글 보러가기