✍️Today I Learned

📅 2025-12-01

• 플레이어 컨트롤러를 중재자로 활용한 제작 시스템 구현

---

플레이어 컨트롤러를 중재자로 활용한 제작 시스템 구현

오너가 없는 제작대 액터와 플레이어 간의 네트워크 통신을 구현할 때, 플레이어 컨트롤러를 중재자(Mediator) 패턴으로 활용했다.

문제 상황: 오너 없는 액터의 네트워크 통신

제작대(ATSCraftingTable)는 월드에 배치된 액터로, 특정 플레이어의 소유가 아니다. 언리얼의 RPC는 기본적으로 Owner를 통해 라우팅되기 때문에, 오너가 없는 액터에서 직접 클라이언트 RPC를 호출하면 어느 클라이언트로 보내야 할지 알 수 없다.

해결책: 플레이어 컨트롤러 중재자 패턴

클라이언트 → 플레이어 컨트롤러 → 제작대

// PlayerController.h
UFUNCTION(Server, Reliable, WithValidation, BlueprintCallable, Category = "Crafting")
void ServerRequestCraft(ATSCraftingTable* CraftingTable, int32 RecipeID);

// PlayerController.cpp
void ATSPlayerController::ServerRequestCraft_Implementation(
    ATSCraftingTable* CraftingTable, int32 RecipeID)
{
    if (!CraftingTable) return;
    
    ATSCharacter* TSCharacter = Cast<ATSCharacter>(GetPawn());
    if (!TSCharacter) return;
    
    // 제작대의 함수를 대신 호출
    CraftingTable->ServerRequestCraft(RecipeID, TSCharacter);
}

클라이언트 UI에서 제작 버튼을 누르면 → 플레이어 컨트롤러의 ServerRequestCraft RPC 호출 → 서버에서 제작대의 실제 제작 로직 실행

제작대 → 플레이어 컨트롤러 → 클라이언트

// CraftingTable.cpp - 제작 완료 후
void ATSCraftingTable::StartCrafting(int32 RecipeID, ATSCharacter* InstigatorCharacter)
{
    // ... 제작 로직 ...
    
    ATSPlayerController* PC = Cast<ATSPlayerController>(InstigatorCharacter->GetController());
    if (!PC) return;
    
    int32 SlotIndex = CraftingInventory->PlaceCraftResult(PC, RecipeData.ResultItemID, RemainingQuantity);
    
    // 플레이어 컨트롤러를 통해 클라이언트에 알림
    PC->ClientNotifyCraftResult(SlotIndex);
}

// PlayerController.cpp
void ATSPlayerController::ClientNotifyCraftResult_Implementation(int32 SlotIndex)
{
    // 델리게이트 브로드캐스트로 UI 업데이트
    OnCraftComplete.Broadcast(SlotIndex);
}

제작 완료 → 플레이어 컨트롤러의 ClientNotifyCraftResult RPC로 결과 전달 → OnCraftComplete 델리게이트 브로드캐스트 → UI가 슬롯 업데이트

중재자 패턴의 장점

1. 네트워크 라우팅 문제 해결

• 플레이어 컨트롤러는 항상 명확한 Owner 관계를 가짐
• 서버와 클라이언트 간 안정적인 RPC 통신 보장

2. 권한 검증 중앙화

bool ATSPlayerController::ServerRequestCraft_Validate(
    ATSCraftingTable* CraftingTable, int32 RecipeID)
{
    return CraftingTable && RecipeID > 0;
}

플레이어 컨트롤러에서 한 번만 검증하면 됨

3. UI 통신 간소화

• UI 위젯 → 델리게이트 바인딩 → 플레이어 컨트롤러만 알면 됨
• 제작대 액터를 직접 참조할 필요 없음

제작대 종료 처리

// PlayerController.h
UFUNCTION(Server, Reliable, BlueprintCallable, Category = "Crafting")
void ServerNotifyCraftingTableClosed(UTSCraftingTableInventory* CraftingInventory);

// PlayerController.cpp
void ATSPlayerController::ServerNotifyCraftingTableClosed_Implementation(
    UTSCraftingTableInventory* CraftingInventory)
{
    if (CraftingInventory)
    {
        CraftingInventory->OnPlayerClosedUI(this);
    }
}

클라이언트가 제작대 UI를 닫으면 → 서버에 알림 → 제작대 인벤토리 정리. 이것도 플레이어 컨트롤러를 통해 처리.

---

💡 느낀 점 (What I Felt)

처음엔 "제작대에서 직접 RPC 날리면 되지 않나?"라고 생각했는데, Owner가 없는 액터는 어느 클라이언트한테 보낼지 몰라서 안 된다는 걸 깨달았다. 플레이어 컨트롤러가 중간에서 전달하는 중재자 역할을 하니까 깔끔하게 해결됐다.

이 패턴의 핵심은 "통신 경로를 명확하게 만드는 것"인 것 같다. UI → PlayerController → CraftingTable → PlayerController → UI 이런 식으로 항상 플레이어 컨트롤러를 거치니까 누가 누구한테 말하는지 헷갈릴 일이 없다.

근데 이렇게 하면 플레이어 컨트롤러가 너무 많은 걸 알게 되는 건 아닌가 싶기도 하다. 제작대도 알고, 인벤토리도 알고, UI도 알고... 나중에 시스템이 더 복잡해지면 플레이어 컨트롤러가 God Object가 될 수도 있을 것 같은데, 그때 가서 리팩토링 고민해봐야겠다.