Unreal Engine - 멀티플레이 네트워크 최적화 2

https://gbleem.tistory.com/166

Unreal Engine - 멀티플레이 네트워크 최적화 1

위의 글에서 이어지는 내용입니다.

 

3. Actor Replication Optimization

---

3 - 1. Network Bandwidth 관리

네트워크 bandwidth는 한정된 자원이기 때문에, 항상 중요한 정보는 놓치지 않고 불필요한 데이터는 줄이는 과정이 필요하다

3 - 1 - 1. Relevancy

"액터"가 "클라이언트"에게 관련된지의 여부를 판단하여, 관련있는 액터만 리플리케이트 하기!

• 관련성을 체크하는 기본 규칙은 "거리 기반" 이다. -> NetCullDistanceSquared
• 설정한 거리 이내에 있는 플레이어에게만 액터를 리플리케이트 하는 것
• 참고) bAlwaysRelevant 플래그를 통해 거리와 상관없이 모든 클라이언트에게 리플리케이트 한다.

3 - 1 - 2. Dormancy

네트워크 관점에서 Actor를 휴면시키는 기능, 액터가 Dormant 상태라면, 깨우기 전까지 리플리케이트 하지 않는다.

• 변화가 드물게 일어나는 액터에 사용해야 한다.
• 네트워크 트래픽을 줄이는데 도움이 된다.
• 예시) 한번만 열리는 문 같은 경우, 처음에 Dormant 상태이고 플레이어가 문을 여는 경우 FlushNetDormancy를 호출하여 문을 열림 상태로 바꾼 후 다시 Dormant 상태로 바꾸기

3 - 1 - 3. 결론 및 예시

Relevancy와 Dormancy를 통해 네트워크 효율성을 올릴 수 있다.

• Enemy AI의 경우 멀리 떨어진 AI는 relevant 하지 않다고 처리하여, replication 하지 않다가 거리가 가까워진 경우 다시 relevant 하다고 판정하여 리플리케이션 하기
• 가만히 있는 NPC AI의 경우, 평소에는 변화가 없으므로 Dormant 상태로 두다가 전투를 하는 등 깨워서 movement replication을 진행하고 다시 전투가 끝나면 Dormant 상태로 변경

Network Profiling

• 언리얼 엔진의 stat net 명령어나 Network Insights를 사용하여 네트워크 사용량을 분석할 수 있다.

 

3 - 2. Update Rate 조절

3 - 2 - 1. NetUpdateFrequency

(네트워크가 이상적인 상태일 때) 초당 업데이트 횟수

• 이 값이 클수록 자주 업데이트 된다.
• 캐릭터의 경우 높게 설정되어 있고(100), PlayerState 등은 1로 설정되어 있다.

3 - 2 - 2. NetPriority

(네트워크가 이상적인 상태가 아닐 때) 어떤 액터를 우선적으로 업데이트 할지

• 이 값이 높을 수록 우선순위가 높다.

3 - 2 - 3. Adaptive Frequency

언리얼 엔진이 액터 리플리케이션 사용 빈도에 따라 자동으로 업데이트 주기를 조절하여 효율성을 제공하는 기능

• 사용하기 위해서는 DefaultEngine.ini 에 아래와 같은 세팅을 해주어야 한다.

[SystemSettings]
net.UseAdaptiveNetUpdateFrequency=1

• 이후 액터의 리플리케이션 속성에서 MinNetUpdateFrequency와 MaxNetUpdateFrequency를 설정해주면 그 사이에서 적합한 NetUpdateFrequency를 설정해준다.

 

3 - 3. Actor의 종류에 따른 튜닝

플레이어 캐릭터나 중요한 액터(움직이는 플랫폼 등)

• 높은 빈도를 사용하기

아이템

• 크게 변하지 않으니까 Frequency 높을 필요는 없다. (1~2)

발사체

• 생성시 위치를 한번 복제하고, 도착할 때 도착지점을 다시 리플리케이션하여, 중간지점에서 절약이 가능하다.

배경 오브젝트

• 움직이지 않는 장식물 같은 경우 Frequency를 0으로 설정
• 혹은 변하지 않는다면 Dormant 로 처리

GameState

• Frequency는 1정도면 충분, 실시간 변동이 심하면 RPC를 사용한다.

결론

• 프로파일링 장치를 통해서 과부화가 있거나 데이터가 많이 변하는 부분 혹은 낭비되는 부분을 찾아서 잘 설정하기

 

 

4. Prediction and Reconciliation

---

4 - 1. Client - Side Prediction and Smoothing

네트워크 지연에 영향이 없이 멀티플레이 게임을 부드럽게 만드는 핵심 기술!

• 클라이언트쪽에서 멀티플레이 게임을 부드럽게 만들기 위해서 사용하는 기술
• 서버 응답을 기다리지 않고 "먼저 클라이언트가 움직이는 것" 에서 시작하는 개념
• 이후에 서버는 클라이언트가 미리 이동한 결과를 받아, 나중에 클라이언트로 보내서 수정하는 방식
• 언리얼 엔진의 CharacterMovementComponent가 동작하는 방식이다.

과정

• 클라이언트는 플레이어가 키 입력시 해당 움직임을 저장해두고, PerfomMovement() 를 통해 즉시 클라 캐릭터를 움직인다. 
  • 이때, ServerMove()를 통해 움직인 정보를 server로 전달 (유효성 체크를 위함)
• 서버는 클라로부터 받은 정보를 기반으로 유효성을 체크한다.
  • 유효성 체크 후, 서버의 캐릭터를 움직인다.
  • 이때, 마지막으로 클라이언트로부터 받은 정보와 현재 정보가 너무 차이난다면,
  • ClientHandleMoveResponse를 통해 클라이언트에게 현재 서버의 위치를 전달해 준다.
• 클라이언트는 다시 서버가 보내준 정보를 받아 자신의 예측 결과와 비교한다.
  • 이때, 차이가 큰 경우 서버의 위치로 클라이언트의 위치를 교정하게 된다.
• 교정하는데 있어서, Network Smoothing을 통해 유저에게 어색함을 주지 않도록 한다.
  • SmoothClientPosition() 등으로 구현 
  • 재실행 하는 과정과 보간을 사용하기

다른 플레이어 캐릭터의 Movement Smoothing

• 이것 또한 보간을 통해서 구현하지만, 지연이 발생할 수 있다.
• 타협점을 찾아서 해결해야 할 문제

 

4 - 2. Lag Compensation and Hit Detection

4 - 2 - 1. Lag Compensation

• 서버가 공격 판정 처리를 할 때 네트워크 지연을 고려하여, 공정하게 계산하는 기술을 말한다.
• Lag Compensation의 경우 쏜 순간 상대방의 위치를 고려하게 된다.
• 즉, 과거의 상태에서 공격의 명중 여부를 파악하는 것

그러나 언리얼 엔진은 Lag Compensation 기능을 내장하고 있지 않음

• 해결책으로 Client-authoritative Hit Detection을 사용한다.

4 - 2 - 2. Client - Authoritative Hit Detection

• 클라이언트가 자신의 화면에서 맞췄다면, 맞춘것으로 생각하고 피격 정보를 서버로 보내는 방식 (서버가 클라의 결과를 신뢰)
• 다시 말해,
  • 클라이언트가 상대를 맞췄다면 서버 RPC로 "상대를 맞췄으니 데미지를 주세요" 라고 요청하면
  • 서버는 데미지 처리를 해주는 방식이다.
  • 서버가 검증을 하긴 하지만, 기본적으로 클라가 보낸 결과를 신뢰하는 구조
• 이 방식은 구현하기 쉽다는 장점이 있지만, 핑 차이로 인해 불공정한 결과가 나올 수 있다는 문제가 있다.

4 - 2 - 3. Server-side Lag Compensation (Backward Reconciliation)

• 최근 FPS에서 사용하는 좀 더 세밀한 방식
• "서버가 최근 플레이어들의 위치 기록을 유지" 하는 방식
• Hit Detection을 실행할 때, "클라이언트가 발사한 시각"을 기준으로 "서버에서의 플레이어 위치"로 상황을 재구성하여 판단하는 방식

과정

• 서버는 모든 플레이어의 위치를 매 프레임을 기록 후 저장(일정 시간 100~200ms)
• 총알 발사 시 RPC에 timestamp를 포함시켜 "발사한 시간" 을 보냄
• 이후 서버는 해당 프레임의 위치를 재구성하여 충돌(피격) 체크 후 다시 캐릭터를 원래 위치로 되돌리게 된다.

Projectile vs Hitscan

• projectile의 경우 서버에서 날라가는 객체를 시뮬레이션하기 때문에, 지연 문제가 줄어든다
• 그러나 히트스캔 방식은 매우 빠르기 때문에(projectile 방식도 빠른 탄환은 같은 문제 발생) Lag Compensation이 없으면 "나는 맞췄는데..." 라는 말이 나올 수 있다.

 

4 - 3. Server Reconciliation

Client-side Prediction의 정반대 개념이다.

클라이언트가 서버로부터 수신한 값을 기반으로 움직이는 것

 

과정

• 먼저 서버가 보낸 상태를 신뢰하고 자신의 상태를 덮어쓰게 된다.
• 그렇게 되면 과거를 기준으로 자신을 맞췄기 때문에 "무시된 입력" 이 존재할 수 있다.
• 이 입력들은 교정된 상태(덮어써진)를 기반으로 다시 실행된다.

 

 

5. 결론

---

좋은 네트워킹 코드는 보정이 필요한 상황을 최소화하고, 보정이 발생하더라도 부드럽게 적용하는 것을 말한다.

• 너무 과한 보정을 하면 그것이 Lag을 발생하는 것처럼 느껴질 수 도 있다.
• 다양한 방법을 통해 클라이언트와 서버의 상태를 일치시키는 것이 중요한 과제이다.