Survival Kids 멀티플레이어 네트워크 인프라 내부 살펴보기

이번 여름, Survival Kids가 Nintendo Switch™ 2의 출시 당일(day-one) 타이틀로 출시되었습니다. 이 게임은 전적으로 Unity 6를 기반으로 구축되었으며, 퍼블리셔 파트너인 KONAMI와 긴밀히 협력하여 진행된 Unity의 사상 첫 엔드 투 엔드 (end-to-end) 개발 프로젝트입니다.

출시 첫날 새로운 플랫폼을 대상으로 개발하는 것은 매우 큰 도전이지만, 이 프로젝트를 구축한 소규모 내부 팀에는 수십 년 동안 Unity와 게임 분야에서 일해온 숙련된 Unity 개발자들이 포함되어 있었습니다. 이 블로그는 게임이 어떻게 만들어졌는지, 이 작업이 프로덕션 검증 (production verification)에 대한 Unity의 약속을 어떻게 강화했는지, 그리고 다른 Unity 게임 개발자 (gamedevs)들이 자신의 프로젝트에 가져와 적용할 수 있는 교훈은 무엇인지 깊이 있게 파헤치는 연속 시리즈의 일부입니다. 이것은 Survival Kids 작업 과정에서 얻은 팀의 교훈을 파헤치는 비하인드 스토리 시리즈의 첫 번째 게시물입니다.

Nintendo Switch는 Nintendo의 상표입니다.

Survival Kids는 Unity 내부의 매우 작은 팀에 의해 구축되었습니다. 핵심 그룹은 다양한 분야(아티스트, 엔지니어, 디자이너)의 개발자 약 10명으로 구성되었습니다. 다른 Unity 팀 인원들이 합류하면서 정점일 때는 약 20명 정도였습니다. 예를 들어, 우리의 렌더링 엔지니어 (rendering engineer)인 Steven은 우리와 많이 협력했지만, 항상 프로젝트에 참여했던 것은 아닙니다.

소규모 팀으로서 우리는 몇 가지 장점도 있었습니다. 엔지니어들은 매우 경험이 풍부했습니다. 우리 대부분은 주로 AAA 분야에서 20여 년 동안 게임을 만들어 왔기에 많은 교훈을 얻었고 많은 실수를 해왔습니다. 그리고 당연히 우리 대부분은 이곳에 꽤 오래 머물렀기 때문에 Unity에 매우 숙련되어 있습니다.

우리 중 일부는 현재 Unity Studio Productions인 Professional Services/Accelerate Solutions와 같은 Unity 지원 팀의 일환으로 고객 프로젝트에서 작업하기도 했습니다. 우리는 고객에게 프로젝트를 최적화하는 방법을 조언하고, 심지어 프로젝트 팀에 합류하여 그들과 함께 일하며 어려운 기술적 문제를 해결하는 데 도움을 주기도 합니다. 따라서 우리는 스튜디오들이 흔히 저지르는 실수와 이를 해결하는 방법에 대해 매우 잘 알고 있습니다.

Survival Kids를 작업하면서, 우리는 모든 함정이 어디에 있을지 알고 있었기 때문에 프로젝트를 설계하고 시작부터 올바른 경로로 안내할 수 있었으며, 이는 많은 시간과 자원을 절약해 주었습니다. 오늘 저는 이 게임의 네트워크 아키텍처 (Network Architecture)를 자세히 살펴보고자 합니다. 우리는 멀티플레이어 네트워킹 (Multiplayer Networking)을 구동하기 위해 Unity를 사용했으며, Survival Kids는 동일한 네트워킹 기반 위에서 플레이어들에게 게임을 즐길 수 있는 여러 가지 다양한 방식을 제공합니다. 그럼 이것이 어떻게 구현되었는지 자세히 알아보고, 여러분의 프로젝트에도 도움이 될 수 있기를 바랍니다.

Survival Kids는 싱글 플레이어 (Single Player), 로컬 협동 플레이 (Local Co-op), 그리고 친구들과 함께하는 온라인 플레이 등 몇 가지 방식으로 즐길 수 있습니다. Nintendo Switch™ 2에서는 플레이어가 GameShare를 사용하여 비디오를 다른 Nintendo Switch 2 또는 기존 Switch로 스트리밍한 다음, TV나 기기에서 누군가와 멀티플레이를 즐길 수도 있는데, 이는 정말 멋진 기능입니다. 우리는 우리의 설정이 이러한 방식과 다른 조합들을 모두 구동하기를 원했습니다. 예를 들어, 한 대의 TV에서 분할 화면 (Split Screen)으로 플레이하는 두 명의 플레이어가 다른 TV에서 분할 화면으로 플레이하는 또 다른 두 명의 플레이어와 연결될 수 있습니다. 즉, 두 대의 기기를 사용하여 네 명의 플레이어가 플레이하는 방식입니다. 이러한 유연성은 다양한 방식으로 플레이할 수 있도록 아키텍처 설계 단계에서부터 우리가 정말로 반영하고 싶었던 부분이었습니다.

이를 위해 우리는 Netcode for Entities를 사용하기로 결정했습니다. KONAMI에 Survival Kids의 컨셉을 제안한 후, 우리는 멀티플레이어 게임의 재미를 찾기 위해 즉시 프로토타이핑 (Prototyping) 단계로 들어갔습니다. 우리는 기존 프로젝트를 시작점으로 사용했는데, 이는 제가 이전에 Netcode for Entities를 백엔드 네트워크 (Backend Network)로 어떻게 사용할 수 있는지에 대한 개념 증명 (Proof of Concept)으로 작성했던 것이며, 그 위에 Prefab과 애니메이션 (Animations)을 활용할 수 있도록 GameObject 레이어를 작성했습니다.

팀원 모두가 Entities를 다뤄본 경험이 있는 것은 아니었기에, 우리는 GameObject와 MonoBehaviour를 함께 사용하기로 결정했습니다. 또한 우리는 게임플레이 로직을 GameObject와 MonoBehaviour에 유지하고 싶었는데, 이 방식이 프로토타이핑 (Prototyping)을 매우 쉽게 만들어주기 때문입니다. 이 설정을 사용하면 요소들을 빠르게 조합하고, 스크립트를 작성하거나, 인터넷에서 스크립트를 다운로드하거나, Asset Store 패키지를 사용하여 프로토타이핑을 진행할 수 있습니다. 우리는 그러한 빠른 반복 (Iteration)과 자유를 원하면서도, Netcode for Entities가 제공하는 고성능 네트워크 레이어 (Network layer)를 활용하고 싶었습니다. 저는 이미 몇몇 고객 프로젝트와 개인 연구 프로젝트에서 이를 사용해 본 적이 있었기에, 그 품질 수준이 우리가 원하는 수준의 게임플레이를 이끌어낼 수 있다는 것을 알고 있었습니다.

약 3년 전 처음 시작했을 당시에는 Netcode for GameObjects가 존재했지만, 우리가 원했던 몇 가지 기능, 특히 클라이언트 측 예측 (Client-side prediction) 기능이 여전히 부족했습니다. 클라이언트 측 예측이 있으면 서버와 클라이언트 사이에 지연 (Lag)이 발생하더라도, 클라이언트가 서버가 무엇을 할지 예측하여 즉시 실행합니다. 따라서 플레이어의 조작은 지연이 있을 때조차 반응성이 좋게 느껴집니다. 플레이어가 이동했는지 등에 대해 서버가 알려줄 때까지 기다릴 필요 없이, 이미 동작이 수행되고 있는 것입니다. 이는 Netcode for Entities가 처음부터 갖추고 있던 기능이었습니다.

프로토타이핑을 위해 우리는 기본적으로 이미 가지고 있던 프로젝트를 가져와 바로 시작했습니다. 물건을 줍거나 나무를 베는 것과 같은 간단한 것부터 시작하여, 점진적으로 게임플레이의 구체적인 내용을 채워나갔습니다. 여전히 프로토타이핑 단계였기 때문에 코드 품질 (Code quality)에 대해서는 크게 걱정하지 않았습니다. 우리는 재미를 찾으려 노력했으며, "모두를 위한 생존"을 포함한 우리의 게임 핵심 요소 (Game pillars)들을 살펴보았습니다. 우리는 생존 게임을 원했지만, 그것이 너무 어렵거나 가혹하기를 원하지는 않았습니다. 우리는 이 장르에서 정말로 재미있고 흥미로운 요소가 무엇인지 추출해내려 노력했습니다.

우리는 스스로에게 질문했습니다. 사람들이 제작 (Crafting)과 자원 수집 (Resource gathering)에서 좋아하는 것은 무엇인가? 그들이 신경 쓰지 않는 것은 무엇인가?

그 과정은 플레이어가 자원을 획득하는 방식, 자원을 한 곳에서 다른 곳으로 이동시키는 방식, 그리고 제작 (Crafting)을 수행하는 방식을 정의하는 데 도움이 되었습니다. 우리는 GameObject와 MonoBehaviour를 사용하여 프로토타이핑 (Prototyping)과 반복 (Iteration)을 매우 빠르게 진행함으로써 그 모든 것을 파악했습니다. 이러한 작은 개념 증명 (Proof-of-concept) 데모에서 시작했기 때문에, 시작 단계부터 바로 인터넷 주소로 연결할 수 있었습니다. 컴퓨터 IP를 사용하여 연결하는 것도 가능했지만, 우리는 클라우드의 릴레이 (Relay) 서버에 게임을 호스팅할 수 있게 해주는 Unity의 Relay 서비스도 사용했습니다. Relay를 사용하면 누구나 참여 코드 (Join code)를 사용하여 해당 게임에 참여할 수 있으며, 사람들은 VPN이나 알려진 IP 없이도 집이나 사무실에서 연결할 수 있습니다. 덕분에 우리는 매주 플레이테스트 (Playtest)를 진행하는 리듬을 갖출 수 있었고, 직장과 집의 네트워크에서 테스트를 수행함으로써 다양한 연결 속도 환경에서 게임플레이와 함께 네트워크 아키텍처 (Network architecture)에 대한 스트레스 테스트 (Stress-test)를 병행할 수 있었습니다. 결국 우리는 프로덕션 (Production) 환경에서도 Relay를 유지했습니다.

우리는 가능한 한 공개적으로 출시된 패키지 (Packages)에 가깝게 유지하려고 노력했습니다. 만약 패키지 중 하나에서 버그를 발견하면, 이를 식별하고 패키지를 로컬 (Locally)로 가져와 수정하려고 시도했습니다. 때로는 이후에 Slack을 통해 Unity의 Netcode 팀에 메시지를 보내 문제와 우리가 수정한 내용을 설명하여, 그들이 이를 가져가 풀 리퀘스트 (PR, Pull Request)를 생성하고 최종 버전에 포함할 수 있도록 했습니다. 우리가 반드시 수정 과정에 직접 참여한 것은 아니었지만, 프로덕션 환경에서 작업함으로써 그들이 아직 발견하지 못한 몇 가지 문제들을 찾아낼 수 있었습니다 (물론 때로는 그들이 우리가 생각해낸 것보다 더 나은 수정안을 가지고 있었거나, 우리가 잘못 사용하고 있다고 알려주기도 했습니다).

Relay를 통해 원격으로 이러한 방식으로 개발했기 때문에, 출시 직전이 되어서야 나중에 오프라인 모드 (Offline mode)를 추가했습니다. 오프라인 모드는 네트워크 소켓 (Network sockets)을 열지 않으며, 인 프로세스 드라이버 (In-process driver)라고 불리는 것을 사용합니다. 이는 효과적으로 서버와 클라이언트가 있는 네트워크처럼 동작하지만, 이들은 동일한 프로세스 내에서 실행되며 서로 통신합니다. 네트워크를 통해 전송하는 대신, 클라이언트로 직접 데이터를 전송합니다.

이것은 프로세스 내 연결 (in-process connection)이라고 불리며, 실제 바이트 (bytes)가 네트워크를 통해 이동하기를 기다릴 필요가 없기 때문에 매우 빠릅니다. 하지만 게임플레이가 진행되는 것과 동일한 모든 흐름을 거칩니다. 이런 방식으로 작동함으로써, 우리는 별도의 버전을 코딩할 필요가 없었습니다. 이것이 우리의 싱글 플레이어 (single-player) 모드이자 멀티플레이어 (multiplayer) 모드입니다. 싱글 플레이어와 오프라인은 여전히 네트워크 게임이지만, 단지 네트워크를 사용하지 않을 뿐이며 모든 것이 내부적으로 발생합니다. 이는 기본적으로 우리가 어디에서나 사용할 수 있는 하나의 코드 아키텍처 (code architecture)를 가졌음을 의미합니다. 하지만 그 대가로, 호스팅을 하거나 싱글 플레이어 모드일 때는 서버 (server)와 클라이언트 (client)를 모두 시뮬레이션해야 하므로, 두 가지를 동시에 실행하는 성능상의 과제 (performance challenge)가 발생합니다. 전용 서버 (dedicated servers)의 경우, 서버가 어딘가에 있는 서버 팜 (server farm)에 존재할 수 있으므로, 사용자는 클라이언트 (client)라고 불리는 것만 있으면 되며, 이는 서버가 전달하는 모든 것에 반응하고 매끄럽게 보이도록 만들어 줍니다. 하지만 싱글 플레이어에서는 시뮬레이션 중이기 때문에, 게임이 두 가지 역할을 모두 수행해야 하며 어딘가에 있는 전용 서버에 따로 떨어져 있을 수 없습니다. 결과적으로 이것은 우리의 가장 큰 성능 과제 중 하나가 되었으며, 서버와 클라이언트가 동일한 게임 내, 동일한 프레임 (frame) 안에 머물면서도 좋은 해상도에서 초당 60프레임 (60 frames per second) 목표를 달성할 수 있도록 최적화하는 것이었습니다. 그 목표는 우리에게 정말 중요했습니다.

Survival Kids 제작 과정을 심층 분석하는 블로그 시리즈의 다른 게시물들도 확인해 보세요:

• "Survival Kids의 그래픽 및 렌더링 팁"
• "Survival Kids의 레벨 레이아웃 및 지형 워크플로우"
• "Survival Kids 멀티플레이어 네트워크 인프라 내부 살펴보기"

Unity로 제작된 프로젝트에 대해 더 자세히 알아보려면 리소스 (Resources) 페이지를 방문하세요.