UEFN 및 Unreal Engine Multiplayer에서 Player Location Desync 해결 방법

Multiplayer Transform Desync의 악몽

모든 멀티플레이어 게임 개발자는 결국 netcode가 거짓말을 하기 시작하는 순간을 마주하게 됩니다. 플레이어가 의자에 앉고, 의자가 맵을 가로질러 이동하는 시퀀스를 스크립트로 작성하면 서버에서는 모든 것이 완벽해 보입니다. 하지만 두 번째 클라이언트를 실행하는 순간 환상은 깨집니다. 클라이언트 A는 자신이 의자에 잘 앉아 있는 것으로 보이지만, 클라이언트 B는 의자만 이동하고 클라이언트 A는 시작 지점의 공중에 얼어붙은 채 떠 있는 것을 보게 됩니다.

이 특정 현상—uefn player location desync—은 플레이어 입력을 사용하여 플레이어가 부착(attached)된 프롭에 MoveTo 명령을 트리거할 때 발생하는 잘 알려진 고충입니다. 서버는 올바른 절대 위치를 등록하지만, simulated proxies(다른 클라이언트의 플레이어 표현)가 부모 프롭으로부터 업데이트된 transform을 상속받지 못해 발생합니다.

UEFN에서 커스텀 경험을 제작하든 Unreal Engine 5에서 독립형 dedicated server를 설계하든, 어태치먼트 replication이 실패하는 이유를 이해하는 것은 매우 중요합니다. 이 튜토리얼에서는 Network Dormancy의 메커니즘, 어태치먼트가 client-side prediction을 깨뜨리는 이유, 그리고 replication graph가 월드 상태를 강제로 따르게 만드는 방법을 분석합니다.

어태치먼트가 Network Updates를 방해하는 이유

데싱크를 해결하려면 먼저 Unreal Engine이 actor replication을 계층적으로 처리하는 방식을 이해해야 합니다.

캐릭터 액터가 프롭에 부착되면 transform은 부모 액터에 대한 상대값이 됩니다. 대역폭을 절약하기 위해 Unreal Engine은 Network Dormancy라는 개념을 적극적으로 활용합니다.

플레이어가 의자에 앉아 직접적인 movement input을 중단하면, 서버의 replication graph는 플레이어 액터를 dormant(휴면) 상태로 표시할 수 있습니다. 서버는 *"플레이어가 독립적으로 움직이지 않으니 업데이트를 보낼 필요가 없다. 움직이는 의자에 대한 업데이트만 보내겠다"*고 가정합니다.

데싱크의 수치적 원인

• Server Tick Rate: UEFN에서는 보통 30Hz.
• Prop NetUpdateFrequency: 기본적으로 초당 100회 업데이트.
• Character MinNetUpdateFrequency: 입력이 없거나 휴면 상태일 때 초당 2.0회까지 떨어질 수 있음.

의자에 MoveTo를 호출하면 의자의 transform은 30Hz로 업데이트됩니다. 하지만 부착된 플레이어가 dormant 상태이거나 매우 낮은 빈도로 업데이트되기 때문에, 다른 클라이언트들은 플레이어의 상대 위치를 업데이트하라는 RPC (Remote Procedure Call)를 받지 못합니다. 결과적으로 심각한 시각적 데싱크가 발생합니다.

1단계: UEFN Verse 우회 방법

UEFN 버그 리포트에서 개발자들은 중요한 단서를 발견했습니다. 의자에서 내리면 문제가 해결된다는 것입니다. 이는 플레이어의 movement mode를 Walking으로 바꾸면 서버가 Network Dormancy를 플러시(flush)하고 모든 클라이언트에 절대 transform 업데이트를 강제로 브로드캐스트하기 때문입니다.

Verse에서 플레이어를 실제로 내리게 하지 않고도 마이크로 텔레포트를 통해 replication graph를 깨워 이 "플러시"를 재현할 수 있습니다.

# [Verse 코드는 원문 유지]

동일한 좌표로 TeleportTo를 호출하면 C++ 엔진의 TeleportPhysics 플래그가 트리거되어 해당 액터의 client-side prediction이 완전히 초기화됩니다.

2단계: 네이티브 Unreal Engine C++ 수정

소스 코드에 접근할 수 있다면 networking API를 직접 사용하여 dormancy를 관리할 수 있습니다.

// UE5 C++ 강제 네트워크 업데이트 예시
// [C++ 코드는 원문 유지]

3단계: 백엔드에 상태 저장

실시간 데싱크 수정은 절반의 성공일 뿐입니다. 지속적인 월드가 있는 게임이라면 데이터베이스에 정확한 절대 좌표가 저장되어야 합니다. horizOn은 게임 개발자를 위해 설계된 Backend-as-a-Service로, 실시간 상태 유지 기능을 제공합니다.

멀티플레이어 이동 및 어태치먼트 5가지 베스트 프랙티스

1. 클라이언트의 어태치 상태를 믿지 마세요: 항상 server-authoritative RPC로 검증하세요.
2. 탈것의 NetDormancy를 수동으로 관리하세요: 이동 중에는 FlushNetDormancy를 명시적으로 호출하세요.
3. 어태치 계층을 얕게 유지하세요: 플레이어 -> 의자 -> 기차 -> 이동 플랫폼과 같은 깊은 계층을 피하세요.
4. 중요한 상태 변경에는 신뢰할 수 있는 RPC를 사용하세요: 승하차 시 NetMulticast를 사용하세요.
5. 하차 시 Transform을 검증하세요: 서버 측에서 위치의 유효성을 체크하세요.

결론

멀티플레이어 데싱크는 엔진이 네트워크 트래픽을 최적화하는 과정에서 발생합니다. Network Dormancy를 이해하면 Verse나 C++를 통해 강제로 업데이트를 수행할 수 있습니다. replication graph를 제어하고 서버 권한을 강화하세요.

백엔드 확장이 고민이신가요? horizOn을 무료로 체험해 보세요.