xodn246 님의 블로그

[내배캠 TIL 260430] C++ 숫자 짝꿍 (빈도수 배열 최적화)

xodn246 — Thu, 30 Apr 2026 10:48:31 +0900

1. 문제 핵심

두 문자열 X, Y에서 공통 숫자로 만들 수 있는 가장 큰 수
길이 최대 3,000,000 → 시간복잡도 중요

2. 기존 방식 문제

sort + 이중 반복문

정렬: O(N log N)
탐색: O(N^2) (최악)

중복 비교 많아서 시간 초과 위험

3. 해결 방법

핵심 아이디어

숫자는 0~9 → 종류가 고정됨
배열로 카운팅

시간복잡도

O(N)

정렬 없음
이중 반복 없음

4. 코드

string solution(string X, string Y) {
    string answer = "";
    int countX[10] = {0};
    int countY[10] = {0};

    for (char c : X) countX[c - '0']++;
    for (char c : Y) countY[c - '0']++;

    for (int i = 9; i >= 0; i--) {
        int common = min(countX[i], countY[i]);
        for (int j = 0; j < common; j++) {
            answer += to_string(i);
        }
    }

    if (answer == "") return "-1";
    if (answer[0] == '0') return "0";

    return answer;
}

5. 핵심 포인트

값의 범위가 작으면 → 배열 카운팅이 최적
정렬 대신 순회 순서로 정렬 효과 만들기
문자열 문제라도 연산 전에 복잡도 먼저 계산

6. 오늘의 교훈

정렬부터 쓰는 습관 버리기
범위 제한 보이면 카운팅 먼저 떠올리기
성능은 결국 자료구조 선택에서 갈린다

[내배캠 TIL 260428] Unreal Grid 기반 Fog of War

xodn246 — Tue, 28 Apr 2026 21:02:12 +0900

1. 문제 상황

기존 방식 (Radial)

원형으로 시야 표시
실제 타일 기반 로직이랑 안 맞음

해결 : Grid 기준으로 Fog를 직접 그림

2. 핵심 흐름

World → Grid → UV

유닛 위치 → 타일 좌표
타일 → RenderTarget 좌표로 변환
그 위치에 Fog 제거

3. 성능 개선

기존

타일마다 Draw 호출
Draw Call 과다 → 느림

개선

Canvas 사용
한 프레임에 한 번만 그림

결론:
N번 그리기 → 1번으로 줄임

4. 핵심 코드

UKismetRenderingLibrary::BeginDrawCanvasToRenderTarget(...);

Canvas->DrawTile(...); // Clear

for (Vision)
{
    for (Tiles)
    {
        Canvas->K2_DrawMaterial(...);
    }
}

UKismetRenderingLibrary::EndDrawCanvasToRenderTarget(...);

5. 핵심 포인트

RenderTarget = 화면용
실제 시야 판단 = Grid 데이터

→ 둘을 분리해야 안 꼬임

6. 한 줄 정리

“Fog는 원이 아니라 타일 기반으로 그려야 정확하다”

[내배캠 TIL 260417] Unreal RTS 영웅 스킬 구조 설계 (다형성 + 타이머 기반 판정)

xodn246 — Fri, 17 Apr 2026 21:17:32 +0900

1. 유닛 & 컨트롤러 구조 (다형성 설계)

핵심은 컨트롤러는 유닛의 "종류"를 몰라도 된다는 것.

구조

부모 클래스: ATWHeroUnitBase
자식 클래스: 투사체형 / 범위형 등

설계 방식

class ATWHeroUnitBase : public AActor
{
public:
    virtual void UseSkill(FVector TargetLocation);
    virtual bool IsIndicatorRequired() const;
};

ATWHeroUnitBase* Hero = Cast<ATWHeroUnitBase>(SelectedUnit);
Hero->UseSkill(ClickLocation);

포인트

컨트롤러에 분기 없음 (if/switch 제거)
새로운 영웅 추가 → 컨트롤러 수정 없음
완전한 다형성 구조

신호등 함수 (Indicator 분기 제거)

if (Hero->IsIndicatorRequired())
{
    ShowIndicator();
}

유닛이 “내가 타게팅 필요한지” 직접 판단
컨트롤러 책임 ↓
확장성 ↑

2. 스킬 로직 vs 연출 분리

문제

매번 액터 Spawn → 비용 큼 / 관리 어려움

해결

로직: 타이머
연출: Debug Draw (임시)

데이터 기반 설계

USTRUCT()
struct FHeroData
{
    TSubclassOf<AActor> SkillAreaClass;
};

스킬 정보는 DataTable에서 관리
코드 수정 없이 확장 가능

3. 시간차 스킬 구조 (타이머)

구조

예고 (충전)
폭발 (판정)
여운 (이펙트)

코드

// 1. 예고
DrawDebugCircle(GetWorld(), Loc, Radius, 50, FColor::Green, false, 3.0f);

// 2. 폭발 예약
GetWorldTimerManager().SetTimer(TimerHandle, [this, Loc]()
{
    // 실제 판정 위치 유지됨 (람다 캡처)
    
    // TODO: 데미지 처리
    DrawDebugCircle(GetWorld(), Loc, Radius, 50, FColor::Red, false, 1.0f);

}, 3.0f, false);

핵심 포인트

[this, Loc] 캡처 → 클릭 당시 위치 유지
액터 없이도 스킬 흐름 구현 가능
상태 머신 없이 간단하게 시퀀스 구성

4. DrawDebugCircle 핵심

DrawDebugCircle(
    GetWorld(),
    Loc,
    Radius,
    50,
    FColor::Green,
    false,
    3.0f,
    0,
    2.0f,
    FVector(0, 0, 1) // 중요
);

중요 파라미터

Normal: (0,0,1) → 바닥 기준 원
Segments: 32~50 → 원 부드러움
LifeTime:
- -1 → 1프레임
- 0 → 유지 시간

트러블슈팅

원이 선처럼 보임 → Normal 값 문제 100%

5. 현재 구조의 장점

컨트롤러 수정 없이 영웅 추가 가능
스킬 흐름을 타이머로 단순화
초기 단계에서 빠른 검증 가능
불필요한 Spawn 제거 → 성능 + 개발 속도 확보

6. 다음 단계 (실전 로직)

TArray<AActor*> HitActors;

UKismetSystemLibrary::SphereOverlapActors(
    GetWorld(),
    Loc,
    Radius,
    ObjectTypes,
    AMonster::StaticClass(),
    IgnoreActors,
    HitActors
);

태그 기반 필터링
실제 데미지 적용
팀 판정 추가 필요

[내배캠 TIL 260415] Unreal 미니맵 카메라 프러스텀 투영 및 클릭 이동 구현

xodn246 — Wed, 15 Apr 2026 21:12:27 +0900

1. 개요

Tiny Dominion 프로젝트에서
현재 카메라가 보고 있는 영역(Frustum)을 미니맵에 실시간으로 표시하고,
미니맵 클릭 시 해당 위치로 카메라를 이동시키는 기능을 구현했다.

핵심은 다음 두 가지다:

화면 → 월드 투영 (Deproject)
월드 → 미니맵 좌표 변환 (UV 매핑)

2. 카메라 프러스텀 렌더링

핵심 아이디어

화면의 4개 모서리를 월드로 변환
해당 Ray를 지면(Z=0)과 교차시켜 실제 위치 계산
월드 좌표를 미니맵 UV로 변환 후 선으로 연결

구현 코드

void ATWMiniMap::DrawCameraFrustum(UCanvas* Canvas, int32 Width, int32 Height)
{
    if (!Canvas || !GetWorld()) return;

    APlayerController* PC = GetWorld()->GetFirstPlayerController();
    if (!PC) return;

    FVector2D ScreenCorners[4] = {
        FVector2D(0, 0),
        FVector2D(Width, 0),
        FVector2D(Width, Height),
        FVector2D(0, Height)
    };

    TArray<FVector2D> MinimapPoints;

    for (int32 i = 0; i < 4; ++i)
    {
        FVector WorldLoc, WorldDir;

        if (PC->DeprojectScreenPositionToWorld(
            ScreenCorners[i].X,
            ScreenCorners[i].Y,
            WorldLoc,
            WorldDir))
        {
            if (FMath::IsNearlyZero(WorldDir.Z)) continue;

            float t = -WorldLoc.Z / WorldDir.Z;
            FVector GroundPos = WorldLoc + (WorldDir * t);

            FVector RelativePos = GroundPos - GetActorLocation();

            float U = (RelativePos.Y / CaptureWidth) + 0.5f;
            float V = (RelativePos.X / CaptureWidth) + 0.5f;

            MinimapPoints.Add(FVector2D(U * Width, V * Height));
        }
    }

    if (MinimapPoints.Num() == 4)
    {
        for (int32 i = 0; i < 4; ++i)
        {
            Canvas->K2_DrawLine(
                MinimapPoints[i],
                MinimapPoints[(i + 1) % 4],
                2.0f,
                FLinearColor::White
            );
        }
    }
}

핵심 포인트

DeprojectScreenPositionToWorld 사용 (함수명 중요)
Ray와 평면 교차로 실제 위치 계산
WorldDir.Z == 0 방어 필요
미니맵 기준 좌표계로 변환 필요

3. 미니맵 클릭 → 월드 좌표 변환

핵심 아이디어

UI 좌표 → UV(0~1)
UV → 월드 상대 좌표
회전된 미니맵 기준으로 축 보정

구현 코드

FVector ATWMiniMap::GetWorldLocationFromTouch(
    FVector2D TouchPos,
    FVector2D WidgetSize)
{
    float U = TouchPos.X / WidgetSize.X;
    float V = TouchPos.Y / WidgetSize.Y;

    float RelativeX = (U - 0.5f) * CaptureWidth;
    float RelativeY = (V - 0.5f) * CaptureWidth;

    // -90도 회전 보정
    float WorldX = -RelativeY;
    float WorldY = RelativeX;

    FVector MapLocation = GetActorLocation();

    return FVector(
        MapLocation.X + WorldX,
        MapLocation.Y + WorldY,
        0.0f
    );
}

핵심 포인트

UV 기준은 항상 (0.5, 0.5)가 중심
CaptureWidth = 월드 범위 스케일
미니맵 회전 시 반드시 축 보정 필요

4. 머테리얼 처리

구성

지형 텍스처 + 프러스텀 RenderTarget 합성
Add 연산으로 외곽선만 덧씌움

핵심 포인트

CustomRotator(-90°)를 둘 다 동일하게 적용
Multiply 사용 시 배경이 어두워짐 → 부적합
Add 사용 시 선만 자연스럽게 합성됨

5. 위젯 처리

흐름

OnMouseButtonDown
Absolute → Local 좌표 변환
C++ 함수 호출
카메라 이동

주의사항

Screen 좌표 그대로 쓰면 틀어짐
반드시 Widget Local 좌표로 변환 필요

TIL - Unreal Engine 미니맵 구현

xodn246 — Mon, 13 Apr 2026 21:27:20 +0900

1. 핵심 구조

미니맵과 안개는 완전히 분리된 시스템이다.

미니맵 → SceneCapture로 지형을 RT에 그림
안개 → 별도의 Render Target 2장으로 관리

"지형 / 현재 시야 / 탐색 기록"을 각각 따로 만들고 마지막에 머티리얼에서 합성

2. 미니맵 캡처 (SceneCapture2D)

핵심 포인트

매 프레임 X → 타이머 기반 갱신
OrthoWidth로 월드 크기 동기화
Render Target에 직접 그림

void ATWMiniMap::BeginPlay()
{
    Super::BeginPlay();

    if (CaptureComp && MinimapRT)
    {
        CaptureComp->TextureTarget = MinimapRT;
        CaptureComp->OrthoWidth = CaptureWidth;

        CaptureComp->bCaptureEveryFrame = false;
        CaptureComp->bCaptureOnMovement = false;

        GetWorldTimerManager().SetTimer(
            CaptureTimerHandle,
            this,
            &ATWMiniMap::UpdateCapture,
            0.1f,
            true
        );
    }
}

void ATWMiniMap::UpdateCapture()
{
    CaptureComp->CaptureScene();
}

핵심 요약:

SceneCapture는 "카메라"가 아니라 "RT에 찍는 도구"
빈번한 업데이트는 성능 낭비 → 타이머로 제한

3. 2중 Fog of War 구조

분리된 RT 2개 사용

CurrentRT
→ "지금 보이는 영역"
→ 매 프레임 덮어씀
ExploredRT
→ "지나간 기록"
→ CurrentRT를 누적(Additive)

동작 흐름

플레이어 이동
	↓
CurrentRT에 원 그리기
	↓
ExploredRT에 누적

4. 머티리얼 합성 로직 (UI 전용)

머테리얼 노드

의미

Explored = 0 → 아예 안보임 (검정)
Explored = 1 + Current = 0 → 어두운 지형
Current = 1 → 완전 밝음

값 설정

Dark = 0.1
Bright = 1.0

5. 방향 문제 해결 (중요)

문제

월드: X+가 북쪽
UI: 오른쪽이 동쪽

→ 그대로 쓰면 90도 틀어짐

해결

머테리얼이 들어갈 UI Image를 -90만큼 회전

6. UI 연결 구조

흐름

C++
→ Dynamic Material 생성
→ RenderTarget 연결
→ UMG Image에 적용

void AMyPlayerController::SetupMinimapUI()
{
    if (MinimapWidgetClass)
    {
        UUserWidget* Widget = CreateWidget<UUserWidget>(this, MinimapWidgetClass);
        Widget->AddToViewport();

        // Dynamic Material 생성
        // BaseMap / CurrentFog / ExploredFog 연결
    }
}

7. 트러블슈팅

1. 안개가 빨갛게 나올 때

Texture Sample → R 채널만 사용

2. 방향 틀어짐

CustomRotator = 0.25

3. 성능 문제

SceneCapture 타이머로 제한
Fog 계산은 전부 GPU(Material)에서 처리

8. 최종 결과 상태

상태값결과

미탐색	0	검정
탐색됨	0.1	어두운 지형
현재 시야	1.0	밝은 지형

[내배캠 TIL 260406] Unreal Fog of War 서버연동 정리

xodn246 — Mon, 6 Apr 2026 21:15:24 +0900

1. 핵심 개념

Fog of War에서 네트워크의 역할은 단순하다.

서버는 "위치 정보만 동기화"

클라이언트는 "시야를 직접 그린다"

렌더링을 서버에서 처리하려고 하면 비용이 폭발한다.
따라서 시야 계산과 렌더링은 완전히 클라이언트 책임으로 분리한다

2. 데이터 흐름 구조

서버 역할

유닛 위치, 상태를 authoritative하게 관리
Pawn / Actor Transform 복제 (Replication)

클라이언트 역할

복제된 유닛 정보 수신
로컬 기준으로 시야 계산
Render Target에 Fog 직접 렌더링

[Server] 위치 동기화 → [Client] 로컬 유닛 필터링 → Fog 렌더링

3. 로컬 소유권 기반 필터링

모든 클라이언트는 모든 유닛을 받는다.
따라서 반드시 “내 유닛”만 골라내는 과정이 필요하다.

APawn* OwnerPawn = Cast<APawn>(VisionComp->GetOwner());

if (OwnerPawn && OwnerPawn->IsLocallyControlled())
{
    // 이 클라이언트 기준 '내 유닛'만 시야 반영
}

핵심 포인트

Replication 자체는 “전체 공유”
시야는 “로컬 필터링”
서버는 시야를 절대 계산하지 않음

4. 왜 IsLocallyControlled()인가

멀티플레이에서 Pawn은 다음과 같이 나뉜다.

Authority (서버)
AutonomousProxy (내 캐릭터)
SimulatedProxy (다른 플레이어)

IsLocallyControlled()는
AutonomousProxy만 true가 된다.

→ 즉, “내가 조작 중인 Pawn”만 정확히 식별 가능

5. 네트워크 안정성 고려

Fog 시스템 자체는 클라이언트 로직이지만
입력 데이터는 네트워크에 의존한다.

주의할 점

Replication 지연 → 시야 반영 지연
Pawn 소유권 변경 시 필터링 영향
Destroy된 Actor 참조 가능성

방어 코드

if (!IsValid(VisionComp)) continue;

APawn* OwnerPawn = Cast<APawn>(VisionComp->GetOwner());
if (!IsValid(OwnerPawn)) continue;

6. 확장 구조 (팀 기반 시야)

현재 구조는 “개인전 기준”이다.
팀 기반으로 확장하려면 Ownership 기준만 바꾸면 된다.

// 개인전
OwnerPawn->IsLocallyControlled()

// 팀전
OwnerPawn->TeamID == MyTeamID

결과

아군 유닛 시야 공유
거점 시야 연동 가능
RTS 전형 구조 완성

7. 네트워크 설계 핵심 요약

서버는 시야를 모른다 (렌더링 X)
클라이언트는 시야를 직접 계산한다
모든 유닛은 공유되지만, 시야는 필터링한다

8. 설계 인사이트

멀티플레이에서 중요한 건
“데이터를 어디서 계산할 것인가”다.

서버 → 상태 관리
클라이언트 → 시각 처리

이 경계를 명확히 나누는 순간
Fog of War는 네트워크 문제가 아니라
단순한 로컬 렌더링 문제로 바뀐다.

[ 내배캠 TIL 260403] Unreal RenderTarget 기반 Fog of War 구현

xodn246 — Fri, 3 Apr 2026 21:21:38 +0900

1. FogManager.cpp (핵심 로직)

안개 시스템의 중심 역할
RenderTarget 초기화 + 유닛 시야를 기반으로 안개를 제거

#include "Kismet/KismetRenderingLibrary.h"
#include "Kismet/KismetMaterialLibrary.h"

void AFogManager::BeginPlay()
{
    Super::BeginPlay();

    // RenderTarget 초기화 (검정 = 안개 상태)
    if (CurrentFogRT)
        UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), CurrentFogRT, FLinearColor::Black);
    
    if (ExploredFogRT)
        UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), ExploredFogRT, FLinearColor::Black);

    // MPC에 맵 크기 전달 (머티리얼에서 좌표 계산용)
    UKismetMaterialLibrary::SetVectorParameterValue(
        GetWorld(),
        FogMPC,
        TEXT("MapSize"),
        FLinearColor(MapSize.X, MapSize.Y, 0, 0)
    );
}

void AFogManager::UpdateFog(float DeltaTime)
{
    // 등록된 모든 VisionComponent 순회
    for (UVisionComponent* VisionComp : RegisteredUnits)
    {
        FVector ActorLoc = VisionComp->GetOwner()->GetActorLocation();
        
        // World → UV 변환 (0~1 범위)
        FVector2D UV;
        UV.X = (ActorLoc.X - MapOrigin.X) / MapSize.X;
        UV.Y = (ActorLoc.Y - MapOrigin.Y) / MapSize.Y;

        // 시야 반경 보정
        float FinalRadius = (VisionComp->VisionRadius / MapSize.X) * 2.5f;

        // 머티리얼 파라미터 전달
        DrawMID->SetVectorParameterValue(TEXT("VisionPos"), FLinearColor(UV.X, UV.Y, 0, 0));
        DrawMID->SetScalarParameterValue(TEXT("Radius"), FinalRadius);

        // RenderTarget에 시야 그리기
        UKismetRenderingLibrary::DrawMaterialToRenderTarget(GetWorld(), CurrentFogRT, DrawMID);
    }
}

RenderTarget은 UV(0~1) 기준으로 동작
월드 좌표 → UV 변환 필수
DrawMaterialToRenderTarget으로 시야 누적

2. M_DrawVision (시야 그리기 머티리얼)

RenderTarget에 흰색 원을 그리는 머티리얼

설정

Domain: Surface (또는 Post Process)
Blend Mode: Additive

노드 구조

핵심

Distance 기반 원 생성
Saturate로 값 안정화 (0~1)
Power로 경계 부드럽게 처리
RGB 동일 값으로 흰색 유지

3. M_FinalFogPostProcess (최종 출력)

게임 화면 위에 Fog를 덮는 포스트 프로세스 머티리얼

설정

Domain: Post Process

노드 구조

핵심

Alpha = Fog 정보
1 → 보임 / 0 → 가림
R 채널만 사용해서 마스크 처리

4. VisionComponent.cpp

유닛에 붙여 시야 정보를 제공하는 컴포넌트

void UVisionComponent::BeginPlay()
{
    Super::BeginPlay();

    AActor* FoundActor = UGameplayStatics::GetActorOfClass(GetWorld(), AFogManager::StaticClass());
    AFogManager* FogMgr = Cast<AFogManager>(FoundActor);
    
    if (FogMgr)
    {
        FogMgr->RegisterUnit(this);
    }
}

핵심

BeginPlay에서 FogManager에 자신 등록
FogManager가 모든 시야를 중앙에서 관리

정리

VisionComponent → 시야 제공
FogManager → RenderTarget에 시야 기록
PostProcess → 화면에 Fog 적용

[ 내배캠 TIL 260402] Unreal Grid & Fog of War 시스템 정리

xodn246 — Thu, 2 Apr 2026 01:08:42 +0900

1. 데이터 구조 설계

RTS에서 지형(Grid)과 시야(Fog)는 역할이 완전히 다르기 때문에 분리해서 관리하는 것이 핵심이다.

핵심 포인트

Grid → 물리/지형 정보
Fog → 시야 정보
메모리 절약을 위해 uint8 사용

// GridManager.h
USTRUCT(BlueprintType)
struct FGridCell 
{
    GENERATED_BODY()

    uint8 WalkableState; // 0: 이동불가, 1: 이동가능
    uint8 TerrainType;   // 0: 평지, 1: 숲, 2: 물 등

    FGridCell() : WalkableState(1), TerrainType(0) {}
};

// FogManager.h
USTRUCT(BlueprintType)
struct FFogCell 
{
    GENERATED_BODY()

    uint8 FogState; // 0: 미탐색, 1: 안개, 2: 현재시야

    FFogCell() : FogState(0) {}
};

정리

역할 분리를 통해 확장성 확보
uint8 사용으로 대규모 배열 메모리 절약
Fog는 단순 상태값만 필요 → 더 가볍게 유지

2. 좌표 변환 (핵심 로직)

RTS에서 가장 중요한 부분 중 하나는
월드 좌표 ↔ 그리드 인덱스 변환

World → Grid Index

int32 AGridManager::WorldToGridIndex(FVector WorldLocation) const 
{
    FVector ActorLoc = GetActorLocation();

    float HalfWidth = (GridCountX * CellSize) * 0.5f;
    float HalfHeight = (GridCountY * CellSize) * 0.5f;

    FVector GridStartLoc = ActorLoc - FVector(HalfWidth, HalfHeight, 0.f);
    FVector RelativePos = WorldLocation - GridStartLoc;

    int32 X = FMath::FloorToInt(RelativePos.X / CellSize);
    int32 Y = FMath::FloorToInt(RelativePos.Y / CellSize);

    if (X < 0 || X >= GridCountX || Y < 0 || Y >= GridCountY)
        return -1;

    return X + (Y * GridCountX);
}

Grid Index → World

FVector AGridManager::GridIndexToWorld(int32 Index) const 
{
    if (!GridData.IsValidIndex(Index))
        return FVector::ZeroVector;

    int32 GridX = Index % GridCountX;
    int32 GridY = Index / GridCountX;

    FVector ActorLoc = GetActorLocation();

    FVector GridStartLoc = ActorLoc - FVector(
        (GridCountX * CellSize) * 0.5f,
        (GridCountY * CellSize) * 0.5f,
        0.f
    );

    float WorldX = GridStartLoc.X + (GridX * CellSize) + (CellSize * 0.5f);
    float WorldY = GridStartLoc.Y + (GridY * CellSize) + (CellSize * 0.5f);

    return FVector(WorldX, WorldY, ActorLoc.Z);
}

정리

Grid 기준점 = Actor 중심 기준 좌측 하단
핵심 수식
- Index = X + (Y * Width)
Cell 중심 좌표 계산 시 + CellSize * 0.5f 필수

3. 배열 초기화 최적화

대규모 Grid/Fog 데이터를 다루기 때문에
초기화 방식이 성능에 큰 영향을 준다.

// GridData
GridData.SetNumUninitialized(TotalCells);
for (int32 i = 0; i < TotalCells; ++i) {
    GridData[i].WalkableState = 1;
}

// FogData
FogData.SetNumZeroed(TotalCells);

정리

방식특징사용 이유

SetNumUninitialized	초기화 생략	기본값이 0이 아닐 때
SetNumZeroed	0으로 초기화	기본값이 0일 때

→ 불필요한 초기화 비용 제거 = 성능 최적화

4. Fog of War 업데이트 로직

기본 흐름은 매우 단순한 상태 머신이다.

처리 순서

현재 시야(2) → 안개(1)로 변경
유닛 주변을 다시 시야(2)로 갱신

void AFogManager::UpdateFog(const TArray<FVector>& ViewerLocations, float SightRadius) 
{
    // 1. 기존 시야를 안개로 변경
    for (auto& Cell : FogData) 
    {
        if (Cell.FogState == 2)
            Cell.FogState = 1;
    }

    // 2. 시야 제공자 기준 갱신
    for (const FVector& Loc : ViewerLocations) 
    {
        int32 CenterIndex = TargetGridManager->WorldToGridIndex(Loc);

        int32 RadiusInCells = FMath::RoundToInt(
            SightRadius / TargetGridManager->CellSize
        );

        // 중첩 for문 + 거리 체크
        // (x^2 + y^2 <= r^2)
    }
}

핵심 개념

Fog 상태 3단계
- 0: 미탐색
- 1: 안개 (과거 시야)
- 2: 현재 시야
원형 범위 체크

(dx * dx + dy * dy <= r * r)

5. 전체 구조 정리

시스템 분리 구조

GridManager
├── 지형 데이터
├── 좌표 변환
└── Cell 정보 관리

FogManager
├── 시야 데이터
├── 유닛 기반 시야 갱신
└── GridManager 참조

RTS 주요 점령 기믹 기획

xodn246 — Fri, 27 Mar 2026 15:57:52 +0900

전장 시스템 기획서

Control Line Nexus Battle

1. 전장 구조 (Map Topology)

1.1 본진 배치

Player A (Blue Team): 맵 좌하단 (7시 방향)
Player B (Red Team): 맵 우상단 (1시 방향)

각 플레이어는 본진(Nexus)을 중심으로 유닛 생산 및 방어를 수행한다.

1.2 거점 배치 (Central Control Line)

맵에는 총 3개의 주요 거점이 존재하며,
좌상단(11시)에서 우하단(5시)을 잇는 대각선 축을 따라 배치된다.

거점위치전략적 특징

거점 1 (North-West)	좌상단 (11시)	Player B에게 유리
거점 2 (Center)	중앙	핵심 교전 지역
거점 3 (South-East)	우하단 (5시)	Player A에게 유리

2. 핵심 시스템

2.1 점령 메커니즘 (51:49 Rule)

초기 상태

모든 거점은 중립 상태 (50%)로 시작
각 거점에는 중립 몬스터가 배치됨

점령 시작 (중립 몬스터 처치)

중립 몬스터 처치 시:
- 막타 팀에게 +20% 점령 보너스 부여
- 점령 게이지 즉시 70%에서 시작

점령 진행 규칙

상황동작

아군만 존재	점령 게이지 증가
적군과 충돌	점령 게이지 정지
아무도 없음	점령 게이지가 50%로 서서히 복귀

소유권 판정

점령 게이지가 51% 이상일 경우 해당 팀이 소유
50%를 기준으로 지속적인 줄다리기 구조 유지

2.2 점령 보상 (Control Benefits)

자원 수급

점령한 거점 수에 비례하여 고급 유닛 생산 자원 자동 획득

넥서스 방어력 시스템 (Nexus Shield)

점령 거점 수상대 넥서스 피해 감소

0개	90%
1개	60%
2개	30%
3개	0%

거점을 점령해야만 본진 공격이 의미를 갖는다.

3. 전략 흐름 (Game Flow)

3.1 초반 (Opening Phase)

각 플레이어는 자신의 위치와 가까운 거점을 우선 확보
- Player A: 5시 거점
- Player B: 11시 거점
초기 자원 확보 및 안정적인 기반 구축

3.2 중반 (Mid Game)

중앙 거점을 둘러싼 본격적인 교전 발생

주요 전략:

정면 교전
기동 유닛을 활용한 측면 교란
적 거점을 49%까지 낮추는 견제 플레이

핵심 개념:
이기지 못하면, 상대의 균형을 무너뜨린다.

3.3 후반 (End Game)

2개 이상의 거점 확보 시 넥서스 방어력 약화
본진 공격 가능 상태 진입

수비 측 전략:

하나의 거점만 탈환해도 넥서스 방어력 즉시 복구

끝까지 역전 가능성을 유지한다.

4. 시스템 연계 요소

4.1 시야 시스템 (Fog of War)

거점 점령 시 해당 지역 주변 시야 확보

효과:

점령이 정보 장악으로 이어짐
전략 판단 요소 강화

4.2 지형 설계 (Terrain Design)

거점 사이에 이동 제한 요소 배치
- 절벽
- 물
- 좁은 통로

목적:

이동 경로 제한
전술 다양성 증가
병목 지점 형성

4.3 UI / UX 설계

상단 상태 UI

화면 상단에 거점 상태를 표시:

// 상단에 3개의 구형 UI
● ● ●

색상의미

Blue	Player A 점령
Red	Player B 점령
Gray	중립

목표:
플레이어가 짧은 시간 내 전황을 직관적으로 파악할 수 있도록 한다.

5. 핵심 디자인 철학

선택과 집중 (Choice and Commitment)

플레이어는 매 순간 선택해야 한다.

안정적으로 유지할 것인가
위험을 감수하고 확장할 것인가

줄다리기 구조 (Tug-of-War)

거점은 고정되지 않고 지속적으로 변화한다.

정보의 가치

거점 점령은 자원뿐 아니라 시야와 전략적 우위를 제공한다.

[ 내배캠 TIL 260325] Unreal Engine 네트워크 복제 시스템 정리

xodn246 — Wed, 25 Mar 2026 19:49:54 +0900

1. 액터 복제 설정 (bReplicates)

역할
해당 액터를 네트워크 복제 대상으로 포함할지 결정
설정 위치
생성자에서 설정

bReplicates = true;

핵심 포인트
- 서버에서 생성된 액터가 클라이언트에도 자동으로 생성됨
- 이 설정이 없으면 복제 자체가 시작되지 않음

2. 변수 복제 등록 (GetLifetimeReplicatedProps)

역할
액터 내부 변수 중 어떤 것을 복제할지 선택
구현 방법

#include "Net/UnrealNetwork.h"

void AMyActor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);

    DOREPLIFETIME(AMyActor, Health);
}

핵심 포인트
- 복제할 변수는 반드시 여기 등록해야 함
- 선언만 하고 구현 안 하면 링커 에러(LNK2001) 발생
- 헤더 포함 필수

3. OnRep 함수 (ReplicatedUsing)

역할
복제된 값이 클라이언트에 도착했을 때 실행되는 콜백 함수
설정 방법

UPROPERTY(ReplicatedUsing = OnRep_Health)
float Health;

UFUNCTION()
void OnRep_Health();

구현 예시

void AMyActor::OnRep_Health()
{
    // 체력 변경 시 실행할 로직 (UI 갱신 등)
}

핵심 포인트
- 값이 변경될 때만 실행 (Tick 필요 없음)
- 기본적으로 클라이언트에서만 자동 호출
- 서버에서는 필요 시 수동 호출
- 이전 값 비교도 가능 (OldValue 활용)

C++ OnRep vs Blueprint RepNotify

공통 개념 (Replication Notify)

변수 값이 변경되어 클라이언트에 복제되는 순간 자동으로 호출되는 콜백 함수
값 변경을 감지해서 후처리를 수행하는 이벤트 기반 시스템

C++ : OnRep_

UPROPERTY(ReplicatedUsing = OnRep_Health)
float Health;

특징
- 함수 이름은 보통 OnRep_변수명 규칙 사용
- C++에서 직접 구현
- 필요 시 OldValue를 받아 이전 값 비교 가능
- 서버에서는 자동 호출되지 않음 (직접 호출 필요)

Blueprint : RepNotify

설정 방식
- 변수 옵션에서 RepNotify 체크
- 자동으로 Notify 함수 생성됨
특징
- 블루프린트에서 이벤트처럼 사용
- 별도 함수 선언 없이 쉽게 연결 가능
- 내부적으로는 C++의 OnRep과 동일한 동작

핵심 차이

C++ → 직접 함수 구현 (유연성 높음)
Blueprint → 자동 이벤트 생성 (사용 편의성 높음)

한줄 정리

→ "OnRep과 RepNotify는 동일한 개념이며, C++은 직접 구현, 블루프린트는 자동 이벤트 형태로 제공된다."

전체 흐름 정리

bReplicates = true
→ 액터 자체를 네트워크에 등장시킴

DOREPLIFETIME
→ 복제할 변수 선택

OnRep_ / RepNotify
→ 값 변경 시 클라이언트에서 후처리

비유로 이해하기

bReplicates → 공연장 입장권
GetLifetimeReplicatedProps → 반입 물품 목록
ReplicatedUsing / RepNotify → 알림 벨
OnRep 함수 → 벨 울리면 하는 행동