성능 & 최적화

관심 관리

Fusion BR은 클라이언트가 관심 있는 네트워크 객체에 대한 데이터만 수신할 수 있는 궁극적인 일관성 복제 모드를 사용합니다. 이렇게 하면 성능이 향상되고 네트워크 트래픽이 줄어듭니다.

모든 플레이어는 카메라 방향에 따라 원뿔 모양의 영역을 정의하여 앞에 있는 물건과 가까이 있는 물건에 대한 정보를 수신합니다.

Player AoI

관심 영역(AoI)은 단일 상자로 표시되기 때문에 원뿔 모양은 크기가 다른 여러 개의 AoI를 사용하여 만들어집니다. 위의 이미지는 영역 설정을 보여 줍니다. 플레이어는 이 영역 내의 객체에 대해서만 상태를 수신하며, 다른 객체의 상태는 수신하지 않습니다.

이 프로젝트에는 성능 비용 및 네트워크 트래픽을 더욱 줄이기 위한 특수한 컴포넌트도 포함되어 있습니다:

StaticNetworkTransform
생성 시 정적 개체의 일회성 위치/회전 동기화. StaticNetworkTransform은 아이템 상자에 사용됩니다. 수백 개의 상자가 있을 수 있으며 StaticNetworkTransform의 사용은 NetworkTransform보다 더 적합합니다.

NetworkAreaOfInterestProxy NetworkAreaOfInterestProxy는 위치나 회전을 동기화할 필요는 없지만 관심 관리 시스템에서 필터링해야 하는 객체에 사용됩니다. 예를 들어 에이전트 소유의 무기는 변환을 동기화할 필요가 없지만 해당 무기가 플레이어의 관심 영역에 있는지 여부에 따라 네트워크 데이터를 수신해야 합니다. AoI 계산을 위한 위치는 지정된 객체에서 가져옵니다. 무기의 경우 소유 에이전트 위치를 기준으로 합니다. 이 기능은 네트워크 트래픽 오버헤드가 없습니다.

NetworkCulling 로컬 컬링에 대한 작은 유틸리티입니다. NetworkObject가 특정 기간 동안(플레이어의 AoI가 아닌) 상태 권한으로부터 새 상태를 얻지 못하면 NetworkObject는 컬링 됩니다.

위의 기능이 네트워크 트래픽에 큰 영향을 미치지만, 아직 추가로 개선해야 할 부분은 있습니다:

  • 레벨 디자인에 따른 더 나은 관심 영역 원뿔 제한
  • 사전 계산된 가시성 영역
  • 플레이어 A는 플레이어 B의 관심 대상 목록에 수동으로 추가하여 네트워크 데이터를 수신하고 볼 수 있도록 할 수 있습니다(예: 오고 있는 발사체는 플레이어 뒤에서 멀리 발사되었음에도 불구하고 플레이어에게 보입니다).

관심 관리에 대한 추가 정보는 Fusion 관심 관리 섹션에서 확인할 수 있습니다.

메인 화면으로

벤치마크

헤드리스 전용 서버 인스턴스에서 안정적인 60Hz 시뮬레이션을 위해 권장되는 최대 플레이어 수는 다음과 같습니다:

구성 (하드웨어 + 빌드 타입) 플레이어 수
Mac Mini M1 2020, Mac 서버 (실리콘) 200
Core i9-10900K, Windows 서버 200
멀티플레이 베어 메탕 (Intel® Xeon® E-2288G @ 3.70GHz), 리눅스 서버 200
멀티플레이 가상 머신 (GCP N2 - Intel® Xeon® @ 2.80GHz), 리눅스 서버= 60 - 80

Multiplay Bare Metal (Intel® Xeon® E-2288G @ 3.70GHz) Performance
멀티플레이 베어 메탈의 성능 (Intel® Xeon® E-2288G @ 3.70GHz), 밀리초의 델타타임

Multiplay Virtual Machine (GCP N2 - Intel® Xeon® @ 2.80GHz)
멀티플레이 베어 메탈의 성능 (GCP N2 - Intel® Xeon® @ 2.80GHz), 밀리초의 델타타임

실제 성능과 플레이어 수는 게임 플레이 모드에 따라 크게 달라집니다. 모든 플레이어가 항상 활동하는 데스매치는 탈락 플레이어들이 오버헤드가 낮은 배틀 로얄보다 항상 더 까다롭습니다. 또한 레벨 디자인(맵 크기, 플레이어 밀도)과 게임 플레이 디자인(플레이어들이 지속적으로 움직여야 함/모양/사격하는 것은 200명의 캠퍼와는 다른 영향을 미칩니다)에도 영향을 받습니다. 위의 숫자는 스폰 후 첫 1분 동안 모든 플레이어가 활발하게 움직이고, 보고, 쏘는 최악의 시나리오를 나타냅니다.

멀티플레이 가상 시스템에 대한 노트: 성능에 영향을 미치는 또 다른 요인은 현재 할당된 하드웨어의 사양입니다. 하나의 매치(게임 서버 인스턴스)는 60명을 간신히 처리할 수 있는 반면, 다른 매치에서는 100명이 참여해도 문제없이 실행합니다. 이 문제는 하드웨어 사양이 다르기 때문에 발생합니다. 더 높은 플레이어를 위해 베어 메탈 서버에서 실행하면 중요도가 높아지고 안정성이 향상됩니다.

메인 화면으로

프로파일링

일반적인 프로파일링 도구 외에도 이 샘플은 릴리즈 모드에서 게임에 대한 오프라인 분석을 위한 도구를 제공합니다. -recordSession 매개 변수를 사용하여 게임을 시작하면 엔진 델타 시간과 플레이어 수가 프레임마다 기록되고 CSV 형식으로 파일에 저장됩니다. 그런 다음 제공된 Python 스크립트(Assets/Extras.zip에서 사용 가능)를 통해 이 파일을 처리할 수 있습니다. 이 스크립트는 그래프로 HTML 파일을 생성합니다.

파일은 Application.persistentDataPath 경로 또는 -dataPath XXX 명령에서 지정한 경로로 생성됩니다.

Profiling Stats

위의 이미지는 파란색 선으로 표시된 증가하고 있는 플레이어 수(최대 200명)와 엔진 델타 타임(대부분 16ms 이상의 피크가 거의 없을 때 안정적)을 나타내고 있습니다. DeltaTimePlayerCount 외에도 사용자 정의 StatsRecorder 인스턴스를 사용하여 추적된 속성 집합을 만들 수 있습니다.

메인 화면으로

풀링

슈터 프로젝트에서는 많은 양의 객체 스폰이 예상됩니다(발사체, 머그 효과, 충격, 타격 효과 등). 새로운 객체의 인스턴스화는 비용이 많이 들기 때문에 Fusion BR의 모든 것이 풀링 됩니다.

풀링의 2가지 유형:

  • NetworkObjectPool은 네트워크 개체를 풀링 하는 데 사용됩니다. NetworkObjectPoolNetworkObjectPool 인터페이스를 구현하고 Networking 스크립트에 있는 NetworkRunner.StartGame 함수로 전달됩니다. 자세한 내용은 Fusion 매뉴얼의 네트워크 객체 풀 섹션을 참조하십시오.

  • ObjectCache은 임팩트 효과와 같은 비네트워크 객체에 사용되는 일반적인 GameObject 풀입니다. 지정된 지연 후 객체를 리턴하는 기능이 제공됩니다. SceneContext를 통해 코드의 다른 부분에서 ObjectCache에 접근할 수 있습니다.

기술문서 TOP으로 돌아가기