프로젝트 산중호걸, 지금까지의 개발 이야기
프로젝트 산중호걸을 개발하기 시작한 지도 꽤 오랜 시간이 지났다.
그동안 개발일지를 계속 작성해왔지만, 대부분은 그때그때 무엇을 만들었고 무엇을 고쳤는지를 기록한 글이었다.
시간이 많이 지난 지금, 처음에는 어떤 생각으로 이 게임을 만들기 시작했고, 무엇을 몰랐고, 무엇을 실패했고, 어떻게 지금의 모습까지 오게 되었는지를 한 번쯤 정리해보고 싶었다.
그래서 처음부터 한번 돌아보려고 한다.
처음의 산중호걸
게임 개발자가 되고 싶었지만, 부산에서 게임 회사에 들어가는 것은 생각보다 정말 어려웠다.
특히 유니티도 아닌 언리얼 엔진을 사용하는 곳은 거의 없다시피 했다.
결국 언리얼 엔진을 이용해 디지털 트윈을 개발하는 회사에 들어가게 됐다.
하지만 입사한 지 1년도 지나지 않아 회사 운영이 어려워졌다.
대부분의 직원이 회사를 떠났고, 월급도 밀리기 시작했다. 나도 그중 한 명이었다.
사람들이 빠져나간 넓은 사무실에 혼자 앉아 있기도 했고, 회사가 어려워지면서 이전한 더 좁고 열악한 사무실에 앉아 있기도 했다.
그럴 때마다 내가 점점 초라해져 가는 것 같은 기분이 들었다.
그러던 즈음, 우연히 아주 멋진 백호 수인 캐릭터 그림 한 장을 보게 됐다.
그 그림을 보면서 문득 생각했다.
이 친구가 게임 안에서 살아 움직이는 모습을 보고 싶다.
프로젝트 산중호걸은 거기서 시작됐다.
장르는 자연스럽게 내가 가장 좋아하던 소울라이크가 됐다.
게임 기획이라는 것도 처음 해보기 시작했다.
지금 다시 보면 당연히 수준 높은 기획은 아니었다.
그리고 온라인에서 함께 게임을 만들 사람들을 구하기 시작했다.
그때는 여러 사람이 모이면 기술적으로 어려운 문제가 생겨도 각자 잘하는 것을 나누면서 금방 해결해 나갈 수 있을 거라고 생각했다.
무엇보다 내가 머릿속으로 그리고 있는 것들이 다른 팀원들의 머릿속에도 어느 정도는 당연히 있을 거라고 생각했다.
지금 생각하면 꽤 어리석은 생각이었다.
팀원을 구하는 것 자체는 어렵지 않았다.
학생도 있었고, 취업 준비생도 있었고, 직장인도 있었다.
문제는 그다음이었다.
합류했던 사람들 대부분은 일주일을 넘기지 못하고 사라졌다.
어느 순간부터 메시지를 보내도 답이 오지 않았다.
물론 모두가 그랬던 것은 아니다.
실제로 개발에 도움이 되어준 기획자나 프로그래머도 있었다. 하지만 그들도 몇 달 정도가 지나면 연락이 끊기곤 했다.
새로운 사람을 모집하고, 개발 환경을 설명하고, 프로젝트를 공유하고, 다시 적응을 도와주고.
그리고 얼마 지나지 않아 다시 연락이 끊기고.
그 과정이 반복될 때마다 시간도 시간이지만 감정적으로도 꽤 많이 소모됐다.
그러다 어느 순간부터는 팀원을 구하는 것 자체에 점점 지쳐갔다.
그냥 내가 만들기 시작했다.
이런 일이 계속 반복되다 보니, 어느 순간부터는 새로운 팀원이 들어와도 마냥 반갑지만은 않았다.
새 사람이 합류하면 지인들에게 농담처럼 이런 말을 하곤 했다.
“이번에는 얼마나 있다 가려나? 일주일?”
실제로 일주일을 넘기지 못하는 경우가 많았다.
처음에는 새로운 사람이 들어올 때마다 개발 환경을 설명하고, 프로젝트를 공유하고, 작업 방법을 알려줬다. 하지만 그렇게 시간을 들인 뒤 얼마 지나지 않아 연락이 끊기는 일이 반복됐다.
그러다 보니 어느 순간부터는 새로운 사람을 위한 준비에 많은 시간을 쓰는 것 자체가 부담스러워졌다.
있는 것으로 만들기
혼자 만든다는 것은 단순히 작업량이 많다는 것만을 의미하지 않았다.
게임에 사용할 리소스를 만들어줄 사람도 없었다.
모델링을 새로 만들 수도 없었고, 게임에 필요한 모든 배경과 오브젝트를 원하는 대로 제작할 수도 없었다.
결국 이미 가지고 있거나 구할 수 있는 리소스를 어떻게든 활용해서 게임을 만들어야 했다.
그러다 보니 서로 전혀 다른 분위기의 리소스를 하나의 게임 안에 집어넣어야 하는 상황이 생겼다.
숲도 쓰고 싶고, 사막도 쓰고 싶었다.
전혀 다른 시대와 장소의 리소스도 사용해야 했다.
그렇다면 애초에 서로 다른 시간과 공간이 뒤섞인 세계로 만들면 되지 않을까?
그렇게 세계의 시간과 공간이 뒤섞여 있다는 설정이 만들어졌다.
처음부터 거대한 세계관을 먼저 만들고 거기에 맞춰 게임을 제작했던 것은 아니었다.
오히려 혼자 개발하면서 마주한 현실적인 제약을 어떻게든 게임의 설정으로 설명하려고 고민하다 보니 지금의 세계관이 만들어지기 시작했다.
- 정말 극 초기 개발 상태, 아직 캐릭터도 없고 그냥 손 가는대로 만들었었다.
- 초기의, 태백의 모델링이 추가되고나서 머지 않아 만든 거점
- 초기의, 산길에서 묘지로 넘어가는 부분, 그 당시에는 중간장소를 거치지 않고, 그냥 이동했다.
레벨 디자인도 마찬가지였다.
그전까지 제대로 된 레벨 디자인을 해본 경험이 없었다.
직장에서도 주로 내부 시스템과 기능을 구현하는 일을 했고, 공간을 구성한다고 해도 작은 규모에 그쳤다.
플레이어가 오랫동안 탐험할 넓은 필드를 만들고, 길을 유도하고, 전투 공간과 휴식 공간을 배치하고, 숏컷을 만들면서 지역 전체를 설계해본 적은 없었다.
그래서 초기의 산중호걸은 레벨 디자인을 공부한 뒤 만든 게임이라기보다, 게임을 만들면서 레벨 디자인을 처음 배워나간 게임에 가까웠다.
당연히 시행착오도 많았다.
맵은 필요 이상으로 커졌고, 공간을 어떻게 채워야 하는지도 잘 몰랐다.
멋있어 보이는 지형을 만드는 것과 실제로 플레이했을 때 재미있는 공간을 만드는 것이 전혀 다른 문제라는 것도 나중에야 알게 됐다.
- 초기의 시작지점, 폭포 아래 시작이라는 점은 같다.
- 산길에서 묘지로 넘어가는 포탈
- 한번 갈아엎은 묘지구역
- 이때의 거점이 1차적으로 자리잡았다.
그림 속 백호가 움직이기 시작했다
개발을 계속하는 동안에도 옛날에 올려둔 팀원 모집글을 보고 가끔 한두 명씩 프로젝트에 합류하곤 했다.
하지만 대부분 오래가지는 못했다.
그래도 그때까지는 괜찮았다.
회사를 그만둔 지 얼마 지나지 않았고 실업급여 조건이 충족되어 있었기 때문에, 당장 생활비를 걱정하지 않고 개발을 계속할 수 있었다.
그렇게 시간은 계속 흘렀다.
하지만 정작 가장 중요한 것이 없었다.
메인 캐릭터의 모델링이었다.
프로젝트를 시작하게 만든 백호 캐릭터의 그림은 있었지만, 게임 안에서 실제로 움직일 모델은 없었다.
결국 큰마음을 먹고 적지 않은 돈을 들여 모델링 외주를 맡겼다.
당시에는 아직 산중호걸의 그래픽 스타일조차 제대로 정해지지 않은 상태였다.
무엇보다 모델링은 내가 잘 아는 분야가 아니었다.
회사에서도 모델링은 담당자가 따로 있었고, 프로그래머였던 내가 그 과정에 깊게 관여할 일은 거의 없었다.
좋은 모델링이 무엇인지 판단할 수 있는 눈도 없었다.
결국 모델러를 믿고 맡기는 수밖에 없었다.
그리고 완성된 모델을 처음 게임에 넣었을 때는 정말 기뻤다.
그림으로만 존재하던 캐릭터가 진짜로 움직이기 시작했다.
- 첫 태백의 모델링
조금 더 살아 있는 캐릭터처럼 보이게 하고 싶었다.
백호였으니 털이 실제 털처럼 보였으면 했다.
그래서 gFur 플러그인을 이용해 물리가 적용되는 털을 캐릭터에 붙였다.
그렇게 지금의 메인 캐릭터인 태백이 만들어지기 시작했다.
- 실제로 물리가 적용되는 털이 붙었다!
하지만 동시에 현실적인 문제도 알게 됐다.
캐릭터 하나를 제대로 만드는 데 생각보다 많은 돈이 필요했다.
처음에는 다른 캐릭터들도 차례대로 게임에 넣고 싶었다.
하지만 모든 캐릭터를 이런 방식으로 제작하려면 상당한 비용이 필요했다.
당시에는 실업급여 외에 별도의 수입이 없었기 때문에 부담은 더 컸다.
그래서 나머지는 나중으로 미뤘다.
다시 일을 시작해서 돈을 벌게 되거나, 게임이 잘되어 충분한 수익이 생기거나, 아니면 모델링을 담당해줄 팀원이 나타난다면 그때 추가하자고 생각했다.
혼자서 막힌다는 것
내부 시스템 개발도 계속됐다.
처음에는 프로그래머 팀원들과 머리를 맞대고, 막히는 부분이 생기면 서로 해결 방법을 찾아가면서 게임을 만들고 싶었다.
하지만 결국 프로그래머도 나 혼자였다.
새로운 기능 하나가 필요하거나 해결하기 어려운 문제가 하나 생기면 그것 하나에 몇 주씩 매달리는 일도 생겼다.
그리고 내가 그 문제를 해결하는 동안에는 다른 작업 대부분이 멈췄다.
프로그래밍을 해야 했다.
해본 적 없던 레벨 디자인도 해야 했다.
AI도 만들어야 했다.
UI도 만들어야 했다.
게임이 무거우면 그래픽 최적화도 직접 해야 했다.
당시에는 언리얼 엔진에서 새롭게 제공하는 기술이라면 일단 사용해보고 싶었다.
문제는 신기술인 만큼 문제가 생겼을 때 참고할 자료가 많지 않았다는 것이다.
옆자리의 다른 프로그래머에게 물어볼 수도 없었다.
웹을 아무리 검색해도 내가 겪고 있는 문제와 같은 사례가 나오지 않는 경우도 있었다.
그럴 때는 결국 혼자 하나씩 건드려보면서 원인을 찾아야 했다.
그리고 몇 주를 매달려 해결한 문제가 알고 보면 아주 사소한 설정 하나 때문이었던 적도 있었다.
그런 식으로 조금씩 언리얼 엔진을 배워갔다.
너무 일찍 출시했다
그러는 동안 실업급여가 끝났다.
그때부터 마음이 급해지기 시작했다.
뭐라도 해야 했다.
개발을 계속하면서 다시 취업도 시도했다.
몇몇 회사에서는 면접에 합격하기도 했다.
하지만 합격 이후 채용이 취소되기도 했고, 내가 생각했던 개발 업무와 실제 업무가 크게 다른 곳도 있었다.
다른 회사에도 몇 차례 들어가 보았지만 오래 정착하지 못했다.
그렇게 안정적인 수입 없이 시간이 계속 흘렀다.
그리고 그 상황은 산중호걸의 개발에도 영향을 미쳤다.
게임은 아직 부족했다.
기술적으로 불안정한 부분도 많았고, 최적화도 부족했다.
레벨 디자인도 계속 배우고 있는 단계였다.
하지만 당시에는 계속 개발만 하고 있을 수는 없다는 생각이 강해졌다.
어떻게든 게임을 세상에 내놓아야 한다는 조급함이 생겼다.
결국 아직 충분히 준비되지 않은 산중호걸을 Steam 얼리 액세스로 출시하기로 결정했다.
2024년 10월 23일.
프로젝트산중호걸이 Steam 얼리 액세스로 출시됐다.
- 얼리 초창기의 크라켄 보스전 입구
- 초창기 크라켄
- 초창기 지역 사이 시공의 틈
- 초창기 거점
- 초창기 시공의 틈
그리고 이 결정은,
지금도 후회하고 있다.
출시하고 나서야 알게 된 것들
Steam 얼리 액세스 출시 이후 얼마 지나지 않아 STOVE에도 얼리 액세스로 출시했다.
멍청했다.
게임을 출시한다고 하면서 정작 게임 본편 이외에는 준비된 것이 거의 없었다.
제대로 된 게임 아이콘도 없었다.
타이틀도, 상점에서 보여줄 메인 이미지도 제대로 준비되어 있지 않았다.
그때의 나는 게임을 만드는 것과 게임을 출시하는 것이 전혀 다른 일이라는 사실을 몰랐다.
기술적으로도 문제가 많았다.
새로운 기술이라면 이것저것 집어넣었고, 게임은 불안정했다.
PIE에서는 정상적으로 동작하던 기능이 패키징된 실제 빌드에서는 문제를 일으키는 일이 많았다.
더 큰 문제는 그다음이었다.
나는 크래시 리포트를 제대로 수집하고 확인하는 방법조차 몰랐다.
누군가 게임이 튕긴다고 제보를 해도 어디에서 문제가 발생했는지 알아낼 방법이 없었다.
내 컴퓨터에서 PIE로 실행해본다.
잘 된다.
다시 해본다.
또 잘 된다.
문제가 재현되지 않으니 어디서부터 찾아야 할지도 몰랐다.
당연히 게임은 팔리지 않았다.
가끔 판매되더라도 환불되는 경우가 많았다.
판매량과 환불률 같은 숫자를 보는 것 자체가 점점 스트레스가 됐다.
그래서 어느 순간부터 재무 관련 페이지에도 잘 들어가지 않게 됐다.
사실 지금도 자주 들어가지는 않는다.
지금도 많이 팔리지 않는다는 것을 알고 있으니까.
두 개의 플랫폼
Steam과 STOVE, 두 플랫폼에 동시에 출시한 것도 당시에는 좋은 선택이라고 생각했다.
더 많은 플랫폼에 게임이 있으면 더 많은 사람이 볼 거라고 단순하게 생각했던 것 같다.
하지만 당시의 산중호걸은 버그 수정이 굉장히 잦았다.
문제를 하나 발견하면 수정하고, 다시 빌드한다.
그런데 플랫폼이 두 개였다.
한 번 수정할 때마다 두 플랫폼에 올릴 빌드를 각각 준비해야 했다.
게임 자체도 불안정한 상황에서 관리해야 할 대상만 늘어난 셈이었다.
STOVE에서는 결국 단 한 장이 판매됐다.
그리고 그 한 장도 다음 날 환불됐다.
그날 이후 STOVE 판매를 중단했다.
공모전, 그리고 번아웃
정확한 순서는 조금 다를 수도 있지만 이 무렵부터 각종 게임 공모전에도 지원하기 시작했다.
결과부터 이야기하면 지금까지 공모전에 선정된 적은 한 번도 없다.
그중에서도 유난히 좋지 않은 기억으로 남은 공모전이 하나 있다.
스마일게이트에서 주최했던 공모전이었는데, 정확한 대회명은 지금은 기억나지 않는다.
몇 달 동안 준비하면서 정말 많은 시간을 쏟았다.
그런데 결과적으로는 심사를 받아 떨어진 것도 아니었다.
참가 자체를 하지 못했다.
주최 측에는 나름의 사정과 이유가 있었을 것이다.
하지만 몇 달 동안 그것 하나를 바라보고 준비했던 내 입장에서는 허탈할 수밖에 없었다.
이 시점 이후부터 번아웃이 정말 자주 찾아오기 시작했다.
그럴 때면 한동안 개발할 의욕 자체가 사라지곤 했다.
그래도 시간이 지나면 다시 언리얼 엔진을 켰다.
이유는 거창하지 않다.
그냥 이 게임을 완성하고 싶다.
처음 산중호걸을 기획하면서 만들었던 캐릭터들도 아직 많이 남아 있다.
지금은 그림으로만 남아 있는 그 친구들도 언젠가는 태백처럼 게임 안에서 움직이는 모습을 보고 싶다.
데모를 만들면 달라지지 않을까
게임이 몇 달 동안 거의 팔리지 않자 다른 방법을 생각하기 시작했다.
그때 생각한 것이 데모 버전이었다.
게임 초반부를 데모로 구성하고, 데모에서 플레이한 세이브 데이터를 그대로 본편으로 가져갈 수 있도록 만들면 괜찮을 것 같았다.
당시에는 꽤 좋은 아이디어라고 생각했다.
하지만 이것 역시 지금 생각하면 잘못된 판단이었다.
나중에서야 알았다.
데모는 단순히 본편의 일부를 무료로 제공하는 버전이 아니었다.
사람들이 게임을 처음 경험하고, 이 게임을 더 해보고 싶은지 판단하게 만드는 중요한 기회였다.
그런데 나는 그 중요한 기회를 당시의 불안정하고 완성도가 낮은 산중호걸을 보여주는 데 사용해버렸다.
게임을 알리는 데 유용하게 사용할 수 있었던 카드를 너무 일찍 써버린 셈이었다.
결국 이후 데모는 내렸다.
현재 itch.io 페이지에도 데모가 내려갔으며 향후 다른 형태로 돌아올 예정이라고 표시되어 있다.
- 이때는 데모가 있었다.
그래도 계속 만들었다
그렇다고 개발을 그만둘 수는 없었다.
가장 단순한 이유는 지금까지 만든 것이 아까웠기 때문이다.
그리고 현실적인 이유도 있었다.
내가 갈 수 있는 일자리가 많지 않았다.
“그렇다면 서울로 올라가면 되는 것 아니냐”고 생각할 수도 있다.
하지만 나는 이곳이 좋았다.
주변 환경이 크게 바뀌는 것을 좋아하지도 않았고, 가족과 친구들이 있는 곳을 떠나 혼자 서울로 올라가 생활하고 싶지도 않았다.
결국 내가 원하는 곳에서, 내가 원하는 일을 하며 살아갈 수 있는 더 나은 미래를 기대하면서 개발을 계속했다.
뒤틀린 숲을 다시 만들다
이 무렵부터 산중호걸의 그래픽 최적화가 엉망이라는 사실을 본격적으로 깨닫기 시작했다.
최적화만 문제가 아니었다.
초기의 뒤틀린 숲은 쓸데없이 넓었고, 어디로 가야 하는지 알기 어려웠다.
당시에는 넓은 공간을 만드는 것 자체가 어느 정도 좋은 레벨 디자인이라고 생각했던 것 같다.
하지만 실제로 플레이해보니 넓기만 한 공간은 이동 시간을 늘릴 뿐이었고, 플레이어가 길을 잃기만 쉬웠다.
결국 기존 뒤틀린 숲을 날려버리고 다시 구성하기 시작했다.
이번에는 하나의 세이브 포인트를 중심으로 여러 길이 서로 교차하고, 다시 돌아올 수 있도록 구역 자체를 좁혀보기로 했다.
그렇게 두 번째 뒤틀린 숲이 만들어졌다.
- 첫 뒤틀린 숲
- 한번 리워크된 뒤틀린 숲
처음보다는 나아졌다고 생각했다.
하지만 여전히 게임은 무거웠다.
당시에는 Nanite만 적용하면 오브젝트가 아무리 많아도 어느 정도 알아서 최적화될 것이라고 생각했다.
그런데 폴리지는 또 다른 문제였다.
나무와 풀에 바람을 표현하기 위해 사용하던 WPO(World Position Offset)가 수많은 폴리지에 적용되고 있었다.
나중에서야 이 문제를 발견했고, WPO가 적용되는 거리를 약 3000 정도로 제한했다.
프레임이 눈에 띄게 좋아졌다.
그제야 알았다.
Nanite를 켰다고 최적화가 끝나는 것이 아니었다.
이후에도 최적화 문제는 계속 따라다녔다.
2026년에 와서는 HLOD, RVT, Nanite, AI 처리, Niagara, World Partition과 스트리밍까지 손보게 됐다. 실제 뒤틀린 숲 리워크에서도 렌더링, HLOD, RVT, AI, Niagara와 스트리밍 전반의 최적화가 함께 이루어졌다.
레벨을 만드는 법을 조금 배우면,
이번에는 그 레벨을 제대로 돌아가게 만드는 법을 배워야 했다.
사막 협곡과 길을 보여주는 법
사막 협곡 지역을 정확히 언제부터 작업했는지는 잘 기억나지 않는다.
처음에는 사막 아래에 고대의 던전들이 서로 얽혀 있다는 느낌으로 지하 구역을 구성했다.
그런데 당시의 나는 동굴이나 지하 공간의 밝기를 어떻게 다뤄야 하는지도 제대로 몰랐다.
지금이라면 포스트 프로세스를 이용해 비교적 간단하게 조정할 수 있는 문제지만, 그때는 그것조차 몰랐다.
- 초기의 사막 지하
길도 문제였다.
나는 내가 만든 레벨이니 어디로 가야 하는지 당연히 알고 있었다.
하지만 처음 들어온 플레이어는 아니었다.
어디로 가야 하는지 알 방법이 없었다.
돌이켜보면 이것은 사막 지하만의 문제가 아니었다.
초기의 뒤틀린 숲도 그랬고, 사막도 그랬다.
플레이어의 시선을 어디로 유도할 것인지, 무엇을 랜드마크로 사용할 것인지, 다음 목적지가 자연스럽게 보이도록 공간을 어떻게 구성할 것인지에 대한 고민 자체가 부족했다.
내가 길을 알고 있다는 사실 때문에 다른 사람도 길을 찾을 수 있을 거라고 착각했던 것이다.
- 사막 지상, 지금과 동일하다.
그리고 새로운 지역을 만든다고 해서 필요한 리소스가 저절로 생기는 것도 아니었다.
필요한 리소스를 직접 만들어줄 사람은 여전히 없었다.
그래서 마켓플레이스를 계속 들여다봤다.
사용할 만한 리소스가 할인하면 지금 만들고 있는 지역에 쓸 수 있을지 고민하고, 감당할 수 있는 가격이면 구입해서 게임에 추가했다.
처음 산중호걸의 세계관이 그랬던 것처럼,
내가 원하는 세계를 먼저 만들고 거기에 필요한 것을 제작한 것이 아니라, 내가 구할 수 있는 것들을 가지고 원하는 세계에 최대한 가깝게 만들어갔다.
혼자가 아니었던 흔적
그러던 중 이펙트를 담당해줄 팀원 한 명이 합류했다.
취업을 준비하고 있던 친구였는데 정말 열심히 작업해줬다.
짧게 프로젝트를 거쳐 간 사람들은 많았지만, 이 친구가 만들어준 것들은 지금도 산중호걸 곳곳에 남아 있다.
세이브 포인트의 효과, 영혼무덤, 경험치를 흡수할 때의 효과와 몇몇 Niagara 이펙트가 그때 만들어졌다.
아쉽게도 지금은 연락이 닿지 않는다.
함께 개발하는 사람들이 생기다
이펙트를 담당하던 친구와 연락이 닿지 않게 되기 전쯤 새로운 사람들이 프로젝트에 합류했다.
한 명은 기획과 연출, 다른 한 명은 음악과 사운드를 담당했다.
그리고 이 두 사람은 지금도 프로젝트산중호걸을 함께 만들고 있다.
정말 고맙게 생각한다.
둘 다 본업이 있기 때문에 프로젝트에 모든 시간을 쏟을 수 있는 것은 아니다.
작업 속도가 빠르지 않을 때도 있다.
그래도 연락이 끊기지 않는다.
조금씩이라도 계속 프로젝트에 참여하고, 자신이 맡은 부분을 만들어준다.
그동안 많은 사람들이 프로젝트에 들어왔다가 사라지는 일을 반복해서 겪었던 나에게는 그것만으로도 굉장히 고마운 일이다.
그리고 이들과 함께 개발하면서 나 역시 협업에 대해 조금씩 배우기 시작했다.
처음 팀원을 모집하던 시절의 나는 내 머릿속에 있는 것을 다른 사람들도 어느 정도는 당연히 알고 있을 거라고 생각했다.
당연히 그렇지 않았다.
내가 어떤 게임을 만들고 싶은지, 지금 무엇을 만들고 있는지, 왜 이렇게 만들려고 하는지를 상대방에게 설명해야 했다.
그 과정에서 문서를 작성하는 것의 필요성도 알게 됐다.
기술적으로 새롭게 배우게 된 것도 있었다.
사운드 작업을 함께하면서 FMOD를 프로젝트에 적용하기 시작했다.
다른 사람이 직접 작업할 수 있는 환경을 만들기 위해서는 나 역시 새로운 작업 방식을 배워야 했다.
팀원이 생긴다는 것은 단순히 내가 해야 할 일을 대신해주는 사람이 생기는 것만을 의미하지 않았다.
다른 사람과 함께 게임을 만들기 위해서는 나 역시 바뀌어야 했다.
같은 프로젝트에 들어와 있는 것과, 함께 프로젝트를 만드는 것은 전혀 다른 일이었다.
혼자 쓰는 프로젝트에서 함께 쓰는 프로젝트로
기획을 담당하는 팀원이 참여한 이후 프로젝트의 여러 부분이 바뀌기 시작했다.
그전까지 산중호걸의 개발 기능들은 대부분 나 혼자 사용하는 것을 전제로 만들어져 있었다.
내가 만든 기능이니 사용 방법을 문서로 남길 필요도 없었다.
UI가 조금 불편해도 상관없었고, 변수나 옵션의 의미도 내가 알고 있으니 알아보기 쉽게 만들 필요가 없었다.
하지만 다른 사람이 프로젝트를 직접 사용하기 시작하면서 더 이상 그렇게 할 수 없었다.
기능의 이름을 알아보기 쉽게 바꾸고, 복잡하게 사용하던 것은 가능한 한 단순하게 만들었다.
내가 아니더라도 기능의 목적을 이해하고 사용할 수 있도록 개발 도구와 작업 방식도 조금씩 고쳐나갔다.
게임 자체에도 변화가 생겼다.
최근 산중호걸에 추가된 시스템 중 상당수는 기획 단계에서 나온 제안을 실제 게임으로 구현하면서 만들어진 것들이다.
혼자 개발할 때는 자연스럽게 내가 생각할 수 있는 범위 안에서만 게임이 만들어졌다.
다른 사람이 게임을 함께 고민하기 시작하면서 내가 생각하지 못했던 문제를 발견하기도 하고, 새로운 시스템이 필요해지기도 했다.
그렇게 산중호걸은 조금씩 나 혼자만의 프로젝트에서 벗어나기 시작했다.
신력 구슬
산중호걸의 핵심 시스템 중 하나인 신력 구슬은 당시 재미있게 플레이하고 있던 영웅전설 시리즈의 쿼츠 시스템에서 아이디어를 얻었다.
캐릭터에게 여러 개의 라인이 있고, 각 라인의 슬롯을 해금한다.
그리고 슬롯에 특정 아이템을 장착하면 그에 따른 특성이 부여된다.
산중호걸의 캐릭터들은 신력을 사용한다는 설정이 있었기 때문에 이 구조가 꽤 잘 어울린다고 생각했다.
그렇게 쿼츠에서 아이디어를 얻어 산중호걸에 맞게 바꾼 신력 구슬 시스템을 만들기 시작했다.
- 구 신력구슬 UI
그런데 여기서 또 새로운 문제를 만났다.
메모리 관리였다.
당시의 나는 언리얼 엔진이 UObject의 메모리를 어떻게 관리하는지 제대로 알지 못했다.
솔직히 말하면,
UPROPERTY만 붙여놓으면 알아서 다 해주는 줄 알았다.
그리고 살아 있는 UObject를 Outer로 지정해 생성하면 그 객체도 계속 살아 있을 것이라고 생각했다.
그렇지 않았다.
신력 구슬을 정의한 데이터와 함께 실제 동작에 필요한 UObject들을 동적으로 생성해 보관하고 있었는데, 내가 참조를 보관하던 구조가 GC에서 해당 객체를 제대로 추적할 수 있는 형태가 아니었다.
결국 플레이 도중 필요한 객체가 GC에 의해 수거되는 문제가 발생했다.
이 문제 역시 PIE에서는 쉽게 드러나지 않다가 패키징된 빌드에서 플레이하면서 발견되곤 했다.
이 일을 겪으면서 처음으로 언리얼 엔진의 UObject와 GC, 객체의 생명주기를 제대로 공부하기 시작했다.
특성 시스템
신력 구슬에 아이템을 장착했을 때 캐릭터에게 실제 효과를 부여할 방법도 필요했다.
그렇게 특성 시스템이 만들어졌다.
그리고 당연하다는 듯이 여기서도 UObject와 GC 문제를 만났다.
게임 도중 필요한 객체가 사라지면서 크래시가 발생하는 일이 반복됐다.
하지만 문제를 해결하고 나니 이 시스템은 신력 구슬 이외의 곳에서도 사용할 수 있었다.
예를 들어 AI에게 가드 기능을 만들어준다고 하자.
가드 어빌리티가 활성화되어 있는 동안 별도의 피해 계산 코드를 새로 만들 필요가 없었다.
가드 중에 피해 감소 특성을 부여하면 됐다.
가드가 끝나면 특성을 제거한다.
처음에는 신력 구슬을 구현하기 위해 필요해서 만든 기능이었지만, 시간이 지나면서 게임의 다른 기능을 만드는 기반 중 하나가 됐다.
실제로 2024년 5월 개발일지에도 일반 몬스터에게 특성을 적용하고, 몬스터의 가드 중 피해 감소에 활용하는 예가 기록되어 있다.
그런데 이걸 어떻게 편집하지?
신력 구슬 시스템 자체가 동작하기 시작하자 또 다른 문제가 생겼다.
구슬 하나를 만들 때마다 라인과 슬롯 정보를 데이터로 직접 작성하는 것은 너무 불편했다.
나 혼자 사용한다고 해도 귀찮았다.
그래서 신력 구슬의 라인을 직접 보면서 편집할 수 있는 에디터 툴을 만들기 시작했다.
- 신력구슬 생성 툴
라인을 만들고, 슬롯을 배치하고, 연결 상태를 확인하면서 데이터를 편집할 수 있도록 했다.
게임을 만들기 위해 게임 기능만 만드는 것이 아니라,
게임을 좀 더 편하게 만들기 위한 도구까지 만들기 시작한 것이다.
무기 대신, 혼
소울라이크 장르의 특징 중 하나를 꼽으라면 다양한 무기가 있을 것이다.
무기마다 공격 방식이 다르고, 사용하는 애니메이션도 다르다.
같은 캐릭터라도 어떤 무기를 선택하느냐에 따라 전투 방식이 크게 달라진다.
산중호걸에도 이런 시스템을 넣고 싶었다.
다만 일반적인 무기를 그대로 장착하는 방식으로 만들지는 않았다.
산중호걸에서는 이것을 Spirit, 혼이라고 부른다.
혼 하나에는 해당 전투 스타일에서 사용할 애니메이션 세트와 기술들이 들어 있다.
플레이어가 혼을 바꾸면 단순히 손에 들고 있는 무기만 바뀌는 것이 아니라, 그에 맞춰 전투 방식 자체가 바뀌도록 만들었다.
내가 처음 생각했던 것은 당연히 여러 종류의 혼을 만들어 플레이어가 다양한 전투 스타일을 선택할 수 있게 하는 것이었다.
하지만 현재 구현되어 있는 혼은 두 종류뿐이다.
이유는 단순하다.
또 리소스 문제다.
혼 하나를 추가한다는 것은 데이터 하나를 추가하는 것으로 끝나지 않는다.
그 혼에서 사용할 무기가 필요하고, 애니메이션 세트가 필요하고, 기술도 필요하다.
이펙트와 사운드도 필요하다.
나 역시 여러 종류를 만들고 싶다.
하지만 지금의 개발 여건에서는 새로운 혼 하나를 추가하는 것도 상당한 작업이 된다.
앞으로 다른 플레이어블 캐릭터가 추가되었을 때 현재의 애니메이션 세트를 새로운 캐릭터에도 문제없이 사용할 수 있을지도 걱정되는 부분이다.
실제 캐릭터가 만들어졌을 때 확인해야 할 문제다.
그래서 Spirit 시스템은 기본적인 구조는 만들어져 있지만,
내가 처음 상상했던 만큼 확장하지는 못한 시스템이기도 하다.
언젠가는 더 다양한 혼과 전투 스타일을 추가하고 싶다.
게임을 밖으로 보여주기 시작하다
그렇게 타의든 자의든 개발을 계속하고 있을 때 처음으로 개발용 계정에 PlayX4 참가 안내 메일이 왔다.
당시에는 오프라인 부스로 참가하는 데 드는 비용이 부담스러웠다.
결국 온라인으로만 참여했다.
지금 생각하면 조금 무리를 하더라도 직접 오프라인 행사에 참가해보는 게 어땠을까 하는 아쉬움이 남는다.
그래도 PlayX4에 참여한 이후 조금씩 달라진 것이 있었다.
개발용 메일로 다른 공모전의 참가 제안이 오기도 했고, 해외 업체에서 협업을 제안하는 메일도 들어오기 시작했다.
물론 대부분의 협업 제안은 비용이 필요했다.
게임 자체를 만드는 비용도 부담스러운 상황에서 외부 업체에 추가 비용을 지불하면서 협업을 진행하기는 어려웠다.
대신 별도의 큰 비용 없이 참여할 수 있는 공모전이나 지원 프로그램이라면 가능한 한 계속 도전하려고 했다.
그리고 지금도 그러고 있다.
아직 붙은 곳은 없지만.
게임을 만드는 것만으로는 부족했다
외부 활동을 경험하면서 또 하나 느낀 것이 있었다.
게임은 만들기만 한다고 사람들이 알아주는 것이 아니었다.
게임을 알리기 위한 활동도 필요했다.
그래서 정말 오래전에 만들어놓고 거의 사용하지 않던 X 계정을 다시 꺼냈다.
그리고 그 계정을 지금까지 계속 사용하고 있다.
그렇다고 SNS 활동을 시작하고 갑자기 많은 사람들이 산중호걸을 알게 된 것은 아니다.
지금도 글 하나가 크게 퍼진다거나, 팔로워가 빠르게 늘어나는 일은 거의 없다.
가끔 다른 개발자의 게시물을 보면 별것 아닌 것처럼 보이는 기능 하나를 올렸는데도 수많은 리포스트가 달리고 조회수가 엄청나게 올라가는 경우가 있다.
솔직히 그런 걸 보면 조금 배가 아프다.
비슷한 개발 이야기를 올리는데 왜 내 글에는 사람이 안 오는지 생각하게 될 때도 있다.
그래도 아무것도 하지 않으면 정말 아무도 모른다.
그래서 새로 만든 것이 있으면 올리고, 개발일지를 쓰면 공유하면서 지금도 계속 계정을 사용하고 있다.
혼자 게임을 만든다는 것은 결국 프로그래밍과 레벨 디자인만 하는 일이 아니었다.
게임을 만들고,
테스트하고,
빌드하고,
상점 페이지를 관리하고,
개발일지를 쓰고,
SNS에 올리고,
팀원을 구하고,
문서를 작성하고,
행사와 공모전을 찾아 지원하는 것까지.
어느 순간부터 이 모든 것이 개발의 일부가 되어 있었다.
다시, 다시 만들다
그리고 최근까지도 기존에 만들어놓은 레벨들을 계속 갈아엎고 있다.
뒤틀린 숲도 다시 만들었다.
거점도 다시 만들었다.
기존 지역에서 발견했던 문제를 고치기 위해서이기도 했고, 내부 회의에서 새롭게 나온 지역 구성과 플레이 흐름을 적용하기 위해서이기도 했다.
예전에는 이미 만들어놓은 것을 버리는 것이 아깝다는 생각도 많이 했다.
하지만 지금은 문제가 있다고 생각되는 레벨이라면 기존 작업량이 아깝더라도 다시 만드는 쪽을 선택하고 있다.
2026년 6월에는 결국 뒤틀린 숲의 전체 구조와 광산, 세이브 포인트, 포탈, NPC와 아이템 배치까지 전면적으로 다시 만든 대규모 리워크를 공개했다.
물론 지금의 레벨 디자인을 보면서
“이제 정말 잘 만든다.”
라고 자신 있게 말할 수 있는지는 모르겠다.
그래도 한 가지는 말할 수 있을 것 같다.
예전보다는 나아졌다.
레벨을 다시 만들 때마다 새로운 문제가 보였고, 그 문제를 해결하면서 필요한 기능도 하나씩 추가됐다.
길을 다시 만들고,
숏컷을 만들고,
세이브 포인트의 위치를 고민하고,
플레이어가 어디를 바라보게 할 것인지 고민하고,
지역과 지역이 어떻게 연결되어야 하는지도 다시 생각했다.
그렇게 레벨을 갈아엎는 작업은 단순히 맵을 새로 만드는 일이 아니라,
그동안 배운 것들을 다시 게임에 적용하는 과정이 됐다.
그리고 지금
팀원은 지금도 계속 모집하고 있다.
여전히 새로운 사람이 들어왔다가 얼마 지나지 않아 나가는 경우도 많다.
이제는 예전만큼 놀랍지도 않다.
공모전에도 여전히 지원하고 있다.
그리고 여전히 결과는 좋지 않다.
게임도 여전히 많이 팔리는 게임은 아니다.
아직 만들고 싶은 지역도 남아 있고, 고쳐야 할 것도 많고, 구현하고 싶은 시스템도 남아 있다.
처음 산중호걸을 만들기 시작했을 때 생각했던 모습과 지금의 게임은 많이 달라졌다.
처음에는 사용할 리소스가 없어서 서로 다른 시간과 공간이 뒤섞인 세계를 만들었다.
레벨 디자인을 해본 적도 없으면서 거대한 필드를 만들었다.
Nanite를 적용하면 최적화도 어느 정도 해결될 거라고 생각했다.
여러 사람이 모이면 자연스럽게 함께 게임을 만들 수 있을 거라고 생각했다.
준비가 충분하지 않은 상태에서 얼리 액세스로 출시했다.
데모도 너무 일찍 공개했다.
공모전에서는 계속 떨어졌다.
만들어놓은 레벨을 통째로 버리고 다시 만든 것도 한두 번이 아니다.
번아웃도 여러 번 왔다.
그래도 계속 만들고 있다.
처음 이 게임을 시작하게 만든 것은 그림 한 장이었다.
그림 속에 있던 백호가 게임 안에서 살아 움직이는 모습을 보고 싶었다.
그것은 이루었다.
하지만 처음 산중호걸을 기획하면서 만들었던 다른 친구들은 아직 그림 속에 남아 있다.
언젠가는 그 친구들도 태백처럼 게임 안에서 움직이는 모습을 보고 싶다.
게임이 얼마나 팔릴지,
공모전에 언제 한번 붙어볼 수 있을지,
앞으로 얼마나 더 오래 개발하게 될지는 나도 모르겠다.
그래도 이유는 처음부터 지금까지 생각보다 단순했던 것 같다.
그냥 이 게임을 완성하고 싶다.
