언리얼 엔진의 리플리케이션 및 RPC 순서 보장

같은 복제 업데이트에 포함됐다면#

서버에서 세 값을 바꾸고 그 변경들이 모두 같은 액터의 한 복제 업데이트에 포함됐다고 하자.

1
void AChest::OpenImmediately()
2
{
3
    if (!HasAuthority())
4
    {
5
        return;
6
    }
7

8
    bHasKey = true;
9
    bIsUnlocked = true;
10
    bIsOpen = true;
11
}

이 예시의 단순한 불리언 세 개는 함께 전달된다.

1
서버                                  클라이언트
2

3
세 값을 모두 true로 변경
4
    │
5
복제 업데이트 #1 전송
6
[HasKey, IsUnlocked, IsOpen] ─────────→ #1 수신
7
                                      세 값 반영

이 업데이트가 담긴 패킷이 손실됐다고 해서 bIsUnlocked만 빠지고 나머지 두 값이 적용되는 상황은 아니다.

다만 값들이 함께 전달되는 것과 서로 다른 OnRep의 실행 순서는 별개다. 세 프로퍼티에 각각 OnRep를 붙였더라도, 그 콜백들이 선언 순서대로 실행된다고 가정하면 안 된다. 아직 해석되지 않은 객체 참조는 이 단순한 불리언 예시와 구분해서 다뤄야 한다.

서로 다른 복제 업데이트로 전송됐다면#

이번에는 열쇠 확보, 잠금 해제, 상자 열기가 서로 다른 게임 이벤트에서 발생한다고 하자.

1
void AChest::OnKeyObtained()
2
{
3
    if (HasAuthority())
4
    {
5
        bHasKey = true;
6
    }
7
}
8

9
void AChest::OnUnlockCompleted()
10
{
11
    if (HasAuthority() && bHasKey)
12
    {
13
        bIsUnlocked = true;
14
    }
15
}
16

17
void AChest::OnOpenRequested()
18
{
19
    if (HasAuthority() && bIsUnlocked)
20
    {
21
        bIsOpen = true;
22
    }
23
}

함수가 다르다는 사실만으로 변경들이 따로 전송되는 것은 아니다. 서로 다른 서버 프레임에서 호출됐더라도, 액터의 다음 복제 시점에 함께 전송될 수 있다.

여기서는 각 이벤트 사이에 실제 복제 업데이트가 있었고 세 변경이 각각 업데이트 #1, #2, #3으로 전송됐다고 가정한다. 또한 #2의 손실이 보완되기 전에 #3이 전송·수신되는 상황을 가정한다.

도식에는 설명에 필요한 변경만 표시했다. 실제 업데이트에 항상 프로퍼티 하나만 들어간다는 의미는 아니다.

클라이언트가 관찰하는 값은 다음과 같다.

#3을 받은 직후에는 “잠겨 있는데 열린 상자”가 된다. 서버에는 없었던 상태 조합이다.

최종 값은 맞아져도 후속 처리는 누락될 수 있다#

클라이언트의 상자 열림 처리가 다음과 같다고 하자.

1
void AChest::OnRep_IsOpen()
2
{
3
    if (!bIsOpen || !bIsUnlocked)
4
    {
5
        return;
6
    }
7

8
    PlayOpenAnimation();
9
}

#3을 받으면 bIsOpen은 true가 되고 OnRep_IsOpen()이 실행된다. 하지만 bIsUnlocked는 아직 false이므로 함수가 그대로 종료된다.

이후 보완 업데이트를 받으면 bIsUnlocked도 true가 된다. 그렇다고 OnRep_IsOpen()이 다시 호출되지는 않는다. 이 함수는 bIsOpen의 RepNotify이지, 다른 프로퍼티의 변경까지 감시하는 함수가 아니기 때문이다.

따라서 두 문제를 구분해야 한다.

• 프로퍼티 값은 복제가 정상적으로 이어지면 누락된 상태가 보완되어 서버의 최종 값과 맞아진다.
• 게임 코드의 후속 처리는 그렇지 않다. 이전 값을 보고 건너뛴 애니메이션은 자동으로 다시 실행되지 않는다.

이 예시에서는 bIsUnlocked가 최종 값에 도달해도 상자를 여는 애니메이션 처리는 영구적으로 누락된다.

두 값이 모두 필요하다면 어느 값이 나중에 도착해도 다시 확인하도록 만들 수 있다.

1
// bIsUnlocked도 ReplicatedUsing = OnRep_IsUnlocked로 변경한다.
2
// 두 OnRep는 UFUNCTION으로 선언한다.
3

4
void AChest::OnRep_IsUnlocked()
5
{
6
    TryPlayOpenAnimation();
7
}
8

9
void AChest::OnRep_IsOpen()
10
{
11
    TryPlayOpenAnimation();
12
}
13

14
void AChest::TryPlayOpenAnimation()
15
{
16
    if (bOpenAnimationPlayed || !bIsOpen || !bIsUnlocked)
17
    {
18
        return;
19
    }
20

21
    bOpenAnimationPlayed = true;
22
    PlayOpenAnimation();
23
}

bOpenAnimationPlayed는 false로 초기화한 클라이언트 로컬 플래그다. 여러 콜백에서 재확인하더라도 애니메이션을 중복 재생하지 않게 한다.

이 코드는 한 번만 열리는 상자를 가정한다. 다시 닫히는 상자나 늦게 접속한 플레이어에게는, 과거의 열림 연출을 재생할지 현재 열린 모습만 표시할지도 별도로 정해야 한다.

게임 규칙상 열쇠 확보, 잠금 해제, 열림이 항상 하나의 진행 단계라면, 여러 불리언 대신 Locked, Unlocked, Open 같은 하나의 상태 값으로 표현하는 설계도 고려할 수 있다.

함께 사용하는 값은 구조체로 묶는다#

무기 종류와 탄약을 하나의 상태로 묶으면 하나의 OnRep에서 처리할 수 있다.

1
USTRUCT()
2
struct FWeaponState
3
{
4
    GENERATED_BODY()
5

6
    UPROPERTY()
7
    FName WeaponId = NAME_None;
8

9
    UPROPERTY()
10
    int32 Ammo = 0;
11
};
12

13
// AMyCharacter 클래스 내부
14
UPROPERTY(ReplicatedUsing = OnRep_WeaponState)
15
FWeaponState WeaponState;
16

17
UFUNCTION()
18
void OnRep_WeaponState();

1
void AMyCharacter::OnRep_WeaponState()
2
{
3
    // 무기가 달라졌을 때만 UI를 교체한다.
4
    EnsureWeaponUI(WeaponState.WeaponId);
5

6
    SetAmmoText(WeaponState.Ammo);
7
}

이제 처리 순서는 함수 안에 직접 적혀 있다.

1
OnRep_WeaponState()
2
    └─ 무기 UI 준비
3
        └─ 탄약 표시 갱신

구조체로 묶으면 두 콜백 사이에 있던 순서 의존성을 하나의 함수 안으로 옮길 수 있다. 네트워크의 도착 순서는 그대로다.

이렇게 콜백의 처리 순서를 정해도 모든 중간 변경이 전달되지는 않는다. 여러 업데이트에 걸친 값들이 자동으로 하나의 완성된 상태가 되지도 않는다.

변수를 분리해 둬야 한다면 PostRepNotifies를 사용한다#

무기와 탄약을 별도 프로퍼티로 유지하면서 UI 갱신만 모으고 싶을 수도 있다. 이때는 각 OnRep에서 갱신이 필요하다는 표시만 남기고 PostRepNotifies()에서 실제 작업을 수행할 수 있다.

1
// AMyCharacter 클래스 내부
2
bool bWeaponUIDirty = false;
3

4
virtual void PostRepNotifies() override;

1
void AMyCharacter::OnRep_WeaponId()
2
{
3
    bWeaponUIDirty = true;
4
}
5

6
void AMyCharacter::OnRep_Ammo()
7
{
8
    bWeaponUIDirty = true;
9
}
10

11
void AMyCharacter::PostRepNotifies()
12
{
13
    Super::PostRepNotifies();
14

15
    if (!bWeaponUIDirty)
16
    {
17
        return;
18
    }
19

20
    bWeaponUIDirty = false;
21

22
    EnsureWeaponUI(WeaponId);
23
    SetAmmoText(Ammo);
24
}

PostRepNotifies()는 해당 객체의 OnRep 호출들이 끝난 뒤 실행된다.

1
OnRep_Ammo()      ─┐
2
                  ├─ 갱신 필요 표시
3
OnRep_WeaponId()  ─┘
4
                          ↓
5
                  PostRepNotifies()
6
                          ↓
7
                  무기 UI 준비 → 탄약 표시

두 OnRep 중 무엇이 먼저 실행돼도 실제 UI 처리 순서는 같아진다.

다만 이 함수가 손실된 업데이트나 다른 액터의 수신까지 기다려주는 것은 아니다. 무기 종류만 도착했다면, 그때의 탄약 값으로 갱신한다.

PostRepNotifies()가 구조체보다 일반적으로 더 권장되는 방식은 아니다. 공식 문서는 여러 값을 함께 다뤄야 할 때 구조체로 묶는 방법을 권장하고 별도 OnRep의 후속 처리를 모으는 방법으로 PostRepNotifies()를 소개한다.

• 하나의 상태로 함께 사용하는 값이라면 구조체와 하나의 OnRep로 묶는다.
• 프로퍼티는 분리하되 공통 후속 처리를 모아야 한다면 PostRepNotifies()를 사용한다.

Reliable과 Unreliable을 섞으면#

같은 액터에서 다음 순서로 호출했다고 하자.

1
R1: Reliable
2
U2: Unreliable Unicast
3
R3: Reliable
4

5
호출 순서: R1 → U2 → R3

U2의 패킷이 손실되면 해당 호출은 실행되지 않는다.

1
실행 순서: R1 → R3

R1의 패킷이 손실되어 재전송을 기다리는 동안 U2가 먼저 실행될 수도 있다.

1
실행 순서: U2 → R1 → R3

Reliable끼리의 R1 → R3는 유지되지만 세 호출 전체의 순서는 보장되지 않는다.

Multicast도 호출 순서대로 처리되는 것은 아니다#

Unicast RPC는 특정 원격 대상으로, Multicast RPC는 여러 대상으로 호출을 전달한다. 같은 액터에서 같은 수신 대상으로 보내고 모두 Reliable RPC라면 Multicast와 Unicast를 섞어도 순서가 유지된다.

Unreliable Multicast는 다르다. 기본 전송 정책에서는 잠시 대기했다가 뒤에 묶여 전송되므로, 먼저 호출했어도 다른 RPC보다 나중에 실행될 수 있다.

1
호출: Unreliable Multicast → Reliable Client RPC
2
실행: Reliable Client RPC → Unreliable Multicast

전송 정책을 ForceSend나 ForceQueue로 바꾸면 전송 시점도 달라진다. 이 설정은 각각 지원되는 조건에서 전송을 앞당기거나 뒤로 미루는 데 사용되며 서로 다른 액터나 프로퍼티까지 포함한 전체 순서를 보장해주지는 않는다.

현재 상태를 맞추려면 프로퍼티와 OnRep를 사용한다#

남은 탄약, 현재 무기, 장전 중인지 여부는 현재 상태다. 나중에 접속하거나 액터가 뒤늦게 보이더라도 현재 상태에 맞는 표시가 필요하다.

예를 들어 지속되는 장전 표시를 제어하려면 bIsReloading 같은 상태를 복제하고 OnRep에서 표시를 켜거나 끌 수 있다.

다만 클라이언트의 OnRep가 게임 규칙상의 장전을 완료하는 것은 아니다. 서버가 장전 완료를 판단하고 탄약과 장전 상태를 변경하면, 클라이언트가 그 결과를 받아 표현한다.

또한 탄약이 증가했다는 이유만으로 장전 완료라고 판단하면 탄약 획득 등 다른 변경과 혼동할 수 있다. 장전 상태 자체가 필요하다면 이를 명시적으로 표현하는 편이 낫다.

그 순간의 연출을 전달하려면 RPC를 고려한다#

장전 완료음이나 짧은 불꽃처럼, 그 순간의 수신자에게만 보여줄 연출은 RPC가 적합할 수 있다. 뒤늦게 접속한 플레이어에게 과거의 완료음을 재생할 필요는 없기 때문이다.

1
// 소유 클라이언트에게만 전달하는 일회성 연출 예시다.
2
UFUNCTION(Client, Unreliable)
3
void ClientPlayReloadFinishedEffect(int32 AmmoAtCompletion);

1
// 서버가 장전 완료를 처리하는 코드
2
Ammo = 30;
3
bIsReloading = false;
4

5
ClientPlayReloadFinishedEffect(Ammo);

RPC 구현에서는 이벤트 당시의 값인 AmmoAtCompletion을 사용한다. 복제 프로퍼티 Ammo가 먼저 갱신됐다고 가정할 필요가 없다. 이후 발사가 진행됐다면 이 인자는 현재 탄약 수와 다를 수 있다.

이 예시의 연출은 가끔 누락돼도 게임 상태에는 영향이 없다는 전제로 Unreliable을 사용했다. 반드시 전달해야 하는 호출이라면 Reliable을 검토하되, 잦은 호출의 재전송 비용도 고려해야 한다.

이펙트라도 불타는 상태처럼 지속되고 늦게 도착한 클라이언트에도 보여야 한다면 프로퍼티 기반 처리가 적합하다. 반대로 모든 일회성 사건을 받아야 한다면, 중간 변경을 건너뛸 수 있는 OnRep만으로 처리해서는 안 된다.