커뮤니티 게시판 글상세

인디 개발자 인터뷰 시리즈 Commit Me의 두번째 손님은 팀 호레이의 안태현 팀장과 문지환 게임 디자이너 입니다.

첫번째 꼭지에서는 팀 호레이의 첫 작품 [던그리드] 개발 당시의 경험을 함께 회고해봅니다.

🎮 다양한 해법을 만들기 위해선 다양한 재료가 필요하다

<팀 호레이의 첫번째 게임 [던그리드]>

선용 ㅣ 안녕하세요 팀 호레이 여러분. 첫번째 질문은 가볍게. 팀 호레이는 왜 로그라이트만 만듭니까?

태현 ㅣ 저희가 [던그리드]를 처음 만든 건, 그 당시에 로그라이크 장르가 흔하기도 했고요.

저도 나름 그 당시에 나온 [데드 셀], [아이작], [로그 레거시] 이런 것들 재미있게 했거든요.

그래서 우리도 이런 거 만들자 해서 시작하게 되었어요.

사실 큰 이유는 없었어요. [던그리드] 만들면서 이제 다시는 로그라이크 만들지 말자.

한번 제대로 된 액션 어드벤처 만들어보자 애서 시작하게 된 게 [페어리 라이츠]였죠. 그런데 맘에 안들더라고요.

그래서 다시 우리가 잘 아는 로그라이트 만들자 생각해서 시작한게 [세피리아] 였고요.

사실 [페어리 라이츠]도 개발 과정에서 로그라이트로 가고 있긴 했어요.

[던그리드]에서 좋았던 시스템들, 독특한 아이템들 넣고 하다보니까 이 게임도 로그라이트랑 딱 맞는 방향으로 가고 있더라고요.

선용 ㅣ 많은 개발자들의 프로젝트 시작 동기가 비슷하긴 하잖아요. 내가 어떤 게임을 너무 재미있게 해서, 나도 이런 거 만들어보고 싶다고 생각하는 거. 팀 호레이도 비슷했군요. 그럼 질문을 바꿔볼게요. 로그라이크가 왜 그렇게 좋았어요?

태현 ㅣ 로그라이크는 매 게임 세션을 가볍게 즐기는 것도 재미있었고요.

저는 특히 그 중에서도 액션성이 좀 강한 것들을 좋아했어요.

그리고 개발 면에서는 게임 속 콘텐츠가 어느 정도 있으면, 장르 특유의 특성 때문에 플레이 타임을 다른 게임 장르보다 더 많이 이끌어낼 수 있는 것이 매력적이었죠.

저희같이 한정적인 자원을 가지고 있는 팀에서는 이런 장르 선택이 스마트한 결정이 아닌가 생각하기도 했고요.

지환 ㅣ 사실 제가 팀에 합류했을 때 게임의 모습은 그냥 메트로베니아에 가까웠어요. 그냥 똑같은 곳을 계속 돌고 왔다 갔다 이동하는데 지루하고 그랬죠.

태현 ㅣ 아 그런 시절이 있었구나 우리가.

지환 ㅣ 근데 메트로베니아라는 장르는 점프의 재미나 방 안에서의 규칙들, 돌아다니는 동선 이런 것들을 세심히 고려해야 하는데 솔직히 그럴 깜냥이 안된다고 생각했거든요.

우리 스스로. 그래서 이 친구가 ‘그럼 맵을 랜덤 생성 해보자’ 했죠.

사실 그 때 부터 저희 끼리 따로 말하지는 않았지만, 로그라이트로 가는 걸로 결정하게 된 것 같아요.

선용 ㅣ 어떻게 보면 내부적으로는 약간 부족한 경험을 랜덤 뒤에 숨어서(?) 보완해보고자 한 거네요.

지환 ㅣ 맞습니다. :D 좀 더 현명하게 가보자 했던 거죠. 그런데 저는 당시 저희가 최선의 선택을 했다고 생각해요.

메트로메니아를 제가 이 팀에서 제일 좋아하고 가장 많이 해봤다고 자신하는데, 이 때 장르를 튼 것은 진짜 좋은 결정이었다고 생각해요.

선용 ㅣ 보통 그렇게 시작하고, 이제 만들면서 아 이거 그렇게 간단한 거 아니구나. 큰일 났다. 이렇게 되잖아요. 어떠셨어요?

태현 ㅣ [던그리드] 만들 당시에는 이거 어차피 처음 만드는 거니까 우리끼리 심사숙고해서 하나 하나 결정한다기 보다는 장르는 이렇게 정했으니까, 이제는 뭘 해야 할까를 고민한 거 같아요.

로그라이트를 만들기로 했으니 다른 게임들 많이 해보고 이런 시스템이 있더라. 이런게 좋더라 서로 얘기 많이 하면서 [던그리드]에는 어떻게 넣으면 좋을지를 결정하면서 살 붙여나가는 거죠.

특히 게임을 한 판 한 판 할 때 이전 판과는 좀 다른 양상을 만들어내는 것을 중요하게 생각했어요.

[세피리아]를 만들 때도 이 기조는 계속 유지를 했죠.

선용 ㅣ 그럼 [던그리드]를 만들면서 제일 잘한 결정은 뭐였다고 생각하세요?

태현 ㅣ 딱 두가지 떠오르는데요. 하나는 [던그리드]의 훈련소 시스템에 대한 건데요.

전에는 로그레거시 라는 게임의 시스템과 비슷했거든요. 퍽들이 있고, 그걸 돈주고 사는.

근데 출시 한 2~3주 정도 남았을 때 이걸 스탯 업그레이드 방식으로 바꾸자고 결정했어요.

그래서 순식간에 5개 정도 스탯 카테고리를 정해서 플레이어들이 좀 더 취향껏 선택할 수 있게 만들었거든요.

개인적으로는 가장 좋은 결정이 아니었나 싶어요.

<[던그리드] 훈련소의 스탯 커스터마이징>

두번째는 음식 시스템을 만든거요. 어떻게 들어갔는지는 기억이 안나요.

이게 알게 모르게 [던그리드]만의 음식 먹는 재미를 만든 것 같아요.

음식 먹으려고 매 층 마다 식당을 찾게 되고, 이런 사이클을 운 좋게 잘 이끌어낸 것이 진짜 좋은 결정이었다는 생각이 들어요.

<[던그리드]에서 사먹을 수 있는 음식들>

지환 ㅣ 저도 비슷한 거 같아요. 굳이 다른게 있다면 이 요리도 중간에 한 번 크게 바꾼 적이 있어요. 원래는 특정 음식이 고정된 스탯을 올려주는 방식이었는데, 이게 나중에 문제가 되기 시작하면서 다른 방식으로 변경했어요.

선용 ㅣ 어떤 문제가 있었는데요?


지환 ㅣ 계속 똑같은 음식만 먹어서 한 스탯을 너무 강력하게 올리는 방식의 플레이는 저희 의도와는 달랐거든요.

그래서 요리들에도 랜덤 요소를 적용해서, 각 음식이 랜덤하게 스탯을 획득하도록 바꿨죠.

다행하게도 플레이어들이 딱히 큰 불만 없이 변화를 받아들여서 좋은 기억으로 남아 있어요.

선용 ㅣ 팀 호레이가 만든 게임들을 보면, 모든 게임들이 게임에서 보여지는 것 보다 훨씬 복잡한 스탯 체계를 가지고 있거든요.

[던그리드]의 경우엔 그냥 막 점프하고, 칼질하다가 아이템 바꿔서 원거리 공격하고 이런 액션 게임으로 보이지만, 사실 그 밑에 온갖 스탯들이 있잖아요. [페어리 라이츠]도, [세피리아]도 생각 보다 많은 스탯들을 가지고 있고요.

게임 디자인 측면에서 이렇게 많은 스탯들을 쫙 나열해놓고, 그걸 커스터마이징 하는 방식을 선호하는 편인가요?

태현 ㅣ 네. 저는 그런 방식을 좋아해요. 일반적인 RPG를 보면 다양한 스탯들이 있잖아요.

저는 이런 능력치들을 조정하는 걸 되게 좋아하는 편이거든요.

[세피리아]도 초반에는 힘, 민첩, 지능 등등 많은 스탯들을 찍을 수 있었는데요.

이걸 로그라이트에 집어넣으니까 너무 복잡해지는 경향이 있더라고요.

그래서 이걸 또 많이 줄였더니, 게임이 또 밋밋해지더라고요.

그래서 [세피리아]에서는 최종적으로 능력치가 아닌 ‘속성’을 스탯으로 활용하기로 했습니다. 물리, 불 이런 속성들이요.

궁극적으로는 결국 이런 스탯 커스터마이징이 게임 속에서의 해법들을 다양하게 만들어야 한다는 방향성을 가지고 있었습니다.

다만 이런 스탯들이 게임을 너무 복잡하게 만들지 않는 선에서 다양하게 넣어보려고 노력했죠.

선용 ㅣ 더 다양한 해법을 만들기 위해서는 더 다양한 재료가 필요하겠죠. 그런데 게임 디자이너 입장에서 이 데이터들을 직접 만지는 건 지환님일 거잖아요?

지환 ㅣ 아뇨. 밸런싱은 거의 다 같이 합니다. 저는 요즘은 밸런싱은 크게 안하고, 아이디어를 만드는 데 더 시간을 보내고 있어요.

게임 디자인 할 때는 이런 스탯을 넣자. 변형해보자 이런 생각들을 많이 하지만, 사실 플레이어로서의 저는 스탯에 그렇게 구애받지 않고 플레이 하는 걸 좋아하거든요.

오히려 게임 속 액션이 재밌어야 하고 그 액션을 좀 더 즐겁게 만들 수 있는, 좀 더 추상적인 방향에서 생각을 많이 하게 되는 거 같아요. 그리고 사실 스탯이 다양해야 아이템도 다양하게 넣을 수 있다는 장점이 있기도 하고요.

선용 ㅣ 팀 호레이의 모든 프로젝트에서 똑같았을 거 같은데, 만드는 과정에서는 게임에 나오는 모든 스탯들과 각 스탯 간의 관계를 처음부터 완벽하게 설계해서 시작하기는 어렵잖아요. 아마 기본 스탯들을 정해놓고, 중간에 뭘 추가하고 수정하고 하게 될텐데, 이게 사실 프로그래머 입장에서는 부담스러운 면이 있잖아요. 특히 이런 장르에서는 뭐 하나가 추가되면 다른 것들이 그것에 영향을 받기 때문에 예상하지 못한 버그가 터지고… 그래서 개발 과정에서 뭐가 들어갔다 빠지고 하면 프로그래머 입장에서 관리하기가 쉽지 않았을 거 같거든요. 어떻게 관리를 하셨어요?

태현 ㅣ 저는 사실 그걸 부담스러워 하지 않는 프로그래머 입니다. :D

오히려 제가 팔랑귀라서 막 생각이 바뀌어요. 프로그래머인 제가 친구들에게 이거 아닌 거 같은데 바꾸자는 말을 더 많이 해요.

아마 팀원들이 오히려 이런 저 때문에 진절머리가 나는 경우가 많이 않을까 하는 생각을 하게 되는데… 물론 프로그래밍 파트에서 시스템 변화에 유연하게 대응해야 할거고요.

저는 뭔가 저 혼자 브랜치를 빼서 현재 프로젝트에 최대한 영향 주지 않고 뭔가를 혼자 만들어서 팀원들에게 보여주는 경우가 꽤 잦은 편이네요. 뭔가 돌아가는게 있으면 설득하기 좋으니까요.

데이터로 분리할 수 있는 요소는 최대한 분리해 두는 것이 가장 중요하다고 생각해요. 개인적으로 유니티의 스크립터블 오브젝트(Scriptable Object) 개념을 좋아하는데요,

게임에 사용할 데이터를 쉽게 생성할 수 있고 상속, 추상화 같은 개념을 함께 이용할 수 있기 때문에 세피리아 내 여러 시스템(챕터/스테이지 구성, 캐릭터 스탯, 아이템, 무기 등)을 스크립터블 오브젝트로 관리하고 있습니다.

스크립터블 오브젝트가 가장 많이 쓰이는 시스템은 ‘챕터/스테이지’ 인데요. [던그리드]는 각 층이 씬 기반으로 되어 있고, 모든 층의 목록이 하드코딩되어 있었습니다.

구현은 아주 쉬웠지만, 새로운 스테이지가 추가될수록 if문과 switch문이 계속 추가되며 하나하나 관리해 주어야 하는데요, 이러한 문제 때문에 시련, 황혼 저택 업데이트 등 새로운 층이 추가되는 작업에 많은 어려움이 있었습니다.

그래서 세피리아는 게임 내의 스테이지 구성이 유연하도록 설계했습니다. 챕터 구성과 스테이지 정보는 스크립터블 오브젝트로, 각 장소는 프리팹으로 관리해서, 스테이지 전반을 두 방식을 혼합해 운용하고 있습니다.

그 덕분에 완전히 디자인된 토끼마을, 그리드 단위로 배치되는 두더지 기지, 방-복도-방 형식으로 구성된 도서관 등 다양한 구성의 월드를 선보일 수 있었습니다.

👉 다음 인터뷰를 기대해주세요.

로그라이트라는 장르에서 게임을 플레이 할 때 마다 다른 경험을 줄 수 있다는 가능성에 매력을 느낀 팀 호레이가 [던그리드]를 개발했던 이야기를 함께 회고해봤습니다. 

다음 편에서는 🎯[던그리드]의 성공이후 개발하다 폐기된 [페어리 라이츠] 프로젝트를 살펴보고, 프로젝트의 폐기 이후 새로운 프로젝트 [세피리아]의 개발 방향을 정립하게 된 과정에 대해 이야기 나눕니다.