UDN
Search public documentation:

ReplicationRolesKR
English Translation

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

게임 상태: 복제 역할

문서 요약: 액터가 가질 수 있는 여러 복제 역할에 대한 설명.

문서 변경 내역: 마지막 업데이트: Michiel Hendriks, UDN 문서로 변환시킴. 원저자: Mike Lambert(UdnStaff?).

역할

이전에 언급한 다양한 우선 순위와 속성 이외에 액터에는 데이터를 복제하는 또 다른 ‘방법’이 있습니다. 로켓 또는 수류탄에는 초기 위치 및 속도만이 필요하고 클라이언트는 나머지 행동 패턴을 클라이언트가 직접 시뮬레이션할 수 있습니다. 게임에서 플레이어는 다른 클라이언트가 업데이트간의 짧은 시간 간견 동안에 플레이어의 모션을 시뮬레이션할 수 있도록 위치와 속도 정보가 다른 모든 클라이언트로 복제되도록 해야 합니다. 이런 다른 네트워크 행위 패턴은 각각의 다른 역할과 상응하는 관계를 나타냅니다.

액터가 서버와 클라이언트 모두에서 존재하는 경우 Role 값은 일반적으로 서버에서 ROLE_Authority 이고, 클라이언트에서는 액터가 넷플레이(netplay)에서 플레이할 수 있는 기본적인 3가지 다른 역할에 상응하는 ROLE_DumbProxy, ROLE_SimulatedProxy, 또는 ROLE_AutonomousProxy 중 하나입니다. 클라이언트에서 액터의 Role 은 액터의 기본 속성에서 RemoteRole 의 값으로 지정되는 것이 일반적이지만 게임을 하는 동안 아무 문제 없이 동적으로 값을 자유롭게 변경할 수 있습니다. Role 값은 현 Role 필드에서 설정되고 RemoteRole 은 연결 상대측에는 어떤 Role이 설정되어 있는지를 나타냅니다. 서버에서 RoleROLE_Authority 라는 코드를 사용하여 어떤 종류의 시뮬레이션이 클라이언트에 제공되고 있는지 확인할 수 있습니다. 일반적으로 어떤 머신이 액터를 스폰하였더라도 RoleROLE_Authority 입니다. 액터가 클라이언트에서 스폰되면 클라이언트는 ROLE_AuthorityRole 을 갖게 되지만 클라이언트상에서 속임수와 무기 제작이 쉽기 때문에 액터는 서버에서 복제되지 않습니다.

이제 Roles와 RemoteRoles이 어떻게 작동하는지 이해하셨으므로 각각의 다양한 역할에 대해 개별적으로 살펴보겠습니다.

본 문서는 Networking Tome 의 일부입니다.

ROLE_Authority

이 역할은 서버에서 항상 Role 이라는 점에서 다른 역할과 다릅니다. 서버에서 모든 Role은 ROLE_Authority 이고 RemoteRole 은 다음 값 중 하나입니다. 클라이언트에서는 반대입니다. 이 역할은 복제 문에서의 사용 이상의 중요한 의미가 없습니다. 이에 대해서는 나중에 설명하겠습니다.

ROLE_None

이 역할은 아마 가장 간단합니다. 이 역할은 서버에게 이 액터를 클라이언트에 관련되지 않도록 지시합니다. 이 때 아무 정보도 발송되지 않고 해당 역할이 만들어진 컴퓨터에만 존재하게 됩니다. 주어진 액터가 클라이언트와 서버에서 각각 독립적으로 만들어졌고(나중에 설명될 시뮬레이션된 함수를 통해) ROLE_NoneRemoteRole 이 주어진 경우 서버와 클라이언트에서 2개 별도의 연결되지 않은 액터 인스턴스가 있게 됩니다. 이것은 복제가 필요 없는 특수 효과에 잘 사용되고 두 컴퓨터에서 독립적으로 스폰될 수 있습니다.

ROLE_DumbProxy

이 역할은 실제 클라이언트측 예측이 필요없는 간단한 액터에 사용됩니다. 이런 간단한 액터에는 어떠한 Physics 예측도 필요 없지만 액터의 변수가 복제되기 위해서는 해당 클라이언트에 관련될 필요가 있습니다. 이것은 높은 대역폭 Simulated Proxy(시뮬레이트된 프록시)와 같은 것을 방지하는 지상에 위치한 모든 Inventory 액터에 대해 사용되지만 인벤토리 액터에 필요한 모든 것을 볼 수 있도록 하여줍니다. 이 액터를 수동으로 이동시키려고 하는 경우 클라이언트는 보통 약 매 0.5초마다 정상 연결 상태에서 주기적으로 업데이트를 받습니다. 특정 Physics 유형의 Dumb Proxy를 사용하는 경우 위치가 1초의 몇 분의 1동안마다 업데이트 되어지고 시뮬레이션 또는 예측이 실행되지 않기에 일정하지 않고 변하는 효과를 만들 수 있습니다. 한 장소의 위치 업데이트이기 때문에 일정하지 않은 주기의 위치 업데이트도 상관 없는 플래그 다시 스폰하기처럼 액터를 레벨 전반에 걸쳐 이동시킬 때 위치 업데이트는 유용하게 사용됩니다. 주기적 변경이 종종 클라이언트로 전송되는 회전 업데이트도 마찬가지입니다. 이 역할은 또한 클라이언트가 구체적으로 bClientAnim 을 통해 전송하지 말라고 명령하지 않은 한 애니메이션 업데이트를 서버에서 클라이언트로 전송되게 유발합니다. 요약하면 이 역할의 액터는 서버에서 강제로 공급되는 데이터입니다. 이 역할은 움직이지 않는(수송, 재스폰 등과 같은 점프를 제외함), 하지만 여전히 관련되어져야 하는 필요가 있는 액터를 대상으로 합니다. 이 역할 유형은 실제로는 그리 자주 사용되지 않습니다. 대부분의 경우 일부 코드와 Simulated Proxy를 사용하여 필요한 모든 경우를 처리할 수 있습니다.

기타 돌발 상황

넷플레이 개발에 중요한 영향을 미칠 수 있는 몇 가지 돌발 상황이 있습니다. Dumb Proxy 액터는 클라이언트측에서 실행되는 다양한 이벤트를 갖고 있지 않습니다. 시뮬레이션되는 Tick(), Timer(), 상태 코드 및 물리 계산은 클라이언트에 위치한 Dumb Proxy 액터에서 실행되지 않습니다. 이러한 액터는 시뮬레이션 행동 패턴 없이 “단순"하고 그저 데이터를 네트워크상으로 전송하는 단순 프록시 액터입니다. 이 규칙에 대한 한 가지 예외는 액터가 넷플레이에서 던져진 무기가 정확하게 낙하하게 하는 낙하 물리를 갖을 경우 Dumb Proxy 액터에 대한 낙하 물리가 클라이언트측에서 실행되는 것입니다. 튜토리얼에서의 이전 무기에 대한 시도에서Dumb Proxy 역할을 통해 고유적으로 전송될 수 있는 위치 및 회전 업데이트가 결합된 클라이언트측 물리를 제작하려고 했지만 클라이언트에서는 Tick() 기반의 물리 계산을 실행할 수 없기에 이 아이디어는 포기해야만 했습니다.

ROLE_SimulatedProxy

이 역할은 예측을 통행 네트워크상에서 시뮬레이션되는 모든 것에 대해 사용됩니다. 로켓을 그 예로 들어보겠습니다. 로켓은 항상 직선으로 이동하고 Simulated Proxy에 대한 이상적인 후보입니다. 같은 이유로 게임은 클라이언트측 낙하 물리를 예상할 수 있고, 그렇기에 수류탄과 낙하하는 사람들은 이 역할에 대한 이상적인 후보입니다. 물리 또는 클라이언트측 물리는 반드시 이 역할을 사용해야 하기 때문에 클라이언트측에서는 모든 것이 예상될 수 있습니다. 플레이어가 달리고 있는 경우 계속해서 달릴 것을 예상할 수 있기 때문에 모든 Controllers 도 또한 이 역할을 사용하여 시뮬레이션의 이점을 활용할 수 있습니다. 이것은 예측할 수 없는 플레이어에 사용할 수 있는 최상의 예상 방법입니다. 플레이어에 대한 이 지침의 유일한 예외는 사용자 자신의 동작을 사용자가 시뮬레이션하고 싶지 않기 때문에 자기 자신이 플레이하고 있는 폰입니다.

실제로 Simulated Proxy 액터에는 Simulated Pawn과 Simulated Non-Pawn의 2가지 유형이 있습니다. 이 2가지 유형은 다르지만 유사한 행동 패턴을 가집니다. 2가지 유형의 차이점은 아래에서 설명되고 있습니다.

Non-Pawn ROLE_SimulatedProxy

이 역할은 기본적으로 Dumb Proxy의 반대입니다. 이것은 초기 값이 주어진 상황에서 액터의 완전한 클라이언트측 예측을 기대합니다. 이것은 현재 Physics는 커브 피팅이고 추정을 시작할 초기 데이터가 주어진 데이터에서 곡선을 추정하는 것과 같습니다. ROLE_SimulatedProxy 는 초기 Location(위치), Rotation(회전), and Physics(물리) 값을 부여합니다. 그런 다음 Velocity(속도)가 변하는 경우 Velocity를 계속하여 업데이트하여 줍니다. 계속해서 물리 예측이 따라진다라는 가정하에 이러한 변수는 클라이언트가 이 객체에 대한 완전한 클라이언트측 예측을 수행할 수 있게 합니다. PHYS_FallingPHYS_Projectile 의 경우가 바로 이 경우입니다. 이러한 행동 패턴에서 벗어날 수는 없습니다(예측에 아주 유용한 Physics 변수인 bBounce 를 사용하여 플레이하지 않는 한). 마지막으로, 클라이언트가 소유자가 아니고 클라이언트측 애니메이션의 설정이 아니라는 가정하에 이 역할에 대한 애니메이션 또한 업데이트 되어집니다. 요약하면, 이 역할은 클라이언트에서 데이터를 원활하게 예측하는 액터를 위한 것입니다.

Pawn ROLE_SimulatedProxy

ROLE_SimulatedProxy 과 Pawn과 결합되면 넷플레이에서 다르게 작동하는 각종 다른 종류의 시뮬레이션된 프록시가 만들어집니다. Pawn은 복제에 관해서는 가장 복잡한 액터 중 하나입니다. 그 이유는 클라이언트측 예측에 필요한 액터이면서도 폰 액터 자체의 이동은 고유적으로 예측 불가능하기 때문입니다. 폰을 하위 클래스로 지정하는 것 이외에는 이 행동 패턴을 복제하는 방법은 없으므로 발사물의 하위 클래스에서 이 작업을 수행하려고 해서는 안됩니다. Simulated Pawn은 최상의 덤프록시와 시뮬레이션된 프록시를 갖게 됩니다. Simulated Pawn은 클라이언트측 예측을 위해 속도 업데이트를 받고, 동시에 서버가 플레이어의 위치를 ‘재조절’하기 위한 위치 업데이트를 받습니다. 새로운 위치 업데이트가 접수될 때 왜 폰이 점프하지 않는지 이상하게 생각하실 수 있습니다. 플레이어의 실제 위치에서부터 너무 멀리 떨어진 위치인 경우 서버가 제공한 위치를 향해 액터가 원활하게 이동하게끔 유발하는 native 코드가 있습니다. 이것은 서버 버전에 플레이어들을 정확히 맞게 유지시키면서 원활한 플레이어의 움직임을 보장합니다. 플레이어가 아닌 모든 폰은 속도만의 클라이언트측 예측으로 충분합니다. 이러한 폰에는 물리가 고려되지 않습니다. 그 이유는 일부 플레이어가 아닌 폰은 PHYS_Spider 될 수 있거나 항상 걷기/낙하 예측과는 작동하지 않는 다른 다양한 물리가 될 수 있기 때문입니다. 플레이어 폰만이 낙하/도보 물리를 가질 수 있는 특수 클라이언트측 예측을 가질 수 있습니다. 이 물리는 플레이어가 지상에 있지 않은 경우 영역의 중력을 적용하여 달성되는 추측된 물리입니다. 폰의 bCanFly 변수가 설정되어 있는 경우 이 논리는 바이패스되고 클라이언트측 물리에서 제외되지만 폰에서는 물리 복제가 없기에 코드에서 반드시 설명되어야 합니다. 이 논리는 또한 폰이 물 영역에 위치한 경우에도 또한 바이패스 되어집니다. 이것은 기본 도보/낙하 물리와 다릅니다. 물 영역에서 액터는 속도만을 사용하여 예측됩니다. 이러한 영역에 존재하는 중력의 양은 적기 때문에 이것만으로 충분합니다. 액터는 다양한 방법으로 자신의 위치를 ‘조정’하기 때문에 장기적으로 실제 큰 차이가 없습니다. 마지막으로 폰의 회전은 업데이트됩니다. 회전(직접 ViewRotation? 기초하거나 플레이어가 바라보고 있는 방향)은 급격하게 변경될 수 있기 때문에 예측을 할 수 없습니다. 대신, 플레이어의 회전은 새 플레이어 회전 정보가 클라이언트에서부터 들어오면서 조정됩니다. 애니메이션은 다른 폰이 아닌 시뮬레이션된 프록시와 동일한 방법으로 처리됩니다.

ROLE_AutonomousProxy

이것은 사용자를 위한 것입니다. 온라인 게임을 플레이할 때 자신은 다른 PlayerControllers와는 다르게 취급되야 합니다. 본인 자신이 서버의 예상대로 예측되어지는 것을 원하지 않을 것입니다. 오히여 본인 자신을 콘트롤하고 서버에게 자신의 진행 위치를 알리고 싶을 것입니다. 이것이 이 역할의 목적입니다. 이 역할은 클라이언트가 직접 콘트롤하는 사물에 사용됩니다. 대부분의 경우 PlayerControllers에만 의해서 사용됩니다. Unreal이 Autonomous Proxy 액터를 볼 때 액터의 상위 소유자(owner->owner->owner...)를 찾습니다. 이것은 PlayerController이어야 합니다. 만약에 Top Owner가 현재 복제되어지는 플레이어가 아닌 경우 일시적으로 RemoteRoleROLE_SimulatedProxy 로 변경합니다. UnChanUActorChannel::ReplicateActor 는 Autonomous Proxy 액터가 다른 모든 사람한테 Simulated Proxy 액터로 본인한테는 Autonomous Proxy 액터로 취급되게 하여줍니다. 액터의 RemoteRole=이 =ROLE_AutonomousProxy 로 설정되면 액터의 소유자를 제외한 모든 사람에게는 Simulated Proxy로 나타납니다. 이 기법은 동일한 방법으로 작동하고 플레이어가 단순히 시뮬레이션하는 클라이언트와는 다른 프록시 설정을 가지도록 조정할 수 있게 하여주기 위해 Guided Redeemer와도 함께 사용된다는 것에 유의하십시오. 서버가 사용자의 Guided Redeemer가 어디로 날아가고 있는지 사용자에게 알려주는 것은 적절하지 않습니다. 오히려 서버에게 사용자의 Guided Redeemer가 어디에 있는지 알려주고 싶을 것입니다. Autonomous Proxy는 이것을 사용자를 위해서만 ‘작동’ 시키지 않으므로 사용자의 Redeemer를 보고 있는 사람들로부터 사용자를 구분합니다. 이것은 다른 사람과 비교하여 사용자가 차별화되게 행동하도록 하는데 필요한 것입니다.

역할 요약

역할:

  • ROLE_Authority 는 액터를 제어하는 서버 또는 컴퓨터에 사용됩니다.

RemoteRoles:

  • ROLE_None 은 액터가 전혀 관련되지 않아야 한다는 것을 표시하는데 사용됩니다.
  • ROLE_DumbProxy 는 클라이언트측 시뮬레이션 또는 행동이 필요없는 액터에 사용됩니다. 실제로는 거의 사용되지 않습니다.
  • ROLE_SimulatedProxy 는 초기 회전, 위치, 속도 설정에 기초한 클라이언트측 시뮬레이션을 필요로 하는 모든 액터에 사용됩니다. 시뮬레이션된 폰은 Simulated Proxies 얻는 모든 정보 이외에 시간 경과에 따라 이 3가지 변수를 얻습니다.
  • ROLE_AutonomousProxy 는 소유자와는 별도로 취급될 필요가 있는 클라이언트 제어 액터에 사용됩니다. 이것은 클라이언트에서 액터를 시뮬레이션하는데 Simulated Proxy를 사용하는 게임에서의 다른 플레이어에 대한 클라이언트에서 서버로의 이동 정보를 제공합니다.

이러한 다양한 역할을 정의하는 실제 코드는 액터의 변수 복제문에서 보여집니다. 그것이 바로 역할이 해야할 것을 수행하게 만드는 코드입니다(물론, 일부 내부 native 코드 이외에).