문제 상황

레벨을 정리할 때 어노말리 액터를 파괴하는 로직

AGameplayCueNotify_Actor 기반의 머티리얼 교체 Cue를 구현하였다.
OnRemove에서 MyTarget과 CachedMaterialCueData 유효성을 모두 체크한 뒤 원본 머티리얼 복원 함수를 호출했음에도, 액터가 파괴될 때 크래시가 발생하였다.

bool ADZGCN_AnomalyChangeMaterial::OnRemove_Implementation(
    AActor* MyTarget, const FGameplayCueParameters& Parameters)
{
    if (!MyTarget) return false;                     // ← 통과
    if (CachedMaterialCueData.Num() == 0) return false; // ← 통과

    for (auto& MaterialData : CachedMaterialCueData)
    {
        if (IsValid(MyTarget))
            ApplyOriginalMaterial(MyTarget, MaterialData); // ← 여기서 크래시
    }
    return true;
}

void ADZGCN_AnomalyChangeMaterial::ApplyOriginalMaterial(
    AActor* MyTarget, FDZMaterialCueData& CueData)
{
    UStaticMeshComponent* TargetMesh = CastChecked<UStaticMeshComponent>(
        MyTarget->FindComponentByTag(..., CueData.TargetMeshTag)); // ← 실제 크래시 지점
    ...
}

원인 분석

OnRemove에서의 IsValid(MyTarget) 체크는 통과하였다.
그러나 액터가 파괴 진행 중(BeginDestroy 이후) 상태일 경우, 액터 자체는 아직 유효한 포인터를 가지고 있더라도 내부 컴포넌트는 이미 정리된 상태일 수 있다.

이 상황에서 FindComponentByTag는 nullptr을 반환하고, 이 nullptr을 CastChecked에 넘기면 즉시 assert 크래시가 발생한다.

OnRemove 진입
    ↓
IsValid(MyTarget) → true  (액터 포인터는 아직 유효)
    ↓
FindComponentByTag → nullptr  (컴포넌트는 이미 정리됨)
    ↓
CastChecked<UStaticMeshComponent>(nullptr) → 💥 크래시

CastChecked는 내부적으로 입력값이 절대 null이 아님을 전제로 동작한다.
외부 조회 결과처럼 null 가능성이 있는 값에는 사용하면 안 된다.

해결 방법

CastChecked → Cast 로 교체하고, 결과에 대해 명시적인 IsValid 체크를 추가하였다.

void ADZGCN_AnomalyChangeMaterial::ApplyOriginalMaterial(
    AActor* MyTarget, FDZMaterialCueData& CueData)
{
    UStaticMeshComponent* TargetMesh = Cast<UStaticMeshComponent>(
        MyTarget->FindComponentByTag(UStaticMeshComponent::StaticClass(), CueData.TargetMeshTag));

    if (!IsValid(TargetMesh))
    {
        UE_LOG(LogTemp, Warning,
            TEXT("ApplyOriginalMaterial: TargetMesh not found. Tag: %s"),
            *CueData.TargetMeshTag.ToString());
        return;
    }

    for (auto& SlotOverride : CueData.SlotOverrides)
    {
        TargetMesh->SetMaterial(SlotOverride.SlotIndex, SlotOverride.OriginalMaterial);
    }
}

OnRemove에서도 !MyTarget 대신 !IsValid(MyTarget)으로 교체하고, 중복 체크를 제거하였다.

bool ADZGCN_AnomalyChangeMaterial::OnRemove_Implementation(
    AActor* MyTarget, const FGameplayCueParameters& Parameters)
{
    if (!IsValid(MyTarget)) return false;
    if (CachedMaterialCueData.Num() == 0) return false;

    for (auto& MaterialData : CachedMaterialCueData)
    {
        ApplyOriginalMaterial(MyTarget, MaterialData);
    }
    return true;
}

핵심 교훈

DungeonZero는 "8번출구" 류의 이상현상 탐지 게임이다. 플레이어는 복도를 반복해서 걷다가 뭔가 달라진 것을 발견해야 한다. 이때 "달라진 것"을 만들어내는 주체가 어노말리 어빌리티다.

4인 멀티플레이를 전제로 하기 때문에 이상현상은 서버에서만 결정되어야 하고, 그 결과는 모든 클라이언트에 동일하게 보여야 한다. 또한 어노말리의 종류는 앞으로 계속 늘어날 것이므로 확장성도 요구된다.

이 두 조건(멀티플레이 복제 + 확장성)을 동시에 충족하기 위해 Unreal의 Gameplay Ability System(GAS) 을 채택했고, 각 이상현상 행동을 독립적인 UGameplayAbility 서브클래스로 구현했다.

현재 구현된 어빌리티는 다음 세 가지다.

설계 원칙 — 메시에 종속되지 않는 범용 어빌리티 (와 그 한계)

이상현상 오브젝트는 의자, 표지판, 소화기 등 메시가 전부 다르다. 어빌리티가 특정 메시나 액터 타입에 종속되면 어노말리를 추가할 때마다 코드를 수정해야 한다.

이를 피하기 위해 두 가지 원칙을 지켰다.

① 어빌리티는 가능한 한 AActor*만 알고 있다 어빌리티 내부 로직은 GetAvatarActorFromActorInfo()로 얻은 AActor*에만 의존하는 것을 원칙으로 한다. AnomalyRelocate와 AnomalyPatrol은 이 원칙을 완전히 따르므로, 어떤 오브젝트에든 부여하면 동작한다.

단, AnomalyScale은 예외다. 스케일 변경은 SetActorScale3D를 호출해도 SetReplicatingMovement만으로는 클라이언트에 복제되지 않는다. 이를 해결하려면 UPROPERTY(ReplicatedUsing = OnRep_...) 전용 변수와 세터가 필요하고, 이 구현은 불가피하게 베이스 액터 클래스(ADZAnomalyActorBase)에 위치할 수밖에 없었다. 결과적으로 AnomalyScale은 ADZAnomalyActorBase를 캐스트해 SetAnomalyScale을 호출하는 형태로 구현되었다.

// DZGA_AnomalyScale.cpp 발췌
if (ADZAnomalyActorBase* AnomalyActor = Cast<ADZAnomalyActorBase>(TargetActor))
{
    AnomalyActor->SetAnomalyScale(NewScale);
}

이는 "멀티플레이 복제 요구사항"과 "범용성" 사이의 트레이드오프이며, 복제 정확성을 우선한 결과다.

② 변화량은 EditDefaultsOnly로 노출한다 크기 범위, 이동 반경, 이동 속도 같은 수치를 블루프린트에서 오버라이드할 수 있게 열어두었다. 덕분에 같은 어빌리티 클래스를 상속한 블루프린트 서브클래스를 만들기만 하면, 의자용·소화기용 등 오브젝트별로 다른 수치를 코드 변경 없이 적용할 수 있다.

// DZGA_AnomalyPatrol.h 발췌
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "DZ | Anomaly | Patrol")
float MinPatrolRadius = 100.f;
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "DZ | Anomaly | Patrol")
float MaxPatrolRadius = 300.f;
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "DZ | Anomaly | Patrol")
float PatrolSpeed = 100.f;

구현 포인트 1 — GetRandomReachablePointInRadius 대신 각도·거리 직접 계산

문제: UNavigationSystemV1::GetRandomReachablePointInRadius는 최소 이동 거리를 보장하지 않는다. 반환된 위치가 원점 바로 옆일 수 있어, 이상현상으로서의 시각적 변화가 없는 경우가 생긴다.

해결: 랜덤 각도(0360°)와 랜덤 반경(`MinMax)을 직접 계산해 후보 위치를 생성한 뒤,ProjectPointToNavigation`으로 NavMesh 위 유효 위치인지 검증하는 루프를 최대 30회 시도한다.

float RandomAngle  = FMath::FRandRange(0.f, 360.f);
float RandomRadius = FMath::FRandRange(MinRelocateRadius, MaxRelocateRadius);
FVector RandomOffset = FVector(
    RandomRadius * FMath::Cos(FMath::DegreesToRadians(RandomAngle)),
    RandomRadius * FMath::Sin(FMath::DegreesToRadians(RandomAngle)),
    0.f
);
FVector TestLocation = OriginLocation + RandomOffset;

FNavLocation NavLocation;
if (NavSystem->ProjectPointToNavigation(TestLocation, NavLocation)) { ... }

추가 검증 (Relocate 한정): ProjectPointToNavigation은 NavMesh 경계 밖의 위치도 가장 가까운 NavMesh 위치로 스냅한다. 이 경우 결과 위치가 원점 근처로 끌려와 최소 거리 보장이 깨진다. XY 거리를 한 번 더 검증해 이를 방지한다.

const float ActualDist2D = FVector::Dist2D(OriginLocation, NavLocation.Location);
if (ActualDist2D < MinRelocateRadius) { continue; }

구현 포인트 2 — Z값 보정 (피벗이 바닥 중심이 아닌 액터 대응)

문제: NavMesh 위의 점은 "바닥 표면" 좌표를 반환한다. 그러나 액터의 피벗이 오브젝트 중심에 있는 경우, 이 값을 그대로 SetActorLocation에 넘기면 액터가 바닥을 뚫거나 허공에 떠 있게 된다.

해결: 이동 전에 현재 위치와 바운딩 박스 최솟값의 Z 차이(PivotToBottom)를 미리 계산해두고, NavMesh 결과에 더해준다. 피벗 위치에 관계없이 "액터 바닥면이 NavMesh 표면에 닿도록" 보정한다. Relocate와 Patrol 양쪽에 모두 적용했다.

const FBox  ActorBox      = TargetActor->GetComponentsBoundingBox();
const float PivotToBottom = OriginLocation.Z - ActorBox.Min.Z;

// NavMesh 위치 계산 후
ResultLocation.Z += PivotToBottom;

구현 포인트 3 — MinScaleDelta (스케일 최소 변화량 보장)

문제: FMath::RandRange(MinScale, MaxScale)로 랜덤 스케일을 뽑으면 결과가 1.0(원래 크기)에 가까울 수 있고, 플레이어가 변화를 인지하지 못한다. 이상현상 게임에서 "변화가 있었지만 눈에 안 띄는" 상황은 게임 경험을 망친다.

해결: 1.0 기준으로 [MinScale, 1 - MinScaleDelta](축소) 또는 [1 + MinScaleDelta, MaxScale](확대) 두 구간으로 나눠 랜덤 선택한다. 두 구간이 모두 유효하면 RandBool()로 방향을 먼저 결정한 뒤 각 범위에서 뽑는다.

const bool bCanShrink = MinScale <= 1.f - MinScaleDelta;
const bool bCanGrow   = MaxScale >= 1.f + MinScaleDelta;

if      (bCanShrink && bCanGrow) NewScale = FMath::RandBool()
    ? FMath::RandRange(MinScale,            1.f - MinScaleDelta)
    : FMath::RandRange(1.f + MinScaleDelta, MaxScale);
else if (bCanShrink)             NewScale = FMath::RandRange(MinScale, 1.f - MinScaleDelta);
else if (bCanGrow)               NewScale = FMath::RandRange(1.f + MinScaleDelta, MaxScale);
else                             /* 범위 오류 → 어빌리티 종료 */;

MinScale, MaxScale, MinScaleDelta 세 값을 EditDefaultsOnly로 노출해 블루프린트 서브클래스마다 다른 변화 폭을 설정할 수 있다.

정리

📅 2025-12-18

• 타이머로 주기적인 연료 소모 시스템 구현
• 델리게이트로 UI와 로직 분리
• 특정 아이템만 받는 커스텀 인벤토리 컴포넌트
• StartTime 저장으로 클라이언트 프로그레스바 구현

타이머로 주기적인 연료 소모 시스템 구현

연료를 넣으면 불을 켤 수 있는 가로등 액터를 만들었다. 핵심은 서버에서 타이머로 연료를 주기적으로 소모하고, 연료가 없으면 자동으로 불을 끄는 구조다.

구현 방식

void ATSStreetLamp::SetFuelTimer()
{
    if (bIsFueling) return;

    GetWorldTimerManager().SetTimer(
        FuelTimerHandle, 
        this, 
        &ATSStreetLamp::UseFuel, 
        MaintenanceInterval,  // 초당 소모 간격
        true,   // 반복
        0.f     // 즉시 시작
    );
    bIsFueling = true;
}

void ATSStreetLamp::UseFuel()
{
    if (LampInventory->GetItemCount(MaintenanceCostID) > 0)
    {
        // 연료 소모 & 불 켜기
        LampInventory->ConsumeItem(MaintenanceCostID, 1);
        ChangeLightScaleByErosion(ErosionSubSystem->GetCurrentErosion());
        StartTime = GetWorld()->GetTimeSeconds();  // 🔑 현재 시간 저장
    }
    else
    {
        // 연료 없으면 불 끄기 & 타이머 중지
        SetLightScale(0);
        GetWorldTimerManager().ClearTimer(FuelTimerHandle);
        bIsFueling = false;
    }
    OnFuelModeChanged.Broadcast(bIsFueling);
}

핵심 포인트

• MaintenanceInterval마다 UseFuel() 호출로 연료 1개씩 소모
• 연료가 있으면 계속 타이머 반복, 없으면 ClearTimer()로 중지
• StartTime을 Replicated로 저장해서 클라이언트도 경과 시간 계산 가능하게 함
• bIsFueling 상태로 현재 가동 중인지 추적

델리게이트로 UI와 로직 분리

UI 업데이트를 위해 FOnFuelModeChanged 델리게이트를 만들었다. 연료 상태가 바뀔 때마다 브로드캐스트해서 위젯에서 구독하도록 했다.

델리게이트 선언 & 사용

// .h
DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnFuelModeChanged, bool, bIsFueling);

UPROPERTY(BlueprintAssignable, Category = "Lamp|Events")
FOnFuelModeChanged OnFuelModeChanged;

// .cpp
UPROPERTY(ReplicatedUsing = OnRep_IsFueling)
bool bIsFueling = false;

void ATSStreetLamp::OnRep_IsFueling()
{
    OnFuelModeChanged.Broadcast(bIsFueling);
}

위젯 측 구현

• 위젯에서 OnFuelModeChanged를 구독
• bIsFueling이 false면 프로그레스바 업데이트 타이머 pause
• true면 타이머 재개해서 0.2초마다 남은 시간 계산

이렇게 하면 액터 로직과 UI 업데이트가 완전히 분리되고, 위젯은 상태 변화에만 반응하면 된다.

특정 아이템만 받는 커스텀 인벤토리 컴포넌트

램프는 연료 아이템만 받을 수 있어야 한다. UTSLampInventory를 만들어서 CanPlaceItemInSlot()을 오버라이드했다.

bool UTSLampInventory::CanPlaceItemInSlot(int32 StaticDataID, EInventoryType InventoryType, int32 SlotIndex)
{
    if (Super::CanPlaceItemInSlot(StaticDataID, InventoryType, SlotIndex))
    {
        if (StaticDataID != MaintenanceCostID)  // 연료 아이템만 허용
        {
            return false;
        }
    }
    OnFuelTransferred.Broadcast();  // 연료 추가됨 알림
    return true;
}

void UTSLampInventory::ClearSlot(FSlotStructMaster& Slot)
{
    Super::ClearSlot(Slot);
    Slot.ItemData.StaticDataID = MaintenanceCostID;  // 빈 슬롯도 연료 ID로
    Slot.MaxStackSize = MaintenanceCostQty;
}

추가 구현

• Internal_TransferItem()에서도 MaintenanceCostID 체크
• 연료가 추가되면 OnFuelTransferred 델리게이트 브로드캐스트
• 램프 액터에서 이걸 구독해서 SetFuelTimer() 호출

// BeginPlay에서 델리게이트 바인딩
LampInventory->OnFuelTransferred.AddDynamic(this, &ATSStreetLamp::SetFuelTimer);

이렇게 하면 플레이어가 연료를 넣는 순간 자동으로 타이머가 시작된다.

StartTime 저장으로 클라이언트 프로그레스바 구현

서버에서만 타이머가 돌지만, 클라이언트도 프로그레스바를 보여줘야 한다. 이를 위해 StartTime을 Replicated 변수로 만들었다.

UPROPERTY(Replicated)
float StartTime = 0.f;

// UseFuel()에서 연료 소모할 때마다 갱신
StartTime = GetWorld()->GetTimeSeconds();

위젯에서 계산

// 위젯의 0.2초 타이머에서
float OperatingTime = CurrentTime - StartTime;
float Progress = 1.0f - (OperatingTime / MaintenanceInterval);

이렇게 하면:

1. 서버가 연료 소모할 때마다 StartTime 업데이트
2. 클라이언트는 StartTime과 현재 시간 차이로 경과 시간 계산
3. MaintenanceInterval로 나눠서 진행률 계산

서버 타이머 없이도 클라이언트가 독립적으로 프로그레스바 업데이트 가능!

💡 느낀 점 (What I Felt)

Tick을 사용하지 않고 부하를 줄이려고 노력했다. 연료를 소비하거나 불을 끄는 시점만 델리게이트로 확실하게 동기화하고 나머지는 클라이언트에서 예측하여 남은 연료 가동시간을 UI에 나타냈다. 이때도 Tick보다는 타이머를 사용해 램프가 가동되는 순간에만 타이머를 활성화하는 방식으로 부하를 줄였다.

기존의 인벤토리를 커스텀하여 특정 아이템만 넣을 수 있고 최대로 넣을 수 있는 연료 아이템의 수도 제한하도록 CanPlaceItemInSlot()를 오버라이드했다. 기존에는 아이템 데이터에서 MaxStack을 가져와 슬롯에 적용하는 방식이었는데 이번 로직을 구현하기 위해 스택할 때 슬롯의 MaxStack을 가지고 오는 방식으로 수정했다. 기존 인벤토리 컴포넌트를 꽤 확장성 높게 만든 것 같아 뿌듯하다.

📅 2025-12-11

• Physical Material을 활용한 재질별 발소리 시스템 구현
• AnimNotify 기반 사운드 트리거링
• 멀티플레이어 환경에서의 로컬 사운드 재생

Physical Material을 활용한 재질별 발소리 시스템 구현

🎯 구현 목표

바닥 재질(콘크리트, 나무, 금속 등)에 따라 다른 발소리를 재생하는 시스템을 구현. 걷기/달리기/착지/웅크리기/벽타기 각각에 대해 재질별 사운드 지원.

📐 시스템 구조

1. FootstepComponent 설계

// 재질별 사운드를 담는 구조체
USTRUCT()
struct FFootstepSound
{
    GENERATED_BODY()
    TObjectPtr<USoundBase> Left;      // 왼발
    TObjectPtr<USoundBase> Right;     // 오른발  
    TObjectPtr<USoundBase> Climbing;  // 벽타기
};

// Physical Surface Type별로 사운드 매핑
TMap<TEnumAsByte<EPhysicalSurface>, FFootstepSound> FootstepSounds;

설계 의도:

• TMap을 사용해 Surface Type을 키로 사운드 검색 → O(1) 성능
• 구조체로 묶어 좌/우/등반 사운드를 하나로 관리
• TObjectPtr로 안전한 포인터 관리

2. 재질 감지: LineTrace + Physical Material

void PlayFootstepSound(const FVector& Location, bool& IsLeft)
{
    FCollisionQueryParams Params;
    Params.bReturnPhysicalMaterial = true; // ⭐ 핵심!

    GetWorld()->LineTraceSingleByChannel(HitResult, Start, End, ECC_Visibility, Params);

    EPhysicalSurface SurfaceType = EPhysicalSurface::SurfaceType_Default;
    if (HitResult.PhysMaterial.IsValid())
    {
        SurfaceType = HitResult.PhysMaterial->SurfaceType;
    }

    // TMap에서 사운드 찾기
    if (USoundBase* Sound = IsLeft 
        ? FootstepSounds.FindRef(SurfaceType).Left 
        : FootstepSounds.FindRef(SurfaceType).Right)
    {
        UGameplayStatics::PlaySoundAtLocation(GetWorld(), Sound, Location);
    }
}

핵심 포인트:

• bReturnPhysicalMaterial = true 없으면 PhysMaterial 정보를 받을 수 없음
• FindRef는 키가 없어도 안전 (기본값 반환)
• Physical Material 미할당 시 → SurfaceType_Default 반환

🎬 AnimNotify 기반 트리거링

AnimNotify 구현

// AN_Footstep.h
UCLASS()
class UAN_Footstep : public UAnimNotify
{
    GENERATED_BODY()
public:
    UPROPERTY(EditAnywhere)
    FName SocketName = TEXT("foot_l");

    UPROPERTY(EditAnywhere)
    bool IsLeft = true;

    virtual void Notify(USkeletalMeshComponent* MeshComp, 
                       UAnimSequenceBase* Animation, 
                       const FAnimNotifyEventReference& EventReference) override;
};

주의사항:

• Super::Notify() 호출 시 Blueprint 이벤트와 충돌 가능 → 호출하지 않는 것을 권장
• Received_Notify는 BlueprintImplementableEvent → C++에서 override 불가
• UE 5.0+ 이후 시그니처에 FAnimNotifyEventReference 파라미터 추가됨

🎯 특수 케이스 처리

1. 착지 소리

// TSCharacter.cpp
void ATSCharacter::Landed(const FHitResult& Hit)
{
    Super::Landed(Hit);
    FootstepComponent->PlayFootstepSoundFromHit(Hit);
}

문제: Landed()의 Hit는 PhysMaterial 정보가 없음

• CharacterMovementComponent의 내부 Sweep이 Physical Material을 요청하지 않음

해결: Hit 위치에서 다시 짧은 LineTrace 수행

void PlayFootstepSoundFromHit(const FHitResult& Hit)
{
    // Hit 위치에서 재질 감지를 위한 재 LineTrace
    FVector Start = Hit.ImpactPoint;
    FVector End = Hit.ImpactPoint - FVector(0, 0, 50);

    FCollisionQueryParams Params;
    Params.bReturnPhysicalMaterial = true; // 필수!

    GetWorld()->LineTraceSingleByChannel(...);
}

2. 벽타기 소리

void PlayClimbingSound(const FVector& Location)
{
    // 캐릭터 앞 방향으로 LineTrace
    FVector Forward = GetOwner()->GetActorForwardVector(); // 정규화됨 (크기=1)
    FVector End = Location + Forward * 100.f;

    // 벽 재질 감지 후 Climbing 사운드 재생
}

학습:

• GetActorForwardVector()는 항상 정규화된 벡터 반환 (크기 = 1)
• 벡터 연산 후 크기 변경 시 GetSafeNormal() 재정규화 필요

🌐 멀티플레이어 고려사항

복제 원리

애니메이션 복제됨 (Character Movement 자동)
  ↓
모든 클라이언트에서 애니메이션 재생
  ↓
각 클라이언트에서 AnimNotify 실행
  ↓
각 클라이언트에서 로컬 사운드 재생 (RPC 불필요!)

핵심:

• RPC를 사용하지 않음 → 네트워크 부하 없음
• 애니메이션이 복제되므로 자연스럽게 동기화
• "애니메이션이 보이면 소리도 들린다" 원칙 성립

주의:

// ❌ 이렇게 하면 안 됨
if (Owner->IsLocallyControlled()) 
{
    PlaySound(); // 자기 캐릭터만 소리 남
}

// ✅ 조건 없이 모든 클라이언트에서 재생
PlaySound();

🛠️ 최적화 & 안정성

1. GC 방지

void BeginPlay()
{
    // 자주 사용하는 사운드를 GC로부터 보호
    for (const auto& Pair : FootstepSounds)
    {
        if (Pair.Value.Left) Pair.Value.Left->AddToRoot();
        if (Pair.Value.Right) Pair.Value.Right->AddToRoot();
        if (Pair.Value.Climbing) Pair.Value.Climbing->AddToRoot();
    }
}

2. Build.cs 설정

PublicDependencyModuleNames.AddRange(new string[] 
{ 
    "PhysicsCore"  // Physical Material 사용 시 필수!
});

• 누락 시 링크 에러: Z_Construct_UEnum_PhysicsCore_EPhysicalSurface

3. Project Settings

• Physics > Physical Surface: SurfaceType1~3 정의
• Physics > Default Physical Material: 미할당 재질의 기본값 설정

💡 느낀 점 (What I Felt)

Physical Material 시스템 엔진 표준 기능을 활용하니 파티클, 데칼 등 다른 시스템과도 자연스럽게 연동되는 것이 인상적이었다. 단순히 발소리만이 아니라 발자국 파티클, 재질별 마찰음 등으로 확장 가능한 설계라는 점이 좋았다.

멀티플레이어 사운드 복제 RPC 없이도 애니메이션 복제만으로 사운드가 동기화되는 구조가 매우 편리했다. 각 클라이언트가 로컬에서 재생하므로 네트워크 부하도 없고, 타이밍도 정확하다. Listen Server 구조에서 특히 효율적이다.

Landed()의 PhysMaterial 미제공 이슈 CharacterMovementComponent의 내부 로직이 Physical Material을 요청하지 않는다는 점이 까다로웠다. Hit 위치에서 재 LineTrace를 해야 한다는 해결책을 찾기까지 시간이 걸렸다. 엔진의 내부 동작을 완전히 이해하는 것이 얼마나 중요한지 다시 깨달았다.

📅 2025-12-09

• 인터페이스 래퍼 + 팩토리 패턴으로 카테고리별 스탯 표시 로직 분리

인터페이스 래퍼 + 팩토리 패턴으로 카테고리별 스탯 표시 로직 분리

📌 문제 상황

빌딩/아이템 스탯 표시 시스템에서:

• FItemData와 FBuildingData는 완전히 다른 구조체 → 함수를 따로 만들어야 함
• 각 카테고리(TOOL, WEAPON, ARMOR, CONSUMABLE, WALL, FLOOR...)마다 표시할 스탯이 다름
• Switch-case로 처리하니 코드가 길어지고, 새 카테고리 추가 시 기존 코드 수정 필요

// Before: 너무 길고 유지보수 어려움
void UpdateCraftingItemStatView(const FItemData& ItemData)
{
    switch (ItemData.Category)
    {
    case EItemCategory::TOOL:
        // 채취 유형, 공격력, 내구도... 50줄
        break;
    case EItemCategory::WEAPON:
        // 공격력, 사거리, 내구도... 50줄
        break;
    // ...
    }
}

void UpdateBuildingItemStatView(const FBuildingData& BuildingData)
{
    switch (BuildingData.Type) { /* ... */ }
}

🎯 해결 방법

인터페이스 래퍼 + 팩토리 패턴 조합으로 해결

1. 인터페이스 래퍼로 데이터 통합

// IDisplayDataProvider (순수 C++ 인터페이스)
class IDisplayDataProvider
{
public:
    virtual FGameplayTag GetCategoryTag() const = 0;
    virtual float GetStatValue(const FGameplayTag& StatTag) const = 0;
    // ...
};

// 각 데이터 타입을 래핑
class FItemDataProvider : public IDisplayDataProvider { /* ... */ };
class FBuildingDataProvider : public IDisplayDataProvider { /* ... */ };

2. 팩토리 패턴으로 카테고리별 Viewer 생성

// 추상 클래스
UCLASS(Abstract)
class UStatViewer : public UObject
{
    virtual void ShowStats(
        UListView* ListView,
        const IDisplayDataProvider& DataProvider,
        UGameplayTagDisplaySubsystem* DisplaySystem) PURE_VIRTUAL();
};

// 카테고리별 구현
UCLASS() class UToolStatViewer : public UStatViewer { /* 도구 스탯 표시 */ };
UCLASS() class UWeaponStatViewer : public UStatViewer { /* 무기 스탯 표시 */ };
UCLASS() class UWallStatViewer : public UStatViewer { /* 벽 스탯 표시 */ };

// 팩토리가 적절한 Viewer 반환
UCLASS()
class UStatViewerFactory : public UObject
{
    UStatViewer* GetViewer(const FGameplayTag& CategoryTag)
    {
        if (CategoryTag == TAG_Category_Tool)
            return CachedToolViewer;
        // ...
    }
};

3. 위젯에서 통합 사용

// After: 5줄로 축약, 모든 타입 통합!
void UItemInfo::UpdateStatViewInternal(const IDisplayDataProvider& DataProvider)
{
    FGameplayTag CategoryTag = DataProvider.GetCategoryTag();
    UStatViewer* Viewer = ViewerFactory->GetViewer(CategoryTag);
    Viewer->ShowStats(ItemStatView, DataProvider, TagDisplaySubsystem);
}

void UpdateCraftingItemStatView(const FItemData& ItemData)
{
    FItemDataProvider Provider(ItemData);
    UpdateStatViewInternal(Provider);
}

void UpdateBuildingItemStatView(const FBuildingData& BuildingData)
{
    FBuildingDataProvider Provider(BuildingData);
    UpdateStatViewInternal(Provider);
}

🔑 핵심 포인트

1. 인터페이스 래퍼 (IDisplayDataProvider)

   • 서로 다른 구조체를 통일된 방식으로 접근
   • 순수 C++ 인터페이스로 가볍게 구현
   • 스택에 생성 가능 (임시 래퍼)

2. 팩토리 패턴 (UStatViewerFactory)

   • 카테고리 태그로 적절한 Viewer 반환
   • Viewer들을 캐싱해서 재사용 (성능)
   • 새 카테고리 추가 시 Factory에 한 줄만 추가

3. Strategy 패턴 (UStatViewer)

   • 각 카테고리별 스탯 표시를 독립 클래스로
   • 각 Viewer가 자기 카테고리 스탯만 담당
   • OCP 준수 (Open-Closed Principle)

📂 폴더 구조

UI/StatDisplay/
├── DisplayDataProvider.h           # 인터페이스
├── Providers/
│   ├── ItemDataProvider.h/cpp      # 아이템 래퍼
│   └── BuildingDataProvider.h/cpp  # 빌딩 래퍼
├── Viewers/
│   ├── StatViewer.h/cpp            # 추상 클래스
│   ├── Items/
│   │   ├── ToolStatViewer.h/cpp
│   │   ├── WeaponStatViewer.h/cpp
│   │   └── ...
│   └── Buildings/
│       ├── CraftingStatViewer.h/cpp
│       └── ...
└── StatViewerFactory.h/cpp         # 팩토리

✅ 장점

• 서로 다른 데이터 타입을 하나의 함수로 처리
• 각 카테고리 로직이 독립적 (유지보수 쉬움)
• 새 카테고리 추가 시 기존 코드 수정 불필요
• 각 Viewer별 단위 테스트 가능

💡 느낀 점 (What I Felt)

처음엔 switch-case가 간단해 보였는데 카테고리가 늘어나면서 함수가 너무 길어졌다. 인터페이스 래퍼로 데이터를 추상화하고, 팩토리 패턴으로 각 로직을 분리하니까 코드가 훨씬 깔끔해졌다. 특히 FItemData와 FBuildingData를 전혀 건드리지 않고 Provider로만 감싸서 해결할 수 있는게 신기했다.

팩토리 패턴이 처음엔 오버엔지니어링 같았는데, 이후 빌딩의 특정 카테고리의 내용만 수정할 때 훨씬 간단해 편했다. 그리고 각 Viewer 클래스가 30~50줄 정도로 짧아서 읽기도 편하고 테스트하기도 좋았다.

UCLASS로 구현한 Viewer 클래스들이 순수 C++ 인터페이스(IDisplayDataProvider)를 파라미터로 받아서 쓸 수 있다는 게 새로웠다. UObject 계열과 순수 C++을 조합해서 쓸 수 있다는 걸 몰랐는데, 스택에 생성한 Provider를 UObject인 Viewer가 참조로 받아서 사용하는 구조가 깔끔했다. 언리얼에서도 순수 C++과 디자인 패턴을 실전에 제대로 적용해본 경험이었다.

📅 2025-12-05

• 아이템 상세데이터 표시 정보 관리를 위한 GameInstanceSubsystem 구현

아이템 상세데이터 표시 정보 관리를 위한 GameInstanceSubsystem 구현

📌 문제 상황

빌딩/크래프팅 위젯의 결과물 상세페이지에서 스탯을 표시할 때 각 스탯과 효과마다 표시 용어가 다름

• "체력 회복", "Health Recovery" 같은 다국어 표시명
• "초", "%", "개" 같은 단위
• 아이템 카테고리(TOOL, WEAPON, ARMOR, CONSUMABLE)마다 보여줄 스탯이 다름
• 하드코딩하면 관리가 어렵고 확장성이 떨어짐

🎯 해결 방법

DeveloperSettings + GameInstanceSubsystem + DataTable 조합으로 중앙 관리 시스템 구축

1. DeveloperSettings로 DT 경로 관리

// GameplayTagDisplaySettings.h
UCLASS(Config=Game, DefaultConfig)
class UGameplayTagDisplaySettings : public UDeveloperSettings
{
    UPROPERTY(Config, EditAnywhere)
    TSoftObjectPtr<UDataTable> GameplayTagDisplayDataTable;
};

• Project Settings에서 DT 경로를 설정 가능
• 하드코딩 없이 에디터에서 변경 가능

2. GameInstanceSubsystem에서 초기화 & 캐싱

void UGameplayTagDisplaySubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    const UGameplayTagDisplaySettings* Settings = GetDefault<UGameplayTagDisplaySettings>();
    GameplayTagDisplayTable = Settings->GameplayTagDisplayDataTable.LoadSynchronous();

    // TMap으로 캐싱 (O(1) 조회)
    TArray<FGameplayTagDisplayData*> Rows;
    DataTable->GetAllRows<FGameplayTagDisplayData>(TEXT("LoadDataTable"), Rows);
    for (FGameplayTagDisplayData* Row : Rows)
    {
        CachedDisplayData.Add(Row->Tag, *Row);
    }
}

3. 위젯에서 실제 사용

void UItemInfo::UpdateCraftingItemStatView(const FItemData& ItemData)
{
    TagDisplaySubsystem = UGameplayTagDisplaySubsystem::Get(this);
    ItemStatView->ClearListItems();

    switch (ItemData.Category)
    {
    case EItemCategory::TOOL:
        // 채취 유형 - 여러 태그를 쉼표로 연결
        UStatDataObject* StatData = NewObject<UStatDataObject>();
        StatData->StatName = TagDisplaySubsystem->GetDisplayName_KR(TAG_Display_Stat_HarvestTarget);
        StatData->StatValue = TagDisplaySubsystem->GetDisplayNamesFromContainer_KR(
            ItemData.ToolData.HarvestTargetTag);
        ItemStatView->AddItem(StatData);

        // 공격력 - 값 + 단위 포맷팅
        GetStatData_KR(*StatData, TAG_Display_Stat_AttackDamage, ItemData.ToolData.DamageValue);
        ItemStatView->AddItem(StatData);
        break;
    }
}

void UItemInfo::GetStatData_KR(UStatDataObject& OutStatData, const FGameplayTag& StatTag, const float& StatValue)
{
    FGameplayTagDisplayData DisplayData;
    if (TagDisplaySubsystem->GetDisplayData(StatTag, DisplayData))
    {
        OutStatData.StatName = DisplayData.DisplayName_KR;
        OutStatData.StatValue = FText::AsNumber(StatValue);
        OutStatData.StatUnit = TagDisplaySubsystem->GetUnit(StatTag); // "초", "%", "개" 등
    }
}

🔑 핵심 포인트

1. DeveloperSettings 활용: 에디터에서 직접 DT 경로 설정, 코드 수정 없이 변경 가능
2. Initialize에서 캐싱: 런타임마다 DT를 순회하지 않고 TMap으로 O(1) 조회
3. Static Get() 헬퍼: WorldContextObject만 있으면 어디서든 접근 가능
4. 유틸리티 함수 제공:
   • GetDisplayName_KR/EN - 단일 태그 표시명
   • GetDisplayNamesFromContainer_KR - 여러 태그를 쉼표로 연결
   • GetUnit - 단위만 가져오기
   • GetDisplayData - 전체 데이터 한 번에
5. ListView와의 조합: UStatDataObject를 동적으로 생성해서 AddItem → 카테고리별로 다른 스탯 표시

📂 구조

Settings (에디터) → Subsystem (캐싱) → Widget (사용)
     ↓                    ↓                ↓
  DT 경로 설정      Initialize에서      Get()으로 접근
                  TMap에 캐싱         GetDisplayName_KR()

💡 느낀 점 (What I Felt)

처음엔 효과 태그, 스탯 별로 출력할 이름과 단위를 매핑하는 함수를 만들다가 효과가 추가되거나 이름을 변경하고 싶을 때 불편함이 커질것 같아 데이터 테이블로 관리하는 방식을 선택했다. 그리고 데이터 테이블에서 데이터를 가져오기 위해 게임인스턴스 서브시스템을 사용했다.

그리고 위젯에서 아이템 카테고리별로 분기 처리하는 부분이 좀 지저분해 보이긴 하는데 이건 나중에 팩토리 패턴으로 개선해봐야겠다.

틀린 풀이

0번 섬에서 시작하여 모든 섬을 한번씩 방문하는 최소 비용을 찾는 로직이라 틀림

#include <vector>
#include <unordered_map>

using namespace std;
struct bridge
{
    int island;
    int cost;
};
void dfs(unordered_map<int, vector<bridge>>& myMap, vector<bool>& visited, int visitedCount, int island, int cost, int& minCost)
{
    if(visitedCount == visited.size())
    {
        minCost = minCost<cost? minCost : cost;
        return;
    }
    for(const auto& m:myMap[island])
    {
        if(visited[m.island]) continue;
        visited[m.island] = true;
        dfs(myMap, visited, visitedCount+1, m.island, cost+m.cost, minCost);
        visited[m.island] = false;
    }
}
int solution(int n, vector<vector<int>> costs) {
    int answer = 1e9;
    unordered_map<int, vector<bridge>> myMap;
    for(auto& v:costs)
    {
        myMap[v[0]].push_back({v[1], v[2]});
        myMap[v[1]].push_back({v[0], v[2]});
    }
    vector<bool> visited(n,false);
    visited[0] = true;
    dfs(myMap, visited, 1, 0, 0, answer);
    return answer;
}

최종 - Kruskal(Union-Find)

최소 신장 트리(MST)의 개념으로 접근하여 해결했다. 최소 신장 트리: 모든 노드를 연결하며 사이클이 없는 부분 그래프(신장 트리) 중 가중치의 합이 최소가 되는 트리

#include <vector>
#include <algorithm>

using namespace std;

int parent[100];

int find(int x)
{
    // 경로 압축
    if(parent[x] == x) return x;
    return parent[x] = find(parent[x]);
}

void unite(int a, int b)
{
    a = find(a);
    b = find(b);
    parent[a] = b;
}

int solution(int n, vector<vector<int>> costs) {
    int answer = 0;

    // parent 초기화
    for(int i=0; i<n; i++)
    {
        parent[i] = i;
    }

    sort(costs.begin(), costs.end(),
        [](const auto& a, const auto& b)
         {
             return a[2]<b[2];
         });
    int edgeCount = 0;
    for(const auto& cost:costs)
    {
        int from = cost[0];
        int to = cost[1];
        int weight = cost[2];

        // 최상위 부모가 같지 않으면 선택
        if(find(from)!=find(to))
        {
            unite(from, to);
            answer += weight;
            ++edgeCount;

            // n-1개의 간선을 선택하면 종료
            if(edgeCount == n-1)
            {
                break;
            }
        }
    }
    return answer;
}

최소 신장 트리(MST) 찾는 기법

Union - Find

개념

서로소 집합(Disjoint Set)을 표현하는 자료구조. "두 원소가 같은 집합에 속하는지" 빠르게 판단하고, 두 집합을 합칠 수 있음.

핵심 연산

1. Find: 원소가 속한 집합의 대표(루트) 찾기
2. Union: 두 집합을 하나로 합치기

구현

int parent[MAX];

// 초기화: 각자가 자신의 부모
for(int i = 0; i < n; i++)
    parent[i] = i;

// Find: 루트 찾기 + 경로 압축
int find(int x) {
    if(parent[x] == x) return x;
    return parent[x] = find(parent[x]);  // 경로 압축
}

// Union: 두 집합 합치기
void union(int a, int b) {
    a = find(a);
    b = find(b);
    if(a != b) parent[a] = b;
}

// 같은 집합인지 확인
if(find(a) == find(b)) // 같은 집합

경로 압축 (Path Compression)

return parent[x] = find(parent[x]);

• find 호출 시 경로상 모든 노드를 루트에 직접 연결
• 트리 높이를 줄여 다음 find를 O(1)로 만듦

시간 복잡도

• 경로 압축 사용 시: O(α(n)) ≈ O(1) (아커만 역함수, 실질적 상수)
• 경로 압축 없으면: O(n)

활용

• 최소 신장 트리(MST): Kruskal 알고리즘에서 사이클 검사
• 네트워크 연결성: 두 노드가 연결되어 있는지 판단
• 동적 연결성: 간선 추가하면서 실시간으로 연결 여부 확인

Kruskal에서의 역할

sort(edges);  // 간선을 비용순 정렬
for(간선 in edges) {
    if(find(u) != find(v)) {  // 사이클 안 생기면
        union(u, v);           // 연결
        answer += cost;
    }
}

핵심: Union-Find로 "이 간선을 추가하면 사이클이 생기는가?"를 O(1)에 판단한다.

Kruskal 알고리즘

Kruskal = Union-Find + 그리디

Union-Find: "사이클 검사 도구"
     +
그리디: "비용이 작은 간선부터 선택하는 전략"
     =
Kruskal 알고리즘

알고리즘 순서

// 1. 간선을 비용 기준 오름차순 정렬 ⭐ (그리디)
sort(edges, 비용순);

// 2. 작은 비용부터 하나씩 확인
for(간선 in edges) {
    // 3. Union-Find로 사이클 체크
    if(find(u) != find(v)) {  // 다른 집합이면
        union(u, v);           // 합치기
        answer += cost;
        edgeCount++;

        // 4. n-1개 선택하면 완료
        if(edgeCount == n-1) break;
    }
}

핵심 아이디어

왜 이게 최소 신장 트리?

1. 비용이 작은 것부터 선택 (그리디)
2. 사이클만 안 만들면 무조건 선택
3. 결과적으로 최소 비용으로 모든 노드 연결

시간 복잡도

• 정렬: O(E log E)
• Union-Find: O(E α(V)) ≈ O(E)
• 전체: O(E log E) (정렬이 지배)

정리: Kruskal은 Union-Find를 사이클 체크 도구로 사용하면서, "비용 작은 간선부터 선택"이라는 그리디 전략을 추가한 MST 알고리즘

Prim 알고리즘

Kruskal vs Prim 핵심 차이

알고리즘 순서

// 1. 시작 정점 선택 (보통 0번)
visited[0] = true;

// 2. 시작 정점의 모든 간선을 우선순위 큐에 추가
for(간선 in graph[0])
    pq.push(간선);

// 3. 비용 작은 간선부터 꺼내기
while(!pq.empty()) {
    edge = pq.top(); pq.pop();

    // 이미 방문한 정점이면 스킵
    if(visited[edge.to]) continue;

    // 새 정점 연결
    visited[edge.to] = true;
    answer += edge.cost;

    // 새로 연결된 정점의 간선들 추가
    for(간선 in graph[edge.to])
        if(!visited[간선.to])
            pq.push(간선);
}

핵심 아이디어

"현재 트리에 연결 가능한 간선 중 가장 비용이 작은 것 선택"

• 트리를 점진적으로 확장
• 항상 연결된 상태 유지
• 우선순위 큐로 최소 비용 간선 선택

시각화

Kruskal (간선 관점):
모든 간선 보고 → 작은 것부터 선택 → 사이클만 피하기

Prim (정점 관점):
시작점 → 인접 정점 중 가장 가까운 곳 → 계속 확장

시간 복잡도

• 우선순위 큐: O(E log E)
• 전체: O(E log E) 또는 O(E log V)

언제 뭘 쓸까?

둘 다 정확도와 시간복잡도는 같다. 구현 편의나 그래프 특성에 따라 선택.

📅 2025-12-03

• 빌딩 컴포넌트
• 건축 시스템 설치 구역 검증 로직
• LightSource 범위 체크로 설치 가능 영역 제한
• 서버 권한 기반 레시피 재료 검증 및 소비

빌딩 컴포넌트

상자나 제작대 등 각각 다른 상호작용이 필요한 액터를 제작 및 설치하는 빌딩 컴포넌트를 구현했다.

설치 구역 검증 시스템

ValidatePlacement - 3단계 검증

bool UTSBuildingComponent::ValidatePlacement(FHitResult HitResult)
{
    // 1. 지면 검사 (경사도 체크)
    const float DotProduct = FVector::DotProduct(HitResult.Normal, FVector::UpVector);
    if (DotProduct < 0.7f) return false;

    // 2. 충돌 체크
    if (!CheckOverlap(HitResult.Location, CheckExtent)) return false;

    // 3. LightSource 범위 체크
    if (!IsInLightSourceRange(HitResult.Location)) return false;

    return true;
}

검증 순서의 의미

• 연산 비용이 낮은 순서로 배치 (DotProduct → BoxOverlap → SphereOverlap)
• Early exit 패턴으로 불필요한 검사 스킵
• 각 단계가 독립적으로 실패 가능

IsInLightSourceRange - 광원 범위 검사

bool UTSBuildingComponent::IsInLightSourceRange(const FVector& Location) const
{
    TArray<AActor*> FoundActors;
    UKismetSystemLibrary::SphereOverlapActors(
        GetWorld(), Location, LightSourceDetectionRadius,
        ObjectTypes, nullptr, IgnoreActors, FoundActors);

    for (AActor* Actor : FoundActors)
    {
        AErosionLightSourceSubActor* LightSource = Cast<AErosionLightSourceSubActor>(Actor);
        if (LightSource && LightSource->GetLightscale() > 0.f)
        {
            return true;
        }
    }
    return false;
}

핵심 로직

• 5000.f 반경 내 LightSource 탐색
• GetLightscale() > 0.f 체크로 활성화된 광원만 인정
• 게임 디자인: 빛의 영역 내에서만 건설 가능

CheckOverlap - 충돌 필터링

bool UTSBuildingComponent::CheckOverlap(const FVector& Location, const FVector& Extent)
{
    // BoxOverlap으로 Pawn, WorldDynamic, WorldStatic 체크
    bool bHasOverlap = UKismetSystemLibrary::BoxOverlapActors(...);
    if (!bHasOverlap) return true;

    for (AActor* OverlappedActor : OutActors)
    {
        if (OverlappedActor->IsA(APawn::StaticClass())) return false;
        if (OverlappedActor->ActorHasTag(FName("BlockBuilding"))) return false;
    }
    return true;
}

Extent 계산

FBoxSphereBounds Bounds = PreviewMeshComp->GetStaticMesh()->GetBounds();
CheckExtent = Bounds.BoxExtent * 0.9f; // 90% 크기로 체크

• 0.9배로 줄여서 경계선 false positive 방지
• 플레이어에게 더 관대한 설치 경험

실시간 피드백 - 프리뷰 색상

void UTSBuildingComponent::UpdatePreviewMesh(float DeltaTime)
{
    bCanPlace = ValidatePlacement(HitResult);

    // 상태 변경 시에만 머티리얼 업데이트
    if (bCanPlace != bLastCanPlace && CachedDynamicMaterial)
    {
        CachedDynamicMaterial->SetVectorParameterValue(FName("Color"),
            bCanPlace ? FLinearColor::Green : FLinearColor::Red);
        bLastCanPlace = bCanPlace;
    }
}

• bLastCanPlace 플래그로 불필요한 업데이트 방지
• 매 프레임 검증하지만 색상은 변경 시에만

레시피 기반 재료 검증

bool UTSBuildingComponent::CanBuild(int32 RecipeID, int32& OutResultID)
{
    if (!GetOwner()->HasAuthority()) return false; // 서버에서만

    FBuildingRecipeData RecipeData;
    if (!BuildingRecipeDataSub->GetBuildingRecipeDataSafe(RecipeID, RecipeData))
        return false;

    OutResultID = RecipeData.ResultItemID;

    // 인벤토리 검증
    for (const FBuildingIngredientData& Ingredient : RecipeData.Ingredients)
    {
        int32 ItemCount = PlayerInventoryComp->GetItemCount(Ingredient.MaterialID);
        if (ItemCount < Ingredient.Count) return false;
    }
    return true;
}

• 서버 권한 체크 필수
• 레시피 데이터와 인벤토리 동시 검증
• ConsumeIngredients에서 실제 재료 소비

💡 느낀 점 (What I Felt)

검증 파이프라인의 순서가 생각보다 중요했다. 비용이 낮은 검사부터 수행해서 불필요한 연산을 줄이는 게 성능과 직결된다는 걸 체감했다.

ActorHasTag를 활용한 블랙리스트 방식이 간단하면서도 확장성이 좋다. 복잡한 타입 체크 대신 태그 하나로 의미를 명확하게 전달할 수 있어서 편했다.

매 틱마다 오버랩으로 LightSource를 검증하는 부분이 비효율적인것 같다. 어떤 방식으로 최적화해야 피드백도 늦지 않고 비용을 줄일 수 있을지 더 찾아봐야겠다.

문제링크

1. BFS를 이용해 1과 각 노드의 거리를 구한다.
2. 더이상 탐색할 하위 노드가 없는 노드들을 저장한다.
3. 저장한 노드를 dist의 내림차순으로 정렬한다.
4. 최대 거리값과 같은 노드의 개수를 구한다.

   #include <unordered_map>
   #include <unordered_set>
   #include <vector>
   #include <algorithm>
   #include <queue>
   

using namespace std; struct point { int node; int dist; }; int solution(int n, vector<vector> edge) { int answer = 0; unordered_map<int, unordered_set> nodes; vector visited(n+1, false); queue q; vector points;

q.push({1,0});
visited[1] = true;

for(auto v:edge)
{
    nodes[v[0]].insert(v[1]);
    nodes[v[1]].insert(v[0]);
}

while(!q.empty())
{
    point temp = q.front();
    q.pop();
    bool isLeafNode = true;
    for(int i:nodes[temp.node])
    {
        if(!visited[i])
        {
            isLeafNode = false;
            visited[i] = true;
            q.push({i,temp.dist+1});
        }
    }
    if(isLeafNode)
    {
        points.push_back(temp);
    }
}
sort(points.begin(), points.end(), 
    [](const auto& a, const auto& b)
     {
         return a.dist>b.dist;
     });
int maxDist = points[0].dist;
for(const point& p:points)
{
    if(p.dist<maxDist)
    {
        break;
    }
    answer++;
}
return answer;

}

```

출처: 프로그래머스 - 가장 먼 노드

📅 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가 될 수도 있을 것 같은데, 그때 가서 리팩토링 고민해봐야겠다.

📅 2025-11-26

• 인벤토리 컴포넌트 편의 함수 구현 (GetItemCount, ConsumeItem, AddItem 오버로드)
• 제작 시스템과 인벤토리 연동을 위한 인터페이스 완성

인벤토리 컴포넌트 편의 함수 구현

📌 구현 내용

제작 시스템에서 필요로 하는 인벤토리 조작 함수들을 추가로 구현했다:

1. GetItemCount - 특정 아이템 총 개수 조회

int32 UTSInventoryMasterComponent::GetItemCount(int32 StaticDataID) const
{
    int32 ResultCount = 0;

    // 핫키 인벤토리 탐색
    for (const FSlotStructMaster& Slot : HotkeyInventory.InventorySlotContainer)
    {
        if (Slot.ItemData.StaticDataID == StaticDataID)
        {
            ResultCount += Slot.CurrentStackSize;
        }
    }

    // 가방 인벤토리 탐색 (가방이 활성화된 경우만)
    if (GetCurrentBagSlotCount() == 0)
    {
        return ResultCount;
    }
    for (const FSlotStructMaster& Slot : BagInventory.InventorySlotContainer)
    {
        if (Slot.ItemData.StaticDataID == StaticDataID)
        {
            ResultCount += Slot.CurrentStackSize;
        }
    }

    return ResultCount;
}

특징:

• const 함수로 읽기 전용 보장
• 핫키 + 가방 인벤토리의 모든 슬롯을 순회하며 집계
• 가방이 비활성화된 경우 조기 반환으로 성능 최적화

2. ConsumeItem - 특정 아이템 소비

void UTSInventoryMasterComponent::ConsumeItem(int32 StaticDataID, int32 Quantity)
{
    // 핫키 인벤토리 탐색
    for (int32 i = 0; i < HotkeyInventory.InventorySlotContainer.Num(); ++i)
    {
        FSlotStructMaster& Slot = HotkeyInventory.InventorySlotContainer[i];
        if (Slot.ItemData.StaticDataID == StaticDataID)
        {
            int32 ToRemove = FMath::Min(Quantity, Slot.CurrentStackSize);
            RemoveItem(EInventoryType::HotKey, i, ToRemove);
            Quantity -= ToRemove;
            if (ActiveHotkeyIndex == i)
            {
                HandleActiveHotkeyIndexChanged();
            }
            if (Quantity <= 0)
            {
                break;
            }
        }
    }
    // 가방 인벤토리 탐색
    if (GetCurrentBagSlotCount() > 0)
    {
        for (int32 i = 0; i < BagInventory.InventorySlotContainer.Num(); ++i)
        {
            FSlotStructMaster& Slot = BagInventory.InventorySlotContainer[i];
            if (Slot.ItemData.StaticDataID == StaticDataID)
            {
                int32 ToRemove = FMath::Min(Quantity, Slot.CurrentStackSize);
                RemoveItem(EInventoryType::BackPack, i, ToRemove);
                Quantity -= ToRemove;
                if (Quantity <= 0)
                {
                    break;
                }
            }
        }
    }
    HandleInventoryChanged();
}

설계 의도:

• 핫키 인벤토리 → 가방 인벤토리 순서로 소비 (접근성 높은 순서)
• 활성 핫키 슬롯의 아이템이 소비되면 장착 상태 갱신
• 전체 소비 완료 후 한 번만 HandleInventoryChanged() 호출

3. AddItem 오버로드 - int32 버전 추가

bool UTSInventoryMasterComponent::AddItem(const int32 StaticDataID, int32 Quantity, int32& OutRemainingQuantity)
{
    FItemInstance ItemData = FItemInstance(StaticDataID, GetWorld()->GetTimeSeconds());
    return AddItem(ItemData, Quantity, OutRemainingQuantity);
}

편의성:

• 제작 시스템에서 StaticDataID만으로 아이템 추가 가능
• 서버 시간 자동 설정으로 부패 시스템 연동
• 기존 FItemInstance 버전 AddItem을 재사용

🎯 제작 시스템과의 연동 완성

이제 제작대에서 다음과 같이 사용 가능:

// 제작 가능 여부 확인
bool ATSCraftingTable::CanCraft(int32 RecipeID, ATSCharacter* InstigatorCharacter)
{
    for (const FIngredientData& Ingredient : RecipeData.Ingredients)
    {
        int32 ItemCount = PlayerInventoryComp->GetItemCount(Ingredient.MaterialID);
        if (ItemCount < Ingredient.Count)
        {
            return false;  // 재료 부족
        }
    }
    return true;
}

// 제작 실행
void ATSCraftingTable::StartCrafting(int32 RecipeID, ATSCharacter* InstigatorCharacter)
{
    // 재료 소비
    for (const FIngredientData& Ingredient : RecipeData.Ingredients)
    {
        PlayerInventoryComp->ConsumeItem(Ingredient.MaterialID, Ingredient.Count);
    }

    // 결과물 생성
    int32 RemainingQuantity;
    InventoryComp->AddItem(RecipeData.ResultItemID, RecipeData.ResultCount, RemainingQuantity);
}

💡 느낀 점 (What I Felt)

오버로드 함수의 편의성을 체감했다. AddItem(int32, ...) 버전 하나 추가했을 뿐인데, 제작 시스템 코드가 훨씬 간결해졌다. FItemInstance를 매번 생성하지 않아도 되니 코드 가독성도 좋아졌다.

위젯쪽에서 현재 부족한 재료 아이템의 경우에는 한눈에 볼 수 있도록 표시를 하거나 "제작 실패 → 사용자 피드백"까지 이어지도록 반환값으로 성공 여부를 전달하거나, 에러 델리게이트를 추가하는 방식을 고려해봐야겠다.

문제링크

처음 풀이

사이클 중복을 방지할 수 없어서 실패

#include <string>
#include <vector>
#include <algorithm>

using namespace std;
// n행 m열
// 상 [0,1], 하 [0,-1], 좌 [-1,0], 우[1,0]

int dx[]={1,0,-1,0};
int dy[]={0,1,0,-1};
int findPath(const vector<string>& grid, const vector<int> startPoint, int n, int m , 
             int direction, int result)
{
    if(result>0 && startPoint[0]==n && startPoint[1]==m && startPoint[2]==direction) return result;

    if(grid[n][m]=='L')
    {
        //1,0 -> 0,1 -> -1,0 -> 0,-1 ->1,0
        direction = (direction+1)%4;
    }
    else if(grid[n][m] == 'R')
    {
        //1,0 -> 0,-1 -> -1,0 -> 0,1 ->1,0
        direction = (direction+3)%4;
    }
    n=n+dx[direction];
    m=m+dy[direction];
    if(n<0) n=grid.size()-1;
    else if(n>=grid.size()) n=0;
    if(m<0) m=grid[0].size()-1;
    else if(m>=grid[0].size()) m=0;

    return findPath(grid,startPoint, n, m, direction, result+1);
}
vector<int> solution(vector<string> grid) {
    vector<int> answer;

    for(int n=0; n<grid.size(); ++n)
    {
        for(int m=0; m<grid[0].size(); ++m)
        {
            for(int i=0; i<4; ++i)
            {
                int temp = findPath(grid,{n,m,i}, n, m, i, 0);
                if(temp>0) answer.push_back(temp);
            }
        }
    }
    return answer;
}

최종 풀이

지나간 경로인지 체크하여 중복 방지하여 해결

#include <string>
#include <vector>
#include <algorithm>

using namespace std;
// n행 m열
// 상 [0,1], 하 [0,-1], 좌 [-1,0], 우[1,0]

int dx[]={1,0,-1,0};
int dy[]={0,1,0,-1};
int findPath(const vector<string>& grid, const vector<int> startPoint,
             vector<vector<vector<bool>>>& visited,
             int n, int m , 
             int direction, int result)
{
    if(visited[n][m][direction] && 
       startPoint[0]==n && startPoint[1]==m && startPoint[2]==direction) 
        return result;

    if(visited[n][m][direction]) return -1;
    visited[n][m][direction]=true;
    if(grid[n][m]=='L')
    {
        //1,0 -> 0,1 -> -1,0 -> 0,-1 ->1,0
        direction = (direction+1)%4;
    }
    else if(grid[n][m] == 'R')
    {
        //1,0 -> 0,-1 -> -1,0 -> 0,1 ->1,0
        direction = (direction+3)%4;
    }
    n=n+dx[direction];
    m=m+dy[direction];
    if(n<0) n=grid.size()-1;
    else if(n>=grid.size()) n=0;
    if(m<0) m=grid[0].size()-1;
    else if(m>=grid[0].size()) m=0;

    return findPath(grid,startPoint,visited, n, m, direction, result+1);
}
vector<int> solution(vector<string> grid) {
    vector<int> answer;
    vector<vector<vector<bool>>> visited(grid.size(), 
                                            vector<vector<bool>>(grid[0].size(),
                                                                 vector<bool>(4,false)));
    for(int n=0; n<grid.size(); ++n)
    {
        for(int m=0; m<grid[0].size(); ++m)
        {
            for(int i=0; i<4; ++i)
            {
                int temp = findPath(grid,{n,m,i}, visited,n, m, i, 0);
                if(temp>0) answer.push_back(temp);
            }
        }
    }
    sort(answer.begin(), answer.end());
    return answer;
}

📅 2025-11-21

• 인터페이스 기반 상호작용 위젯 표시 시스템 추가
• 픽업 아이템 액터 구현 및 AddItem 테스트
• 컨테이너 액터 구현
• 서버/클라이언트 실행 분기 처리 (RunOnServer 패턴)

인터페이스 기반 상호작용 위젯 표시 시스템

기존 코드 (팀원 작업)

• 캐릭터에서 라인트레이스로 CurrentHitActor, LastHitActor 저장
• 액터 전환 감지 기능

추가 구현 내용

1. IInteractableInterface 확인 후 위젯 표시

// 이전 액터 처리
    if (IsValid(LastHitActor.Get()))
    {
        if (LastHitActor->Implements<UIInteraction>())
        {
            IIInteraction* InteractionInterface = Cast<IIInteraction>(LastHitActor);
            if (InteractionInterface)
            {
                InteractionInterface->HideInteractionWidget();
            }
        }
    }

    // 현재 액터 처리
    if (IsValid(CurrentHitActor.Get()))
    {
        if (CurrentHitActor->Implements<UIInteraction>())
        {
            IIInteraction* InteractionInterface = Cast<IIInteraction>(CurrentHitActor);
            if (InteractionInterface && InteractionInterface->CanInteract(this))
            {
                InteractionInterface->ShowInteractionWidget(this);
            }
        }
    }

2. 픽업 아이템 액터 구현

• FItemInstance 데이터 보유 (StaticDataID, CreationServerTime)
• Widget Component로 "줍기 [E]" 프롬프트 표시
• Interact() 호출 시 UTSInventoryMasterComponent::AddItem() 연동
• AddItem 성공 시 액터 Destroy <- 추후 풀로 반환하도록 수정 예정
• 멀티플레이어 테스트 완료

3. 컨테이너 액터 구현

• UTSInventoryMasterComponent 보유
• "열기 [E]" 프롬프트 표시
• Interact() 호출 시 PlayerController의 HUD에서 ToggleContainer() 실행

RunOnServer 패턴으로 서버/클라이언트 실행 분기 처리

문제 상황

E키 상호작용 시 실행 위치가 액터마다 달라야 하는 문제:

• 픽업 아이템: AddItem()은 인벤토리 데이터 수정이므로 서버에서 실행 필요
• 컨테이너: HUD의 ToggleContainer()는 UI 조작이므로 클라이언트에서 실행 필요

기존 방식으로는 모든 상호작용을 ServerInteract RPC로 보내면 컨테이너에서 HUD를 찾을 수 없는 문제 발생

해결 방법: RunOnServer() 인터페이스 함수 추가

1. 인터페이스에 실행 위치 판별 함수 추가

// IInteractableInterface
UFUNCTION(BlueprintNativeEvent, BlueprintCallable)
bool RunOnServer();

2. 각 액터에서 실행 위치 반환

// ATSPickupItem - 서버에서 실행해야 함
bool ATSPickupItem::RunOnServer_Implementation()
{
    return true;  // AddItem()은 서버에서 실행
}

// ATSContainerActor - 클라이언트에서 실행해야 함
bool ATSContainerActor::RunOnServer_Implementation()
{
    return false;  // ToggleContainer()는 클라이언트에서 실행
}

3. 캐릭터에서 실행 위치 분기

void ATSCharacter::OnInteract(const struct FInputActionValue& Value)
{
    UE_LOG(LogTemp, Log, TEXT("e pressed"));

    if (!IsValid(CurrentHitActor.Get()))
    {
        return;
    }
    if (CurrentHitActor->Implements<UIInteraction>())
    {
        IIInteraction* InteractionInterface = Cast<IIInteraction>(CurrentHitActor);
        if (InteractionInterface && InteractionInterface->CanInteract(this))
        {
            if (InteractionInterface->RunOnServer())
            {
                ServerInteract(CurrentHitActor.Get());
            }
            else
            {
                InteractionInterface->Interact(this);
            }
        }
    }
}

패턴의 장점

• ✅ 확장성: 새로운 액터 추가 시 RunOnServer()만 구현하면 자동으로 올바른 위치에서 실행
• ✅ 명확성: 각 액터가 자신의 실행 위치를 명시적으로 선언
• ✅ 유지보수성: 캐릭터 코드 수정 없이 액터별 동작 변경 가능

💡 느낀 점 (What I Felt)

1. 인터페이스 설계의 유연성

• RunOnServer() 함수 하나 추가로 서버/클라이언트 실행 분기를 깔끔하게 처리할 수 있었다.
• 각 액터가 자신의 실행 위치를 결정하는 방식이 객체지향 설계 원칙에 부합하고 확장성도 좋은 것 같다.

2. 멀티플레이어 아키텍처의 복잡성

• 같은 E키 입력이라도 액터 종류에 따라 서버/클라이언트 중 어디서 실행해야 하는지가 다르다는 점이 흥미로웠다.
• 데이터 수정은 서버, UI 조작은 클라이언트라는 기본 원칙을 명확히 이해하게 되었다.

3. 팀 작업의 효율성

• 팀원이 구현한 라인트레이스 시스템 위에 인터페이스 기반 기능을 추가하는 방식으로 협업이 잘 이루어졌다.
• 기존 코드를 최대한 수정하지 않고 기능을 확장할 수 있어서 협업 시 충돌을 최소화할 수 있었다.

 📅 2025-11-20

• 언리얼 GAS: 클라이언트에서 실행되지 않는 패시브 어빌리티 문제 해결

언리얼 GAS: 클라이언트에서 실행되지 않는 패시브 어빌리티 문제 해결

1. 🎯 내가 하려던 것 (Goal)

• 목표: 언리얼 엔진의 Gameplay Ability System (GAS)을 사용하여 리슨 서버 멀티플레이 환경에서 상태 유지형 패시브 어빌리티를 구현하고, 클라이언트의 특정 입력(예: 숫자키 1)이 있을 때 이 어빌리티가 이벤트를 받아 특정 동작을 수행하도록 만들고자 했다.
• 구현 방식:
  1. 어빌리티 부여 시, 능력이 종료되지 않고 활성화 상태를 유지.
  2. 활성화된 능력 내에서 Wait Gameplay Event 노드를 사용하여 특정 태그를 기다림.
  3. 클라이언트가 키를 누르면 SendGameplayEventToActor를 호출하여 이벤트를 보냄.

2. 🤯 직면한 문제 (Problem)

• 현상: 어빌리티가 호스트(서버 겸 클라이언트)에서는 정상적으로 동작했으나, 일반 클라이언트에서는 어빌리티가 활성화되지 않거나, 활성화되더라도 키 입력에 따른 후속 동작이 실행되지 않음.

• 오류 코드:

  UGA_Hotkey::UGA_Hotkey() {
      // ...
      NetExecutionPolicy = EGameplayAbilityNetExecutionPolicy::LocalOnly; // 문제의 원인 1
  }
  
  void UGA_Hotkey::OnGiveAbility(...) {
      // ...
      if (ActorInfo->IsLocallyControlled() && !Spec.IsActive()) { // 문제의 원인 2
         // ... TryActivateAbility 호출
      }
  }

3. 💡 문제의 원인 및 해결 방법 (Cause & Solution)

1. 초기 활성화 권한 문제

능력의 NetExecutionPolicy가 LocalOnly로 설정되어 있어 서버의 권한이 있는 상태에서 활성화되지 않음. 또한 OnGiveAbility에서 IsLocallyControlled() 조건만 확인하여, 클라이언트의 로컬 복사본에서만 활성화가 시도되어 서버에는 상태가 복제되지 않음.

해결: 서버 권한으로 초기 활성화

1. NetExecutionPolicy를 EGameplayAbilityNetExecutionPolicy::ServerOnly로 변경하여 어빌리티의 실행 권한을 서버로 위임.
2. OnGiveAbility에서 ActorInfo->IsNetAuthority() (서버)일 때만 TryActivateAbility를 호출하여 능력이 서버에서 권한 있게 활성화되도록 수정.

2. 이벤트 전송 문제

능력이 ServerOnly로 서버에서 활성화되어 Wait Gameplay Event 노드가 서버에서만 실행됨. 그런데 클라이언트에서 호출된 SendGameplayEventToActor는 로컬 함수 호출일 뿐, 네트워크를 통해 서버에 전달되지 않아 서버의 대기 중인 능력이 이벤트를 받지 못함.

해결: Server RPC를 통한 이벤트 전달

1. 클라이언트의 키 입력 처리 부분에서 SendGameplayEventToActor를 직접 호출하는 대신, 서버로 전송되는 Server RPC 함수를 호출.
2. 서버 RPC 함수 안에서 UAbilitySystemComponent::HandleGameplayEvent 또는 SendGameplayEventToActor를 호출하여 서버의 능력에게 이벤트를 전달.

💡 느낀 점 (What I Felt)

멀티플레이 환경에서 Gameplay Ability System (GAS)을 사용할 때는, 단순히 코드를 작성하는 것 이상으로 "이 코드가 지금 서버에서 실행되는가, 클라이언트에서 실행되는가?"에 대한 네트워크 권한(Authority) 이해가 가장 중요하다는 것을 다시 한번 깨달았다. 특히 패시브 어빌리티라도 서버에서 권한을 가지고 활성화해야 하며, 클라이언트 입력이 서버의 상태를 변경할 때는 반드시 Server RPC를 사용해 안전하게 권한을 넘겨야 예상치 못한 싱크(Sync) 문제를 방지할 수 있다. LocalOnly 정책은 신중하게 사용해야겠다.

📅 2025-11-19

• 위젯 스위처를 활용한 UI 상태 관리
• Toggle 패턴으로 UI Open/Close 통합
• ESC 키 우선순위 기반 UI 닫기 로직
• UInterface를 통한 블루프린트-C++ 데이터 전달
• 방어적 프로그래밍으로 UI 상태 관리

위젯 스위처를 활용한 UI 상태 관리

핵심 개념

Visibility를 직접 바꾸지 말고 SetActiveWidgetIndex()만 사용해서 UI 전환

구조 설계

// WidgetSwitcher_Backpack
enum EBackpackWidgetIndex {
    Empty_Backpack = 0,
    PlayerInventory = 1
};

// WidgetSwitcher_Content  
enum EContentWidgetIndex {
    Empty_Content = 0,
    Container = 1,
    BuildingMode = 2,
    CraftingMode = 3,
    Settings = 4
};

장점

• 코드가 간결해짐 (Visibility 제어 불필요)
• enum으로 가독성 향상
• 각 스위처는 독립적으로 동작

Toggle 패턴으로 UI Open/Close 통합

사용자 입력(E키)키 하나로 UI Open/Close 통합 관리

void ToggleContainer(AContainerActor* Container) {
    // 같은 상자면 닫기
    if (CurrentContainer == Container) {
        CloseCurrentContainer();
        return;
    }
    // 다른 상자면 교체
    // ...
}

ESC 키 우선순위 기반 UI 닫기 로직

요구사항

• ESC로 UI 단계적으로 닫기
• 아무것도 없으면 환경설정 열기

구현

void HandleEscapeKey() {
    // 1순위: 환경설정 닫기
    if (bIsSettingsOpen) {
        CloseSettings();
        return;
    }

    // 2순위: 게임 UI 모두 닫기
    if (IsAnyUIOpen()) {
        CloseAllGameUI();
        return;
    }

    // 3순위: 환경설정 열기
    OpenSettings();
}

UInterface를 통한 블루프린트-C++ 데이터 전달

문제

블루프린트로 만든 위젯에 C++의 컨테이너 인벤토리 데이터를 어떻게 전달할까?

해결: UInterface 사용

// C++ 인터페이스 정의
UINTERFACE(Blueprintable)
class UIInventoryWidget : public UInterface {
    GENERATED_BODY()
};

class IIInventoryWidget {
    GENERATED_BODY()
public:
    UFUNCTION(BlueprintNativeEvent, BlueprintCallable)
    void SetInventoryData(UTSInventoryMasterComponent* Inventory);
};

// C++에서 호출
if (ContainerWidget->Implements<UIInventoryWidget>()) {
    IIInventoryWidget::Execute_SetInventoryData(
        ContainerWidget, 
        ContainerInventory
    );
}

블루프린트 연결

1. 위젯 블루프린트 Class Settings에서 인터페이스 추가
2. Event Graph에서 SetInventoryData 이벤트 구현
3. 전달받은 데이터로 슬롯 UI 생성

방어적 프로그래밍으로 UI 상태 관리

발견한 버그

// 문제 시나리오
1. 상자 열림 (타이머 실행 중)
2. 환경설정 버튼 클릭
3. 환경설정 닫음
4. CurrentContainer가 남아있고 타이머도 실행 중!

해결

void CloseSettings() {
    bIsSettingsOpen = false;

    // ✅ 혹시 남은 상태 정리
    CloseCurrentContainer();  // nullptr이면 바로 return

    UpdateInputMode();
}

void OpenSettings() {
    // ✅ 열기 전에 게임 UI 정리
    if (IsAnyUIOpen()) {
        CloseAllGameUI();
    }
    // ...
}

💡 느낀 점 (What I Felt)

UI 시스템을 설계하면서 "사용자가 어떤 순서로 버튼을 누를지 모른다"는 걸 체감했다. 처음엔 정상적인 경로만 생각했는데, 상자 열고 → 설정 열고 → 설정 닫으면 상자 타이머가 남아있는 버그를 발견했다.

방어적 프로그래밍의 중요성을 깨달았다. 특히 UI처럼 상태가 복잡한 시스템에서는 각 함수가 "들어올 때 상태 확인, 나갈 때 정리"를 철저히 해야 한다.

📅 2025-11-17

• OnPreviewMouseButtonDown vs OnMouseButtonDown 차이점
• 드래그앤드롭에서 좌클릭/우클릭 분기 처리
• DragDropOperation에 데이터 저장하는 패턴
• 언리얼 이벤트 버블링 순서 (Tunneling vs Bubbling)

OnPreviewMouseButtonDown vs OnMouseButtonDown 차이점

언리얼 엔진의 마우스 이벤트는 두 단계로 처리된다:

1. Tunneling 단계 (Preview)

OnPreviewMouseButtonDown
- 부모 → 자식 방향으로 전파 ⬇️
- 원본 이벤트 정보를 그대로 받음
- Get Effecting Button이 정확하게 동작함

2. Bubbling 단계 (일반)

OnMouseButtonDown
- 자식 → 부모 방향으로 전파 ⬆️
- 자식 위젯이 이벤트를 먼저 처리
- 이벤트 정보가 변형되거나 손상될 수 있음

실제 문제 상황

Button (또는 Canvas Panel)
├─ Image
└─ TextBlock

• OnMouseButtonDown 사용: Image/TextBlock이 먼저 이벤트를 받아 변형 → 부모가 받을 때는 버튼 정보 손상
• OnPreviewMouseButtonDown 사용: 부모가 먼저 원본 이벤트 받음 → 버튼 정보 정확함 ✅

결론: 드래그앤드롭 구현 시 OnPreviewMouseButtonDown을 사용해야 한다. 위젯 타입(Button, Canvas Panel 등)과 무관하게 자식 위젯이 있으면 Preview를 써야 한다.

드래그앤드롭에서 좌클릭/우클릭 분기 처리

요구사항

• 좌클릭 드래그: 아이템 전체 이동 (bIsFullStack = true)
• 우클릭 드래그: 아이템 1개만 이동 (bIsFullStack = false)

잘못된 접근 ❌

OnMouseButtonDown의 반환값(true/false)이
→ OnDragDetected나 OnDrop으로 전달된다고 생각

→ 전달되지 않는다! 각 이벤트의 FPointerEvent 파라미터에서 독립적으로 확인해야 함.

올바른 접근 ✅

1단계: 버튼 정보 캐싱

OnPreviewMouseButtonDown:
  Mouse Event → Get Effecting Button
    → Set CachedMouseButton (위젯 변수에 저장)
    → Branch (Left or Right?)
       True: Detect Drag 반환
       False: Unhandled 반환

2단계: DragOperation에 정보 저장

OnDragDetected:
  CachedMouseButton 사용
    → Branch (Left?)
       True: 
         - bIsFullStack = true
         - TransferQuantity = CurrentStackSize
       False:
         - bIsFullStack = false
         - TransferQuantity = 1
    → DragOperation 생성 및 반환

3단계: OnDrop에서 사용

OnDrop:
  DragOperation → bIsFullStack 읽기
    → ServerTransferItem(..., bIsFullStack)

DragDropOperation에 데이터 저장하는 패턴

핵심 원칙

버튼 확인은 한 번만, 저장해서 재사용

구조

UCLASS()
class UMyDragDropOperation : public UDragDropOperation
{
    UPROPERTY(BlueprintReadWrite)
    bool bIsFullStack;

    UPROPERTY(BlueprintReadWrite)
    int32 TransferQuantity;
};

장점

1. 중복 확인 제거: OnDragDetected에서 한 번만 확인
2. 드래그 비주얼: TransferQuantity로 개수 표시 가능
3. OnDrop 간소화: 저장된 값만 읽으면 됨

흐름

OnPreviewMouseButtonDown (버튼 확인 및 캐싱)
    ↓
OnDragDetected (DragOperation에 데이터 저장)
    ↓
OnDrop (저장된 데이터 사용)

추가 학습 내용

OnMouseButtonDown 반환값의 의미

• Detect Drag: 드래그 감지 시작 (가장 일반적)
• Handled: 이벤트만 소비, 드래그 안 함
• Unhandled: 이벤트 무시, 부모로 전파

OnDragDetected의 버그

OnDragDetected의 Pointer Event에서 Get Effecting Button → None 반환

• 드래그 감지 후 시점이라 원본 버튼 정보 손실
• 해결책: OnPreviewMouseButtonDown에서 미리 캐싱

💡 느낀 점 (What I Felt)

언리얼의 이벤트 시스템이 생각보다 복잡하다는 걸 깨달았다. 처음에는 단순히 OnMouseButtonDown에서 반환값을 조작하면 되는 줄 알았는데, 실제로는:

1. 이벤트 전파 순서 (Preview → Normal)
2. 자식/부모 위젯 간 이벤트 흐름
3. 각 이벤트 함수의 Pointer Event 독립성

이 모든 것을 이해해야 제대로 동작시킬 수 있었다.

특히 OnPreviewMouseButtonDown의 존재를 몰랐다면 계속 삽질했을 것 같다. 위젯 안에 Image나 TextBlock 같은 자식 위젯이 있으면 이들이 이벤트를 먼저 받아서 버튼 정보를 망가뜨린다는 것도 직접 겪지 않았으면 상상도 못했을 문제다.

결국 프레임워크의 내부 동작 원리를 이해하는 것이 중요하다는 걸 다시 한번 배웠다. 표면적인 사용법만 아는 것과 내부 메커니즘을 이해하는 것의 차이를 체감했다.

📅 2025-11-14

• 2주차 작업 정리

2주차 작업 정리

🎯 핵심 구현 내용

1. 부패도 시스템 연동

• 인벤토리 컴포넌트에서 부패도 관련 구현
  • 부패도 매니저 델리게이트 구독 (OnDecayTick 바인딩)
  • OnDecayTick() 콜백 함수 구현 - 1초마다 호출
  • ConvertToDecayedItem() 함수로 만료된 아이템을 부패물로 변환
  • UpdateExpirationTime() 함수로 아이템 스택 시 만료 시각 평균값 계산
  • 부패물 아이템 정보 캐싱 (CachedDecayedItemInfo)

2. 인벤토리 시스템 리팩토링

• 데이터 구조 개선

  • 기존 슬롯 구조를 FItemInstance 구조체 기반으로 전면 수정
  • 만료 시간(ExpirationTime) 필드 추가 및 활용
  • 오래된 중복 프로퍼티 제거

• 핵심 기능 구현

  • AddItem 테스트 및 검증 완료
  • TransferItem 기능 테스트
  • 소모품 아이템 사용 시 GameplayAbility 활성화 연동
  • 서버 네트워크 갱신 (ForceNetUpdate 주석 처리 - 테스트 중)

3. UI 시스템 개선

• HUD 초기화 및 동기화

  • 컨트롤러에서 HUD 초기화 구현
  • 클라이언트 HUD 업데이트 문제 해결 ✅

• 인벤토리 UI 기능

  • ToggleInventory 함수 구현
  • 가방 사이즈 확장 시 동적 슬롯 추가 UI 구현

• 드래그 앤 드롭 개선

  • FSlotStructMaster 관련 위젯 변경사항 적용
  • 슬롯 아이콘 이미지 업데이트 기능 추가

4. 최적화 및 리팩토링

• 델리게이트 처리 간소화 (HandleInventoryChanged())
• OnInventoryInitialized 델리게이트 추가
• 부패도 매니저 캐싱으로 성능 최적화

TSInventoryMasterComponent 완성도 평가

📊 전체 완성도: 약 73%

세부 분석:

✅ 완전 구현된 기능 (약 65%)

1. 네트워크 리플리케이션 (100%)

   • DOREPLIFETIME 설정 완료
   • OnRep 콜백 구현
   • Server RPC (Validate + Implementation) 완벽 구현

2. 인벤토리 관리 (95%)

   • 핫키/장비/가방 인벤토리 초기화 ✅
   • AddItem (스택 처리, 우선순위 로직 포함) ✅
   • RemoveItem ✅
   • 슬롯 조회/검증 함수 ✅

3. 아이템 이동 시스템 (100%)

   • Internal_TransferItem (스택 처리, 교환) ✅
   • 타입 검증 (CanPlaceItemInSlot) ✅
   • 드래그 앤 드롭 지원 ✅

4. 가방 확장 시스템 (100%)

   • ExpandBagInventory ✅
   • 가방 아이템 사용 로직 ✅
   • OnBagSizeChanged 델리게이트 ✅

5. 부패도 시스템 연동 (100%)

   • OnDecayTick 콜백 ✅
   • ConvertToDecayedItem ✅
   • UpdateExpirationTime ✅
   • 부패물 캐싱 ✅

6. 아이템 사용 (90%)

   • Internal_UseItem ✅
   • GAS 연동 (Ability 활성화) ✅
   • 가방 아이템 특수 처리 ✅

⚠️ 부분 구현/TODO 항목 (약 8%)

7. 장비 시스템 (30%)

   • Equipment 인벤토리 구조 ✅
   • 슬롯 타입 검증 ✅
   • ❌ 실제 장착/해제 로직 (TODO 주석만 존재)
   • ❌ 장비 효과 적용 (스탯, 능력치 변화 등)

8. 월드 아이템 드롭 (20%)

   • ServerDropItemToWorld RPC 구조 ✅
   • ❌ 스폰 매니저 연동 (TODO 주석)

9. 네트워크 최적화 (50%)

   • ⚠️ ForceNetUpdate() 전부 주석 처리
   • 의도적인지 테스트 중인지 불명확

❌ 미구현 기능 (약 27%)

10. 컨테이너/상자 시스템 (0%)

    • 스크럼 메모에서 "다음 할 일"로 언급
    • 현재 플레이어 인벤토리만 구현됨
    • 컨테이너와의 상호작용 로직 필요

11. 내구도 시스템 (0%)

    • ItemData.h에 데이터는 존재
    • 인벤토리 컴포넌트에서 내구도 감소/복구 로직 없음
    • 장비/도구 사용 시 내구도 처리 필요

12. 에러 처리 및 클라이언트 피드백 (40%)

    • 서버 측 검증은 잘 되어 있음
    • ❌ 클라이언트로의 실패 피드백 메커니즘 부족
    • ❌ 인벤토리 가득 참, 이동 불가 등의 UI 알림 없음

13. 추가 필요 기능

    • ❌ 아이템 정렬 기능
    • ❌ 빠른 이동 (더블클릭 등)
    • ❌ 아이템 분할 UI

💡 종합 평가

현재 상태: 약 73% 완성

• 핵심 플레이어 인벤토리: 95% 완성 (매우 잘 구현됨)
• 멀티플레이어 네트워크: 90% 완성 (ForceNetUpdate 주석 처리 확인 필요)
• 확장 시스템: 30% 완성 (구조만 있거나 TODO)

다음 단계 권장사항:

1. 🔴 우선: 컨테이너/상자 인벤토리 구현 (계획된 작업)
2. 🟡 중요: 장비 시스템 완성 (TODO 해결)
3. 🟡 중요: 월드 드롭 스폰 매니저 연동
4. 🟢 개선: ForceNetUpdate 주석 처리 의도 확인
5. 🟢 장기: 내구도 시스템, 에러 피드백 UI

강점:

• 코드 구조가 깔끔하고 모듈화가 잘 되어 있음
• 네트워크 리플리케이션 구조가 탄탄함
• 부패도 같은 복잡한 시스템도 잘 통합됨

개선점:

• TODO 항목들 해결 필요
• 클라이언트 UX 관련 피드백 메커니즘 추가 필요

💡 느낀 점 (What I Felt)

코드랑 이번주 스크럼 내용으로 AI를 이용해 완성도를 평가해봤다. 2주차까지 한 작업을 정리해보니 어느 부분을 빠르게 처리해야할지 한 눈에 보인다.

📅 2025-11-13

• 언리얼 네트워크 복제: Actor 이름은 월드별로 독립적이다
• 구조체 내부 값 변경 시 자동 복제 조건

언리얼 네트워크 복제: Actor 이름은 월드별로 독립적이다

🤔 문제 상황

멀티플레이어 환경에서 Client가 BP_TSCharacter_C_0을 참조하는 것을 보고 "어? Player 1인데 왜 0번 캐릭터를 참조하지?"라고 착각했다.

💡 핵심 개념

각 월드(Server, Client)는 자신만의 Actor 인스턴스를 가지며, 이름은 각 월드에서 독립적으로 생성된다.

Server 월드:
├─ BP_TSCharacter_C_0 (Server Player)
└─ BP_TSCharacter_C_1 (Client Player)

Client 월드:
├─ BP_TSCharacter_C_0 (자신 = AutonomousProxy) ← 서버의 C_1과 동기화!
└─ BP_TSCharacter_C_1 (서버 복제본 = SimulatedProxy)

Actor 이름이 아니라 Role 값으로 판단해야 한다:

• Role: ROLE_AutonomousProxy (2) = 내가 제어하는 캐릭터
• Role: ROLE_SimulatedProxy (1) = 다른 플레이어의 복제본
• Role: ROLE_Authority (3) = 서버

✅ 결론

• Actor 이름(C_0, C_1)은 각 월드에서 독립적으로 생성됨
• "같은 Player"라도 Server 월드와 Client 월드에서 이름이 다를 수 있음
• Role 값이 진실! 이름만 보고 판단하면 안 됨

구조체 내부 값 변경 시 자동 복제 조건

🤔 기존 지식

"구조체 안에 구조체가 있으면 내부 값만 바꿨을 때 복제 안 되니까 ForceNetUpdate() 써야 한다"

💡 실제로는?

최상위 변수에 ReplicatedUsing을 선언하고, 내부 값들을 UPROPERTY로 정의하면 언리얼이 알아서 직렬화해서 복제해준다!

// 구조체 정의
USTRUCT(BlueprintType)
struct FSlotStructMaster
{
    GENERATED_BODY()

    UPROPERTY()  // ✅ UPROPERTY만 있으면 됨!
    int32 CurrentStackSize;

    UPROPERTY()
    FItemInstance ItemData;  // 구조체 안의 구조체도 OK
};

// 컴포넌트
UPROPERTY(ReplicatedUsing = OnRep_HotkeyInventory)  // ✅ 최상위만 선언
FInventoryStructMaster HotkeyInventory;

내부 값을 바꾸면:

HotkeyInventory.InventorySlotContainer[0].CurrentStackSize = 10;
// ✅ 자동으로 OnRep_HotkeyInventory() 호출됨!
// ForceNetUpdate() 불필요!

✅ 조건

1. 최상위 변수에 ReplicatedUsing 선언
2. 구조체의 모든 멤버 변수에 UPROPERTY 매크로
3. GetLifetimeReplicatedProps에 등록

→ 언리얼이 자동으로 변경 감지 및 직렬화!

💡 느낀 점 (What I Felt)

네트워크 복제는 "눈에 보이는 것"과 "실제 동작"이 다를 수 있다는 걸 배웠다. Actor 이름 같은 표면적인 정보에 속지 말고, Role이나 NetMode 같은 본질적인 값을 봐야 한다.

그리고 언리얼의 복제 시스템은 생각보다 똑똑해서, UPROPERTY만 제대로 선언하면 복잡한 구조체도 알아서 직렬화해준다. 불필요한 ForceNetUpdate() 남발을 줄일 수 있을 것 같다.