---

연관성 (Relevancy)

---

문서 변경내역: Mike Lambert 원저. Michiel Hendriks, James Tan 업데이트. 홍성진 번역.

개요

---

리플리케이션의 목적은 클라이언트가 필요로 하는 액터의 부분집합을 제한시켜, 애먼 클라이언트 정보를 보내느라 대역폭이 낭비되지 않도록 하기 위함입니다.

점검사항

---

먼저, (PlayerController, Pawn, Vehicle 을 제외한 모든 액터에 대한) 일반 점검사항은:

1. 액터의 RemoteRole 이 ROLE_None 인 경우, 연관성이 없습니다.
2. 액터의 NetUpdateTime 이 현재 시간보다 큰 경우, 연관성이 없습니다.
3. 액터가 bAlwaysRelevant 인 경우, 연관성이 있습니다.
4. 액터가 (클라이언트일 수도 있는) 뷰어에 의해 소유된 경우, 연관성이 있습니다.
5. 액터가 클라이언트에 의해 소유된 경우, 연관성이 있습니다.
6. 액터가 뷰어인 경우, 연관성이 있습니다.
7. 뷰어가 액터의 인스티게이터인 경우, 연관성이 있습니다.
8. 액터의 Base 가 설정된 경우, Base 액터가 연관성이 있으면 그 역시 연관성이 있습니다.
9. 액터에 bBlockActors 가 없으면서 bHidden 이거나 bOnlyOwnerSee 인(액터를 막지 않으면서 숨어 있거나 오너만 볼 수 있는) 경우, 연관성이 없습니다.
10. 액터의 Location 과 플레이어의 ViewLocation 사이의 시선 검사 결과 액터가 보이는 경우, 연관성이 있습니다.
11. 액터가 포털을 통한 시선 검사 결과 보이는 경우, 연관성이 있습니다.
12. 그 이외에는 연관성이 없습니다.

무슨 뜻인지 좀 따져 봅시다. 이러한 규칙들은 다음과 같이 일반화시킬 수 있습니다:

다음과 같은 경우에 속하면 액터는 관련성이 있습니다:

• bAlwaysRelevant
• 최근 플레이어나 플레이어의 ViewTarget 에 보임
• 플레이어나 플레이어의 ViewTarget 에 소유됨

프로그래머로써, 액터가 클라이언트에 대해 연관성을 갖게 하려면, 위의 세 가지 방법이 가장 안전할 것입니다. 플레이어가 항상 보이는 것은 아니기에 연관성이 없을 수도 있으니 항상 연관성이 있는 액터, 즉 PlayerReplicationInfo 에 (이름, 점수 등의) 플레이어 정보를 저장하는 것이 중요합니다. GameInfo 액터는 클라이언트에 클라이언트에 연관성이 있지 않기 때문에, GameReplicationInfo 를 사용해서 게임 정보를 클라이언트에 전송합니다. ReplicationInfo 는 클라이언트가 필요로 하는 정보 창고인 bAlwaysRelevant 유형 액터로 쓰기에 좋은 베이스 클래스입니다.

레벨에 있는 인벤토리나 소유중인 것은 모두 플레이어 근처에 있으니 연관성이 있습니다. 보이는 프로젝타일도 모두 연관성이 있습니다. 클라이언트의 월드에 영향을 끼치는 것은 무엇이는 연관성이 있습니다. 음악을 재생하거나 콜리전이 있는 액터는 연관성이 있습니다. 그리고 벽 뒤에 웅크려 숨어있다가 다시 보이게 되는 폰의 경우, 언리얼은 연관성에 따른 액터의 프로퍼티 세트 전송 부하가 발생하지 않도록 액터가 사라진 후에도 5 초간 연관성을 유지합니다. 그리고 그 마무리를 위해, 언리얼은 유체이탈 경험 등 자신의 바디 외부 다른 곳에서 월드를 볼 수도 있음을 고려, 연관성이 있는 액터 세트를 결정하는 데 있어 ViewTarget 및/또는 ViewLocation 을 사용합니다.

PlayerController 점검목록

PlayerController 는 클라이언트의 PlayerController 일 때만 연관성이 있습니다. 다른 클라이언트는 절대 볼 일이 없는 다른 게임 인스턴스의 플레이어 콘트롤러에는 리플리케이트하지 않습니다.

Pawn 점검목록

일반 목록의 #7 과 #8 사이에서:

1. 폰이 뷰어에 BasedOn(...) (베이스를 두고 있다)면, 연관성이 있습니다.
2. 뷰어가 폰에 BaseOn(...) (베이스를 두고 있다)면, 연관성이 있습니다.
3. 뷰어에 bReplicateAllPawns (모든 폰 리플리케이트) 옵션이 있다면, 연관성이 있습니다.
4. 폰이 항상 항상 연관된 거리 안에 있다면, 연관성이 있습니다.
5. 폰에 앰비언트 사운드가 있다면, 연관성이 있습니다.

일반 목록의 #9 와 #10 사이에서:

1. 디스턴스 포그가 컴파일되어 있고 액터가 그 포그 너머에 있다면, 연관성이 없습니다.

Vehicle 점검목록

일반 목록의 #7 과 #8 사이에:

1. 비히클이 뷰어에 BasedOn(...) (베이스를 두고 있다)면, 연관성이 있습니다.
2. 뷰어가 폰에 BaseOn(...) (베이스를 두고 있다)면, 연관성이 있습니다.
3. 뷰어에 bReplicateAllPawns (모든 폰 리플리케이트) 옵션이 있다면, 연관성이 있습니다.
4. 비히클이 항상 연관된 거리 안에 있다면, 연관성이 있습니다.
5. 비히클에 들리는 앰비언트 사운드가 있다면, 연관성이 있습니다.

일반 목록의 #9 와 #10 사이에:

1. 디스턴스 포그가 컴파일되어 있고, 액터가 그 포그 너머에 있다면 연관성이 없습니다.

비히클에는 시선 검사를 하지 않습니다.

연관성은 재귀적이지 않습니다

---

연관성은 재귀적(recursive)이지 않다는 것에 유의해야 합니다. 연관성이 있는 액터가 리플리케이트된 변수를 통해 다른 액터를 참조하는 경우, 그 액터가 꼭 연관성이 있을 필요는 없습니다. 그 둘째 액터는 자체적인 근거에다 위에 요약한 연관성 조건을 만족해야 합니다. 연관성이 있는 액터 A 가 연관성이 없는 액터 B 를 참조하는 경우, 액터 A 에서 B 로의 참조는 클라이언트에서는 None 이 되는데, 액터 B 는 클라이언트에 존재하지 않기 때문입니다.

NetPriority

---

모든 액터가 똑같이 태어나는 것은 아닙니다. 예를 들어 폰의 운동은 어떤 사람의 핑 변화보다 우선권이 높아야 할 것입니다. 언리얼의 모든 액터에는 NetPriority 변수가 있는데, 네트워크 플레이에서 액터의 우선권을 나타내는 데 사용되는 변수입니다. 일정 기간 업데이트되지 않은 액터는 한 틱 전에 업데이트된 액터보다 더욱 중요할 것입니다. 이러한 요인이 전부 NetPriority 에 의해 처리됩니다.

사용된 NetPriority 값은:

• Actor - 1.0
• Inventory - 1.4
• MatineeActor - 2.7
• Pawn - 빙의된 폰은 3, 빙의되지 않은 (배경) 폰에는 2
• Pickup - 1.4
• PlayerController - 3.0
• Projectile - 2.5
• Vehicle - 탑승한 비히클은 3, 탑승하지 않은 비히클은 1

NetUpdateFrequency

---

NetPriority 에 추가로, 다른 것처럼 자주 업데이트할 필요가 없는 액터를 위해 NetUpdateFrequency 가 있습니다. 디폴트로 Actor 에는 NetUpdateFrequency 값이 100 입니다. 즉 서버가 초당 100 틱 미만으로 실행중이라 가정한다면, (디폴트로 게임은 초당 20 틱으로 실행) 서버는 클라이언트에 액터에 대한 업데이트를 매 틱마다 보내기만 하면 차고도 넘칠 것입니다. 실제로 변수를 초당 100 번 미만 바꾸는 진짜 액터의 경우, NetUpdateFrequency 값이 좀 더 현실적으로 덮어쓰여집니다. 액터 자체에 저장된 값은 액터를 얼마나 자주 업데이트해야 하는지에 대한 대충의 추정치입니다.

베이스 클래스에 대한 NetUpdateFrequency 값은 이렇습니다.

• Actor - 100
• Info - 10
• DroppedPickup - 8
  • 땅에 앉아있(어서 bAlwaysRelevant, 항상 연관성이 있)을 때만 적용됩니다.
• TeamInfo - 2

언리얼은 액터가 1/NetUpdateFrequency 초마다 한 번씩만 연관되도록 하여 그 작업을 이뤄냅니다. 그래서 액터는 그 NetUpdateFrequency 가 아직 업데이트하지 말라고 하면 나중의 모든 프로세싱 태스크에서 효율적으로 걸러냅(cull)니다.