P2P 멀티플레이어 히트작 Ship of Fools로 항해에 나선 Fika Productions

Fika Productions는 협동 로그라이트 게임이라는 흔치 않은 장르로 시장에 진출하며 로컬 협동 게임에 주목했습니다. 하지만 2020년, 팬데믹이 전 세게를 강타했습니다. 이번에는 리드 게임플레이 프로그래머 대니얼 카마이클과 개발자 야니크 반더루를 만나 Fika Productions의 게임에 대해 이야기하고, 게임 업계가 혼란스러웠던 시기에 Ship of Fools를 출시하기 위해 어떤 개발 과제를 해결해야 했는지 들어 보았습니다.

Ship of Fools는 어디에서 영감을 받았나요? 혹시 항해와 관련된 배경을 가진 동료가 있으신가요?

대니얼: 첫 번째로 떠오른 영감은 협동 로그라이트 게임 장르로 시장의 빈틈을 공략한다는 것이었습니다. 저희 팀은 모두 로그라이트 장르의 팬인데요, 지금까지 훌륭한 로그라이트 게임이 많이 출시되었지만 그중에서 협동 플레이가 제대로 구현된 작품은 없다고 생각했습니다. 

테마 측면에서도 선박이라는 아이디어가 마음에 들었습니다. 배가 가라앉으면 다 함께 가라앉으니까요. 협력을 통해 배가 가라앉지 않도록 하는 것이 바로 핵심 아이디어입니다. 항해를 해 본 동료가 있거나 저희가 바닷속 출신인 건 아니에요.

팀에 인어나 뱃사람은 없다는 말씀이시군요. 알겠습니다. 시장 조사는 어떤 식으로 진행하셨나요?

대니얼: 시장 조사라고 해도 Reddit에서 약간 찾아본 게 전부였지만, 그래도 매우 많은 정보를 얻을 수 있었습니다. 로컬 협동과 로그라이트에 관한 서브레딧 25~30개에서 ‘성공적인 협동 로그라이트 게임에 필요한 요소가 무엇이라고 생각하는지’에 대한 질문을 던졌습니다. 그렇게 받은 많은 제안 사항을 문서로 요약하고 중복되는 부분과 핵심 내용을 분석했어요. 이 과정에서 여러 아이디어를 검증하고 새로운 아이디어를 얻기도 했습니다. 

Ship of Fools를 제작하며 가장 좋았던 순간은 언제인가요?

대니얼: 사무실에서 저희끼리 하는 농담이 있었어요. 작은 기능을 구현하면 매번 누군가 “게임 완성!”이라고 외치고는 했죠. 그러던 어느 날 게임에서 상당히 중요한 대규모 파트를 병합한 다음 제가 플레이 테스트를 진행했고, 너무 기뻐서 팀원들에게 “팔 수 있는 게임 완성!”이라고 외쳤어요. 정말 잊지 못할 특별한 느낌이었죠. 매우 자랑스러운 순간이었습니다.

게임의 멀티플레이어 개발 과정에서 특별히 어려웠던 점은 무엇이고, 어떻게 극복하셨는지 알려 주실 수 있을까요?

야니크: 호스트나 클라이언트가 모든 부분을 완전히 제어하는 경우라면 보통은 게임 내 네트워킹이 간단한 방법입니다. 하지만 어떤 요소는 로컬 플레이어가 관리하고 다른 요소는 게임 호스트가 관리하는 식으로 관리 주체를 분할해야 하면 상황이 어려워집니다.

이러한 설정에서 특히 까다로운 부분은 발사체였습니다. 발사체가 경쾌한 느낌으로 나가는 느낌을 주고 싶었기 때문에 수없이 많은 시나리오를 고려해야 했습니다. 게다가 적이 반격하며 발사한 탄환을 플레이어가 다른 방향으로 쳐낼 때 어떤 플레이어도 어색하게 느끼지 않도록 상호작용을 세심하게 계획해야 했고, 이는 지연 시간이 긴 상황에서도 마찬가지였죠. 수많은 예외 상황을 고려해야 했습니다. 특히 플레이어 모두가 빠른 속도감과 높은 반응성을 경험할 수 있어야 했죠.

대니얼: 또 다른 심각한 걸림돌은 네트워킹 문제였습니다. 로컬 협동 플레이에 맞는 게임을 디자인하는 데 1년 반이라는 긴 시간을 보냈습니다. 온라인 플레이는 전혀 고려하지도 않은 채 말이죠. 그런데 갑자기, 팬데믹이 터지고 말았어요. 별안간 사람들이 서로 어울리지 못하고 집에 갇혀 지내야 하는 상황이 되면서 로컬 전용 게임은 의미가 없었습니다.

원래는 서로 얼굴을 맞대고 다함께 즐길 수 있는 게임을 만드는 중이었고, 그런 분위기가 저희 게임의 핵심이었어요. 하지만 팬데믹이 시작되면서 퍼블리셔는 게임을 온라인으로 전환할 것을 제안했고, 저희도 새로운 도전에 나섰죠. 게임의 모든 부분을 온라인 플레이에 맞게 바꿔야 했는데, 지난 1년 동안 진행한 작업을 모조리 다시 하는 것처럼 힘들었어요.

개발자 여러분께 팁을 하나 드리자면, 처음부터 온라인 플레이를 염두에 두는 편이 좋습니다. 100% 확신하지 않더라도 말이죠. 온라인을 염두에 두면 게임을 더 안정적으로 디자인할 수도 있고, 나중에 새로운 기능을 자꾸 추가하는 것보다 이미 구현된 기능을 제거하는 편이 훨씬 쉽습니다.

발사체 문제를 어떻게 관리했는지 조금 더 자세히 알려주세요. 특히 어떤 방식으로 Netcode for GameObjects를 사용하셨나요?

야니크: 게임에 네트워킹을 적용하는 작업은 결국 독특한 방식으로 진행되었습니다. 저희에게는 기존 Netcode for GameObjects 설정이 없었어요. 대신 클라이언트와 호스트 양쪽 모두에 존재하는 오브젝트를 사용하여 서로의 동작을 인식하고 누가 제어하고 있는지 언제든 알 수 있게 했죠. 마치 상시 대화를 통해 서로에게 무슨 일이 일어나고 있는지 업데이트하는 것과 같습니다.

예를 들면 총알이 발사되는 시나리오의 경우, 총알이 호스트 측 목표물에 명중하면 게임은 클라이언트가 명중 여부를 확인할 때까지 기다립니다. 클라이언트는 명중했다고 할 수도 있고, 피했다고 할 수도 있으며, 심지어 총알을 튕겨냈다고 할 수도 있습니다. 클라이언트의 리스폰스에 따라 게임은 결과를 조정하고 양측을 동기화합니다.

이렇게 설정하면 유연성을 크게 높일 수 있습니다. 클라이언트 측 플레이어는 총알을 다른 방향으로 쳐내는 등 자신의 동작에 게임이 즉시 반응하는 모습을 볼 수 있으므로 게임의 반응성을 높일 수 있습니다. 그러나 최종 결과는 호스트의 입력에 따라 조정되어야 할 수 있으며, 불일치가 있다면 최초 반응이 오버라이드될 수도 있습니다.

약간 사교 댄스와 비슷하죠. 권한이 이쪽저쪽으로 바뀔 수 있으니까요. 저희가 찾은 가장 간단한 솔루션은 양측이 각자의 일을 하도록 두고, 상대방의 피드백을 바탕으로 차이가 발생하면 조정하는 방식이었습니다. 이는 호스트와 클라이언트 양측이 게임 플로에 기여할 수 있는 협업 프로세스입니다.

독자분들을 위해 시각 자료를 준비했습니다.

첫 번째 이미지에서 멀티플레이어 설정을 보면, 제가 호스트로서 왼쪽에 있는 토드를 플레이하고, 제 친구가 클라이언트로서 오른쪽에 있는 힝크를 플레이합니다.

이제 크랩스터라는 적이 나타나 발사체를 쏩니다. 여기서 중요한 것은 조율입니다. 호스트와 클라이언트 모두 원격 프로시저 호출을 통해 정보를 받죠. 두 플레이어 모두 발사체를 볼 수 있지만, 발사체가 보트에 명중할 것인지 방향이 바뀔 것인지는 플레이어의 반응에 따라 달라지며, 호스트는 최종 결과를 확인하기 위해 클라이언트의 입력을 기다려야 합니다.

마지막 이미지는 힝크를 플레이하는 클라이언트가 발사체의 방향을 바꿨을 때의 모습입니다. 핑이 높으면 약간의 지연이 발생하기 때문에 호스트가 처음에는 발사체가 보트에 명중하는 것처럼 볼 수 있지만, 클라이언트의 반응이 확인되면 이는 저절로 수정됩니다. 그러면 클라이언트는 지연을 느끼지 않고 실시간으로 게임을 플레이하는 것처럼 느낄 수 있으며, 클라이언트의 행동이 호스트에 반영되어 게임을 동기화합니다.

이 아이디어의 핵심은 플레이어가 총을 쏘거나 공격을 방어할 때 즉시 반응을 제공하여 원활한 느낌의 멀티플레이어 경험을 실현하는 것입니다.

공유해 주실 만한 다른 구체적인 이야기가 있나요? 독자들에게 주고 싶은 유용한 팁이 있다면 알려 주세요.

대니얼: 아주 많은 문제가 발생했지만, 그중에서도 가장 큰 것은 메모리 관리 문제였습니다. 특히 저희 팀이 처음 제작하는 멀티플레이어 게임이었기 때문에 어셈블리와 어드레서블을 빠르게 익히고 적용해야 했습니다.

흥미로운 점은 에셋이 그렇게 많지 않음에도 게임 로딩에 2분이나 걸렸던 적이 있어요. 이렇게 작은 게임에서는 말도 안 되는 속도죠. 당연히 플레이어의 항의를 들었습니다.

아무튼 그런 식으로 힘들게 메모리와 에셋을 간소화하는 방법을 배울 수 있었어요. 처음부터 기본에 충실했다면 더 좋았을 겁니다. 

어드레서블은 어땠나요? 무엇을 배웠는지 구체적으로 알려 주세요.

야니크: 어드레서블을 사용하는 방법은 매우 간단합니다. 에셋을 동시에 로드하기에 적합한 그룹으로 구성하면 됩니다. 그러면 특정 씬에서 사용되지도 않는 에셋으로 인해 게임이 복잡해지는 것을 방지할 수 있습니다.

이를테면 저희 게임에는 각기 다른 섹터가 있으며, 섹터마다 고유의 적, 씬, 배경이 있습니다. 처음에는 모든 것을 하나의 거대한 그룹으로 묶었으나, 로딩 시간이 너무 오래 걸렸습니다. 그래서 간소화된 구성을 위해 섹터별로 에셋을 그룹화했더니 엄청난 차이가 생겼습니다. 필요에 따라 한 섹터의 적이나 배경만 로드할 수 있어 모든 것이 훨씬 더 효율적이고 원활해졌죠.

네트워킹 작업에 NGO(Netcode for GameObjects)를 선택한 이유는 무엇인가요?

야니크: 네트워킹에 NGO를 선택한 이유는 유니티의 지원을 받을 수 있기 때문입니다. 플랫폼과 함께 발전하고 장기적인 지원을 받을 수 있다는 것인데, 저희에게 매우 중요한 부분이죠. 게다가 필요한 모든 기능이 NGO에 갖춰져 있었습니다.

저희가 원했던 핵심은 P2P 연결을 사용하는 것이었습니다. 향후 매출과 플레이어 기반이 불확실한 게임에서 서버 비용은 큰 문제가 될 수 있으므로 회피해야 했죠. NGO를 통해 현재의 요구 사항과 미래의 개발 모두를 위해 안전한 선택을 했다고 확신했습니다. Unity 생태계에 남아 게임에 대한 장기적인 지원을 보장받는 것이 가장 현명한 선택이었죠.

Ship of Fools의 향후 계획은 무엇인가요?

지금까지 새로운 콘텐츠로 가득 찬 두 차례의 대규모 업데이트가 진행됐고, 새로운 캐릭터를 선보이는 두 개의 DLC를 출시했습니다. DLC는 완전히 선택 사항이기 때문에 구매하지 않더라도 게임에 제한이 없습니다. 그저 더 많은 선택권을 가질 수 있을 뿐이죠. 가장 멋진 부분은 그런 주요 콘텐츠 업데이트가 무료로 진행되었고, 저희가 보기에는 플레이어들이 매우 좋아했다는 점입니다.

앞으로의 계획은 현재로서는 비밀로 하고 싶네요. 하지만 향후 업데이트에 대한 정보를 공개할 준비가 되면 꼭 알려 드리겠습니다.

멀티플레이어 개발에 관심이 있으신가요? 2024 유니티 게임 업계 보고서의 멀티플레이어 섹션을 살펴보고 성공을 거둔 스튜디오의 인사이트, 더 많은 스튜디오가 멀티플레이어 게임을 개발하는 이유에 대한 최신 데이터, 팀의 경쟁력을 높이는 데 도움이 되는 다양한 팁을 확인해 보세요.