[ UE5 ] 액터의 역할과 커넥션 핸드셰이킹

.

---

 

 

우리가 사용하는 리슨 서버 구조에서는

서버와 클라이언트가 동일한 어플리케이션을 사용한다.

 

그렇기 때문에 이 어플리케이션을 구현할 때는

서버와 클라이언트가 같은 코드를 사용해야 되는데

 

신뢰를 가져야된다.

신뢰를 가져야 하는 액터는 서버에만 존재하기 때문에

게임 플레이에 영향을 미치는 게임 로직은

 

우리가 서버인지를 파악해서 그 서버에서만 동작하도록 구성을 해줘야 된다.

액터 단위로 이 액터가 신뢰할 수 있는지를 파악할 수 있어야 되는데

 

이를 위해서 제공하는 것이 언리얼엔진에서는 '역할' 이라는 설정을 제공한다.

 

현재 동작하는 어플리케이션을 중심으로 해서 이 어플리케이션의 역할을

로컬 역할, 그리고 이 어플레케이션과 커넥션으로 맺어진 원격 어플리케이션의

역할을 리모트 역할이라고 한다.

 

그리고 오른쪽에 어플리케이션을 살펴보면,

오른쪽에 커넥션으로 맺어진 어플리케이션

 

관점에서는 여기에서의 로컬 역할이 왼쪽 어플리케이션의 리모트 역할이 된다.

여기서 리모트 역할은 왼쪽 어플리케이션의 로컬 역할이 되는

이런 상대적인 구조를 가지고 있다.

이렇게 액터에 설정된 역할을 사용해서 서버와 클라이언트가 동일하게 사용하는

어플리케이션에서 우리는 클라이언트 서버 모델을 구현할 수 있게 되는 것이다.

---

 

 

액터의 역할은 4가지 종류가 있다.

두 군데 모두 액터가 존재하지 않을 수도 있다.

이 경우에 원격에서는 역할이 없다. 

 

그리고 서비스를 대표하는 신뢰할 수 있는 역할이 있다.

이것은 게임 로직을 수행하는 데 Authority를 가진다고 표현한다

 

그리고 나서 나머지는 프록시들이다.

첫번재 프록시는 Autonomous 프록시라고 하는데

이 Authority를 가진 액터의 복제품이다.

일부 게임 로직을 수행하는 특징이있다.

 

그 다음에 Simulated 프록시는 게임 로직을 전혀 수행하지 않고

서버에 변경된 사항을 그냥 반영만 해주는 허상 액터라고 할 수 있다.

 

 

Autonomous는 서버의 액터정보를 일방적으로 보내는게 아니라

클라이언트 에서도 사용자의 조작 정보에 관련한

입력 데이터들을 서버에 보내주는 역할을 수행한다.

 

반면에 Simulated 같은 경우에는

일방적으로 서버로부터 데이터를 수힌해서 그 결과를 반영해주면 된다.

주로 배경 액터들이 여기에 해당 된다.

 

Autonomous 역할을 하는 액터로는 주로 입력에 관련된 것들을 처리하는

플레이어 컨트롤러와 폰이 있다.

---

---

 

 

서버에만 존재하는 액터는 클라이언트에는 아예 존재하지 않는다.

주로 게임의 승패를 결정하는 규칙을 관리하는데 사용한다.

대표적인 액터로는 게임 모드를 들 수가 있다.

 

그리고 서버와 모든 클라이언트에 존재하는 액터들이 있다.

이 회사의 대표적인 액터로는 배경 액터,

시뮬레이티드 프록시가 해당된다고 볼 수가 있다.

 

그리고 서버와 모든 클라이언트가 아닌 소유하는 클라이언트

즉, 오너쉽을 가지는 클라이언트에만 배치되는 액터가 있다.

대표적인 예시로 오토너머스 프록시 역할을 가지는

플레이어 컨트롤러가 있다.

 

마지막으로는 클라이언트 기능만 구현하는

특별한 오브젝트들이 있다.

주로 시각적인 표현을 담당하는 오브젝트들이다.

애니메이션 재생을 담당하는 애니메이션

블루프린트나 어떤 헤드업 디스플레이 같은

UI에 관련된 오브젝트들이 클라이언트 기능만

수행하는 이런 특별한 오브젝트라고 볼 수가 있다.

 

 

이러한 특징들을 알면 역할 관련된 API를

불 필요하게 호출하는 것을 막을 수가 있다.

 

게임 모드의 경우에는 서버에만 존재하기 때문에

굳이 HasAuthority 함수를 호출해

이것이 신뢰를 할 수 있는지 없는지를 파악할 필요가 없다.

 

폰의 경우에는 오토너머스와 시뮬레이티드가 혼재 되어있다.

그렇기 때문에 API를 사용해 Autonomous인지 Simulated 인지 파악해

입력에 관련된 로직을 구분해서 처리를 해줘야 된다.

 

시각적인 기능을 담당하는 애니메이션 재생이나

UI라든지 이펙트 같은 로직들은 클라이언트에서만 사용하게 된다.

이 경우에는 서버는 어떤 액터의 변경된 속성 정보만 전달하고

이 속성이 변경되면 그 변경된 속성을 파악해서

애니메이션이나 UI를 바꾸도록 설계 해주면 된다.

 

---

 

게임 모드의 경우에는 원격 역할이 없다. 

처음에 플레이어 컨트롤러도 원격 역할이 없다고 되어 있다가

포스트 로그인이 수행되면서 준비가 되어 가는 과정에서 플레이어 컨트롤러와

플레이어들이 다 시뮬레이티드 프록시로 변경되는 것을

확인할 수 있다.

 

 

서버쪽에서, 클라이언트가 하나 추가가 되면 접속한

플레이어 컨트롤러가 생성이 될 때는

역할이 없는데 포스트 로그인 과정에서 OnPossess 함수를 통해서

빙의가 진행된다.

플레이어 같은 경우에 오토너머스 프록시로

설정되어 있는게 보인다.

 

처음에는 시뮬레이티드 프록시로 처음에 설정이 되는데

말 그대로 서버가 보내주는 

정보만 사용하겠다는 것이다.

 

그런데 빙의하는 과정에서 이 Owner가 설정되면서

오토너머스 포록시로 변경되는 것이다.

 

이렇게 해서 플레이어 컨트롤러와 캐릭터에 해당하는

캐릭터 플레이어 경우에는 두 가지

다 오토너머스 프록시로 원격 역할이

설정되는 것을 우리가 확인 할 수 있다.

 

 

클라이언트 관점에서 로컬 역할과 원격 역할을 살펴보자

 

플레이어 컨트롤러 처음에는 역할이 없다가 포스트 넷 이닛을 통해서

네트워크로부터 모든 설정이 완료가 되었다.

설정했던 값들이 세팅이 완료가 되면

 

이거랑 반대로 설정이 되게 되는데

그래서 컨트롤러와 플레이어 경우에는 로컬 역할이 오토너머스 프록시가 되고

원격 역할이 Authority를 가진 Authority가 된다.

 

그리고 마지막에 보면 시뮬레이트 프록시라고 되어 있는

플레이어가 있는데 이것은 서버도 플레이어로 참여를 하니까

서버용 플레이어에 대해서는 Ownership을 가지고 있지 않기 때문에

이 경우는 그냥 우리가 조작할 수가 없는 것이다.

그렇기 때문에 서버로 보내주는 데이터만 일방적으로 받아서 이 친구의

위치와 상태만 변경해주는 시뮬레이티드 프록시로 동작을 하게 된다.

 

 

 

 

로컬 플레이어 클라이언트 입장에서 자기 자신이 0번이다.

자기 자신이 0번에 대해서는 지금 오토너머스 프록시로 설정되어

있는 것을 볼 수가 있고

 

서버 캐릭터 즉, 외부 캐릭터 이것이 1번인데 1번의 경우에는

시뮬레이티드 프록시로 설정되어 있는 것을 확인 할 수 있다.

 

 

IsLocallyControlled 함수를 호출하고 이것이 참이 아니면

그냥 반환하도록 되어있다.

여기서 컨트롤러를 가져와서 입력에 관한 설정들을

이 함수 로직에서 진행을 하게 되는데

오토너머스 프록시의 경우에는 이것을 진행하는 게 맞다.

 

컨트롤 할 수 있으니까 하지만 남의 캐릭터 시뮬레이티드

프록시 같은 경우에는 

컨트롤러 자체가 부여가 되지 않는다.

 

그냥 폰에 대한 정보만 복제가 되는 형태이기 때문에

이 로직을 실행 할 수가 없다.

그렇기 때문에 IsLocallyControlled 라는 함수를 호출해서

내가 소유한 캐릭터의 로직인지 아닌지를

이렇게 걸러낼 수가 있다.

 

 

---