하이스트리트 마켓이 Unity의 ECS로 VR MMO를 확장한 방법

하이스트리트: 칼라미티는 하이스트리트 마켓의 차세대 MMORPG의 도시 규모 슬라이스입니다. 팀은 전투 및 진행과 같은 핵심 기능을 테스트하기 위해 플레이어 커뮤니티에 이를 출시했습니다.

이 단계에서 팀은 멀티플레이어 경험의 확장에 집중하고 있습니다. 개발 중에 기술적 병목 현상에 직면했지만, 신중한 프로파일링과 반복을 통해 근본적인 문제를 식별하고 해결했습니다. 그들이 어떻게 했는지 보세요.

하이스트리트: 칼라미티: Unity 활용 사례

스튜디오가 기술적 도전을 극복하면서 멀티플레이어 개발을 어떻게 확장합니까?

그들이 네트워크 게임을 설정하기 시작했을 때, 팀은 두 가지 주요 도전에 직면했습니다: 컴퓨팅 및 렌더링 비효율성.

“컴퓨팅 측면에서 우리의 가장 큰 도전은 효율적으로 계산을 처리하는 것이었습니다. 특히 세계를 시뮬레이션하는 임무를 맡은 서버에 대해 그렇습니다.”라고 하이스트리트의 CTO인 Jack Qiao가 말합니다. “더 많은 플레이어와 네트워크 엔티티를 추가함에 따라, 서버는 이들을 효율적으로 처리하는 데 어려움을 겪었습니다.”

렌더링 측면에서, 대규모 몰입형 VR 세계를 구축하는 것은 어렵습니다. “VR은 플레이어가 탐험할 수 있는 많은 객체와 관심 지점이 있는 매력적인 환경을 요구합니다.”라고 Qiao가 설명합니다. “하지만 독립형 VR 하드웨어는 현대 PC GPU에 비해 제한된 GPU 성능을 가지고 있어 우리가 렌더링할 수 있는 것을 제한합니다.”

품질을 유지하기 위해 팀은 VR에 내재된 성능 한계를 균형 있게 유지하면서 모든 각도에서 보기 좋게 장면을 신중하게 설계했습니다.

결과

가장 최적화된 게임 지역에서 72 fps를 기록했습니다.

Scriptable Render Pipeline (SRP) 드로우 호출 수를 80에서 5로 줄였습니다.

단일 메쉬의 삼각형 수를 200만에서 50만으로 줄였습니다.

네트워크 효율성을 위해 Unity에 ECS를 채택했습니다.

팀은 먼저 데이터 흐름과 게임 로직을 처리하기 위해 Mirror의 전송 계층 위에 맞춤형 서버를 구축했습니다. “그 당시 대부분의 네트워킹 도구는 대규모 MMO가 아닌 캐주얼 모바일 타이틀을 위해 설계되었기 때문에 우리는 자체적으로 만들어야 했습니다.”라고 Highstreet의 수석 기술 아키텍트인 Omar Sleam이 말합니다.

Unity가 성능과 대규모 게임을 위해 구축된 생산 준비 완료 프레임워크인 Netcode for Entities를 도입했을 때, 팀은 Unity의 Entity Component System (ECS) 및 Netcode for Entities로 전환할 기회를 보았습니다. 확장성을 염두에 두고 설계된 이 프레임워크는 복잡한 게임 데이터를 더 작고 관리하기 쉬운 단위로 나누는 청크화를 도입했습니다. 이는 팀이 MMO에 필수적이라고 여겼습니다.

“Netcode for Entities를 사용하면 데이터는 전체 서버에 방송하는 대신 범위 내의 플레이어에게만 전송됩니다.”라고 Sleam이 설명합니다. “또한 멀티스레드로 되어 있어 서버 작업이 훨씬 더 효율적입니다.”

네트워킹을 넘어 팀은 Unity를 위해 ECS로 완전히 구축된 행동 트리 시스템도 개발했습니다. 이전 버전은 흐름 제어와 관련된 일반 기능을 구현하기 어렵게 만들었습니다. Unity 기반의 맞춤형 ECS 행동 트리는 이 한계를 해결하여 성능을 저하시키지 않으면서 유연하고 재사용 가능한 도구를 제공합니다.

팀은 네트워크 환경에서 원활하게 작동하도록 시스템을 설계하여 서버, 클라이언트 또는 둘 다에서 행동 트리를 실행할 수 있는 유연성을 제공합니다. 이를 통해 비핵심 행동을 클라이언트로 오프로드하여 성능을 개선하면서 핵심 게임 로직에 대한 중앙 집중식 제어를 유지할 수 있었습니다.

게임의 세션 기반 구조를 관리하기 위해 팀은 Unity의 멀티플레이어 서비스 생태계에 의존했습니다. Multiplay 호스팅은 게임의 세션 기반 특성에 이상적인 동적 서버 할당을 가능하게 했습니다. “자동화는 우리의 DevOps 부담을 줄여주었고, 게임 자체를 만드는 데 집중할 수 있게 해주었습니다.” Sleam이 말합니다. Matchmaker는 설정 및 위치와 같은 다양한 요소를 기반으로 플레이어를 그룹화하는 데 사용되어 균형 잡힌 저지연 매치를 보장하는 데 도움을 주었습니다.

Unity Lobby는 플레이어가 게임 세션에 참여하기 전에 그룹을 형성하고 관리할 수 있도록 파티 시스템을 지원했습니다. Friends는 Lobby와 통합되어 서로 다른 서버 간에 파티를 유지할 수 있게 하여 플레이어가 최소한의 구현 노력으로 연결 상태를 유지할 수 있도록 했습니다.

이 도구들은 호스팅, 매치메이킹, 파티 관리 및 소셜 시스템을 포함하는 완전한 멀티플레이어 백본을 제공하면서 구현을 경량화하고 확장 가능하며 고성능 게임 플레이에 최적화되었습니다.

Unity의 ECS로 모듈성을 개선하기

팀은 GameObject 기반 디자인에서 Unity의 ECS로 전환하는 동안 가파른 학습 곡선을 경험했지만, 온보딩 후 생산성이 크게 향상되었습니다.

“Unity의 ECS는 많은 오버헤드를 줄였습니다. 부분적으로는 아키텍처 때문이고, 부분적으로는 우리가 상향식 디자인 접근 방식으로 전환했기 때문입니다.” Qiao가 말합니다. “GameObjects와 달리, GameObjects는 신중하게 설계되지 않으면 종종 중복된 논리를 초래했지만, Unity의 ECS는 모듈식, 구성 요소 기반 디자인을 강제했습니다. 이는 자연스럽게 더 깔끔하고 유지 관리가 용이한 시스템을 촉진했습니다.”

팀은 Unity의 ECS와 함께 가장 큰 이점 중 하나가 게임 디자인 변경을 처리하는 것이 얼마나 쉬운지라고 공유했습니다. “구 시스템에서는 변경 사항이 종종 여러 MonoBehaviour 스크립트를 수정해야 했습니다. Unity의 ECS를 사용하면 많은 변경 사항을 단순히 구성 요소를 추가하거나 제거함으로써 수행할 수 있습니다. 행동은 해당 구성 요소에 연결된 시스템에 의해 구동되기 때문입니다.” Qiao가 말합니다. “전반적으로, Unity의 ECS로 수정 가능성과 확장성이 크게 향상되었고, 우리의 개발 파이프라인이 훨씬 더 효율적이 되었습니다.”

팀은 게임 아키텍처에 대한 주요 도전 과제도 해결했습니다. 전통적인 소프트웨어와 달리, 게임 논리는 코드뿐만 아니라 그 코드가 위치하는 곳에도 의존합니다. 예를 들어, 회전 스크립트를 자동차 바퀴에 부착하면 움직임을 시뮬레이션하지만, 같은 스크립트를 스카이박스에 적용하면 낮-밤 주기를 구동할 수 있습니다. 이 공간적이고 계층적인 의존성은 팀이 코드뿐만 아니라 배치 및 계층 측면에서도 시스템을 설계할 수 있는 방법이 필요하다는 것을 의미했습니다.

이를 해결하기 위해 팀의 소프트웨어 아키텍트인 Mohamed Hamdy는 Unity의 ECS를 위한 창의적인 그래프 기반 접근 방식을 고안했습니다. 이 방법은 팀이 시각적이고 모듈화된 방식으로 엔티티, 구성 요소, 저자 및 시스템을 설계할 수 있게 하였으며, 그들의 배치 및 설정을 정의할 수 있게 하였습니다. 이렇게 함으로써, 작은 재사용 가능한 코드 블록이 적용되는 위치에 따라 매우 다른 목적을 달성할 수 있었습니다.

이 시스템은 나중에 Unity 엔티티를 위한 ECS뿐만 아니라 MonoBehaviour, GameObject, 행동 트리 및 Unity의 행동 그래프를 통합하도록 확장되었습니다. Lucidchart 다이어그램과 Excel 시트를 조합하여 팀은 전체 게임의 아키텍처를 명확하고 효율적인 방식으로 매핑하고 검증하였습니다. 앞으로 그들은 이 아키텍처 방법을 편집기에서 완전히 볼 수 있도록 전용 Unity 도구를 구축할 계획이며, 실제 구현과 비교하여 검증할 수 있는 기능을 갖출 것입니다.

하이브리드 아키텍처 시스템 사용

커스텀 서버에서 마이그레이션한 후, 팀은 처음에 Unity 물리학을 위한 전체 ECS 접근 방식을 채택하였습니다. 그들은 이 방법이 데이터 처리와 확장성에서 효율적이어서 선택하였으며, 특히 서버 측에서, 그러나 특정 CPU 측 렌더링 최적화 때문이기도 하였습니다.

“하나의 주요 장점은 스킨 메쉬 애니메이션을 정점 애니메이션을 통해 처리하는 데 있으며, ECS for Unity는 전통적인 본 기반 시스템보다 훨씬 더 효율적으로 처리할 수 있습니다.”라고 하이스트리트 마켓의 기술 아티스트인 Alwin Joshy가 말합니다. “그러나 VR에서는 CPU와 GPU 모두 제약을 받으며, ECS for Unity 기반 애니메이션의 이점을 완전히 누리기 위해서는 먼저 장면 복잡성을 줄여 자원을 확보해야 했습니다.”

게임의 복잡한 애니메이션으로 인해 그들의 작업 흐름은 ECS를 통해 MonoBehaviour와 결합된 하이브리드 시스템으로 발전하였습니다.

화면에 여러 캐릭터를 시각화하기 위해 일부 처리를 GPU로 오프로드하였습니다. CPU가 네트워크와 게임 루프의 논리적 측면으로 인해 과부하가 될 것이 분명했기 때문에, 그들은 Rukhanka Animation System을 사용하였습니다.

“물리학을 위해 우리는 모든 물리적 엔티티를 서버와 클라이언트 간에 동기화하여 주요 물리 세계에서 모든 것을 구축하였습니다.”라고 Sleam이 설명합니다. “처음에는 복잡했으며, 서버가 모든 물리적 엔티티를 동기화하였습니다. 그 후 우리는 여러 물리 세계를 탐색하였고, ECS for Unity에서 로컬 물리 계산기를 계속 사용할지 아니면 MonoBehaviour에서 로컬 물리를 사용할지 선택해야 했습니다.”

MonoBehaviour는 Hurricane 및 Freehand와 같은 서드파티 VR 도구와의 통합을 허용하며, 버튼을 누르거나 손이 벽을 통과하지 않도록 하는 것과 같은 현실적인 물리 상호작용을 가능하게 합니다. 반면 ECS for Unity는 팀이 이러한 시스템을 처음부터 구축해야 했으며, MonoBehaviour와 같은 상점에 준비된 서드파티 도구가 없었습니다.

“결국, 우리는 반응성과 몰입감을 보장하기 위해 MonoBehaviour를 클라이언트 측 VR 상호작용, 예를 들어 손 충돌에 사용했습니다.”라고 Sleam이 말합니다. “한편, 서버 측 물리는 검증을 위해 몬스터를 치는 것과 같은 중요한 게임 플레이 상호작용을 처리했습니다.”

이 하이브리드 접근 방식은 몰입감과 보안을 균형 있게 유지하며, 치트를 방지하기 위해 서버에서 게임 플레이에 중요한 충돌 감지를 실행하고 클라이언트에서 덜 중요한 상호작용을 관리합니다.

안정적인 VR 성능을 위한 드로우 콜 감소

Unity의 ECS와 Rukhanka는 수천 개의 애니메이션 캐릭터를 지원하는 것과 같은 확장 가능성을 열어주지만, VR에서 팀의 가장 큰 도전 중 하나는 성능 최적화였으며, 특히 CPU/GPU 제약이 심한 상황에서 더욱 그렇습니다.

“전통적인 게임과 달리, VR은 CPU와 GPU를 모두 완전히 소모합니다.”라고 Joshy가 설명합니다. “장면이 매우 최적화되지 않는 한 오프로드는 항상 옵션이 아닙니다.”

프로젝트를 빌드한 후, 그들은 먼저 Meta Quest에서 OVR stat 도구를 사용하여 무거운 영역이나 프레임 드롭을 식별하기 위해 예비 성능 검사를 실행했습니다. 그런 다음, 개발 빌드를 생성하고 Meta Quest를 Unity Profiler에 연결하여 CPU-GPU 데이터 전송, 텍스처 메모리 사용, 렌더링 계층 및 드로우 타이밍을 분석했습니다.

“성능을 개선하기 위해, 우리는 최근에 렌더링을 수동으로 제어하여 드로우 콜 중단을 줄이는 데 집중했습니다.” 조명은 주요 도전 과제였습니다. 처음에는 크기를 줄이기 위해 만화 스타일 압축으로 라이트맵을 구웠지만, 라이트맵이 적용된 객체와 비라이트맵 객체를 혼합하는 것이 셰이더 변형 문제를 일으켰습니다.”라고 Joshy가 말합니다. “이를 해결하기 위해 우리는 라이트맵을 완전히 포기하고 완전한 환경 조명 만화 셰이더를 채택했습니다. 이로 인해 우리는 더 일관된 성능과 렌더링에 대한 더 나은 제어를 얻었습니다.”

팀은 또한 단계적 감쇠가 있는 스포트라이트를 사용하고 셰이더 변형을 최소화했습니다. 불투명 및 투명 클립을 위한 하나의 셀 셰이더와 아마도 풀만 있었습니다. 그들은 드로우 순서를 수동으로 제어했습니다: 불투명 객체는 레이어 1, 투명 객체는 2, 클립 객체는 3입니다. 이것은 배칭을 일관되게 유지하여 드로우 콜 중단을 줄이는 데 도움이 되었습니다.

“드로우 콜을 분할하는 숨겨진 문제를 잡기 위해, 우리는 Unity Frame Debugger에 크게 의존하여 배칭과 드로우 순서를 검증했습니다.”라고 Joshy가 계속합니다. “GPU 프로파일링은 렌더링 최적화와 드로우 콜 오버헤드 감소를 위한 우리의 주요 도구 중 하나였습니다.”

유연성과 성능의 균형

팀이 개발을 확장하면서, 전투가 발생하는 아레나 장면에서 렌더링 문제에 직면했습니다.

“우리의 목표는 Meta Quest 2와 같은 장치에서 72 fps를 유지하는 것이지만, 삼각형 수가 500,000 이하일 때도 성능 문제가 발생하고 있습니다.”라고 Joshy가 말합니다.

그들은 GPU 셰이더 전환을 줄이기 위해 SRP 배처를 사용하고 있지만, 독립형 VR에서는 GPU 제약이 PC보다 훨씬 더 엄격합니다. “우리는 200만 개의 삼각형이 있는 장면도 부드럽게 렌더링된다는 것을 발견했습니다 – 단일 재질의 단일 메시일 경우에만 가능합니다. 하지만 우리 게임의 개방적이고 수직적인 환경은 그러한 단순화를 비현실적으로 만듭니다.”라고 Joshy가 말합니다.

성능을 개선하기 위해 팀은 드로우 콜을 최소화하는 데 집중했습니다:

아트 팀에 의한 맞춤형 메시 베이킹

재질 유연성과 배칭의 균형을 맞추기 위해 자산을 서브 메시로 그룹화

세상을 청크로 나누고 자산별이 아닌 청크 수준 LOD를 생성

Unity 호환 시스템을 위한 ECS를 사용하여 청크 스트리밍

LOD 시스템만 사용하여 장면을 약 200만 개의 삼각형에서 500,000으로 줄이는 데 도움이 되었습니다.

이 접근 방식은 일부 유연성을 희생하고 아티스트의 작업량을 증가시켰지만, 하드웨어 한계를 고려할 때 필요했습니다 – 특히 개발자가 GPU를 업그레이드할 수 없는 Meta Quest 2와 같은 장치에서요.

“궁극적으로 드로우 콜을 80에서 5로 최소화하는 것이 우리의 가장 큰 성과입니다.”라고 Joshy가 말합니다. “우리는 그에 맞춰 콘텐츠와 워크플로를 재구성하고 있습니다 – 비록 재질 다양성을 제한하더라도 – 현재 하드웨어에서 안정적인 VR 성능을 위한 가장 실행 가능한 경로이기 때문입니다.”

스마트한 방식으로 확장하기

팀이 VR MMORPG를 개발하면서 가장 중요한 고려 사항인 아키텍처와 그래픽 관점에서의 확장성에 계속 집중하고 있습니다.

“첫날부터 대규모 MMO를 목표로 한다면, 높은 엔티티 수와 동시 네트워킹을 처리하기 위해 Unity의 ECS가 필요합니다. 처음부터 매우 구체적인 비전이 없다면 점진적으로 확장하는 것도 잘 작동합니다.”라고 Qiao가 말합니다. “우리는 처음에 ‘0에서 100’ 접근 방식을 취하여 피크 규모를 위해 초기 최적화를 했습니다. 돌이켜보면, 우리는 너무 일찍 인프라를 과도하게 구축하여 게임 플레이와 콘텐츠에 사용할 수 있었던 자원을 소모했습니다.”

그래픽 관점에서 팀은 VR의 장단점을 인식하고 있습니다. “유기적이고 부드러운 메시들은 상당한 컴퓨팅 자원을 소모하며 VR에서 성능이 좋지 않습니다. 우리 게임은 유기적 요소가 포함된 만화 스타일을 사용하여 캐릭터나 환경 디자인과 같은 다른 영역의 그래픽 예산을 제한합니다.”라고 Qiao가 말합니다.

전반적으로 팀은 VR 게임의 성능을 극대화하기 위해 더 깨끗하고 저세부 기술 스타일의 환경을 선택할 것을 권장합니다. “더 깨끗한 장면 디자인과 세계 구축을 통해 더 많은 그래픽과 캐릭터 디자인 및 구조 디자인과 같은 다른 것들을 위한 자원 및 그래픽 예산을 확보할 수 있습니다. 성능을 염두에 두고 설계하는 것이 중요합니다.”라고 Qiao가 말합니다.

지금 Unity Pro 다운로드하기

강력한 툴, 지원, 검증된 파트너, 활발한 커뮤니티의 도움을 받아 대형 스튜디오의 출시작과 경쟁하거나 이를 능가하는 수준의 품질을 갖춘 성공적인 게임을 제작해 보세요.