4인 개발팀으로 턴제 전략 게임의 공식을 다시 쓴 RESEARCH and DESTROY

공식 홈페이지에서 빠른 프로토타이핑과 최고 퀄리티 게임 개발의 비결로 언리얼 엔진을 통한 다양한 개발 경험을 꼽으셨는데요. 언리얼 엔진이 어떻게 그걸 가능하게 하는지 설명해 주시겠어요?

대니얼 마키위츠: 지난 여러 인터뷰에서 언급했던 터라 달리 뭐라 말해야 좋을지 모르겠지만, 어쨌든 언리얼 엔진은 사실상 없는 게 없지 않나요? 이 프로젝트를 시작했던 시점을 생각하면 지금 제공되는 기능 중에 없었던 기능도 있긴 했습니다. (언리얼 마켓플레이스가 그 당시에도 지금과 같았다면 참 좋았을 텐데 말이죠!) 하지만 3D 게임을 제작한다면, 제작하려는 대상에 따라 몇 주 혹은 며칠 만에 쓸만한 프로토타입을 얻을 수 있는 완벽한 툴박스죠.

특히 블루프린트를 사용하면 신규 게임플레이 피처를 아주 쉽게 프로토타이핑할 수 있습니다. 정말 유용한 샘플 프로젝트가 포함되어 있어서 어려운 시스템도 간단하게 이해할 수 있도록 해주거든요. 슈팅 게임(Shooter Game) 샘플 프로젝트를 특히 요긴하게 참조했습니다.

도쿄 인디 페스트와 비트서밋에서 리서치 앤 디스트로이에 대한 플레이어들의 반응을 유심히 살피셨을 텐데, 플레이 이후 설문 조사에서 알아낸 것들이 게임 발전에 어떤 영향을 미쳤나요?

크리스 윌러시: 두 이벤트에서 모두 거의 전적으로 긍정적인 피드백을 받았기 때문에 주요 요소들을 빼거나 리팩터링할 필요는 없었지만 확연히 눈에 띄는 일부 문제들은 수정이 필요했죠. 예를 들어, 초기 버전 무기 중 시험관 발사기(Test Tube Launcher)는 재장전은 느리고 폭발력은 극도로 막강했으며 보조 모드인 보호막은 상황을 너무 많이 탔어요. 폭발 모드는 팀킬이 과다하게 일어났고 보호막 모드는 사용 비중이 너무 적다는 것을 단번에 알 수 있었습니다. 그런 부분들이 꽤 있었어요. 뼈대는 잘 잡아 놓았지만 세부적인 부분은 개선의 여지가 있었죠. 저희의 피조물은 아직도 손이 갈 부분이 많았습니다.

새로운 플레이어가 저희 게임을 플레이하는 모습을 볼 때마다 새롭게 배우는 점이 있습니다. 자신감도 어느 정도 필요하지만 초보 플레이어들이 게임상에서 플레이하는 방식을 이해하려면 제삼자의 관점에서 보는 것이 매우 중요합니다. 자존심을 접어두고 첫술이나 두 술 혹은 세 술 만에 배부를 수 없다는 사실을 인정하는 노력이 필요합니다. 이처럼 새로운 관점으로 보는 것은 매우 중요합니다. 새로운 관점이 없이는 몇몇 사람만의 경험과 감정을 바탕으로 게임을 만들게 되기 십상인데, 이는 좋지 않은 결과물로 이어지기 마련입니다.

결국에는 피드백을 통해 큰 틀은 옳게 잡아가고 있으나 플레이어들이 게임을 이해할 수 있도록 보조적인 시스템을 추가해야 한다는 것을 알 수 있었습니다. 쉽지만은 않은 길이었지만, 다행히 충분히 시간을 두고 여러 사항을 유기적으로 고쳐 나갈 수 있었습니다.

하옌탄: 리서치 앤 디스트로이를 직접 시연하면서 느낀 것은 이 게임의 독특한 시간 기반 메커니즘으로 인해 직접 설명하는 건 많은 시간이 소요된다는 것입니다. 도쿄 인디 페스트와 비트서밋이 끝난 후, 데모 버전과 정식 게임 버전 양쪽에 메인 메뉴에서 언제나 바로 들어갈 수 있는 독립형 튜토리얼 미션을 만들었습니다. 집에 놀러 온 친구와 로컬 협동으로 미션을 플레이해 보고 싶다면 친구에게 튜토리얼을 몇 분 정도 플레이해 보도록 하는 거죠. 그러면 게임의 메커니즘을 완벽하게 이해할 수 있습니다.

마키위츠: 그리고 또 한 가지 배운 건 팀킬을 보고 즐거워하는 사람들이 어디에나 있다는 겁니다.

리서치 앤 디스트로이를 개발하는 데에 언리얼 엔진을 사용하기로 결정한 요인은 무엇인가요?

윌러시: 저희 세 명의 다양한 언리얼 엔진 사용 경력을 합하면 30~40년 정도의 시간이 되니, 그 부분은 논의할 생각조차 없이 다들 당연하게 여겼습니다. 저희는 리서치 앤 디스트로이 개발 비용에 보태기 위해 언리얼 엔진에 대한 개발진의 역량을 살려 지난 6년간 여러 프로젝트 개발에 참여하였으며, 참여할 때마다 새로운 것을 배울 수 있었습니다. 그래서 제작 초기에 완성한 요소들은 개발 과정 동안 새롭고 더 나은 방법을 습득할 때마다 한두 번 정도 다시 고쳤습니다.

게임에 사용해야겠다는 생각을 갖게 한 특정 엔진 요소가 있었나요?

마키위츠: 크로스 플랫폼 기능을 꼽을 수 있는데, 이는 이미 클라이언트의 프로젝트를 돕는 저희의 '본업'에서 항상 사용하고 있었습니다.

윌러시: '시점'과 '이유'만 납득할 수 있으면 다양한 분야에서 매일 마주쳐야 하는 수학적 계산에서의 수많은 '방법'은 언리얼 엔진이 대부분 해결해 주었습니다. 전 수학에 뛰어난 편이 아니라 그 덕을 톡톡히 봤죠.

하옌탄: 아티스트들에게 언리얼 엔진은 항상 훌륭한 툴입니다. 상대적으로 작은 단순 소스 에셋 풀에도 콘텐츠에 다양성을 더할 수 있는 수많은 방법이 언제나 있으니까요.

디자인과 관련하여 극복한 과제가 있다면 설명해 주실 수 있을까요?

윌러시: 소규모 팀이 얼마 되지 않는 예산으로 야심 찬 타이틀 개발에 착수했다는 점에서 대부분의 디자인 과제가 생겨났던 것 같습니다.

다양한 무기, 장치, 게임플레이 액터를 디자인하여 통일성 있게 결합하는 것이 가장 큰 과제였습니다. 단지 무기와 장치 사이에 저희가 미처 예상치 못한 상호작용이 있었다는 이유만으로 디자인의 일부가 된 의외의 게임플레이 요소들이 다수 있었습니다.

아홉 가지 무기에 무기당 두 가지 기능 모드와 여덟 가지 업그레이드 조합이 들어가며 아홉 가지 장치에 장치당 두 가지 잠재적인 업그레이드가 들어가고 종종 서로 다른 방식으로 영향을 미치기 때문에, 숫자를 생각하면 골치가 아픕니다. 다행히 저 혼자만 골치를 싸매지 않고, 작은 팀 규모 덕에 예리한 디자인 감각을 지닌 다른 팀원들과 서로 아이디어를 긴밀히 검토하여 워크플로를 번잡하게 하지 않으면서도 기여할 수가 있었습니다.

구체적으로, 모든 전투 데이터를 외부 스프레드시트에 중앙화한 것을 예로 들 수 있습니다. 레벨 디자인과 적 스폰 시스템을 담당하는 사람은 저 혼자였기 때문에 전투에 살을 입히고 반복작업을 빨리 수행할 코드를 작성해야 했는데요. 스프레드시트와 언리얼 엔진의 데이터 임포트 시스템을 사용해서 전투 오버로드 및 언더로드 시 발생하는 문제를 재빨리 시각화할 수 있었죠. 데이터를 그래프로 변환하고 읽을 수 있는 UE4 링크를 여럿 생성하여 임포트 전에 유효성 검사를 수행할 수 있었습니다. 덕분에 프로젝트를 수행하면서 몇 주 혹은 몇 달이 걸렸을 작업 기간을 절약할 수 있었습니다.
UE4는 데이터 기반 접근법을 택할 경우 많은 시간을 절약할 수 있습니다.

또 다른 예를 들자면, 저는 오디오 부문 역시 담당하고 있는데 배경 음악에 많은 시간을 할애할 수가 없어서 턴 대상, 컨트롤하는 캐릭터, 게임플레이 이벤트 등의 다양한 요소에 따라 음악을 바꿔주는 동적 음악 시스템을 구상했습니다. 처음에는 이를 언리얼 엔진 타임 신디로 구현했고 이후에는 쿼츠로 구현했는데, 쿼츠로 제가 오랫동안 바라왔던 것들을 모두 구현할 수 있었습니다. 이 덕에 머릿속에서 생각만 하고 여러 이유로 15년간 구현할 수 없었던 것을 아주 기분 좋게 구현할 수 있었죠. 향후 다른 프로젝트에서는 여기서 한 발짝 더 나아가보고 싶습니다.

마키위츠: 이 게임의 핵심 요소 중에는 시간을 다 사용한 캐릭터는 멈춘다는 개념이 있습니다. 캐릭터가 현재 달리는 중이든 비행 중이든 추락 중이든 래그돌 버그가 일어났든 상관없습니다. 무조건 수행 중인 동작을 멈춰야 하고 때가 되면 바로 계속할 수 있습니다. 이는 특히 온라인 멀티플레이어 모드에 있어서 해결해야 할 예상보다 더 큰 과제였습니다.

예를 들어, 늑대인간을 폭발을 통해 공중에 띄운다고 가정해 봅시다. 물론 이를 행동에 옮기는 사람은 아주 나쁜 사람이지만요. 늑대인간은 두 아이를 키우는 한부모 가정의 가장이었거든요! 어쨌든 늑대인간은 허공에서 래그돌 피직스에 따른 포즈를 취한 채로 멈출 겁니다. 한 번에 많은 캐릭터가 게임에 함께 참여하여 많은 폭발을 일으킬 것이므로 정지한 래그돌이 많이 생겨나겠죠.

네트워크상에서 이들을 동기화하는 것은 이 시스템을 처음 구현했을 때만 해도 염두에 두지 않은 것이었습니다. 이런저런 접근법을 시도해 봤지만 제대로 구현하기 힘들었고, 네트워크 상태가 좋지 않을 때는 특히나 더 그랬죠. 대부분의 게임에서 래그돌은 보통 캐릭터가 사망할 때 작동하며 사망 시점에는 대부분 장식성 요소 정도로 볼 수 있습니다.

리서치 앤 디스트로이에서는 폭발에 따라 허공에 멈춰 있는 늑대인간을 조준하여 시간이 허용하는 내에 헤드샷을 쏠 수 있습니다(아주 나쁜 사람이네요). 결국 모든 무기의 타격 탐지를 클라이언트 권한으로 돌려서 이 문제를 해결했습니다. 즉, 일반적인 방식대로 서버에서 피격 여부를 판정하는 대신, 피격 여부를 판정하여 서버에 전달하는 것이 클라이언트의 몫이라는 겁니다. PvP 게임이었다면 이는 매우 골치 아픈 치트 등의 문제를 수반했겠지만 저희는 그다지 신경 쓰지 않았습니다. 가장 중요한 점은, 비록 호스트가 보기에는 공중에 있는 적의 머리 위치가 클라이언트와 다르더라도, 클라이언트 플레이어의 관점에서 제대로 머리를 조준해 쏘기만 했다면 피격 판정이 나온다는 겁니다. 그래서 호스트 플레이어 입장에서는 뭔가 시각적으로 이상한 점이 종종 있더라도 저희는 별로 개의치 않습니다. 그보다는 사격하는 플레이어의 경험이 더 우선시되기 때문이죠.

차세대 하드웨어와 언리얼 엔진의 장기적 가능성에 대해 팀에서 가장 기대하는 바는 무엇인가요?

윌러시: 개인적으로는 UE5의 메타사운드를 다뤄보고 싶습니다. 저는 오디오 작업을 정말 좋아하는데, 그 점이 리서치 앤 디스트로이의 오디오에 반영되었기를 바랍니다. 메타사운드는 게임플레이와 더욱 밀접하게 연결된 굉장한 오디오를 선사해 줄 것 같습니다.

하드웨어 측면에서는 게임 제작에 필요한 여러 잡무에 덜 신경 쓸 수 있는 날이 오길 고대합니다. 특히 이런 새로운 하드웨어가 UE5의 일부 기능들과 밀접하게 결합되고 있으니 저희 바람이 이루어지고 있다고 봐도 되겠죠.

마키위츠: 나나이트는 최신 콘솔 및 PC의 빠른 로딩 시간과 함께 결합되어 게임플레이상의 스케일(및 동적 스케일 조절) 잠재력에 대한 큰 기대를 심어줍니다.

시간 내주셔서 감사합니다. 임플러저블 인더스트리와 리서치 앤 디스트로이에 대한 자세한 정보는 어디에서 볼 수 있을까요?

임플러저블 인더스트리에 대한 자세한 내용은 http://implausibleindustries.com/에서, 리서치 앤 디스트로이에 대한 자세한 내용은 https://rad-official.com/ 페이지를 참조하세요.