[언리얼서밋] 소규모 인디 개발팀이 지켜야 할 몇 가지 규칙

게임뉴스 | 이현수 기자 | 댓글: 10개 |


▲ 넥스트 스테이지 강현우 대표

과거 통설 중에 "인디 개발자는 '언리얼 엔진'을 고려할 필요도 없다."라는 말이 있었다. 그만큼 타사 상용엔진 대비 들어가는 품이 크고 어려웠다. 그러나 '언리얼 엔진4'에 들어와서는 이야기가 달라졌다. 손쉬운 블루프린트를 비롯해 다양한 방식으로 접근성이 크게 좋아진 것은 물론 강력한 툴 덕에 시간도 줄일 수 있게 됐다.

인디 게임 개발사 '넥스트 스테이지'는 언리얼 엔진4를 사용한 모바일 액션 RPG '다이스 이즈 캐스트'를 만든 개발사다. 넥스트 스테이지의 강현우 대표는 이 게임의 개발 스토리를 소개하며 그 과정에서 얻은 소규모 팀에서 언리얼 엔진을 사용할 때의 팁을 공유했다.

[다이스 이즈 캐스트 트레일러]

'다이스 이즈 캐스트'는 기억을 잃은 소년의 이야기를 담은 게임으로 화려한 그래픽과 극한의 콘트롤이 강점이다. 게임 이름에 걸맞게 스테이지에서 주사위를 던저 이동하고, 그 지점의 몬스터와 전투를 펼치는 방식을 채택했다.

액션성을 살린 컨트롤 중심의 게임답게 게임 패드와 연동이 되며, 타격 수에 따라 다양한 스킬을 사용할 수 있는 것도 특징이다. 또한, 스토리 모드 외에도 챌린지, 레이드 등 즐길 거리를 제공한다. '다이스 이즈 캐스트'는 원스토어, 구글 플레이, 애플 앱스토어 유료 순위에 오르기도 했다.



■ 나는 왜 게임을 만들기로 했나.

군 시절 간부 덕분이었다. 어느 날 간부가 나에게 시켜준 '인피니티 블레이드'는 정말 충격이었다. 어떻게 모바일에서 이런 게임을 만들 수 있는지 이해조차 할 수 없었다. 그래서 만들고 싶었다. 자는 시간을 줄여가면서 게임 기획을 독학했다. '다이스 이즈 캐스트'의 기획 대부분은 그때 만들어졌다.

컨트롤 위주의 액션 RPG를 만들고 싶었다. 자동전투가 없는 극한의 컨트롤게임. 방치형 게임과 자동사냥과의 차이점을 두고 싶었다. 완전히 트렌드를 벗어난, 무식해서 용감한 기획이었다. 아무튼, 뭐 그랬다.

그래도 고집은 있어서 이걸 밀고 나가고자 했고 전역 후에 프로그램을 배워서 2012년 UDK(언리얼 엔진3)로 개발을 시작했다. 개발능력이 학부생 수준 정도밖에 안되는 나로서는 이해하기 쉬운 언리얼 스크립트를 이용했다. 한글화된 방대한 문서에도 도움을 많이 받았다. 무조건 '인피니티 블레이드' 급으로 만들고 싶다는 단순한 생각으로 밀어붙였다. 그때는 그랬다.



▲ '인피니티 블레이드'급 게임을 만들기로 했다. 무식하면 용감하니까.

UDK를 이용해서 2명이 프로토타입을 만들었다. 논타겟팅 전투 시스템에 20개의 스킬, 3개의 스테이지가 있는 타입이었다. 이건 지금 봐도 굉장히 아스트랄했다. 그래도 이걸 가지고 GGDC(글로벌 게임제작 경진대회)에 출품했고 상용화 부문에서 은상을 받을 수 있었다.

프로토타입을 만드는 과정에서 개발 프로세스를 이해하고 개발력을 끌어올릴 수 있었으며 자신감을 얻었다. 그러나 프로토타입 한계가 분명히 존재했다. 일단 UDK 자체의 한계가 있었다. UDK는 안드로이드로 포팅이 되지 않았으며 내 개발력 자체도 보잘것없는 수준이었다. 프로토타입을 만든다고 상용화 게임으로 반드시 이어지지 않는다는 것도 배웠다.

이후 1년간 프로젝트를 정지했다. 액션 RPG를 만들고 싶었지만, 두 명이 함께 하기에는 현실적인 문제도 있었다. 또한, 어찌어찌 게임을 만든다 해도 개발도 어려운데, 판매나 마케팅은 꿈도 꾸지 못할 일이었다. 그래서 원점에서 생각해 보기로 했다.


■ 나는 '공돌이'라 언리얼 엔진4를 사용했다.

중지된 1년간 많은 고민을 했다. 일단 '완성할 수 있을까?'부터 가장 근본적인 '이걸로 먹고 살 수 있을까?'라는 고민을 계속했다.

그러던 중 2015년. TIF(도쿄 인디 페스트)에 갑자기 신청하고 싶어졌다. 그래서 신청했고 선정됐다. 일본어를 못하기 때문에 부산정보산업진흥원이 통역 지원을 해줘 도쿄로 가게 됐다. 사실 난 처음에 일본 사람들 특유의 '겉과 속이 다른 말' 때문에 좋은 말만 해줄 것으로 생각했다.

그러나, 아니었다. 하고 싶은 말 엄청나게 다 하더라. 여기서 수많은 사람들의 피드백을 받을 수 있었다. 오래 고민했던 '나만 재밌나?'라는 생각에 답을 얻을 수 있었다. 대체로 전투 부분에 긍정적인 반응이 많았다. 사흘 동안 하루 한 번씩 오는 사람도 있을 정도였다. 그래서 본격적으로 상용화를 결정했다.




▲ TIF 참석이 지금의 게임을 만들었다.

가장 먼저 한 것은 학교 창업 센터에 가는 것이었다. 동아대 창업 선도대학 지원사업을 신청했고 선정됐다. 열정적으로 도와준 덕분에 창업 초기 자금 문제를 해결할 수 있었다.

개발을 조금 진행하자 사무실에 대한 필요성이 생겼다. 집에서 매일 컴퓨터만 한다고 어머니한테 혼나는 것도 하루 이틀이었다. 그래서 스마일게이트의 '오렌지 팜'에 지원했고 입주할 수 있었다. '오렌지 팜' 같은 인큐베이팅 시스템은 안정적인 풀타임 작업이 가능하다는 장점이 있다. 또한, 다른 스타트업 기업들과 네트워크를 할 수 있다는 장점도 있다. 인디 개발을 하려면 인큐베이팅 센터를 고려하는 것도 좋다.

15년 9월부터 본격적으로 언리얼 엔진4를 이용하여 개발을 진행했다. 주위에서 왜 유니티가 아니라 언리얼을 쓰느냐는 질문을 많이 받았다. 나는 공돌이 마인드라 실제로 돌아가는 걸 보지 않으면 믿지를 않는다. 그래서 언리얼 엔진의 풀소스코드에 끌렸다. 또 '파라곤', '기어즈 오브 워', '로보리콜' 등 수준 높은 게임을 만드니까 신뢰감도 있었다.




인디는 창의력이 중요하지만, 고집도 필요하다고 본다. 나는 핵심 재미를 회피와 콤보로 결정하고 끝까지 밀어붙였다. 이를 위해 즉각적으로 반응하는 반응성, 60프레임의 부드러운 움직임을 최우선 목표로 삼았다. 한 프레임, 한 프레임을 중요하게 생각해서 정확하게 세팅했다. 그러나 모바일 게임에서는…. 해봐야 쓸데없는 짓이다.

자연스러운 애니메이션을 위해 루트모션을 넣었고, 극한의 컨트롤 전투를 위해 쿼터뷰 밖의 시야도 제공해주고 싶었다. 그래서 Yaw 축 회전을 넣었다. 이런 점이 극한의 컨트롤 게임으로 가는 길이라 생각했다. 그때는 그랬다.

전투 방식도 소수의 똑똑한 적과 제한된 공간에서 빡빡하게 긴장하는 전투로 만들고 싶었다. 그러기 위해서는 우선 몬스터가 똑똑해야만 했다. 비헤이비어 트리를 사용했다. 플로킹 알고리즘을 이용한 이동으로 자연스러운 공격, 회피, 경계가 가능해졌다. 그런데 자연스러워진 것은 좋은데 적을 똑똑하게 만들다 보니 AI 작업 부담이 커졌다.



▲ 자연스러웠지만, 몬스터가 너무 똑똑했다.

서버는 처음에 쉽게 생각했다. 비동기 방식의 서버를 구현하기 위해 구글 앱 엔진을 사용했다. 대충 만들면 '구글 신'이 다 알아서 해줄지 알았는데. 아니었다. 또 한 번 강조하는데 대충 만들면 안 된다. NoSQL은 생각보다 공부해야 할 부분이 많다. 그러므로 인디는 서버 없이 돌아가는 게임을 만들 것을 추천한다. 서버가 꼭 필요하다면 서버 전담 프로그래머가 필요하다고 생각한다.

에셋은 마켓 플레이스에서 구매했고, 유니티 에셋스토어에서 마음에 드는 게 있으면 메일을 보내 개인적으로 구매했다. 이렇게 라이센스 문제를 해결했다. 많은 사람들이 구매한 에셋을 그냥 쓰고는 하는데 반드시 수정해서 사용해야 한다. '에셋 티'가 나기 마련이다.

애니메이션 에셋은 애님 리타겟팅을 사용하면 여러 가지를 화려하게 만들 수 있어 편리하다.


■ 필요하다고 생각했던 건 필요 없었고, 쓸데없다고 생각했던 것은 쓸모 있었다.

2016년 3월, 지금은 사라진 네이버 앱스토어 베타 테스트를 진행했다. 그리고 'Dev Grant'도 신청했다. 출시를 앞두고 막연한 두려움이 있었는데 테스트를 통해 이겨낼 수 있었다.

베타 테스트 결과는 좋지 않았다. 모바일에서 높은 컨트롤 난이도를 엄청 지적받았다. 게임의 특징이었던 제한된 필드에서 펼쳐지는 빡빡한 전투 자체도 높은 평가를 못 받았다. 너무 똑똑한 AI 때문에 게임이 어려워졌기 때문이다.

왜 이런 문제가 생겼는지 생각해봤다. 일단 테스트를 지금껏 진행했던 개발자들은 이미 게임의 '마스터 레벨'에 도달한 사람들이다. 이런 사람들이 밸런스를 잡았으니 제대로 된 밸런스가 나왔을 리가 없었다. 그리고 사용자가 게임에 익숙해지기까지 허들이 너무 높았고 제대로 된 튜토리얼도 없었던 것이 패착이라고 생각했다.

그래서 '플레이어의 죽음'에 초점을 맞춰 게임을 수정해나갔다. 바로 게임오버가 되는 부분을 바꾸어 여러 번의 기회를 주는 방향으로 선회했다. 방어를 누르면 다운 모션이 캔슬 된다든지, 공격 준비 모션이 큰 기술이 끊김 없이 나간다든지, 대시로 공격 모션을 회피한다든지, 타이밍 여지를 주면서 밸런스를 개선했다.

돌이켜보면 필요 없다고 생각했던 것들이 필요했고, 없어도 될 것 같은 것들은 있었다. 많은 고생을 했지만, 사용자 피드백을 통해 많은 발전을 할 수 있었다. 정말 최대한 의견을 많이 들었다.




이후 2016년 5월, 드디어 원스토어에 출시한다. 다들 왜 원스토어냐고 물어봤는데, 유료게임이라 그랬다. 원스토어는 캐시 이벤트를 많이 해서 부담 없이 구매가 가능한 환경이라 판단했다.

출시했을 때 홍보에 대한 개념이 부족해서 매우 힘들었다. 잘 몰라서 몇몇 사이트에만 글을 올렸다. 다행히도 한 사이트에서 반응이 좋아 다운로드가 늘었다.

다운로드가 늘어나 데이터를 분석할 필요가 생겼다. 그런데 구글 플레이 콘솔은 며칠 전 데이터만 보여주기에 대응이 늦을 수밖에 없다. 이 역시 대단한 사람들이 만들어 놓은 멋진 플러그인들이 존재해 이를 통해 필요성을 충족할 수 있었다.

인디 개발자도 나중을 위해서 트래킹 툴을 붙이는 것을 추천한다.

2016년 6월 구글 유료 게임 순위 2위를 달성했다. 1위는 '넘사벽' 마인크래프트이기 때문에 엄청 기뻤다. 7월에는 애플 유료 게임 순위 3위에 올랐으며 원스토어에서는 7월 한 달간 1위를 유지했다. 그때 많은 이익을 얻을 수 있었다.

2016년 9월에는 Dev Grant에 선정됐다. 사실 나도 넣어놓고 완전히 잊었던 일인데 선정돼서 너무 좋았다. 특히 상금이 나오니까 그 점이 제일 좋았다. GGDC에서 상 받을 때보다 더 좋았다.

현재는 신작을 구글에 출시할 준비를 하고 있으며 소니와 라이센스를 체결해 플레이스테이션 신규 타이틀을 개발하고 있다. 우리 회사 이름 처럼(넥스트 스테이지) 차근차근 올라가는 거 같다.





■ 소규모 개발팀이 지켜야할 것들

개발 전 반드시 고려해야 할 사항이 있다. 이게 만들고 싶은 게임인지, 만들 수 있는 게임인지, 만들만 한 게임인지 고려해야 한다.

만들고 싶지 않은 게임을 만들면 반드시 후회하고 결과물도 좋지 않기 때문에 만들고 싶은 게임인지 확실히 해야 한다. 인디 개발자의 경우 만들고 싶다는 생각만으로 개발하는데 그러면 안 된다. 만들 수 없는 거면 100년을 만들어도 못 만들기 때문이다. 그러므로 만들 수 있는 게임인지 확신이 있어야 하며, 게임은 내가 하는 게 아니라 유저들이 하는 것이기 때문에 혼자 즐길 게임이 아니라면 만들만 한 게임인지도 생각해 재미있는 요소를 넣어야 한다.

이런 것을 고려했을 때 UDK로 개발한 '다이스 이즈 캐스트'는 낙제점이다. 거의 모든 전투 프로토타입도 말아먹고, 재미도 나만 있었으며, 시간도, 일정도 부족해 하다가 중단되는 경우도 있었다.




대규모 팀뿐만 아니라 소규모 팀도 버전 관리가 매우 중요하다. 분명히 말할 수 있는 것은 '오늘의 나'와 '내일의 나'가 다르다는 점이다. 오늘의 나와 내일의 나는 완전히 다른 별개의 사람이라 생각하는 것이 편하다. 코드도 생각도 다르다. 그러므로 버전 관리를 통해 며칠 전의 자신을 추노할 수 있게 해야 한다.

소규모 팀에서 뜻밖에 간과하는 것 중의 하나가 일정 관리다. 그러나 일정 관리를 통해 책임감과 목적의식을 부여할 수 있고 일의 능률도 올릴 수 있다. Trello, Redmine 등 다양한 일정 관리 툴이 있으니 마일스톤과 데드라인을 관리하는 것이 좋다.

언리얼의 예저 프로젝트를 분석하는 것도 큰 도움이 된다. 콘텐츠 예제 프로젝트, 슈터게임, 로보리콜, 태양의 사원 같은 예제 프로젝트는 반드시 뜯어보기를 추천한다.

자금을 획득하기 위한 정부 지원사업도 장, 단점이 존재한다. 정부에서는 창업을 위한 여러 가지 지원사업을 운용하고 있는데, 개발 중인 아이템이 있다면 도전해볼 만하다. 시도만 해봐도 성공, 실패와 관계없이 배울 점이 많다.

이를 위해 반드시 프로토타입이나 알파 버전 정도의 구체적으로 보여줄 '무엇'은 가지고 있어야 한다. 페이퍼 워크만으로는 높은 경쟁률을 이겨낼 수 없다.

정부 지원사업은 시간 소모도 많고, 서류를 잘 써야 하고, 사업 기간 내 강제적으로 결과물이 나와야 한다는 단점은 존재하지만, 자금이 필요할 경우 도전할만한 가치가 있다.



▲ 언리얼 방식을 따르는 것도 도움이 된다.

인디 개발은 속도전이다. 그래서 프로토타입을 블루프린트로 빠르게 빌드하고 핵심로직은 C++로 최상위까지 만들어 두는 게 좋다.

많은 이야기를 했지만, 소규모 팀에서 가장 중요한 것은 바로 '끝 없는 커뮤니케이션'이다. 한 두시간이 걸리든 며칠이 걸리든 소통을 통해 무슨 게임을 만들지 확실히 공유해야 한다. 그래야 만들고 싶은 게임에 좀 더 다가갈 수 있다.

이를 위해서는 수평적인 관계를 확립하는 게 매우 중요하다. 수직적인 관계에서는 애초에 소통을 기대하기 힘들다. 마지막으로 팀원 모두가 '멋진 게임을 만들자'라는 열정을 가지고 있어야 한다. 이러면 프로젝트를 성공할 수 있을 것이다.

댓글

새로고침
새로고침

기사 목록

1 2 3 4 5