인프런 영문 브랜드 로고
인프런 영문 브랜드 로고

인프런 커뮤니티 질문&답변

wwwwhy님의 프로필 이미지

작성한 질문수

이득우의 언리얼 프로그래밍 Part3 - 네트웍 멀티플레이 프레임웍의 이해

11강 움직임 리플리케이션

움직임 리플리케이션 질문

작성

·

68

0

안녕하세요 저는 데디케이티드 서버 환경으로 공부를 진행하고 있습니다.

강의를 통해 움직임 리플리케이션을 공부하다가 궁금한점이 생겨 글을 남깁니다.

현재 제가 이해하고 있는 움직임 리플리케이션의 간단한 플로우는 아래와 같습니다.

1. 클라가 이동하고자 하는 좌표를 누르면 해당 방향으로 클라가 이동한다

2. 이 과정에서 매 틱마다 클라가 움직인 변화값이 하나의 데이터화 되어 RPC를 호출해 서버에 움직인 값을 전달한다

3. 서버는 클라가 움직인 변화값을 기반으로 서버에서 시뮬레이션을 진행한다

4. 서버와 클라의 위치에 별다른 오차범위, 특이 사항이 없다면 그대로 승인 RPC를 호출하고

5. 만약 서버와 클라간에 오차가 발생하면 해당 부분을 보정하여 클라에게 수정을 요청하는 RPC를 호출한다

6. 클라는 서버가 수정 값을 보내줬다면 보정된 위치로 이동한다 (오차 범위에 대한 동기화)

 

이 내용을 기반으로 질문드리고 싶은 내용은 아래와 같습니다.

그렇다면 캐릭터를 움직이는 로직을 구현할 때, 서버와 클라이언트의 코드를 분리해서 서버와 클라가 Tick부분에서 같이 움직이는 방식은 비효율적인가요?

 

예를 들어서 클라이언트가 이동하고자 하는 목적지를 클릭했다면, 그 목적지 좌표를 Server RPC를 호출하여 리플리케이트하고

Tick() 부분에서 클라액터도 움직이고 서버 액터도 같이 움직이게 하는 방식같은 케이스입니다..

 

이 방식을 생각했던 이유는 캐릭터가 목적지로 이동하고 있을때 클라이언트 쪽에서 렉이 걸려서 잠깐 멈췄다가 접속해도

클라이언트의 캐릭터는 계속 목적지를 향해서 달리고 있는 상황을 재현하고 싶어서였습니다.

서버와 클라이언트가 둘 다 목적지를 알고 있고, 그 목적지로 Tick에서 같이 이동하는 방식이면,

네트워크 연결이 원활할 경우엔 기존 리플리케이트 플로우처럼 서버는 클라의 움직임을 검증하고 승인할 것이며,

오차범위가 발생할 경우 서버가 목적지까지 움직이고 있었으니 서버의 위치로 클라를 동기화할 수 있기 때문입니다.

더불어 서버는 클라이언트가 어떠한 이동의 변화값을 보낼지 짐작할 수 없으며, 최악의 경우에는 클라이언트가 악의적으로 잘못된 이동값을 전달할수도 있다는 걱정도 이 이유에 포함됩니다.

 

하지만 이러한 생각을 기반으로 HasAuthority() 함수를 이용해 코드를 분리해서 구현해보니

서버에서 이동한 위치는 결국 다시 클라에 RPC를 해줘야하고, 클라에서 AddMovementInput으로 움직인 값은 서버에 자동으로 RPC되고....

뭔가 이중 RPC를 하는 느낌이 들더라구요.. 제가 너무 깊게 생각한건가 싶기도 하고...

제가 이해를 잘못해서 오히려 생각을 이상하게 해버린건지, 아니면 접근 방식이 잘못된건지

개인적인 선생님의 의견을 들어보고 싶습니다.

 

답변 2

0

이득우님의 프로필 이미지
이득우
지식공유자

네 서버와 클라 움직임의 동기화 방법은 다양하고, 게임의 장르마다 구현 방식도 다릅니다.

말씀주신 방법으로는 틱마다 정보를 전송하더라도 어짜피 통신으로 인한 지연시간이 있기에 부드러운 움직임을 만들기는 어려울 것 같습니다. 그리고 어떤 데이터를 보내는지 명확하지 않아 올바른 방법인지 판단하기가 어렵네요. 악의적인 의도로 발생할 모든 경우를 서버가 다 검증하면 계산량과 통신량이 많아지니, 게임로직에서 판정과 같은 핵심적인 부분만 검증하는 형태로 진행하는게 좋을 것 같습니다.
언리얼의 움직임 동기화 로직 및 데이터 구조가 많은 고민 끝에 만들어졌으니, 이를 참고하시고 자신의 게임에 맞춰서 추가로 잘 응용하시면 될 것 같아요.

0

인프런 AI 인턴님의 프로필 이미지

안녕하세요, 인프런 AI 인턴입니다. wwwwhy님.

언리얼 엔진에서의 움직임 리플리케이션과 관련한 궁금증을 해결해 보겠습니다. wwwwhy님께서 언급하신 방식은 클라이언트와 서버가 서로 다른 목적을 가지고 움직임을 처리할 때 유용할 수 있지만, 일반적인 상황에서는 클라이언트가 서버의 권위를 받아들이고 그에 따라 움직이는 구조가 더 일반적입니다. 이를 통해 네트워크 지연이나 패킷 손실로 인한 문제가 줄어들며, 서버가 궁극적으로 게임의 상태를 관리하는 역할을 수행합니다.

서버와 클라이언트 간의 움직임 리플리케이션:

  1. 클라이언트에서 목적지 설정: 클라이언트가 움직임을 위해 특정 좌표를 설정하면, 그 좌표를 서버로 전송해야 합니다.

  2. 서버에서 검증 및 반영: 서버는 클라이언트가 설정한 움직임 좌표를 수신하고, 이를 바탕으로 서버 내에서 움직임을 검증하게 됩니다. 서버는 이 검증 과정에서 클라이언트의 의도한 움직임이 합리적인지 확인합니다.

  3. 클라이언트와 서버의 동기화: 서버는 검증된 결과를 클라이언트와 동기화하여, 클라이언트 측에서도 동일한 움직임이 이뤄지도록 합니다. 이 과정에서 서버는 클라이언트의 정보를 통해 추가적으로 보정 작업을 수행할 수 있습니다.


이중 RPC 발생 우려 해결:

  • 클라이언트 절차: 클라이언트가 목적지로 이동하는 도중 렉이 발생하더라도, 서버는 지속적으로 해당 클라이언트의 목적지를 인지하고 있기 때문에 서버 측에서 발생한 위치 정보를 클라이언트에게 전송하여 클라이언트의 상태를 보정할 수 있습니다.

  • 보정 및 승인 과정: 만약 클라이언트가 잘못된 움직임 정보를 서버에 보냈다면, 서버는 그 정보를 무시하고 보정된 데이터를 활용해 클라이언트를 동기화시킬 수 있습니다.

이러한 방식으로 처리하게 되면, 서버가 움직임의 최종 결정권을 가지게 되고 네트워크 지연이나 클라이언트의 악의적인 움직임에 대한 처리가 보다 용이해집니다.

여기에 추가적으로 “서버와 클라이언트의 움직임 동기화” 문서를 참고해 보시는 것도 좋습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

wwwwhy님의 프로필 이미지

작성한 질문수

질문하기