✍️Today I Learned

📅 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를 검증하는 부분이 비효율적인것 같다. 어떤 방식으로 최적화해야 피드백도 늦지 않고 비용을 줄일 수 있을지 더 찾아봐야겠다.

---