자신만의 길을 찾는 것은 Pantheon: Rise of the Fallen 게임플레이의 핵심입니다. 플레이어는 어디든 갈 수 있고, 무엇이든 오를 수 있으며, 새로운 경로를 개척하고, 호기심을 따라 모험을 찾아 떠날 수 있습니다. 이는 이 MMORPG를 구축하는 제작사 Visionary Realms의 방식과도 크게 다르지 않습니다. 그들 또한 자신들만의 방식으로 개발을 진행하고 있습니다.

플레이어를 판타지 세계인 Terminus로 이동시키는 Pantheon: Rise of the Fallen은 오픈 월드를 방랑하며 우연히 발견하는 즐거움과 다른 플레이어와의 사회적 상호작용이 게임 경험의 중심이 되는 클래식 MMO(Massively Multiplayer Online) 게임을 연상시킵니다.

어떠한 멀티플레이어 게임을 만드는 것도 도전적인 일이지만, 이 정도 규모의 고도로 사회적인 온라인 게임을 만드는 것은 서사적인 퀘스트와 같습니다. 저희는 리드 프로그래머(Lead Programmer)인 Kyle Olsen과 만나 팀이 이 MMORPG 판타지 세계에서 플레이어들을 연결하기 위해 Unity를 어떻게 사용하고 있는지에 대해 이야기를 나누었습니다.

질문: Pantheon: Rise of the Fallen을 다른 MMO 게임과 차별화하는 요소는 무엇인가요?

Kyle Olsen: 확실히 사회적 측면입니다. 플레이어는 세계를 경험하고 그 안을 자연스럽게 이동해야 합니다. 어떤 면에서는 조금 더 반복적인 작업(Grind)이 될 수도 있지만, 저는 그것이 단순히 여기저기 텔레포트하거나 LFG(Looking For Group) 시스템에 참여하거나 던전에 배치되는 대신, 플레이어를 캐릭터와 게임, 그리고 세계에 더 깊게 연결해 준다고 생각합니다. 플레이어는 지형을 더 잘 배우게 되고, 길을 찾아야 하며, 퀘스트 마커 등을 따라 핀볼처럼 목표 사이를 튕겨 다니는 것보다 눈을 더 많이 사용하게 됩니다. 이는 좀 더 사고를 요하는 게임입니다.

질문: 플레이어 경험과 특정 월드 인스턴스(World Instances) 간의 동기화는 어떻게 관리하고 있나요?

Kyle Olsen: 저희는 소켓 전송 계층(Socket Transport Layer)을 위해 직접 구축한 ViNL이라는 자체 네트워크 라이브러리를 보유하고 있습니다. 이것이 모든 구역(Zone) 간 통신, 즉 구역과 구역 사이, 그리고 플레이어와 구역 사이의 통신을 담당하는 핵심 요소입니다. 백엔드(Back end)에는 SQL 서버를 사용하며, 이는 일종의 표준적인 방식입니다.

하지만 대부분의 전송(Transports)은 저희 자체 네트워크 라이브러리에 의해 처리됩니다. 이 거대한 세계를 위한 에셋 로딩(Asset loading)에는 어떤 방식으로 접근하시나요? 저희는 대륙을 타일(Tiles) 형태로 구워내는(Bake) 단계를 거치며, 여기에 연결할 수 있는 다양한 백엔드(Backends)를 갖추고 있습니다. 표준 프리팹(Prefabs)을 출력하는 방식이 있고, Unity 6 이전까지 사용했던 서브씬(Subscenes)을 출력하는 방식이 있으며, 추가적으로(Additively) 로드할 수 있는 실제 완전한 Unity 씬(Scenes)을 출력하는 방식도 있어 콘텐츠를 어떻게 출력할지 선택할 수 있습니다. Unity 6 이전에는 프리팹(Prefabs)에서 벗어나 DOTS 서브씬(Subscenes)을 로드하고 BRG를 기반으로 구축된 이를 사용하기 시작했습니다. 또한 스크립터블 오브젝트(Scriptable objects)를 사용하고 자체 데이터를 관리함으로써, 저희의 커스텀 배치 렌더 그룹(Batch render group)으로 직접 렌더링할 수 있는 출력 방식도 보유하고 있습니다. 덕분에 다양한 방식을 실험하고 테스트하며 어떤 것이 최상의 클라이언트 성능(Client performance)을 내는지 확인할 수 있었습니다. Unity 6 이전에는 서브씬(Subscenes)을 통해 대륙 전체를 출력하고 렌더링했지만, Unity 6와 함께 모든 것을 관리하기 위해 Instantiate Async 및 어드레서블(Addressables)을 사용하는 프리팹(Prefabs) 방식으로 다시 전환했습니다. 저희는 레지던트 드로어(Resident Drawer)와 GPU 오클루전 컬링(GPU occlusion culling)을 사용하고 있는데, 결과적으로 서브씬(Subscenes)이나 자체 배치 렌더 그룹(Batch render group)보다 훨씬 더 나은 성능을 보여주었습니다. 아마도 현재 다른 렌더 패스(Render paths) 중 일부는 GPU 오클루전 컬링(GPU occlusion culling)을 지원하지 않기 때문이라고 추측합니다. 그래서 꽤 많은 시행착오를 겪으며 여러 방식을 오갔고, 모든 메모리와 에셋 로딩(Asset loading)을 관리하기 위해 어드레서블(Addressables)을 사용하는 것으로 결정했으며, GPU 레지던트 드로어(GPU Resident Drawer)와 함께 일반적인 프리팹 인스턴스화(Instantiate Prefabs)를 사용하는 것이 현재 클라이언트 측 성능 면에서 가장 좋은 것으로 보입니다.

구체적으로 GPU 레지던트 드로어(GPU Resident Drawer)를 활용하기 위해 Unity 6로 업그레이드하신 건가요?
사실, 저는 오클루전 컬링(Occlusion culling) 때문에 정말 원했습니다. 특정 렌더 패스(Render paths)에서만 오클루전 컬링(Occlusion culling)을 사용할 수 있다는 사실을 몰랐기 때문에, Unity 6 이전과 동일한 서브씬(Subscene) 렌더링 방식을 사용하며 이를 적용하려 시도했으나 실제로는 아무것도 컬링(Culling)되지 않고 있다는 것을 깨달았습니다.

그래서 저희는 Resident Drawer를 사용했을 때 어떤 모습일지 확인하기 위해 Prefab 출력 방식으로 다시 전환하기로 결정했고, 그 결과 오클루전 컬링 (Occlusion Culling)과 FPS가 향상되었습니다. 초기에는 약간의 문제가 있었는데, Unity 6 이전에는 Instantiate Async가 없었기 때문에 타일을 인스턴스화 (Instantiate)할 때 약간의 스톨 (Stall, 멈춤 현상)이 발생했습니다. 인스턴스화되는 것들이 꽤 많았는데, 몇 가지 버그를 수정한 후 이를 Instantiate Async로 전환하자 로드 시의 스톨이 사라졌고 로드 이후의 전반적인 프레임 레이트 (Frame Rate)도 더 높아졌습니다. 결과적으로 양쪽 모두에서 이득을 본 셈입니다.

Unity 6로 전환하면서 정말 눈에 띄는 생산성 향상이 있었나요?
지금까지 말씀드린 모든 내용은 클라이언트 측면의 이야기였으므로, 저희 플레이어들이 그 이점을 경험했습니다. 개발자 측면에서는 에디터 (Editor)의 안정성과 성능이 상당히 향상되었습니다. Unity 6의 에디터 안정성은 매우 크게 개선되어, 이제 실제로 크래시 (Crash)가 발생하는 일은 매우 드뭅니다. 그것만으로도 적어도 코딩 측면에서는 엄청난 승리였습니다. 확실히 전체적으로 더 안정적이라는 느낌을 줍니다.

모든 것을 망가뜨리지 않고 변경 사항과 업데이트를 처리하는 방법은 무엇인가요?
저희는 레이블 (Label)을 매우 적극적으로 사용하여 어드레서블 (Addressables) 방식으로 빌드하며, 레이블별로 어드레서블 패키징 (Addressable Packaging)을 수행합니다. 따라서 특정 구역이나 구역 내의 에셋, 또는 주문과 연관된 VFX 같은 것을 수정하면, 해당 레이블과 관련된 번들 (Bundle)들만 업데이트됩니다.

그리고 저희만의 콘텐츠 전달 시스템(Content Delivery System)이 있는데, 게임을 Steam과 자체 패처 (Patcher)를 통해 제공하며 이 두 가지 모두 어드레서블 번들을 통해 작은 업데이트만을 전달하는 델타 변경 (Delta Changes) 방식을 처리합니다. 넷코드 (Netcode)는 애초에 동일한 버전이 연결되어야 하므로, 네트워크 라이브러리 (Network Library) 측면의 처리는 핸드셰이크 (Handshake) 과정에서 자동으로 이루어집니다.

MMO 게임이나 다른 야심 찬 멀티플레이어 프로젝트에 도전하려는 사람에게 어떤 조언을 해주고 싶으신가요?
제 생각에는 작게 시작해야 할 것 같습니다. 단계적인 과정입니다. 소규모 팀이라면, 작게 시작하세요. 그것은 단계적인 과정입니다.

소규모 팀이라면 너무 많은 것을 한꺼번에 감당하려 해서는 안 됩니다. 완전히 압도당할 수 있기 때문입니다. 하지만 이는 MMO뿐만 아니라 규모가 큰 모든 게임에 해당되는 이야기입니다. 아마도 기술 선택(technology selection)의 문제일 것입니다. 초기에 현명한 선택을 내리고 이를 고수해야 합니다. 수많은 미들웨어(middleware)와 백엔드 기술(backend tech)을 다루고 이들이 서로 잘 작동하도록 조율해야 할 텐데, 매번 가장 최신의 멋진 기술로 바꾸는 것은 결코 좋은 징조가 아닙니다.

이 게임을 통해 팀이 이룬 가장 흥며진 기술적 성취는 무엇인가요?
Unity로 구현된 오픈 월드(open world) MMO는 단언컨대 그리 많지 않다고 생각합니다. 저희는 거대한 팀을 보유하고 있지 않지만, 진정으로 거대한 게임을 만들고 있습니다. 따라서 저희는 작고 고립된 영역들에 집중하여 최선을 다해 개발한 다음, 다음 단계로 넘어가 피드백을 받는 방식을 취해야 합니다.

이 모든 패키지를 하나로 묶는 것은 상당히 새로운 영역입니다. MMO가 존재한다면, 주변에 수많은 사람들이 각자의 일을 하고 있는 듯한 MMO 특유의 정신(spirit)이 느껴져야 합니다. 그리고 저희는 그것을 해냈습니다. 저는 우리가 지금까지 나온 거의 모든 Unity 기반 MMO보다 더 잘 해냈다고 생각합니다. 그 점에 대해서는 스스로 자부심을 가져도 된다고 생각합니다.

Unity의 Resources 페이지와 이 블로그에서 개발자들의 더 많은 인사이트를 확인해 보세요. Steam에서 Early Access로 제공되는 Pantheon: Rise of the Fallen을 확인해 보세요.