EntityRef Hijacking
소개
EntityRef Hijacking 은 예측 롤백 모델이 뷰에서 가질 수 있는 알려진 부작용에 사용되는 용어입니다.
설명
이 역할에는 여러 개의 가변적인 요소가 있습니다:
- 예측-롤백
- 엔티티 생성 그리고
- 엔티티 뷰.
시뮬레이션은 계속해서 다음 몇 개의 프레임을 예측합니다. 예측된 프레임은 확인되지 않은 플레이어 입력을 사용합니다. 서버가 모든 플레이어에 대해 입력을 수신하면 Quantum은 확인된 프레임을 시뮬레이션합니다.
예측 프레임에 엔티티 A를 생성해야 하는 경우 이 프레임으로 계속 진행하여 "EntityRef X"를 할당했습니다. 연결된 EntityViewAsset의 Bind Behaviour가 검증되지 않음로 설정된 경우 뷰 컴포넌트는 유니티의 다음 OnUpdateView 콜백에 생성됩니다.
서버에서 확인된 입력을 수신하면 Quantum은 서버 측 유효성 확인된 정보를 사용하여 프레임을 다시 시뮬레이션합니다. 이러한 정보는 검증된 프레임입니다. 여기가 흥미로운 부분입니다.
예측 프레임에서 생성되지 않은 또 다른 엔티티 B가 엔티티 A 이전에 생성된 경우, EntityRef가 결정적이고 순차적으로 제공되므로 "EntityRef X"가 재할당됩니다. 이 경우 엔티티 A에 새로운 "EntityRef Y"가 할당됩니다.
이제 다음 두 가지 중 하나가 발생합니다.
엔티티 A 및 엔티티 B는 각각 서로 다른
EntityViewAsset을 사용합니다.EntityViewUpdater스크립트는 불일치를 감지하여 엔티티 A에 대한 링크와 관련 뷰를 삭제합니다. 정리가 완료되면 엔티티 A 및 엔티티 B에 대한 새 뷰가 생성됩니다.엔티티 A 및 엔티티 B는 동일한
EntityViewAsset을 사용합니다.EntityViewUpdater스크립트는 다음 업데이트의 불일치를 감지하고 엔티티 A와 해당 뷰 간의 링크를 끊고 엔티티 B를 기존 뷰에 링크하고 엔티티 A에 대한 새 뷰를 인스턴스화합니다.- 엔티티 A는 새로운 뷰를 가집니다. 이 뷰에는 올바른 데이터가 사용됩니다.
- 엔티티 B는 이전의 엔티티 A와 관련되어 있는 뷰를 갖고 있습니다. 이 뷰는 잘못된 데이터로 초기화되었고, 업데이트가 필요합니다.
노트 EntityViewUpdater:
EntityViewUpdater 스크립트는 EntityRef 및 EntityViewAsset 키 쌍 값을 캐싱 하여 시뮬레이션과 해당 뷰 사이의 링크를 저장합니다. 자세한 내용은 EntityViewUpdater.cs를 참조하십시오.
노트 바인드 방식:
엔티티 뷰가 검증된 바인드 동작을 사용하는 경우 확인된 프레임에서만 인스턴스화되므로 위의 작업이 수행되지 않습니다. 이는 트레이드오프이며, 엔티티의 "유형"은 어떤 행동이 더 적합한지를 결정합니다(아래 일반 조언 섹션 참조).
처리 방식
이 상황은 시뮬레이션 또는 뷰를 조정하여 쉽게 해결할 수 있습니다.
코드
엔티티가 확인된 프레임에서만 생성되도록 하기 위해 다음 조건문을 줄바꿈 할 수 있습니다.
C#
if(f.IsVerified) {
// Do stuff
}
또는 다음을 사용하여 검증되지 않은 프레임(예측된 프레임)에서 조기에 나가도록 할 수 있습니다.
C#
if (f.IsPredicted == false)
return;
필요한 경우 OnPlayerDataSet에서도 API를 사용할 수 있습니다.
유니티에서
뷰에서 초기화 동작을 수정하여 문제를 처리하거나, 보관 중인 데이터의 불일치가 감지되면 뷰 자체를 업데이트하도록 선택할 수 있습니다. 솔루션은 바인드 동작을 검증됨 으로 설정할지 아니면 검증되지 않음으로 설정할지에 따라 달라집니다.
Unity에서 바인드 방식를 변경하려면 EntityViewAsset와 연결된 prefab에 있는 Entity View 스크립트로 이동하여 검증되지 않음 에서 검증됨 으로 변경하세요.
바인드 방식 - 검증됨
이 경우 시작 단계에서 올바른 정보를 얻을 수 있으며 Unity의 Start() 방법에 따라 제공되는 정보를 신뢰할 수 있습니다. 또한 OnEntityInstantiated를 사용할 수도 있습니다(프리팹에 연결된 Entity View 스크립트 참조).
바인드 방식 - 검증되지 않음
이 경우 인스턴스화 시 사용자에게 제공되는 정보가 잘못되었을 수 있습니다.
뷰가 이 변경 사항을 반영할 수 있도록 하려면 폴링을 통해 유니티 Update() 내에서 뷰를 설정할 수 있어야 합니다. 이렇게 하면 데이터가 잘못될 경우 데이터를 전환할 수 있습니다. 이 뷰가 시뮬레이션과 완전히 독립되어 있고 필요한 정보를 이미 보유하고 있다면, EntityViewUpdater가 GameObject를 파괴하고 재 생성함으로써 문제를 해결할 수 있기 때문에 이러한 예방 조치를 취할 필요가 없습니다.
바인드 방식에 대한 일반적인 조언
두 방식, 검증됨 and 검증되지 않음 모두 서로 장단점이 있습니다.
검증됨: 플레이어 캐릭터와 같이 밀리초 단위의 정확한 인스턴스화에 매우 민감하지 않은 것입니다.검증되지 않음: 발사체처럼 빠르고 플레이어가 반응할 시간이 필요합니다.