---

리플리케이션 롤

---

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

롤

---

앞서 말한 것처럼 액터의 우선권이나 프로퍼티를 다양하게 하는 것에 더해, 액터의 데이터 리플리케이션 '방법'도 여러가지 있습니다. 로켓이나 수류탄은 초기 위치와 속도만 있으면, 나머지는 클라이언트가 알아서 시뮬레이션할 수 있습니다. 잠깐 업데이트 도중 게임 내 플레이어의 동작을 시뮬레이션할 수 있도록 하기 위해서는, 위치와 속도 정보 둘 다 다른 모든 클라이언트에 리플리케이트해 줘야 합니다. 이렇게 다양한 역할에 대해 다양한 네트워킹 처리 방식이 있습니다.

액터가 서버와 클라이언트 둘 다에 존재하는 경우, 그 Role (역할) 값은 보통 서버에서는 ROLE_Authority (전권행사)가, 클라이언트에서는 ROLE_SimulatedProxy 나 ROLE_AutonomousProxy (시뮬레이션 / 자율 프록시)가 됩니다. 넷 플레이 상황에서 액터가 맡는 기본적 역할에 따라서 말이죠. 클라이언트에서 액터의 Role 은 보통 액터 defaultproperties 블록의 RemoteRole 값에 지정되어 있지만, 게임내에서 동적으로 바꿔도 아무런 문제 없습니다. Role 값은 보통 현재 Role 필드에 지정되며, RemoteRole 은 반대편에 접속된 곳에 설정된 Role 이 무엇인가를 나타냅니다. 이를 통해 Role 이 ROLE_Authority 인 서버의 코드로 클라이언트에 어떤 종류의 시뮬레이션이 이루어지고 있는지를 확인할 수 있습니다. 일반적으로 어떤 머신에서든 액터를 스폰한 것의 Role 은 ROLE_Authority 입니다. 액터가 클라이언트에 스폰된 경우, 클라이언트의 Role 은 ROLE_Authority 가 되겠지만, 클라이언트에서는 무기 치트나 생성이 쉽기때문에, 그 액터를 서버로 리플리케이트하지는 않습니다.

Role 과 RemoteRole 작동 방식을 이해했다면, 각 롤에 대해 개략적으로 살펴보도록 합시다.

ROLE_Authority

항상 서버의 Role 이라는 점에서 다른 롤과는 다릅니다. 서버의 롤은 항상 ROLE_Authority 이며, RemoteRole 은 다음 중 하나가 됩니다. 클라이언트에서는 그 반대입니다. 롤 자체의 용도는 나중에 설명할 리플리케이션 문에서 말고는 별달리 쓰이는 곳이 없습니다.

ROLE_None

아마도 가장 간단한 롤입니다. 이 액터는 단지 클라이언트에 연관성이 없다 서버에 알리기만 합니다. 그에 대한 정보는 송신되지 않으며, 생성된 머신에만 존재합니다. 주어진 액터가 (나중에 설명할 simulated 함수를 통해) 클라이언트와 서버 둘 다에서 독립적으로 생성된 경우, 그리고 RemoteRole 이 ROLE_None 인 경우, 서버와 클라이언트에 연결되지 않은 액터 인스턴스가 두 개 별도로 존재하게 됩니다. 이는 보통 리플리케이트할 필요가 없고 두 머신에서 독립적으로 스폰 가능한 특수 효과같은 데 주로 사용됩니다.

ROLE_SimulatedProxy

네트워크 반대편에서 예측을 통해 시뮬레이션해야 하는 것에 사용됩니다. 로켓을 예로 들어 봅시다. 항상 직선으로 날아가므로, Simulated Proxy 로 하기에 딱입니다. 마찬가지로 자유낙하는 게임 클라이언트측에서 물리 법칙을 통해 예측할 수 있기에, 이 롤은 수류탄이나 추락하는 것에 좋습니다. 즉 물리나 클라이언트측 물리를 통해 예측할 수 있는 것은 이 롤이 딱이지요. 모든 Controller 역시 이 롤을 사용하는데, 플레이어가 달릴 때는 보통 계속해서 달리려는 경향이 있기 때문에, 그 역시 시뮬레이션 덕을 볼 수 있습니다. 보통은 예측 불가능한 플레이어에 대해 통하는 예측법은 이 정도가 최선이죠. 플레이어에 대한 이러한 방침에서 유일한 예외라면 자신이 플레이하고 있는 폰인데, 보통 자신의 행위를 시뮬레이션할 이유는 없기 때문입니다.

실제적으로 Simulated Proxy 액터는 두 종류 있습니다. Simulated Pawn 과 Simulated Non-Pawn, 둘 다 다르면서도 비슷한 행태를 보입니다. 차이점은 아래와 같습니다.

Non-Pawn ROLE_SimulatedProxy

초기값을 준 상태로 액터 예측을 완전히 클라이언트-측에서 할 것으로 기대합니다. 초기 데이터를 토대로 현재 물리(법칙)에 따라 곡선에 맞추어 추론하는 것과 같다고 볼 수 있죠. ROLE_SimulatedProxy 는 초기 Location, Rotation, Physics (위치, 회전, 물리) 값을 줍니다. 그 이후 변화가 있다면 Velocity (속도)로 업데이트합니다. 오브젝트가 물리 법칙을 따른다는 가정하에, 이 변수들을 통해 클라이언트에서 완벽히 예측해내는 것입니다. PHYS_Falling 과 PHYS_Projectile 인 경우가 그렇습니다. 이러한 행위에는 (예측에 매우 유리한 bBounce 와 같은 물리 변수를 가지고 놀지 않는 이상에야) 일탈적 행위가 있을 수 없습니다. 마지막으로 이 롤의 경우, 클라이언트가 오너가 아니면서 클라이언트측 애니메이션 용으로 설정되지 않았다고 가정한다면, 애니메이션 업데이트 역시도 가능합니다. 요약하자면 이 Role 은 클라이언트에서 그 데이터를 매끄럽게 예측할 수 있는 액터를 위한 것입니다.

Pawn ROLE_SimulatedProxy

ROLE_SimulatedProxy 가 폰과 결합하면, 넷 플레이에서 다른 작용을 하는 다른 종류의 시뮬레이션 프록시가 만들어집니다. 리플리케이션 관점에서 볼 때 가장 복잡한 액터 중 하나가 폰인데, 클라이언트측 예측이 필요하면서도 그 운동이 본질적으로 예측 불가능하기 때문입니다. Pawn 서브클래스를 만드는 것 말고는 이 행위를 따라잡을 수 있는 방법이 없으니, Projectile 서브클래스로는 꿈도 꾸지 맙시다. 클라이언트측 예측을 위해 속도 업데이트를 받음과 동시에, 플레이어의 위치를 '재조정'하기 위한 위치 업데이트를 서버에서 받습니다. 그러면 위치 업데이트가 새로 들어올 때 왜 폰이 점프하지 않는가가 궁금해 지겠지요. 서버에서 받은 위치가 플레이어의 실제 위치와 너무 멀면, 액터가 그 위치를 향해 부드럽게 이동하도록 만드는 네이티브 코드가 있습니다. 이것이 또 플레이어의 운동을 매끄럽게 해 주면서 서버 버전과 일치하도록 만듭니다. 플레이어가 아닌 것들은 속도만 가지고 클라이언트측에서 예측을 합니다. 이러한 폰에 대해서는 물리를 고려하지 않지요. 플레이어가 아닌 경우 PHYS_Spider 가 될 수도, 항상 보행/낙하 예측만으론 해결할 수 없는 그 어떤 물리가 될 수도 있기 때문입니다. 플레이어 폰만이 낙하/보행 물리를 위한 특수 클라이언트측 예측을 합니다. 이 물리는 가상의 물리로, 플레이어가 땅 위에 있지 않은 경우 영역의 중력을 적용하는 식으로 이루어집니다. 이 로직은 폰에 bCanFly (비행 가능) 변수가 설정되어 있는 경우 생략시켜 클라이언트측 물리를 무시할 수 있지만, 폰에는 물리가 리플리케이트되지 않기 때문에 코드에서 참작해 줘야 합니다. 폰이 수중 영역에 있는 경우에도 생략되는데, 기본적인 보행/낙하 물리와도 다르기 때문입니다. 수중 영역에서 액터의 예측은 속도 하나만으로 이루어지는데, 그런 곳에서는 중력이 미미하니 그걸로 충분합니다. 액터는 어쨌든 위치를 '조정'받으니, 길게 보면 실제로 큰 차이는 없습니다. 마지막으로 폰은 방향을 업데이트 받습니다. (ViewRotation 을 직접 기반으로 하거나, 플레이어가 바라보는) 방향은 꽤나 심하게 바뀔 수 있기에 예측을 하지 않습니다. 대신 플레이어의 방향은 클라이언트에서 플레이어 방향 정보가 새로 도착하면 바로 조정됩니다. 애니메이션은 다른 Non-Pawn Simulated Proxy 와 같은 방식으로 취급됩니다.

ROLE_AutonomousProxy

플레이어에 사용됩니다. 온라인 플레이시 자신은 다른 모든 PlayerController 와는 다르게 취급되어야 하겠죠. 자신을 서버의 기대에 따라 예측받는 다는 것이 왠말입니까. 그보다는 마음대로 제어를 하고, 서버에게 어디로 이동하는지 알리는 편이 나을 것입니다. 그게 이 롤의 목적입니다. 이 롤은 클라이언트가 직접 제어하는 것에 사용됩니다. 대부분의 경우 PlayerController 에서만 사용되구요. 언리얼이 Autonomous Proxy (자율 프록시) 액터를 보면, Top Owner 액터 (Owner.Owner.Owner...) 를 찾습니다. 거의 PlayerController 가 되겠죠. 이 Top Owner 가 현재 우리가 리플리케이트 대상으로 삼는 플레이어가 아닌 경우, RemoteRole 을 ROLE_SimulatedProxy 로 임시 전환합니다. 이를 통해 자율 프록시 액터가 다른 모든 이에게는 시뮬레이션 프록시 액터로, 자신에게는 자율 프록시 액터로 취급하는 것이 가능합니다. 액터의 RemoteRole 이 ROLE_AutonomousProxy 로 설정된 경우, 액터의 오너를 제외한 모두에 대해 시뮬레이션 프록시로 나타나게 됩니다.

참고로 이 기법은 유도 보완기(guided redeemer)와 함께 사용, 똑같은 작동 방식을 보장하면서도 시뮬레이션만 하는 기타 클라이언트와는 다른 프록시 세팅을 플레이어에게 할 수 있도록 합니다. 유도 보완기가 어디로 날라가는지를 서버가 자신에게 알리도록 하는 것보다는, 자신의 유도 보완기가 어디 있는지를 서버에게 알리는 편이 낫습니다. 자율 프록시가 그 작업을 알아서 해 주지는 않겠지만 보완기를 보는 데 있어 다른 사람과 자신을 구분해 주기는 하며, 다른 이와 비교했을 때 자신에게 다른 식으로 작용하도록 하는 데는 그 정도면 됩니다.

롤 요약

---

Role

• ROLE_Authority 는 액터를 제어하는 머신이나 서버에 사용됩니다.

RemoteRole

• ROLE_None 은 아무 것에도 연관되지 않은 액터에 사용됩니다.
• ROLE_SimulatedProxy 는 초기 위치, 방향, 속도 세팅에 따라 클라이언트측 시뮬레이션을 해야 하는 액터에 사용됩니다. Simulated Proxy 에 추가로, Simulated Pawn 은 시간에 따라 그 세 가지 값을 추가로 받습니다.
• ROLE_AutonomousProxy 는 그 오너와는 달리 클라이언트에 서버 이동 정보를 제공하여 별도 취급해줘야 하는 클라이언트 제어 액터에 사용됩니다. 반면 게임 내 다른 플레이어에는 Simulated Proxy 를 사용하여 각자의 클라이언트에서 액터를 시뮬레이션합니다.

이와 같이 다양한 롤을 정의하는 실제 코드는 나중에 액터의 변수 리플리케이션 문에 나타납니다. (약간의 내부 네이티브 코드는 말할 것도 없이) 롤이 실제 어떤 일을 하는가가 바로 이 코드에서 결정되는 것이지요.