view29579 님의 블로그

Unreal 응용반 분반수업 4차 내용정리

view29579 — Thu, 17 Sep 2026 20:19:58 +0900

1. ControlRotation 복습

PlayerController는 플레이어가 바라보거나 조준하고 있는 방향을 ControlRotation으로 가지고 있다.

bUseControllerRotationYaw

APawn에 있는 옵션이다.

true로 설정하면 Pawn의 Yaw가 Controller의 ControlRotation.Yaw를 따라간다.

ControlRotation.Yaw
        ↓
Character Actor Yaw

주로 캐릭터가 카메라 또는 조준 방향을 따라가야 하는 경우 사용한다.

예:

FPS
TPS 조준 모드
캐릭터와 조준 방향을 일치시키는 방식

bUseControllerDesiredRotation

UCharacterMovementComponent의 옵션이다.

활성화하면 CharacterMovement가 Controller의 방향을 목표 회전 방향으로 사용한다.

이때 RotationRate를 이용해서 캐릭터가 즉시 회전하지 않고 점진적으로 회전한다.

ControlRotation
      ↓
목표 회전 방향
      ↓
RotationRate
      ↓
Character 회전

bOrientRotationToMovement

UCharacterMovementComponent의 옵션이다.

활성화하면 캐릭터가 Controller가 바라보는 방향이 아니라 이동 방향을 기준으로 회전한다.

이동 방향
   ↓
Character 회전

3인칭 일반 이동에서 자주 사용하는 방식이다.

RotationRate

CharacterMovementComponent가 캐릭터를 회전시키는 속도이다.

예:

MovementComponent->RotationRate = FRotator(0.0f, 240.0f, 0.0f);

Yaw 방향으로 초당 240도 회전하도록 설정할 수 있다.

2. SpringArm의 bUsePawnControlRotation

SpringArm이 Pawn의 Control Rotation을 카메라 방향에 사용할지 결정하는 옵션이다.

PlayerController
      ↓
ControlRotation
      ↓
SpringArm
      ↓
Camera

따라서 마우스를 움직였을 때 카메라가 Controller의 회전을 따라가게 만들 때 사용할 수 있다.

3. UObject와 Actor

UObject

UObject는 Unreal Object System의 기본이 되는 클래스이다.

일반 C++ 객체와 다르게 Unreal의 객체 관리 시스템을 사용할 수 있다.

일반적인 C++ 객체:

FMyData* Data = new FMyData();
delete Data;

UObject 계열:

UMyObject* MyObject = NewObject<UMyObject>(this);

UObject는 Unreal의 Garbage Collection 시스템과 연결되어 관리된다.

Outer

Outer는 UObject가 어떤 객체에 속해 있는지를 나타내는 관계이다.

NewObject<UMyObject>(this);

여기서 this는 새로 만들어지는 UObject의 Outer가 된다.

Outer는 UObject의 객체 계층과 소속 관계를 이해할 때 중요하다.

Actor

AActor는 UObject를 상속받은 클래스이다.

차이점은 Actor는 월드에 존재할 수 있는 객체라는 것이다.

Actor는 위치, 회전, 크기 등의 Transform을 가지고 월드에 배치되거나 Spawn될 수 있다.

GetWorld()->SpawnActor<AMyActor>();

Actor는 단순히 C++ 객체 하나를 생성하는 것이 아니라 Unreal의 월드와 연결되어야 하기 때문에 SpawnActor() 등을 통해 생성한다.

4. Actor의 생명주기

Actor는 대략 다음과 같은 흐름으로 동작한다.

Actor 생성
   ↓
Construction
   ↓
Component 초기화
   ↓
BeginPlay
   ↓
GamePlay
   ↓
EndPlay
   ↓
World에서 제거
   ↓
Garbage Collection

C++에서 작성한 기본 설정과 Blueprint에서 작성한 로직의 실행 순서도 고려해야 한다.

따라서 모든 로직을 단순히 같은 시점에 실행된다고 생각하면 예상과 다른 결과가 발생할 수 있다.

기본 생성자

기본 생성자에서는 주로

기본값 설정
Component 생성

등을 작성한다.

Construction

에디터에서 Actor의 값이 변경되었을 때 갱신되는 과정에서 많이 사용된다.

게임 시작 후 실행해야 하는 로직은 일반적으로 BeginPlay()에서 처리한다.

PostInitializeComponents

Actor의 Component 초기화가 완료된 후 호출된다.

5. Destroy

Destroy()는 C++의 delete와 다르다.

Destroy();

이것은 Actor를 즉시 메모리에서 직접 삭제하는 것이 아니라 World에서 제거하는 과정을 시작하는 것이다.

이후 EndPlay 등의 과정이 진행되고 실제 UObject 메모리 정리는 Unreal의 Garbage Collection 시스템이 담당한다.

따라서 Actor에 대해 직접:

delete MyActor;

하는 방식은 사용하지 않는다.

6. UObjectPtr

UObject 계열 객체를 참조할 때 Unreal의 객체 관리 시스템과 함께 안전하게 사용하기 위해 TObjectPtr를 사용할 수 있다.

예:

UPROPERTY()
TObjectPtr<UMyObject> MyObject;

특히 Unreal의 UPROPERTY()와 함께 객체 참조를 관리할 때 중요하다.

객체가 유효한지 확인해야 하는 상황에서는 IsValid() 등의 방법을 사용할 수 있다.

7. Actor의 Owner

Actor에는 다른 Actor를 Owner로 지정할 수 있다.

Weapon->SetOwner(PlayerCharacter);

그러면 Weapon에서:

AActor* OwnerActor = GetOwner();

를 통해 자신의 Owner를 확인할 수 있다.

Owner가 없다면 nullptr이 반환될 수 있으므로 예외 처리가 필요하다.

if (!OwnerActor)
{
    return;
}

Owner에서 주의할 점

Owner는 C++에서 말하는 메모리 소유권과 같은 의미가 아니다.

또한 Attachment와도 다르다.

Owner
→ Gameplay / Network 관계

Attachment
→ Transform 부모-자식 관계

예를 들어 총을 캐릭터 손 Socket에 붙이는 것과 총의 Owner를 캐릭터로 지정하는 것은 서로 다른 개념이다.

총을 캐릭터 손에 Attach하면서 Owner도 캐릭터로 설정할 수 있지만, 둘은 각각 다른 목적을 가진다.

특히 Multiplayer에서는 Actor의 Owner 관계가 RPC, Replication 등의 동작과 관련되기 때문에 중요하다.

8. V키를 이용한 Control Mode 전환

V키를 눌렀을 때 카메라와 캐릭터의 컨트롤 방식을 변경하는 시스템을 만들었다.

컨트롤 모드를 Enum으로 구분한다.

UENUM(BlueprintType)
enum class EPlayerControlMode : uint8
{
    ThirdPerson UMETA(DisplayName = "Third Person"),
    FirstPerson UMETA(DisplayName = "First Person"),
    TopDown UMETA(DisplayName = "Top Down"),
    Shoulder UMETA(DisplayName = "Shoulder / Aim")
};

Enum을 사용하는 이유는 여러 모드를 명확하게 구분하고, 이후 모드가 추가되더라도 관리하기 쉽도록 하기 위해서이다.

9. ChangeControlMode와 ApplyControlMode

두 함수를 분리해서 사용했다.

void ChangeControlMode();

→ 다음에 어떤 모드로 변경할지 결정

void ApplyControlMode(
    EPlayerControlMode NewControlMode
);

→ 선택된 모드의 실제 설정을 적용

책임을 나누면 함수 하나가 너무 많은 역할을 담당하지 않게 된다.

컨트롤 모드 변경 흐름은 다음과 같다.

ThirdPerson
    ↓
FirstPerson
    ↓
TopDown
    ↓
Shoulder
    ↓
ThirdPerson

10. 컨트롤 모드별 설정

Third Person

Camera
→ SpringArm 사용
→ Controller Rotation 사용

Character
→ Controller Yaw 직접 사용 X
→ 이동 방향으로 회전

주요 설정:

bUseControllerRotationYaw = false;
bOrientRotationToMovement = true;
bUseControllerDesiredRotation = false;

First Person

Camera
→ Character 머리 위치

Character
→ Controller Yaw를 따라감

주요 설정:

bUseControllerRotationYaw = true;
bOrientRotationToMovement = false;
bUseControllerDesiredRotation = false;

Top Down

Camera
→ 높은 위치에서 내려다봄

Character
→ 이동 방향으로 회전

주요 설정:

bUseControllerRotationYaw = false;
bOrientRotationToMovement = true;
bUseControllerDesiredRotation = false;

Shoulder / Aim

Camera
→ Character 오른쪽 어깨 방향
→ Controller Rotation 사용

Character
→ Controller Yaw를 따라감

주요 설정:

bUseControllerRotationYaw = true;
bOrientRotationToMovement = false;
bUseControllerDesiredRotation = false;

11. 예외 처리의 중요성

C++ 코드를 작성할 때 정상적인 상황만 생각하지 않고 객체가 존재하지 않는 상황도 고려해야 한다.

예:

if (!MovementComponent || !CameraBoom || !FollowCamera)
{
    return;
}

이런 방어 코드를 추가하면 필요한 객체가 준비되지 않았을 때 바로 접근해서 문제가 발생하는 것을 막을 수 있다.

앞으로 AI에게 코드를 요청할 때도 예외 처리와 방어 코드가 필요한 부분을 함께 확인해 달라고 요청하는 습관을 가지는 것이 좋다.

12. 이번 주 복습 포인트

이번 주에는 다음 내용을 다시 확인했다.

이동 구현
마우스 회전
ControlRotation
PlayerController
bUseControllerRotationYaw
bUseControllerDesiredRotation
bOrientRotationToMovement
RotationRate
SpringArm::bUsePawnControlRotation
UObject와 Actor의 차이
UObject의 생명주기
Actor의 생명주기
Destroy()와 C++ delete의 차이
TObjectPtr
Actor Owner와 Attachment의 차이
Enum을 이용한 Control Mode 분리
Third Person / First Person / Top Down / Shoulder Mode
함수의 책임 분리
C++ 방어 코드와 예외 처리
기획서에 맞춰 컨트롤 모드를 수정하는 과정

느낀 점

오늘은 단순히 캐릭터를 움직이는 것에서 끝나는 것이 아니라, Controller → ControlRotation → Character / Movement → Camera가 어떻게 연결되는지 다시 정리할 수 있었다.

또한 UObject, Actor, Owner처럼 Unreal에서 자주 사용하지만 서로 헷갈리기 쉬운 개념들을 복습하면서, 단순히 코드를 따라 작성하는 것보다 각 객체와 기능이 어떤 역할을 담당하는지 이해하는 것이 중요하다는 점을 다시 확인했다.

웨이브 시스템에서는 웨이브가 끝났을 때 남아있는 악몽을 기준으로 침대 Stress를 증가시키고 HUD의 악몽 수를 초기화하는 기능까지 연결했다.

TIL-2nd. 팀프로젝트 DreamProtector (8/21)WaveManager 웨이브 종료 처리 및 4차 분반수업 내용 정리

view29579 — Thu, 17 Sep 2026 20:16:23 +0900

오늘은 기존에 구현해둔 WaveManager에 웨이브 종료 시 남아있는 악몽을 침대에 데미지로 반영하고, HUD의 악몽 수를 초기화하는 기능을 추가했다.

기존 웨이브 시스템은 CurrentMonsterCount와 KilledMonsterCount를 이용해서 현재 웨이브의 남은 악몽 수를 계산하고 있었다.

const int32 RemainingCount =
    FMath::Max(CurrentMonsterCount - KilledMonsterCount, 0);

RemainingCount를 계산한 이유

현재 웨이브의 전체 악몽 수에서 처치한 악몽 수를 빼면 남아있는 악몽 수를 알 수 있다.

전체 악몽 수 - 처치한 악몽 수 = 남은 악몽 수

예를 들어 45마리가 스폰되고 30마리를 처치했다면:

45 - 30 = 15

따라서 남은 악몽은 15마리이다.

여기서 FMath::Max()를 사용한 이유는 계산 결과가 음수가 되는 것을 방지하기 위해서이다.

FMath::Max(CurrentMonsterCount - KilledMonsterCount, 0);

결과가 0보다 작아지더라도 최소값을 0으로 유지한다.

2. 웨이브 종료 시 침대에 Stress 적용

웨이브 제한시간이 끝났을 때 호출되는 함수인 OnWaveTimeExpired()에서 남은 악몽 수를 확인하도록 했다.

const int32 RemainingCount =
    FMath::Max(CurrentMonsterCount - KilledMonsterCount, 0);

그리고 남아있는 악몽 1마리당 침대 Stress를 10 증가시키도록 했다.

if (Bed && RemainingCount > 0)
{
    Bed->IncreaseStress(RemainingCount * 10);
}

RemainingCount * 10을 사용하는 이유

기획상 웨이브가 종료되었을 때 살아남은 악몽이 침대를 공격하는 것으로 처리하기 위해서이다.

악몽 1마리당 Stress 10이므로:

남은 악몽 1마리 → Stress +10
남은 악몽 5마리 → Stress +50
남은 악몽 10마리 → Stress +100

따라서 남은 악몽 수에 10을 곱해서 한 번에 침대에 전달했다.

3. Bed->IncreaseStress()를 사용한 이유

침대에는 이미 IncreaseStress() 함수가 구현되어 있었다.

void ABed::IncreaseStress(int32 Amount)
{
    CurrentStress += Amount;

    CurrentStress =
        FMath::Clamp(CurrentStress, 0, MaxStress);

    OnStressChganged.Broadcast(
        CurrentStress,
        MaxStress
    );

    OnBedAttacked.Broadcast();
}

WaveManager에서 침대의 Stress 값을 직접 변경하지 않고 기존 함수를 호출했다.

Bed->IncreaseStress(RemainingCount * 10);

이렇게 한 이유는 침대의 Stress 처리를 Bed 클래스가 담당하도록 하기 위해서이다.

WaveManager가 직접:

Bed->CurrentStress += ...

처럼 처리하게 되면 WaveManager가 침대 내부의 Stress 시스템까지 알아야 한다.

반면 IncreaseStress()를 사용하면 WaveManager는

"침대의 Stress를 이만큼 증가시켜줘."

라고 요청만 하면 된다.

실제 Stress 증가, 최대값 제한, HUD 알림, 침대 공격 알림은 ABed가 담당한다.

즉 역할을 나누었다.

WaveManager
→ 남은 악몽 수 계산
→ 침대에 증가량 전달

Bed
→ Stress 증가
→ 최대 Stress 제한
→ Stress 변경 알림
→ 침대 공격 알림

4. if 방어 코드를 추가한 이유

침대 객체가 연결되지 않은 상태에서 바로:

Bed->IncreaseStress(...);

를 호출하면 문제가 발생할 수 있다.

그래서 다음과 같이 방어 코드를 작성했다.

if (Bed && RemainingCount > 0)
{
    Bed->IncreaseStress(RemainingCount * 10);
}

여기서 두 가지를 확인한다.

Bed
→ 침대 객체가 존재하는가?

RemainingCount > 0
→ 실제로 남아있는 악몽이 있는가?

둘 다 만족할 때만 침대 Stress를 증가시킨다.

이번 작업을 통해 C++에서 객체를 사용하기 전에 유효한지 확인하는 방어 코드가 중요하다는 것도 다시 확인했다.

5. 웨이브 종료 후 HUD 악몽 수 초기화

기존에는 웨이브가 끝나도 HUD에 이전 웨이브의 숫자가 남아있었다.

예를 들어:

15 / 45

상태에서 웨이브가 종료되어 대기시간으로 들어가도 숫자가 그대로 표시될 수 있었다.

그래서 웨이브 종료 시:

OnMonsterCountChanged.Broadcast(
    0,
    0
);

을 호출하도록 했다.

Broadcast()를 사용한 이유

OnMonsterCountChanged는 몬스터 수가 변경되었을 때 HUD 등 다른 시스템에 알려주는 Delegate이다.

따라서 WaveManager가 HUD를 직접 찾아서 텍스트를 변경하는 대신:

WaveManager
    ↓
OnMonsterCountChanged.Broadcast()
    ↓
HUD
    ↓
악몽 숫자 변경

방식으로 연결했다.

웨이브 종료 시 0, 0을 전달하면 대기시간 동안:

00 / 00

으로 표시할 수 있다.

여기서 두 번째 값까지 0으로 전달한 이유는 단순히 남은 악몽 수만 0으로 만드는 것이 아니라 대기시간 동안 전체 악몽 수도 표시하지 않도록 하기 위해서이다.

6. 전체 흐름

최종적으로 웨이브 제한시간이 끝나면 다음 순서로 처리된다.

OnWaveTimeExpired()
        ↓
현재 웨이브의 전체 악몽 수 확인
        ↓
처치한 악몽 수 확인
        ↓
RemainingCount 계산
        ↓
남은 악몽 × 10
        ↓
Bed->IncreaseStress()
        ↓
침대 Stress 증가
        ↓
OnMonsterCountChanged.Broadcast(0, 0)
        ↓
HUD → 00 / 00
        ↓
대기시간
        ↓
다음 웨이브 시작
        ↓
새로운 몬스터 수 표시

예를 들어 Stage 2에서 45마리가 등장하고 32마리를 처치한 상태로 웨이브가 끝났다면:

45 - 32 = 13마리 생존

13 × 10 = Stress +130

HUD → 00 / 00

침대의 MaxStress가 100이므로 실제 Stress는 ABed::IncreaseStress() 내부의 FMath::Clamp()에 의해 최대 100까지만 증가한다.

7. 이번 작업에서 중요했던 점

이번 작업에서는 새로운 시스템을 크게 만드는 것보다 기존에 만들어둔 시스템을 연결하는 방식으로 구현했다.

WaveManager
→ 웨이브와 몬스터 수 관리

Bed
→ Stress 관리

HUD
→ Delegate를 통해 몬스터 수 표시

각 클래스가 자신의 역할을 담당하도록 유지하면서 필요한 부분만 연결했다.

특히 WaveManager에서 침대의 Stress 내부 값을 직접 수정하지 않고 IncreaseStress()를 호출한 것이 중요한 부분이었다.

TIL-2nd. 팀프로젝트 DreamProtector (7/21) SpawnVolume / WaveManager 수

view29579 — Tue, 15 Sep 2026 20:55:41 +0900

1. SpawnVolume과 WaveManager의 역할 확인

현재 프로젝트에서는 ASpawnVolume이 몬스터를 직접 생성하는 것이 아니라, 스폰 영역 안의 랜덤한 위치를 반환하는 역할을 담당하고 있다.

FVector ASpawnVolume::GetRandomSpawnLocation() const
{
    const FVector Origin = SpawnBox->GetComponentLocation();
    const FVector Extent = SpawnBox->GetScaledBoxExtent();

    return Origin + FVector(
        FMath::FRandRange(-Extent.X, Extent.X),
        FMath::FRandRange(-Extent.Y, Extent.Y),
        FMath::FRandRange(-Extent.Z, Extent.Z)
    );
}

실제 몬스터 생성은 AWaveManager::SpawnCurrentWave()에서 담당하고 있다.

const FVector SpawnLocation = SpawnVolume->GetRandomSpawnLocation();

GetWorld()->SpawnActor<AActor>(
    MonsterData.MonsterClass,
    SpawnLocation,
    FRotator::ZeroRotator
);

따라서 스폰되는 몬스터의 개별 이동속도를 설정하는 기능은 SpawnVolume보다 WaveManager에서 처리하는 것이 적절하다.

2. 같은 종류의 몬스터도 개체마다 다른 이동속도 적용

하나의 몬스터 BP를 여러 번 스폰하면서 각각 다른 이동속도를 적용하기로 했다.

예를 들어 같은 BP_Melee를 스폰하더라도:

Melee 1 → 215
Melee 2 → 387
Melee 3 → 452
Melee 4 → 301

처럼 개체마다 다른 이동속도를 가질 수 있도록 구현했다.

기존에는:

GetWorld()->SpawnActor<AActor>(
    MonsterData.MonsterClass,
    SpawnLocation,
    FRotator::ZeroRotator
);

형태로 생성했지만, 생성된 몬스터를 ABaseMonster*로 받아서 속도를 설정하도록 변경했다.

ABaseMonster* SpawnedMonster = GetWorld()->SpawnActor<ABaseMonster>(
    MonsterData.MonsterClass,
    SpawnLocation,
    FRotator::ZeroRotator
);

그리고 ABaseMonster에 이동속도를 변경하는 함수를 추가했다.

BaseMonster.h

void SetMoveSpeed(float NewSpeed);

BaseMonster.cpp

void ABaseMonster::SetMoveSpeed(float NewSpeed)
{
    MoveSpeed = NewSpeed;

    if (GetCharacterMovement())
    {
        GetCharacterMovement()->MaxWalkSpeed = MoveSpeed;
    }
}

이후 WaveManager에서 스폰될 때마다 랜덤한 속도를 적용했다.

if (SpawnedMonster)
{
    SpawnedMonster->SetMoveSpeed(
        FMath::FRandRange(200.0f, 500.0f)
    );
}

이를 통해 같은 몬스터 클래스라도 생성된 각각의 몬스터가 200~500 사이의 랜덤한 이동속도를 가지도록 했다.

3. MoveSpeed와 MaxWalkSpeed의 차이 확인

처음에는 MoveSpeed 값을 랜덤하게 변경했는데도 실제 몬스터의 이동속도가 변하지 않는 문제가 발생했다.

ABaseMonster의 생성자에서는 기본 이동속도를 다음과 같이 설정하고 있었다.

MoveSpeed = 300.0f;

또한 BeginPlay()에서 MoveSpeed를 실제 캐릭터 이동속도에 적용하고 있었다.

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

    CurrentHealth = MaxHealth;

    if (GetCharacterMovement())
    {
        GetCharacterMovement()->MaxWalkSpeed = MoveSpeed;
    }
}

문제는 실행 순서였다.

몬스터 생성
↓
생성자에서 MoveSpeed = 300
↓
BeginPlay()
↓
MaxWalkSpeed = 300
↓
WaveManager에서 MoveSpeed를 랜덤값으로 변경

따라서 WaveManager에서 MoveSpeed만 변경하면 CharacterMovementComponent의 MaxWalkSpeed는 이미 300으로 설정된 상태였다.

이 문제를 해결하기 위해 SetMoveSpeed()에서 스탯 변수와 실제 이동속도를 동시에 변경하도록 했다.

void ABaseMonster::SetMoveSpeed(float NewSpeed)
{
    MoveSpeed = NewSpeed;

    if (GetCharacterMovement())
    {
        GetCharacterMovement()->MaxWalkSpeed = MoveSpeed;
    }
}

이를 통해 스폰 이후 변경된 랜덤 속도가 실제 이동속도에도 적용되도록 했다.

4. 랜덤 이동속도 적용 여부 디버깅

실제로 랜덤값이 적용되고 있는지 확인하기 위해 로그를 추가했다.

UE_LOG(
    LogTemp,
    Warning,
    TEXT("AFTER RANDOM Speed: %f"),
    SpawnedMonster->MoveSpeed
);

처음에는 300만 출력되는 것으로 확인하여 원인을 추적했지만, 이후 확인 결과 실제로는 랜덤한 값이 정상적으로 들어가고 있는 것을 확인했다.

따라서 문제의 원인은 랜덤값 생성이나 WaveManager의 스폰 로직이 아니라, MoveSpeed가 실제 이동 시스템의 MaxWalkSpeed에 적용되는 시점에 있었다.

5. WaveManager의 웨이브 스폰 구조 확인

현재 WaveManager는 DataTable의 FWaveData를 이용해 웨이브 정보를 관리한다.

FWaveMonsterData에서는:

UPROPERTY(EditAnywhere, BlueprintReadWrite)
TSubclassOf<AActor> MonsterClass;

UPROPERTY(EditAnywhere, BlueprintReadWrite)
int32 SpawnCount = 0;

를 통해 몬스터 클래스와 스폰 개수를 관리한다.

그리고 SpawnCurrentWave()에서:

for (const FWaveMonsterData& MonsterData : WaveData->Monsters)

를 통해 웨이브에 등록된 몬스터 종류를 확인하고,

for (int32 i = 0; i < MonsterData.SpawnCount; ++i)

를 통해 설정된 개수만큼 반복해서 스폰한다.

또한:

ASpawnVolume* SpawnVolume =
    SpawnVolumes[i % WaveData->SpawnVolumeCount];

를 사용해 여러 SpawnVolume에 몬스터를 분배하고 있다.

이를 통해 현재 프로젝트의 DataTable → WaveManager → SpawnVolume → Monster 구조를 다시 확인할 수 있었다.

Git 작업

6. GitHub Push 시 대용량 파일 오류 발생

GitHub에 Push하는 과정에서 다음 오류가 발생했다.

The push operation includes a file which exceeds GitHub's file size restriction of 100MB.

원인을 확인한 결과, 배포받은 약 8GB 크기의 압축파일을 프로젝트 폴더에 삭제하지 않은 상태에서 Git 작업을 진행한 것이 원인이었다.

GitHub에는 일반 Git 저장소에서 개별 파일을 업로드할 때 100MB 제한이 있기 때문에 프로젝트에 불필요한 대용량 압축파일이 포함되지 않도록 주의해야 한다.

7. Git lock 파일 오류 확인

이후 다음 오류도 발생했다.

A lock file already exists in the repository, which blocks this operation from completing.

Git 작업 중 생성된 .git/index.lock 파일을 확인하고 삭제했다.

이 과정에서 대용량 파일 문제와 Git lock 문제는 서로 다른 문제라는 것도 확인했다.

오늘 배운 점

SpawnVolume은 스폰 위치를 제공하고, 실제 몬스터 생성은 WaveManager에서 담당한다.
같은 몬스터 BP를 사용해도 생성된 개체마다 다른 스탯을 적용할 수 있다.
MoveSpeed 같은 스탯 변수와 실제 이동에 사용되는 MaxWalkSpeed는 별개의 값이다.
BeginPlay()에서 MoveSpeed를 MaxWalkSpeed에 적용한 뒤 MoveSpeed만 변경하면 실제 이동속도에는 반영되지 않을 수 있다.
따라서 스폰 이후 이동속도를 변경할 때는 MoveSpeed와 MaxWalkSpeed를 함께 변경해야 한다.
SetMoveSpeed() 같은 함수를 만들어 스탯 변경과 실제 시스템 적용을 한 번에 처리하는 방법을 익혔다.
DataTable을 이용한 웨이브 구조에서 몬스터 종류와 스폰 개수를 관리하고, 실제 개체별 추가 설정은 SpawnCurrentWave()에서 처리할 수 있다.
GitHub에 Push하기 전에 프로젝트 폴더에 대용량 압축파일이나 불필요한 파일이 포함되어 있지 않은지 확인해야 한다.
Git의 index.lock은 Git 작업을 막을 수 있는 잠금 파일이며, Git 프로세스가 종료된 것을 확인한 후 제거할 수 있다.

TIL-2nd. 팀프로젝트 DreamProtector (6/21) WaveManager / SpawnVolume 웨이브 시스템 구현

view29579 — Mon, 14 Sep 2026 19:52:54 +0900

1. 오늘 구현한 것

오늘은 WaveManager를 중심으로 게임의 웨이브 시스템 기본 구조를 구현했다.

구현한 기능은 다음과 같다.

SpawnVolume 구현
WaveData 구조체 구현
DataTable을 이용한 웨이브 데이터 관리
현재 웨이브 데이터 가져오기
웨이브별 몬스터 수 계산
몬스터 스폰
SpawnVolume을 이용한 랜덤 스폰 위치 지정
튜토리얼 30초 대기
Wave별 제한시간 설정
웨이브 종료 후 45초 대기
다음 웨이브 자동 시작
최대 웨이브 이후 더 이상 웨이브가 진행되지 않도록 처리
빌드 오류 트러블슈팅

현재 기획은 다음과 같다.

구분몬스터 수SpawnVolume제한시간

Wave 1	30마리	2개	60초
Wave 2	45마리	3개	90초
Wave 3	60마리	4개	90초

튜토리얼은 30초이며, 웨이브 사이에는 45초의 대기시간을 둔다.

2. SpawnVolume

SpawnVolume의 역할

SpawnVolume은 몬스터를 실제로 관리하는 객체가 아니라, 몬스터가 스폰될 수 있는 위치를 제공하는 역할을 한다.

즉,

SpawnVolume
→ "이 영역 안에서 랜덤한 위치 하나 줘"

라고 요청하면 랜덤한 위치를 반환한다.

실제 어떤 몬스터를 몇 마리 스폰할지는 WaveManager가 담당한다.

SpawnVolume 생성자

ASpawnVolume::ASpawnVolume()
{
    // 스폰 영역 박스 컴포 생성
    SpawnBox = CreateDefaultSubobject<UBoxComponent>(TEXT("SpawnBox"));

    // 스폰볼륨 액터의 루트컴포를 스폰박스로 지정
    RootComponent = SpawnBox;
}

코드 의미

CreateDefaultSubobject<UBoxComponent>

를 이용해 BoxComponent를 생성한다.

이 박스가 실제로 몬스터가 랜덤하게 생성될 영역이 된다.

그리고

RootComponent = SpawnBox;

를 통해 생성한 BoxComponent를 SpawnVolume Actor의 RootComponent로 지정한다.

따라서 레벨에 BP_SpawnVolume을 배치하면 Box의 크기를 조절하여 스폰 영역을 지정할 수 있다.

3. 랜덤 스폰 위치 만들기

FVector ASpawnVolume::GetRandomSpawnLocation() const
{
    // SpawnBox의 월드 위치를 가져온다.
    const FVector Origin = SpawnBox->GetComponentLocation();

    // SpawnBox의 실제 월드 크기(절반)를 가져온다.
    const FVector Extent = SpawnBox->GetScaledBoxExtent();

    // Box 범위 안에서 X, Y, Z가 각각 랜덤인 위치를 반환한다.
    return Origin + FVector(
        FMath::FRandRange(-Extent.X, Extent.X),
        FMath::FRandRange(-Extent.Y, Extent.Y),
        FMath::FRandRange(-Extent.Z, Extent.Z)
    );
}

코드 의미

먼저 SpawnBox의 중심 위치를 가져온다.

const FVector Origin = SpawnBox->GetComponentLocation();

그리고 Box의 크기를 가져온다.

const FVector Extent = SpawnBox->GetScaledBoxExtent();

Extent는 박스 전체 크기가 아니라 중심에서 각 방향으로 얼마나 떨어져 있는지를 나타낸다.

예를 들어 X 방향 범위가 -500 ~ +500이라면:

FMath::FRandRange(-Extent.X, Extent.X)

를 이용해 그 사이의 랜덤한 값을 만든다.

X, Y, Z 각각에 랜덤값을 적용하기 때문에 최종적으로 SpawnBox 내부의 랜덤한 위치를 반환한다.

4. WaveManager의 웨이브 데이터 구조

웨이브마다 필요한 정보를 DataTable에서 관리하기 위해 두 개의 구조체를 만들었다.

FWaveMonsterData

USTRUCT(BlueprintType)
struct FWaveMonsterData
{
    GENERATED_BODY()

    // 스폰할 몬스터 클래스
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    TSubclassOf<AActor> MonsterClass;

    // 해당 몬스터를 몇 마리 스폰할지
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    int32 SpawnCount = 0;
};

의미

하나의 몬스터 종류에 대한 정보를 담는다.

예를 들어:

MonsterClass = BP_Suicide
SpawnCount = 30

이라고 설정하면

BP_Suicide를 30마리 스폰한다.

는 의미가 된다.

5. FWaveData

USTRUCT(BlueprintType)
struct FWaveData : public FTableRowBase
{
    GENERATED_BODY()

    // 해당 웨이브에서 사용할 몬스터 목록
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    TArray<FWaveMonsterData> Monsters;

    // 해당 웨이브에서 사용할 스폰볼륨 개수
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    int32 SpawnVolumeCount = 0;

    // 해당 웨이브의 제한시간(초)
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    float WaveTimeLimit = 60.0f;
};

의미

FWaveData는 하나의 웨이브 전체에 대한 정보를 담는다.

즉 한 행이 하나의 웨이브가 된다.

예:

Wave1
 ├─ Monsters
 │   └─ BP_Suicide / 30
 ├─ SpawnVolumeCount = 2
 └─ WaveTimeLimit = 60

DataTable에서 이 데이터를 관리할 수 있도록

public FTableRowBase

를 상속했다.

6. WaveManager 변수

현재 WaveManager에서는 다음과 같은 변수를 사용한다.

// 현재 진행 중인 웨이브 번호
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Wave")
int32 CurrentWave = 1;

현재 몇 번째 웨이브인지 저장한다.

처음에는 1이므로 Wave 1부터 시작한다.

// 전체 웨이브 개수
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Wave")
int32 MaxWave = 3;

전체 웨이브의 개수를 나타낸다.

현재 프로젝트에서는 총 3웨이브이므로 3이다.

// 현재 웨이브에서 아직 처리해야 할 몬스터 수
// 웨이브 시작 시 해당 웨이브의 몬스터 수를 넣어줌
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Wave")
int32 CurrentMonsterCount = 0;

현재 웨이브의 몬스터 수를 관리하기 위한 변수이다.

현재는 웨이브 시스템 기본 구현 단계이며, 이후 몬스터 사망 처리와 연결할 예정이다.

7. SpawnVolume 배열

// 웨이브에서 사용할 스폰볼륨 목록
// 레벨에 배치된 스폰볼륨들을 웨이브매니저가 참조
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Wave|Spawn")
TArray<TObjectPtr<class ASpawnVolume>> SpawnVolumes;

의미

레벨에 배치된 여러 개의 SpawnVolume을 WaveManager가 가지고 있는 것이다.

예를 들어:

SpawnVolumes[0] → SpawnVolume 1
SpawnVolumes[1] → SpawnVolume 2
SpawnVolumes[2] → SpawnVolume 3
SpawnVolumes[3] → SpawnVolume 4

Wave 1에서 2개만 사용한다면 앞의 2개를 사용하고,

Wave 3에서는 4개를 사용하도록 구성했다.

8. WaveDataTable

// 웨이브 정보를 담고 있는 데이터테이블
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Wave|Data")
TObjectPtr<UDataTable> WaveDataTable;

의미

DT_WaveData를 WaveManager가 참조하기 위한 변수이다.

실제 웨이브의 몬스터 수나 제한시간을 코드에 직접 적지 않고 DataTable에서 관리할 수 있게 했다.

9. 현재 웨이브 데이터 가져오기

const FWaveData* AWaveManager::GetCurrentWaveData() const
{
    // 현재 웨이브 번호를 DataTable의 Row 이름으로 만든다.
    // 예: CurrentWave = 1 → "Wave1"
    const FName RowName = FName(*FString::Printf(TEXT("Wave%d"), CurrentWave));

    // DataTable에서 해당 Row를 찾아 반환한다.
    return WaveDataTable->FindRow<FWaveData>(RowName, TEXT("GetCurrentWaveData"));
}

동작 과정

현재 웨이브가 1이라면:

CurrentWave = 1

이 값을 이용해

Wave1

이라는 Row 이름을 만든다.

그리고 DataTable에서 해당 Row를 찾는다.

즉:

CurrentWave = 1
        ↓
"Wave1"
        ↓
DT_WaveData에서 Wave1 검색
        ↓
Wave1 데이터 반환

Wave 2라면 "Wave2", Wave 3이라면 "Wave3"가 된다.

10. 현재 웨이브 몬스터 수 계산

void AWaveManager::UpdateCurrentMonsterCount()
{
    // 현재 웨이브의 데이터를 가져온다.
    const FWaveData* WaveData = GetCurrentWaveData();

    // 웨이브 데이터가 없으면 종료
    if (!WaveData)
    {
        return;
    }

    // 현재 웨이브의 몬스터 수를 0부터 다시 계산
    CurrentMonsterCount = 0;

    // 몬스터 종류별 SpawnCount를 모두 더한다.
    for (const FWaveMonsterData& MonsterData : WaveData->Monsters)
    {
        CurrentMonsterCount += MonsterData.SpawnCount;
    }
}

의미

DataTable에 몬스터 종류가 여러 개 들어갈 수 있기 때문에 Monsters 배열을 순회한다.

예를 들어:

Melee      20
Suicide    10
Ranged     15

라면:

20 + 10 + 15 = 45

가 되어 CurrentMonsterCount는 45가 된다.

현재 프로젝트에서는 한 웨이브에 BP_Suicide만 넣었기 때문에:

Wave 1 → 30
Wave 2 → 45
Wave 3 → 60

이 된다.

11. 몬스터 스폰

void AWaveManager::SpawnCurrentWave()
{
    // 현재 웨이브 데이터를 가져온다.
    const FWaveData* WaveData = GetCurrentWaveData();

    // 웨이브 데이터가 없으면 종료
    if (!WaveData)
    {
        return;
    }

    // 현재 웨이브의 몬스터 종류를 하나씩 확인한다.
    for (const FWaveMonsterData& MonsterData : WaveData->Monsters)
    {
        // 몬스터 클래스가 지정되지 않았으면 건너뛴다.
        if (!MonsterData.MonsterClass)
        {
            continue;
        }

        // 설정된 몬스터 수만큼 반복해서 스폰한다.
        for (int32 i = 0; i < MonsterData.SpawnCount; ++i)
        {
            // 사용할 SpawnVolume이 없으면 종료
            if (SpawnVolumes.Num() == 0)
            {
                return;
            }

            // 현재 웨이브에서 사용할 SpawnVolume에 몬스터를 골고루 분배한다.
            ASpawnVolume* SpawnVolume =
                SpawnVolumes[i % WaveData->SpawnVolumeCount];

            // SpawnVolume이 없으면 해당 스폰을 건너뛴다.
            if (!SpawnVolume)
            {
                continue;
            }

            // SpawnVolume에서 랜덤한 스폰 위치를 가져온다.
            const FVector SpawnLocation =
                SpawnVolume->GetRandomSpawnLocation();

            // 몬스터를 스폰한다.
            GetWorld()->SpawnActor<AActor>(
                MonsterData.MonsterClass,
                SpawnLocation,
                FRotator::ZeroRotator
            );
        }
    }
}

핵심 구조

먼저 현재 웨이브 데이터를 가져온다.

const FWaveData* WaveData = GetCurrentWaveData();

그 다음 웨이브에 등록된 몬스터 종류를 확인한다.

for (const FWaveMonsterData& MonsterData : WaveData->Monsters)

그리고 SpawnCount만큼 반복하여 몬스터를 생성한다.

for (int32 i = 0; i < MonsterData.SpawnCount; ++i)

SpawnVolume 분배

SpawnVolumes[i % WaveData->SpawnVolumeCount]

여기서는 % 연산을 사용했다.

예를 들어 SpawnVolume이 2개이고 몬스터가 6마리라면:

i = 0 → Volume 0
i = 1 → Volume 1
i = 2 → Volume 0
i = 3 → Volume 1
i = 4 → Volume 0
i = 5 → Volume 1

따라서 몬스터가 SpawnVolume에 순서대로 골고루 분배된다.

현재 설정에서는:

Wave 1
30마리 / 2개
→ 15마리씩

Wave 2
45마리 / 3개
→ 15마리씩

Wave 3
60마리 / 4개
→ 15마리씩

이 된다.

12. 웨이브 제한시간

void AWaveManager::StartWaveTimer()
{
    // 현재 웨이브의 데이터 가져오기
    const FWaveData* WaveData = GetCurrentWaveData();

    // 웨이브 데이터가 없으면 종료
    if (!WaveData)
    {
        return;
    }

    // 현재 웨이브의 제한시간으로 타이머 시작
    GetWorldTimerManager().SetTimer(
        WaveTimerHandle,
        this,
        &AWaveManager::OnWaveTimeExpired,
        WaveData->WaveTimeLimit,
        false
    );
}

의미

DataTable에 설정된 WaveTimeLimit을 이용해 타이머를 시작한다.

Wave 1:

WaveTimeLimit = 60

이면 60초 후

OnWaveTimeExpired()

가 호출된다.

Wave 2와 Wave 3은 각각 90초로 설정했다.

13. 튜토리얼 30초 대기

처음에는 게임이 시작되자마자 몬스터가 스폰되었지만, 기획상 튜토리얼 30초 동안은 몬스터를 스폰하지 않도록 수정했다.

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

    UE_LOG(LogTemp, Warning, TEXT("===== WaveManager BeginPlay ====="));

    UpdateCurrentMonsterCount();

    // 튜토리얼 30초 후 Wave 1 시작
    GetWorldTimerManager().SetTimer(
        TutorialTimerHandle,
        this,
        &AWaveManager::StartFirstWave,
        30.0f,
        false
    );
}

의미

게임 시작 시 BeginPlay()는 실행되지만 바로 몬스터를 스폰하지 않는다.

대신:

게임 시작
 ↓
30초 대기
 ↓
StartFirstWave()
 ↓
Wave 1 스폰

의 흐름으로 변경했다.

14. Wave 1 시작

void AWaveManager::StartFirstWave()
{
    UE_LOG(
        LogTemp,
        Warning,
        TEXT("===== WAVE 1 START =====")
    );

    // Wave 1 몬스터 스폰
    SpawnCurrentWave();

    // Wave 1 제한시간 시작
    StartWaveTimer();
}

의미

튜토리얼 30초가 끝나면 호출된다.

여기서 두 가지를 실행한다.

1. Wave 1 몬스터 스폰
2. Wave 1 제한시간 시작

실제 PIE 테스트에서

===== WaveManager BeginPlay =====
===== WAVE 1 START =====

로그가 확인되었고, 실제 몬스터가 스폰되는 것도 확인했다.

15. 웨이브 시간이 끝났을 때

void AWaveManager::OnWaveTimeExpired()
{
    UE_LOG(
        LogTemp,
        Warning,
        TEXT("===== WAVE TIME EXPIRED ===== Wave: %d"),
        CurrentWave
    );

    // 45초 후 다음 웨이브 시작
    GetWorldTimerManager().SetTimer(
        NextWaveTimerHandle,
        this,
        &AWaveManager::StartNextWave,
        45.0f,
        false
    );
}

의미

현재 웨이브의 제한시간이 끝나면 바로 다음 웨이브를 시작하지 않는다.

45초의 대기시간을 가진다.

Wave 1
 ↓
60초
 ↓
WaveTimeExpired
 ↓
45초 대기
 ↓
Wave 2

이 45초 대기는 NextWaveTimerHandle을 이용해 관리한다.

16. 다음 웨이브 시작

void AWaveManager::StartNextWave()
{
    // 다음 웨이브 번호로 변경
    CurrentWave++;

    // 최대 웨이브를 넘으면 종료
    if (CurrentWave > MaxWave)
    {
        return;
    }

    UE_LOG(
        LogTemp,
        Warning,
        TEXT("===== WAVE %d START ====="),
        CurrentWave
    );

    // 다음 웨이브 몬스터 스폰
    SpawnCurrentWave();

    // 다음 웨이브 제한시간 시작
    StartWaveTimer();
}

의미

다음 웨이브를 시작하기 전에:

CurrentWave++;

로 웨이브 번호를 증가시킨다.

예:

Wave 1 → CurrentWave = 1

다음 웨이브
→ CurrentWave = 2

그 후 현재 웨이브 번호를 이용해 DataTable에서 Wave2 데이터를 가져오고 몬스터를 스폰한다.

최대 웨이브 제한

if (CurrentWave > MaxWave)
{
    return;
}

현재 MaxWave = 3이기 때문에:

Wave 1 → 진행
Wave 2 → 진행
Wave 3 → 진행
Wave 4 → 시작하지 않음

이 조건을 통해 3웨이브 이후 더 이상 새로운 웨이브가 생성되지 않도록 했다.

17. 타이머 핸들

WaveManager에서는 세 개의 타이머를 사용한다.

// 현재 웨이브 제한시간을 관리하는 타이머
FTimerHandle WaveTimerHandle;

// 튜토리얼 종료까지 대기하는 타이머
FTimerHandle TutorialTimerHandle;

// 다음 웨이브 시작까지 대기하는 타이머
FTimerHandle NextWaveTimerHandle;

각각의 역할은 다르다.

WaveTimerHandle
→ 현재 웨이브 제한시간

TutorialTimerHandle
→ 게임 시작 후 30초 대기

NextWaveTimerHandle
→ 웨이브 종료 후 45초 대기

18. 현재까지 완성된 전체 흐름

게임 시작
   ↓
WaveManager BeginPlay
   ↓
30초 튜토리얼
   ↓
StartFirstWave()
   ↓
Wave 1
30마리 / SpawnVolume 2개 / 60초
   ↓
시간 종료
   ↓
45초 대기
   ↓
Wave 2
45마리 / SpawnVolume 3개 / 90초
   ↓
시간 종료
   ↓
45초 대기
   ↓
Wave 3
60마리 / SpawnVolume 4개 / 90초
   ↓
Wave 3 종료
   ↓
더 이상 Wave 4 생성 X

실제 PIE에서도 다음 로그를 확인했다.

===== WaveManager BeginPlay =====
===== WAVE 1 START =====
===== WAVE TIME EXPIRED ===== Wave: 1
===== WAVE 2 START =====

따라서 튜토리얼 → Wave 1 → 제한시간 → 45초 대기 → Wave 2까지 실제 동작을 확인했다.

19. 기획 변경 — 놓친 몬스터 처리

처음에는 웨이브 제한시간 안에 처치하지 못한 몬스터를 다음 웨이브에 추가하는 방식을 생각했다.

예:

Wave 1
30마리 스폰
25마리 처치
5마리 생존

↓

Wave 2
45마리 + 생존 5마리
= 50마리

하지만 기획이 변경되었다.

현재는 생존 몬스터를 다음 웨이브에 이월하지 않는다.

대신 놓친 몬스터 수를 계산하여 보호 대상의 스트레스 지수에 반영한다.

현재 예정된 수치는:

몬스터 1마리 놓침
→ 스트레스 +10

예:

30마리 중 25마리 처치
→ 5마리 놓침
→ 스트레스 +50

따라서 다음 웨이브는 항상 DataTable에 설정된 수량대로 시작한다.

Wave 1 → 30
Wave 2 → 45
Wave 3 → 60

이 기능은 몬스터의 사망 처리와 연결해야 하기 때문에 현재는 구현을 보류했다.

특히 다른 팀원이 BaseMonster를 수정하고 있는 상황이라, 머지 충돌을 피하기 위해 해당 작업은 이후 진행하기로 했다.

20. 트러블슈팅 — WeaponBase 관련 컴파일 오류

오늘 WaveManager 작업 과정에서 WeaponBase.cpp와 관련된 컴파일 오류가 발생했다.

처음에는 최근 수정한 WaveManager 코드의 문제인지 확인했지만, 실제 오류가 WeaponBase 쪽에서 발생하는 것을 확인했다.

오류 원인을 분리해서 확인하기 위해 Unity Build를 끄는 방법도 사용해 보았다.

bUseUnityBuild = false;

이렇게 설정했을 때 해당 오류가 사라지는 것을 확인했다.

이를 통해 최근 작성한 코드만 무조건 원인이라고 생각하기보다 실제 빌드 로그에서 오류가 발생한 파일과 위치를 먼저 확인해야 한다는 것을 다시 확인했다.

TIL-2nd. 팀프로젝트 DreamProtector (2/21) 업무 재분배 및 몬스터 클래스 구현

view29579 — Tue, 8 Sep 2026 20:08:24 +0900

오늘 한 일

한분이 이탈함에 따라 업무를 재조정했고, 그에 따라 몬스터 부분을 팀원분과 함께 진행하게 되었다.

우선 작업 진행 전 다이어그램으로 구조와 필요 기능을 정리해 보았다.

오늘은 몬스터의 공통 기능을 담당하는 BaseMonster를 만들고, 이를 상속받는 Suicide 몬스터의 기본 구조를 구현했다.

1. BaseMonster 클래스 구현

플레이어와 몬스터의 역할을 분리하면서, 몬스터마다 공통적으로 필요한 기능을 BaseMonster에서 관리하도록 구성했다.

ACharacter
    ↓
ABaseMonster
    ↓
각종 몬스터

BaseMonster에는 모든 몬스터가 공통적으로 사용할 수 있는 기능을 넣었다.

주요 스탯

MaxHealth : 최대 체력
CurrentHealth : 현재 체력
AttackDamage : 공격력
AttackInterval : 공격 간격
MoveSpeed : 이동 속도
Target : 공격 및 추적 대상

생성자에서 기본값을 설정하고, BeginPlay()에서 현재 체력을 최대 체력으로 초기화했다.

CurrentHealth = MaxHealth;

또한 CharacterMovementComponent의 MaxWalkSpeed에 MoveSpeed를 적용하여 몬스터의 이동 속도를 스탯과 연결했다.

2. 몬스터 공통 피격 및 사망 처리

몬스터가 데미지를 받았을 때의 공통 로직을 TakeDamage()에서 처리하도록 했다.

CurrentHealth -= DamageAmount;

if (CurrentHealth <= 0.0f)
{
    Die();
}

이미 죽은 몬스터가 다시 데미지를 받는 것을 방지하기 위해 체력이 0 이하라면 바로 반환하도록 했다.

if (CurrentHealth <= 0.0f) return;

사망 시에는 이동을 정지시키고 충돌을 비활성화한 뒤 액터를 제거하도록 했다.

GetCharacterMovement()->DisableMovement();
SetActorEnableCollision(false);
Destroy();

3. Attack을 공통 인터페이스로 분리

몬스터마다 공격 방식이 다르기 때문에 공격 자체를 BaseMonster에서 완전히 구현하지 않고 Attack()을 공통 인터페이스처럼 사용하도록 했다.

UFUNCTION(BlueprintNativeEvent, BlueprintCallable, Category = "Monster|Damage")
void Attack();

BlueprintNativeEvent를 사용하면 C++에서 기본 구현을 제공하면서 Blueprint에서도 해당 함수를 재정의할 수 있다는 점을 배웠다.

실제 C++ 구현은 _Implementation()으로 작성한다.

void ABaseMonster::Attack_Implementation()
{
    // 기본 공격 로직
}

자식 몬스터에서는 자신의 공격 방식에 맞게 Attack_Implementation()을 재정의할 수 있도록 구성했다.

4. Suicide 몬스터 생성

Suicide는 BaseMonster를 부모 클래스로 가지는 자식 몬스터로 만들었다.

ABaseMonster
    ↓
ASuicide

자폭 몬스터는 일반 몬스터와 달리 플레이어에게 접근한 뒤 폭발하는 전용 공격 방식을 사용하기 때문에, 자폭에 필요한 기능은 Suicide에서 담당하도록 했다.

5. Suicide 전용 Collision 구현

자폭 범위를 감지하기 위해 USphereComponent를 추가했다.

UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Suicide")
TObjectPtr<USphereComponent> ExplosionCollision;

생성자에서 Sphere Collision을 생성하고 Root Component에 붙였다.

ExplosionCollision = CreateDefaultSubobject<USphereComponent>(
    TEXT("ExplosionCollision")
);

ExplosionCollision->SetupAttachment(RootComponent);

자폭 범위는 Sphere 형태로 설정하고, Pawn과 Overlap이 발생하도록 Collision 설정을 짜보았다.

ExplosionCollision->SetSphereRadius(150.0f);

ExplosionCollision->SetCollisionEnabled(
    ECollisionEnabled::QueryOnly
);

ExplosionCollision->SetCollisionResponseToAllChannels(
    ECR_Ignore
);

ExplosionCollision->SetCollisionResponseToChannel(
    ECC_Pawn,
    ECR_Overlap
);

ExplosionCollision->SetGenerateOverlapEvents(true);

이를 통해 몬스터의 기본 몸체 충돌과 별개로 자폭 전용 감지 범위를 만들었다.

오늘 배운 점

1. 부모 클래스와 자식 클래스의 역할 분리

모든 몬스터가 공통으로 사용하는 기능은 BaseMonster에서 관리하고, 몬스터마다 다른 공격 방식이나 특수 기능은 자식 클래스에서 구현하는 것이 좋다는 것을 다시금 인지했다.

BaseMonster
 ├─ 체력
 ├─ 공격력
 ├─ 이동속도
 ├─ 피격
 ├─ 사망
 └─ Attack 인터페이스

Suicide
 ├─ 자폭 Collision
 └─ 자폭 공격 구현

2. Collision도 기능별로 분리할 수 있다

ACharacter에는 기본적으로 Capsule Collision이 존재하지만, 특정 기능을 위한 별도의 Collision Component를 추가할 수 있다는 것을 배웠다.

이번에는 몸체 충돌과 자폭 감지 범위를 분리했다.

3. C++과 Blueprint의 역할 분담

이번 구조에서는 C++에서 컴포넌트와 기본적인 구조를 만들고, 이후 Blueprint에서 BeginOverlap 이벤트를 이용해 실제 폭발 연출 및 게임플레이 로직을 연결하는 방식으로 진행한다.

즉,

C++
 ↓
ExplosionCollision 생성
 ↓
Blueprint
 ↓
BeginOverlap
 ↓
폭발 처리

와 같은 구조를 사용한다.

오늘의 한 줄 정리

몬스터의 공통 기능은 BaseMonster에 모으고, 각 몬스터만의 특수한 기능은 자식 클래스에서 확장하는 구조를 만들었다.

내일 할 것

TIL-2nd. 팀프로젝트 DreamProtector (1/21) 팀 회의 내용 및 이슈 해결

view29579 — Mon, 7 Sep 2026 21:06:23 +0900

1. 오늘 작업 내용

이번 팀 프로젝트의 전체 게임 기획을 정리하고, 내가 담당하게 된 Map / Spawn / WaveManager 파트의 구현 방향을 구체화했다.

게임의 전체적인 컨셉은 **「Dream Protector」**이다.

아이가 잠든 밤, 장난감이 깨어나 아이의 꿈을 지키고 악몽을 해결하는 게임.

현실에 나타난 악몽으로부터 아이를 보호하고, 이후 꿈속으로 직접 들어가 악몽의 근원을 제거하는 싱글 플레이 TPS PVE 게임을 목표로 한다.

2. 게임의 핵심 컨셉

게임은 크게 두 가지 플레이 경험으로 구성된다.

Stage 1 — 아이의 방

아이를 악몽으로부터 보호하는 디펜스 플레이

아이의 침대 주변을 방어
여러 방향에서 악몽이 등장
웨이브가 진행될수록 SpawnVolume이 증가
등장하는 몬스터의 종류와 수가 증가
플레이어의 행동에 따라 아이의 Stress가 감소

즉, 단순히 몬스터를 많이 잡는 것이 아니라 아이를 보호하면서 전장을 관리하는 플레이를 목표로 한다.

Stage 2 — 꿈속 / 장난감의 성

악몽의 근원을 직접 찾아 제거하는 섬멸전

꿈속으로 진입
웨이브 단위로 몬스터와 전투
웨이브가 진행될수록 몬스터 종류와 스폰량 증가
마지막 웨이브에서는 보스전 진행
플레이어가 사망하면 실패
제한 시간 안에 모든 적을 처치하면 웨이브 성공

3. 게임의 차별성

이번 프로젝트에서 생각한 차별점은 인간의 수면 주기인 REM 수면을 게임의 진행 구조에 활용하는 것이다.

단순히 계속 전투가 이어지는 방식이 아니라,

REM 수면 → 악몽 출현 → 전투 → 비 REM 상태 → 탐색 / 준비

와 같은 흐름을 만든다.

REM 수면을 악몽이 등장하는 전투 시간으로 활용하고, 전투가 아닌 시간에는

맵 탐색
아이템 루팅
제작
다음 전투 준비

등을 할 수 있도록 설계한다.

이를 통해 전투만 반복하는 구조가 아니라 전투와 준비가 반복되는 게임의 리듬을 만드는 것을 목표로 했다.

4. Stage 1 규칙

Stage 1은 아이의 방에서 진행되는 방어전이다.

아이의 침대 주변에는 일정한 거리를 기준으로 방어 구역을 설정한다.

특히 플레이어가 침대 바로 옆에서 계속 공격하는 것을 방지하기 위해,

침대 주변 일정 거리 안에서 공격하면 아이의 Stress가 증가하도록 설계

했다.

따라서 플레이어는 단순히 아이 근처에 붙어서 싸우는 것이 아니라 적의 접근을 막으면서 적절한 위치에서 전투해야 한다.

Spawn 구조

맵의 여러 방향에 SpawnVolume을 배치하고 웨이브가 진행될수록 활성화되는 SpawnVolume의 수를 증가시킨다.

예시:

Wave 1
↓
SpawnVolume 2개 활성화

Wave 2
↓
SpawnVolume 3개 활성화

Wave 3
↓
SpawnVolume 4개 활성화

또한 웨이브가 진행될수록 등장하는 몬스터의 종류도 증가시켜 난이도를 높인다.

실패 조건

아이의 Stress가 한계치에 도달하면 게임 실패

성공 조건

모든 웨이브에서 아이를 보호

5. Stage 2 규칙

Stage 2에서는 아이의 꿈속으로 들어가 악몽과 직접 전투한다.

Stage 1과 달리 플레이어의 생존 자체가 중요한 요소가 된다.

웨이브 구조

Wave 1
↓
기본 악몽 몬스터

Wave 2
↓
강화된 몬스터 + 장난감 로봇 등

Wave 3
↓
장난감 기사 + 대형 몬스터
↓
Boss Battle

웨이브마다 제한된 시간이 존재하며,

제한 시간 안에 모든 몬스터를 처치하면 웨이브 성공

으로 설계했다.

웨이브 성공 / 실패에 따른 보상과 패널티

웨이브를 성공하면 중앙 맵 양쪽의 지역 문이 해금되고, 해당 지역에서 버프 아이템을 획득할 수 있도록 한다.

반대로 웨이브 처치에 실패하면 다음 웨이브에 추가로 처치해야 할 몬스터가 증가하는 등의 디메리트를 부여한다.

웨이브 성공
    ↓
지역 해금
    ↓
버프 획득
    ↓
다음 REM 전투

웨이브 실패
    ↓
다음 웨이브 디메리트
    ↓
난이도 증가

또한 다음 REM 주기가 시작되기 전에는 다음 전투 구역으로 이동할 수 없도록 하여 플레이어의 진행 속도를 통제한다.

6. 내가 맡은 파트

팀의 전체적인 파트 분배는 다음과 같이 진행했다.

GameManager
UIManager
Character / WeaponManager
Monster / CombatManager
Map / Spawn / WaveManager ← 내가 담당
Story
ItemManager

내가 담당한 부분에서는 크게 다음 세 가지를 구현하게 된다.

Map

전투 맵 구성
Spawn 위치 구성
플레이어 이동 동선 구성
주요 전투 구역 배치

Spawn

SpawnVolume 배치
Spawn 위치 관리
몬스터 생성 위치 랜덤화
웨이브별 SpawnVolume 활성화

Wave

웨이브 시작 / 종료
웨이브별 몬스터 구성
웨이브별 Spawn 수량 관리
제한 시간 관리
웨이브 성공 / 실패 처리
다음 웨이브 진행

7. Spawn 시스템 설계

Spawn 시스템은 SpawnVolume을 중심으로 구성할 예정이다.

기본적인 흐름은 다음과 같다.

Wave 시작
    ↓
SpawnVolume 위치 선택
    ↓
랜덤 Spawn 위치 생성
    ↓
지정된 수량만큼 Enemy 생성
    ↓
모든 Enemy 처치 확인
    ↓
Wave 종료
    ↓
다음 Wave 시작

이를 위해 사용할 클래스로는 다음과 같이 생각하고 있다.

ASpawnVolume
AWaveManager
AEnemy
AIController
AI Behavior Tree

SpawnVolume은 단순히 적을 생성하는 것뿐만 아니라 어떤 위치에서 적을 생성할 것인지 관리하는 역할을 담당한다.

8. 웨이브 구성 예시

현재 기획한 기본적인 웨이브 구성은 다음과 같다.

Wave적 타입출현 위치특징

1	붉은 슬라임 / 비행형 가오리	하단 입구 → 중앙	기본 패턴, 소수
2	람머스 슬라임 / 쁘띠 뮤탈	양쪽 측면 → 중앙	중간 난이도, 더 빠른 이동속도
3	해골 사신 인형 / 대형 몬스터	성탑 + 중앙	보스급 전투, 강한 패턴

실제 수량과 타이밍은 구현 후 플레이 테스트를 진행하면서 조정할 예정이다.

따라서 처음부터 수치를 완벽하게 결정하기보다는 시스템을 먼저 구현하고 실제 플레이를 통해 밸런스를 조정하는 방향으로 생각했다.

9. 에셋 병합 과정에서 발생한 문제

오늘은 시스템 기획뿐만 아니라 팀원들이 작업한 에셋을 머지하는 과정에서도 문제를 하나 발견했다.

탄환으로 사용할 구미베어 젤리 에셋이 4개가 하나의 메쉬로 묶여 있는 상태였다.

게임에서는 각각의 젤리를 개별적으로 사용해야 했기 때문에 메쉬를 분리할 필요가 있었다.

10. 메쉬 분리 방법

언리얼 에디터에서 해당 에셋을 열고 모델링 모드를 이용해 메쉬를 분리했다.

내가 사용한 과정은 다음과 같다.

에셋 선택
↓
좌측 상단 Select Mode
↓
Modeling Mode로 변경
↓
XForm
↓
Split

그리고 Split 옵션을 다음과 같이 변경했다.

Output Type

Dynamic

Split Method

By Poly Groups

이렇게 설정한 뒤 Split을 실행하니 하나로 묶여 있던 4개의 젤리 메쉬를 각각 분리할 수 있었다.

11. 이번 작업에서 배운 점

이번 작업을 통해 단순히 에셋을 가져와 사용하는 것뿐만 아니라 가져온 에셋의 구조를 확인하고 게임에 맞게 수정하는 과정도 필요하다는 것을 알게 되었다.

특히 같은 에셋이라도

여러 개의 Mesh가 각각 존재하는 경우

와

하나의 Mesh 안에 여러 개의 오브젝트가 묶여 있는 경우

는 수정 방법이 다를 수 있다는 것을 알게 되었다.

이번에 사용한 Split → By Poly Groups 방식은 메쉬가 폴리곤 그룹 단위로 구성되어 있는 경우 분리할 수 있는 방법으로 이해했다.

따라서 앞으로 다른 에셋에서도 무조건 같은 방법이 적용된다고 생각하기보다는, 해당 에셋의 Mesh 구조와 Polygon Group 구성을 먼저 확인해야 한다.

12. 오늘의 핵심 정리

이번 작업에서 가장 크게 정리된 부분은 게임의 기획을 실제 시스템 구조로 연결하는 것이다.

처음에는

"웨이브 방식으로 몬스터가 나온다."

정도로 생각했다면, 이번에는 이를 구체적으로

Map
 ↓
SpawnVolume
 ↓
Spawn 위치
 ↓
WaveManager
 ↓
Enemy Spawn
 ↓
Enemy 처치 확인
 ↓
Wave 종료
 ↓
다음 Wave

라는 시스템 구조로 생각할 수 있게 되었다.

또한 REM 수면이라는 기획 요소도 단순한 스토리 설정으로 끝나는 것이 아니라,

REM
↓
전투
↓
웨이브 종료
↓
탐색 / 루팅 / 준비
↓
다음 REM

이라는 실제 게임 플레이 사이클로 연결할 수 있다는 점을 정리했다.

한 줄 회고

오늘은 Dream Protector의 전체 게임 구조와 내가 담당할 Map / Spawn / WaveManager의 역할을 구체화하고, 실제 에셋 작업 과정에서는 하나로 묶여 있던 메쉬를 Modeling Mode → XForm → Split → By Poly Groups를 통해 분리하는 방법을 익혔다.

Unreal C++ TIL — 3차 분반수업

view29579 — Thu, 3 Sep 2026 19:59:04 +0900

1. UPrimitiveComponent

언리얼에서 Actor를 구성하는 Component를 공부하면서 UPrimitiveComponent에 대해 배웠다.

UPrimitiveComponent는 렌더링이나 충돌 등의 물리적 기능을 가질 수 있는 Component의 기반 클래스이다.

대표적으로 우리가 자주 사용하는

UStaticMeshComponent
USkeletalMeshComponent
UBoxComponent
USphereComponent
UCapsuleComponent

등이 UPrimitiveComponent를 상속한다.

대략적인 관계는 다음과 같다.

UObject
 └─ UActorComponent
     └─ USceneComponent
         └─ UPrimitiveComponent
             └─ UStaticMeshComponent

즉, UPrimitiveComponent는 단순히 화면에 보이는 Mesh만을 의미하는 것이 아니라 충돌, 렌더링 등 물리적인 표현이 가능한 Component의 기반이라고 이해하면 된다.

2. Scene Component와 Transform

이번 수업에서 중요하게 배운 내용 중 하나가 USceneComponent이다.

USceneComponent는 Transform 정보를 가지고 있는 Component이다.

Transform에는 크게

Location → 위치
Rotation → 회전
Scale → 크기

가 있다.

즉,

USceneComponent
 └─ Location
 └─ Rotation
 └─ Scale

을 가지고 있다고 이해했다.

Actor와 Root Component

Actor에 Scene Component가 여러 개 있다면 그중 하나를 Root Component로 지정할 수 있다.

Actor
 └─ RootComponent
      ├─ Mesh
      ├─ Camera
      └─ SpringArm

Root Component는 Actor 전체 Transform의 기준이 된다.

쉽게 말하면 Actor의 좌표 기준점이라고 이해했다.

언리얼의 Actor는 Transform을 Actor가 직접 가지고 있는 것처럼 보이지만 실제로는 Root Component가 Actor의 Transform 기준을 담당한다.

3. Component Attachment

Component끼리는 서로 부모-자식 관계를 만들 수 있다.

예를 들어 플레이어에게 카메라를 붙이면

Player
 └─ Capsule (Root)
      └─ Mesh
      └─ SpringArm
           └─ Camera

같은 구조를 만들 수 있다.

여기서 중요한 점은

Attachment는 상속이 아니다.

C++의 상속과 Component Attachment는 완전히 다른 개념이다.

C++ 상속

UStaticMeshComponent
        ↓
UPrimitiveComponent
        ↓
USceneComponent

이것은 클래스와 클래스 사이의 상속 관계이다.

반면

Root
 └─ Mesh
     └─ Camera

는 Component 사이의 부모-자식 관계이다.

따라서

UStaticMeshComponent → UPrimitiveComponent와
Root → Mesh는 완전히 별개의 개념이다.

이 부분은 앞으로 헷갈리지 않도록 구분해야 한다.

4. SetupAttachment와 AttachToComponent

SetupAttachment()

주로 생성자에서 Component의 부모 관계를 설정할 때 사용한다.

예를 들어

Camera->SetupAttachment(SpringArm);

이라고 하면

SpringArm
   └─ Camera

라는 부모-자식 관계를 설정한다.

즉,

Component 구조를 미리 만들어 놓는 느낌

이라고 이해했다.

AttachToComponent()

게임이 실행되는 도중에 Component의 Attachment 관계를 변경해야 한다면 AttachToComponent()를 사용할 수 있다.

예를 들어 플레이어가 무기를 교체한다면

Player
 └─ Hand
      └─ Weapon

처럼 새로운 무기를 손에 붙이는 작업에 사용할 수 있다.

정리하면

SetupAttachment()
→ 주로 생성자에서 초기 Attachment 설정

AttachToComponent()
→ 게임 실행 중 Attachment 변경

공식 문서에서도 이 용도로 구분해서 설명한다.

5. Movement Component

언리얼에서는 Actor의 이동이나 특정 움직임을 담당하는 Movement Component가 존재한다.

대표적으로

UCharacterMovementComponent

ACharacter의 이동을 담당한다.

걷기, 달리기, 점프, 중력 등의 캐릭터 이동과 관련된 기능을 처리한다.

Character
   ↓
CharacterMovementComponent
   ↓
이동 / 점프 / 중력 / 속도 등

URotatingMovementComponent

Actor를 지속적으로 회전시키는 Component이다.

예를 들어

아이템
  ↓
계속 빙글빙글 회전

같은 효과를 코드로 직접 매 프레임 회전시키지 않고 Movement Component를 이용해서 구현할 수 있다.

즉 Movement Component는 단순히 "캐릭터만 움직이는 것"이 아니라 Actor의 특정 움직임을 담당하는 Component라고 이해했다.

6. 전방 선언(Forward Declaration)

이번 수업에서 전방 선언도 배웠다.

예를 들어 헤더에서 어떤 클래스의 포인터나 참조만 사용하고 있다면 굳이 해당 클래스의 전체 헤더를 포함하지 않고

class UCameraComponent;

처럼 이름만 미리 알려줄 수 있다.

이것이 전방 선언이다.

그리고 실제 구현이 필요한 .cpp에서

#include "Camera/CameraComponent.h"

를 포함한다.

왜 사용하는가?

헤더 파일의 의존성을 줄이기 위해서이다.

특히 .h 파일은 다른 여러 .cpp에서 포함될 수 있다.

따라서 헤더에 불필요한 #include가 많아질수록

A.h
 ↓
B.h
 ↓
C.h
 ↓
D.h

처럼 의존성이 계속 늘어날 수 있다.

그래서 가능한 경우

// .h
class UCameraComponent;

// .cpp
#include "Camera/CameraComponent.h"

처럼 분리한다.

7. IWYU

언리얼 엔진은 IWYU(Include What You Use) 방식의 헤더 관리를 사용한다.

뜻 그대로

내가 사용하는 것에 필요한 헤더만 Include하자.

라는 개념이다.

따라서 무작정

#include "Everything.h"

식으로 가져오는 것이 아니라 해당 파일에서 실제로 필요한 헤더만 포함하는 습관이 중요하다.

8. 전방 선언을 사용할 수 있는 경우

여기가 아직 가장 헷갈리는 부분이다.

전방 선언이 가능한 경우

해당 타입의 이름만 알면 되는 경우.

대표적으로 포인터나 레퍼런스.

class UCameraComponent;

UCameraComponent* Camera;

이런 경우에는 클래스의 내부 구조까지 알 필요가 없기 때문에 전방 선언이 가능하다.

전방 선언이 안 되는 경우

클래스 자체의 실제 내용이 필요한 경우.

예를 들어 상속받는 경우

class AMyCharacter : public ACharacter

ACharacter가 실제로 어떤 클래스인지 알아야 하기 때문에 해당 헤더가 필요하다.

또한 클래스의 멤버를 직접 사용하거나 객체의 크기 등을 알아야 하는 상황에서는 완전한 정의가 필요하다.

그래서 아직은 다음 정도만 기억하기로 했다.

포인터/레퍼런스로 이름만 필요 → 전방 선언 고려
상속하거나 내부 내용을 실제로 사용 → 헤더 Include 필요

9. Spring Arm

USpringArmComponent도 배웠다.

Spring Arm은 자식 Component를 일정 거리만큼 떨어뜨려 유지하는 Component이다.

대표적인 사용 방법이 3인칭 카메라이다.

Player
 └─ SpringArm
      └─ Camera

Spring Arm의 길이를 설정하면 Camera가 플레이어와 일정 거리를 유지한다.

또한 카메라와 플레이어 사이에 벽 등의 충돌이 발생하면 Spring Arm이 길이를 줄여서 카메라가 벽을 뚫고 들어가는 것을 방지할 수 있다.

다만 내가 적어둔

"FPS에서 벽 바라보면 FOV가 늘어나는 것"

은 Spring Arm의 대표적인 기능이라고 보기보다는 다른 카메라 연출과 혼동한 부분이다.

Spring Arm의 핵심은

카메라와 캐릭터 사이의 거리 유지 + 충돌 시 길이 조절

이라고 기억하는 게 정확하다.

10. Camera Component

UCameraComponent는 실제 카메라를 담당한다.

단순히 위치와 회전만 담당하는 것이 아니라 카메라의 여러 설정을 가지고 있다.

대표적으로

Location
Rotation
Field of View(FOV)
Projection 관련 설정

등이 있다.

즉,

SpringArm = 카메라를 어떻게 따라오게 할지
CameraComponent = 실제 카메라 자체

라고 생각하면 이해하기 쉬웠다.

11. Raw Pointer

이번 수업에서 가장 머리가 아팠던 부분.

UCameraComponent* Camera;

여기서 *는 포인터를 의미한다.

포인터는 쉽게 말해서

어떤 객체가 메모리의 어디에 존재하는지를 가리키는 값

이다.

따라서

UCameraComponent* Camera;

를 보면

Camera
 ↓
UCameraComponent 객체가 있는 메모리 주소

라고 이해하면 된다.

T*의 의미

T* Pointer;

여기서 T는 특정한 하나의 자료형을 의미하는 게 아니라 타입을 대신 나타내는 표현이다.

예를 들어

int* Number;
float* Value;
UCameraComponent* Camera;

처럼 사용할 수 있다.

즉

T* 
 ↓
"어떤 타입 T를 가리키는 포인터"

라고 이해했다.

12. Raw Pointer와 Unreal UObject

일반적인 C++의 Raw Pointer는 언리얼의 UObject 시스템과는 별개이다.

예를 들어 일반 C++ 객체를

Weapon* WeaponPtr = new Weapon();

처럼 생성했다면 그 객체의 메모리 관리는 일반적인 C++ 방식으로 이루어진다.

반면 언리얼의 UObject는 Unreal의 Garbage Collection 시스템에 의해 관리된다.

그래서 단순히

UCameraComponent* Camera;

라고 포인터를 가지고 있는 것만으로는 Unreal GC가 해당 객체를 참조하고 있다는 사실을 제대로 추적하지 못할 수 있다.

그래서 Unreal에서는 UObject 계열 객체를 참조할 때 Unreal의 객체 시스템에 맞는 방식을 사용하는 것이 중요하다.

13. TObjectPtr

그래서 나온 것이

TObjectPtr<T>

이다.

예를 들어

UPROPERTY()
TObjectPtr<UCameraComponent> Camera;

처럼 사용할 수 있다.

TObjectPtr은 일반적인 C++ 스마트 포인터와 같은 개념이 아니라

Unreal의 UObject 시스템에서 UObject를 참조하기 위한 포인터 타입

이라고 이해했다.

특히 UPROPERTY()와 함께 사용하면 Unreal의 객체 시스템이 해당 참조를 추적할 수 있다.

14. Raw Pointer / TObjectPtr / Smart Pointer 구분

이번 수업에서 이것도 구분해야 했다.

Raw Pointer

T*

일반적인 C++ 포인터.

객체의 수명을 자동으로 관리해주는 스마트 포인터가 아니다.

TObjectPtr

TObjectPtr<UObject>

Unreal의 UObject 시스템에서 객체를 참조하기 위한 포인터.

TSharedPtr / TUniquePtr

TSharedPtr<T>
TUniquePtr<T>

일반적인 C++ 객체의 수명 관리에 사용하는 스마트 포인터.

따라서

Raw Pointer
→ 일반적인 C++ 포인터

TObjectPtr
→ Unreal UObject 참조

TSharedPtr / TUniquePtr
→ 일반 C++ 객체의 스마트 포인터

로 구분하면 된다.

15. Unreal에서 포인터를 사용할 때

이번 수업에서 느낀 점은

"C++ 포인터라고 다 같은 포인터가 아니다."

라는 것이다.

특히 Unreal에서는 UObject와 Garbage Collection이 있기 때문에

UObject*

를 그냥 일반 C++ 포인터처럼 생각하면 안 된다.

그래서 Unreal의 UObject를 멤버 변수로 가지고 있을 때는 상황에 따라

UPROPERTY()
TObjectPtr<...>

형태를 사용하는 것이 권장된다.

16. Unreal의 기본 방향

회전을 이해하기 전에 언리얼의 좌표축부터 확실하게 외워야 한다.

X = Forward = 앞
Y = Right   = 오른쪽
Z = Up      = 위

즉,

FVector::ForwardVector

는

(1, 0, 0)

이고,

FVector::RightVector

는

(0, 1, 0)

이다.

위쪽은

(0, 0, 1)

이다.

17. FVector와 FRotator

이번 수업에서 특히 중요하게 구분해야 하는 부분.

FVector

위치 또는 방향을 표현한다.

FVector Location;

하면 위치를 표현할 수 있고,

FVector Direction;

하면 방향을 표현할 수도 있다.

즉 FVector는

3차원 공간에서의 X/Y/Z 값

이라고 생각하면 된다.

FRotator

회전 값을 표현한다.

FRotator Rotation(0.0f, 90.0f, 0.0f);

여기서

Pitch = 상하 회전
Yaw   = 좌우 회전
Roll  = 기울기

이다.

따라서

FRotator(Pitch, Yaw, Roll)

순서로 기억한다.

18. FVector vs FRotator vs 실제 회전

이번 수업에서 가장 중요한 구분 중 하나.

FVector

어디에 있는가?
어느 방향인가?

를 표현할 수 있다.

FRotator

얼마나 회전되어 있는가?

를 표현한다.

SetActorRotation()

SetActorRotation(Rotation);

실제로 Actor의 회전을 변경한다.

즉,

FVector
→ 방향

FRotator
→ 회전값

SetActorRotation()
→ 실제 Actor 회전 적용

이라고 정리했다.

19. FRotationMatrix

FRotationMatrix는 처음 보면 굉장히 수학적으로 보여서 겁먹기 쉬운데 일단은

특정 회전을 기준으로 현재 앞/오른쪽/위 방향이 어디인지 계산해주는 도구

라고 이해하기로 했다.

예를 들어 Actor가

Yaw = 90°

만큼 회전했다면 기존의

X = 앞
Y = 오른쪽

기준이 그대로 유지되는 것이 아니라 Actor가 바라보는 방향에 맞게 새로운 방향을 계산해야 한다.

이때 FRotationMatrix 등을 이용해서 회전된 기준에서의 방향을 구할 수 있다.

20. GetUnitAxis()

회전된 기준에서 특정 축의 방향을 가져올 때 사용할 수 있다.

예를 들어

FRotationMatrix(Rotation).GetUnitAxis(EAxis::X);

라면

현재 Rotation을 기준으로 X축, 즉 Forward 방향이 어디를 가리키는지

구하는 것으로 이해했다.

마찬가지로

EAxis::Y

는 Right 방향,

EAxis::Z

는 Up 방향을 구하는 데 사용할 수 있다.

그래서 나중에 캐릭터가 바라보는 방향으로 총알을 발사하거나 이동 방향을 계산할 때 이런 코드가 등장할 수 있다.

21. 캐릭터 회전에서 자주 나오는 개념

캐릭터를 만들다 보면 다음과 같은 코드가 자주 등장한다.

FRotator
FRotationMatrix
GetControlRotation()
YawRotation
GetUnitAxis(EAxis::X)

처음에는 각각 따로 노는 것처럼 보이지만 결국

"캐릭터가 어디를 바라보고 있는가?"
        ↓
회전값(FRotator)
        ↓
회전된 방향 계산
        ↓
Forward / Right 방향(FVector)
        ↓
이동 / 공격 / 회전 등에 사용

이라는 흐름으로 연결된다.

22. 이번 수업에서 헷갈렸던 것

이번 수업에서 특히 헷갈렸던 부분은 포인터와 전방 선언이었다.

포인터

UCameraComponent* Camera;

에서 *가 단순히 이상한 기호가 아니라

UCameraComponent 객체를 직접 저장하는 것이 아니라 그 객체를 가리키는 주소를 저장한다.

는 의미라는 것을 이해했다.

그리고 Unreal에서는 UObject가 Garbage Collection의 영향을 받기 때문에 일반적인 C++ 포인터와 Unreal의 객체 참조를 구분해야 한다.

전방 선언

전방 선언은

class UCameraComponent;

처럼 클래스의 존재만 미리 알려주는 것이다.

따라서

UCameraComponent* Camera;

처럼 포인터를 선언하는 데는 사용할 수 있지만,

클래스의 내부 내용이 필요한 경우에는 실제 헤더가 필요하다.

아직 이 부분은 경험이 부족해서 "언제 전방 선언을 쓰고 언제 Include해야 하는지"를 바로 판단하는 짬은 부족하다.

앞으로 코드를 작성하면서 경험을 쌓아야 할 것 같다.

23. 오늘 배운 내용 전체 연결

오늘 배운 내용을 하나의 구조로 연결해보면 다음과 같다.

Actor
 │
 └─ Root Component
      │
      ├─ Mesh
      │
      ├─ SpringArm
      │    └─ Camera
      │
      └─ 기타 Component

Component는 USceneComponent를 기반으로 Transform을 가질 수 있고,

Location
Rotation
Scale

을 기준으로 서로 Attachment 관계를 만들 수 있다.

그리고 캐릭터의 움직임은

Movement Component

가 담당한다.

카메라를 구성할 때는

SpringArm
   ↓
Camera

구조를 사용할 수 있다.

코드에서는

FVector
→ 위치 / 방향

FRotator
→ 회전값

FRotationMatrix
→ 회전 기준의 방향 계산

SetActorRotation()
→ 실제 회전 적용

으로 연결된다.

과제 / 복습

이번 수업의 과제 및 복습 내용.

필수 복습

UPrimitiveComponent
USceneComponent
Root Component
Component Attachment
SetupAttachment()
AttachToComponent()
Movement Component
Forward Declaration
IWYU
Raw Pointer
TObjectPtr
TSharedPtr / TUniquePtr
FVector
FRotator
FRotationMatrix

실습

Player Mesh 지정
Player Camera 세팅

암기

Unreal 기본 방향

X = Forward = 앞
Y = Right   = 오른쪽
Z = Up      = 위

그리고

FVector  = 위치 / 방향
FRotator = 회전값

이 두 가지는 확실하게 익히기.

오늘의 핵심 한 줄 정리

Actor는 Component들의 집합으로 구성되고, Root Component가 Transform의 기준이 된다. Component 간 Attachment는 C++ 상속과 다른 개념이며, Unreal에서는 UObject의 생명주기와 GC를 고려해 포인터를 사용해야 한다. 또한 FVector는 위치/방향, FRotator는 회전값을 나타내며 회전된 방향을 계산할 때 FRotationMatrix 등을 활용한다.

Unreal C++ TIL — 지뢰 피하기 게임 3-4 — 캐릭터 체력 시스템 & 아이템 상호작용

view29579 — Mon, 24 Aug 2026 20:54:48 +0900

1. 캐릭터 체력 시스템

이번에는 캐릭터에게 최대 체력과 현재 체력을 만들어주었다.

Header

// 최대 체력
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Health")
float MaxHealth;

// 현재 체력
UPROPERTY(VisibleAnywhere, BlueprintReadWrite, Category = "Health")
float Health;

내가 이해한 것

MaxHealth

→ 캐릭터가 가질 수 있는 최대 체력

Health

→ 현재 캐릭터가 가지고 있는 실제 체력

예를 들어:

MaxHealth = 100
Health = 100

상태에서 데미지를 30 받으면:

MaxHealth = 100
Health = 70

이 된다.

2. 생성자에서 체력 초기화

MaxHealth = 100.0f;
Health = MaxHealth;

처음에는 최대 체력을 100으로 설정하고,

Health = MaxHealth;

현재 체력을 최대 체력과 동일하게 만들어준다.

즉:

게임 시작
 ↓
MaxHealth = 100
 ↓
Health = MaxHealth
 ↓
Health = 100

왜 Health = 100.0f라고 직접 쓰지 않고 MaxHealth를 넣었는가?

나중에 최대 체력을 변경하더라도 현재 체력을 자동으로 최대 체력에 맞출 수 있기 때문이다.

MaxHealth = 150.0f;
Health = MaxHealth;

로 바꾸면 현재 체력도 150이 된다.

3. 체력 조회 함수

UFUNCTION(BlueprintPure, Category = "Health")
int32 GetHealth() const;

현재 체력을 가져오는 함수이다.

CPP:

float AJunCharacter::GetHealth() const
{
    return Health;
}

여기서 조금 특이했던 점은 Header에서는:

int32 GetHealth() const;

로 되어 있었는데 실제 Health는:

float Health;

이다.

따라서 현재 코드에서는 반환형을 float로 맞추는 것이 더 자연스럽다.

float GetHealth() const;

그리고 CPP도:

float AJunCharacter::GetHealth() const
{
    return Health;
}

로 맞추는 게 좋다.

const를 붙이는 이유

이 함수는 현재 체력을 가져오기만 하고 캐릭터의 값을 변경하지 않기 때문이다.

GetHealth()

→ 읽기만 함

그래서:

const

를 붙인다.

4. 체력 회복 함수

UFUNCTION(BlueprintCallable, Category = "Health")
void AddHealth(float Amount);

CPP:

void AJunCharacter::AddHealth(float Amount)
{
    Health = FMath::Clamp(
        Health + Amount,
        0.0f,
        MaxHealth
    );

    UE_LOG(
        LogTemp,
        Log,
        TEXT("Health increased to: %f"),
        Health
    );
}

FMath::Clamp()가 핵심

FMath::Clamp(Health + Amount, 0.0f, MaxHealth);

의 의미는:

Health + Amount
       ↓
0보다 작으면 → 0
MaxHealth보다 크면 → MaxHealth
그 사이면 → 계산된 값

예를 들어 현재 체력이:

Health = 70

이고 회복량이:

Amount = 20

이면:

70 + 20 = 90

→ Health = 90

하지만:

Health = 90
Amount = 30

이면:

90 + 30 = 120

MaxHealth가 100이므로:

Health = 100

이 된다.

즉 체력이 최대 체력을 초과하지 않도록 방어하는 코드이다.

5. 데미지 처리 — TakeDamage()

이번에 새롭게 배운 중요한 부분.

virtual float TakeDamage(
    float DamageAmount,
    FDamageEvent const& DamageEvent,
    AController* EventInstigator,
    AActor* DamageCauser
) override;

AActor에 이미 존재하는 TakeDamage()를 오버라이드했다.

즉 외부에서:

ApplyDamage()

등을 통해 데미지가 들어오면 캐릭터가 이 함수를 통해 데미지를 처리할 수 있다.

CPP

float AJunCharacter::TakeDamage(
    float DamageAmount,
    FDamageEvent const& DamageEvent,
    AController* EventInstigator,
    AActor* DamageCauser)
{
    float ActualDamage = Super::TakeDamage(
        DamageAmount,
        DamageEvent,
        EventInstigator,
        DamageCauser
    );

    Health = FMath::Clamp(
        Health - DamageAmount,
        0.0f,
        MaxHealth
    );

    UE_LOG(
        LogTemp,
        Warning,
        TEXT("Health decreased to: %f"),
        Health
    );

    if (Health <= 0.0f)
    {
        OnDeath();
    }

    return ActualDamage;
}

흐름

외부에서 데미지 발생
        ↓
TakeDamage()
        ↓
Health - DamageAmount
        ↓
Clamp로 0~MaxHealth 제한
        ↓
Health <= 0 ?
   ↓             ↓
  YES            NO
   ↓              ↓
OnDeath()       계속 플레이

6. 사망 처리

virtual void OnDeath();

CPP:

void AJunCharacter::OnDeath()
{
    UE_LOG(
        LogTemp,
        Error,
        TEXT("Character is Dead!")
    );
}

현재는 실제 사망 처리가 아니라 로그만 출력하도록 만들었다.

Health = 0
 ↓
OnDeath()
 ↓
"Character is Dead!"

나중에는 여기에:

캐릭터 Destroy
사망 애니메이션
Game Over UI
리스폰

등을 넣을 수 있다.

7. HealingItem — 아이템이 플레이어의 체력을 회복

HealingItem에서는 아이템이 플레이어와 상호작용하도록 만들었다.

void AHealingItem::ActivateItem(AActor* Activator)
{
    if (Activator && Activator->ActorHasTag("Player"))
    {
        if (AJunCharacter* PlayerCharacter =
            Cast<AJunCharacter>(Activator))
        {
            PlayerCharacter->AddHealth(HealAmount);
        }

        DestroyItem();
    }
}

흐름

플레이어가 아이템과 충돌
        ↓
ActivateItem()
        ↓
Activator가 존재하는가?
        ↓
Player 태그가 있는가?
        ↓
JunCharacter로 Cast 가능한가?
        ↓
AddHealth()
        ↓
체력 회복
        ↓
DestroyItem()

여기서 중요한 것은 아이템이 직접 Health 변수에 접근하지 않는다는 것이다.

PlayerCharacter->AddHealth(HealAmount);

라는 함수를 호출한다.

즉:

HealingItem
     ↓
AddHealth()
     ↓
Character가 자기 Health를 변경

이 구조가 된다.

8. CoinItem — 아이템과 GameState의 상호작용

CoinItem에서는 플레이어가 코인을 획득했을 때 점수를 증가시키는 구조를 만들었다.

if (Activator && Activator->ActorHasTag("Player"))
{
    if (UWorld* World = GetWorld())
    {
        if (ASpartaGameStateBase* GameState =
            World->GetGameState<ASpartaGameStateBase>())
        {
            GameState->AddScore(PointValue);
        }
    }

    DestroyItem();
}

흐름은:

플레이어가 코인 획득
        ↓
Player 태그 확인
        ↓
World 가져오기
        ↓
GameState 가져오기
        ↓
AddScore(PointValue)
        ↓
점수 증가
        ↓
코인 Destroy

그런데 여기서 트러블슈팅 발생

현재 내 프로젝트에는:

SpartaGameStateBase.h

가 존재하지 않았다.

그래서:

C1083
Cannot open include file:
'SpartaGameStateBase.h'

에러가 발생했다.

강의 프로젝트에서 사용하는 클래스 이름을 내 프로젝트에 그대로 가져왔기 때문이다.

현재 아직 GameState를 구현하지 않았다면 해당 부분을 잠시 제외하고:

if (Activator && Activator->ActorHasTag("Player"))
{
    DestroyItem();
}

정도로 아이템 획득/삭제까지만 구현할 수 있다.

9. MineItem — 플레이어에게 데미지를 주는 아이템

지뢰는 HealingItem과 반대다.

HealingItem:

아이템 → Player → AddHealth()

MineItem:

아이템 → Player → TakeDamage()

지뢰의 핵심은 Timer를 이용한 지연 폭발이다.

ExplosionDelay = 5.0f;

그리고:

GetWorld()->GetTimerManager().SetTimer(
    ExplosionTimerHandle,
    this,
    &AMineItem::Explode,
    ExplosionDelay,
    false
);

이 코드는:

5초 후 Explode() 실행

이라는 뜻이다.

특히:

false

이므로 반복 타이머가 아니라 한 번만 실행된다.

10. 지뢰 폭발 → ApplyDamage()

UGameplayStatics::ApplyDamage(
    Actor,
    ExplosionDamage,
    nullptr,
    this,
    UDamageType::StaticClass()
);

이 부분이 오늘 배운 아이템 → 캐릭터 데미지 전달의 핵심이다.

지뢰가 직접:

Health -= 30;

하는 것이 아니다.

대신:

MineItem
   ↓
ApplyDamage()
   ↓
Player의 TakeDamage()
   ↓
Health 감소
   ↓
Health <= 0 ?
   ↓
OnDeath()

라는 구조를 만든다.

이렇게 하면 데미지를 주는 쪽과 데미지를 받는 쪽을 분리할 수 있다.

11. 아이템 시스템 전체 구조

오늘 배운 내용을 연결하면 이런 구조가 된다.

                    ┌──────────────┐
                    │   Player     │
                    │ JunCharacter │
                    └──────┬───────┘
                           │
                아이템과 상호작용
                           │
             ┌─────────────┼─────────────┐
             ↓             ↓             ↓
       HealingItem      CoinItem       MineItem
             │             │             │
             ↓             ↓             ↓
        AddHealth()     AddScore()   ApplyDamage()
             │             │             │
             ↓             ↓             ↓
          Health         Score       TakeDamage()
                                         │
                                         ↓
                                      Health 감소
                                         │
                                         ↓
                                      OnDeath()

이 구조가 오늘 배운 것 중에서 가장 중요한 부분이라고 생각한다.

12. 오늘의 트러블슈팅

① 유니코드 지옥

코드를 복사하는 과정에서:

->   → 
=    
(    
)    
<    

등으로 깨지는 현상이 발생했다.

예를 들어:

ExplosionCollision→SetupAttachment(Scene);

정상적인 C++는:

ExplosionCollision->SetupAttachment(Scene);

이다.

해결

깨진 코드를 그대로 사용하지 않고 정상적인 C++ 기호로 복구했다.

13. MineItem.h와 .cpp가 섞인 문제

오늘 가장 중요한 실수 중 하나.

MineItem.h에 있어야 하는:

UCLASS()

class AMineItem : public ABaseItem
{
    GENERATED_BODY()
    
    ...
};

가 사라지고 대신:

AMineItem::AMineItem()
{
    ...
}

같은 CPP 구현 코드가 들어가 있었다.

그래서:

"어? 왜 MineItem.h에 UCLASS가 없지?"

라는 이상한 상황이 발생했다.

정상 구조

MineItem.h

클래스 선언
UPROPERTY
UFUNCTION
함수 원형

MineItem.cpp

생성자 구현
함수 구현
실제 로직

14. generated.h 에러

C1083
Cannot open include file:
'MineItem.generated.h'

이 에러도 처음에는 generated.h 파일 자체가 문제인 것처럼 보였다.

하지만 generated.h는 내가 직접 만드는 파일이 아니라 UnrealHeaderTool이 UCLASS, UPROPERTY, UFUNCTION 등을 기반으로 생성하는 파일이다.

따라서:

#include "MineItem.generated.h"

자체가 잘못된 것이 아니라,

그 전에 헤더 구조가 깨져서 UHT가 정상적으로 처리하지 못했을 가능성을 먼저 봐야 한다.

그리고 .generated.h는 헤더의 마지막 include로 둔다.

15. C1014 too many include files

C1014
too many include files: depth = 1024

이 에러도 발생했다.

이는 헤더가 서로 무한히 include되는 순환 참조가 발생했을 때 나타날 수 있다.

예:

MineItem.h
 ↓
BaseItem.h
 ↓
MineItem.h
 ↓
BaseItem.h
 ↓
...

따라서:

MineItem.cpp
#include "MineItem.h"

자체가 문제인 것이 아니라,

헤더끼리 서로 물고 있는 구조가 문제라는 것을 알게 되었다.

16. 오늘 배운 핵심 정리

체력

MaxHealth

→ 최대 체력

Health

→ 현재 체력

AddHealth()

→ 체력 회복

TakeDamage()

→ 데미지 처리

OnDeath()

→ 체력이 0이 되었을 때 사망 처리

아이템 상호작용

HealingItem
→ AddHealth()
→ 체력 증가

MineItem
→ ApplyDamage()
→ TakeDamage()
→ 체력 감소

CoinItem
→ GameState
→ AddScore()
→ 점수 증가

Unreal C++에서 중요한 구조

.h
→ 무엇이 존재하는지 선언

.cpp
→ 실제로 어떻게 동작하는지 구현

그리고:

#include "MineItem.generated.h"

은 직접 만드는 파일이 아니라 UHT가 생성하는 파일이며, 반드시! 헤더의 마지막 include로 둔다.

오늘의 한 줄 회고

오늘은 단순히 체력과 아이템 기능을 구현한 것뿐만 아니라, HealingItem → AddHealth(), MineItem → ApplyDamage() → TakeDamage(), CoinItem → GameState → AddScore()처럼 "아이템이 플레이어의 데이터를 직접 건드리는 것이 아니라 적절한 함수를 통해 상호작용한다"는 구조를 이해했다. 또한 유니코드 깨짐, .h/.cpp 혼동, generated.h 생성 문제 등의 트러블슈팅을 통해 Unreal C++에서 파일 구조와 프로젝트 클래스 관계가 얼마나 중요한지도 경험했다.

Unreal C++ TIL — 지뢰 피하기 게임 3-3 (DataTable과 랜덤 아이템 스폰 시스템 구현)

view29579 — Fri, 21 Aug 2026 23:20:30 +0900

1. 오늘 학습한 내용

오늘은 기존에 구현했던 아이템 시스템에서 한 단계 더 나아가 DataTable을 이용한 아이템 데이터 관리와 랜덤 스폰 시스템을 구현해보았다.

이번 작업에서는 크게 다음 내용을 다뤘다.

FTableRowBase를 상속받은 아이템 데이터 구조체 생성
USTRUCT(BlueprintType)를 이용한 구조체의 언리얼 엔진 및 블루프린트 인식
TSubclassOf<AActor>를 이용한 아이템 클래스 지정
UBoxComponent를 이용한 스폰 영역 설정
스폰 영역 내부의 랜덤 좌표 계산
SpawnActor()를 이용한 액터 생성
DataTable을 이용한 아이템 데이터 관리

2. ItemSpawnRow 구조체

먼저 DataTable의 한 행에 들어갈 데이터를 정의하기 위해 FItemSpawnRow 구조체를 만들었다.

USTRUCT(BlueprintType)
struct FItemSpawnRow : public FTableRowBase
{
    GENERATED_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FName ItemName;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    TSubclassOf<AActor> ItemClass;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    float SpawnChance;
};

FTableRowBase를 상속받음으로써 이 구조체를 DataTable의 Row 데이터로 사용할 수 있게 된다.

한 행에는 다음과 같은 정보가 들어간다.

ItemName
ItemClass
SpawnChance

즉, 아이템 하나에 대한 데이터를 하나의 행으로 관리할 수 있다.

예를 들어 DataTable에서 다음과 같이 관리할 수 있다.

Coin    → BP_Coin    → 50
Potion  → BP_Potion  → 30
Mine    → BP_Mine    → 20

이렇게 하면 아이템의 종류나 스폰 확률 같은 데이터를 코드에 직접 하나하나 작성하지 않고 DataTable에서 관리할 수 있다는 점을 배웠다.

3. TSubclassOf에 대한 이해

이번에 TSubclassOf<AActor>도 다시 사용해보았다.

TSubclassOf<AActor> ItemClass;

이것은 아무 객체나 넣는 것이 아니라 AActor를 상속받은 클래스만 지정할 수 있도록 제한하는 역할을 한다.

따라서 DataTable에서 아이템의 실제 클래스를 선택할 수 있고, 이후 SpawnActor()에 전달하여 실제 액터를 생성할 수 있다.

또한 TSubclassOf와 TSoftClassPtr의 차이도 함께 학습했다.

TSubclassOf → 사용할 클래스를 직접 참조
TSoftClassPtr → 클래스의 경로를 이용하는 소프트 참조

이번 시스템에서는 실제로 스폰할 아이템 클래스를 지정해야 하기 때문에 TSubclassOf를 사용했다.

4. SpawnVolume 구현

아이템이 생성될 영역을 만들기 위해 ASpawnVolume을 구현했다.

USceneComponent* Scene;
UBoxComponent* SpawningBox;

Scene을 루트 컴포넌트로 만들고 SpawningBox를 그 하위에 붙였다.

Scene
└── SpawningBox

이렇게 함으로써 Box 영역을 기준으로 아이템을 스폰할 수 있도록 만들었다.

5. 스폰 영역 안에서 랜덤 좌표 만들기

가장 재미있었던 부분 중 하나는 스폰 영역 안에서 랜덤한 위치를 계산하는 것이었다.

FVector BoxExtent = SpawningBox->GetScaledBoxExtent();
FVector BoxOrigin = SpawningBox->GetComponentLocation();

return BoxOrigin + FVector(
    FMath::FRandRange(-BoxExtent.X, BoxExtent.X),
    FMath::FRandRange(-BoxExtent.Y, BoxExtent.Y),
    FMath::FRandRange(-BoxExtent.Z, BoxExtent.Z)
);

GetScaledBoxExtent()를 이용하여 Box의 현재 스케일이 적용된 크기를 얻고, GetComponentLocation()을 통해 Box의 중심 위치를 가져온다.

그 다음 각 축마다

-Extent ~ +Extent

범위에서 랜덤한 값을 생성하여 중심 위치에 더한다.

결과적으로 Box 내부의 임의의 위치가 만들어진다.

        Box
┌─────────────────┐
│      •          │
│   •        •    │
│        •        │
│ •            •  │
└─────────────────┘

이 과정을 통해 아이템이 매번 같은 위치가 아니라 스폰 영역 내부의 랜덤한 위치에 생성될 수 있게 된다.

6. SpawnActor를 이용한 실제 아이템 생성

랜덤 위치를 구한 뒤에는 SpawnActor()를 이용해 실제 아이템을 생성했다.

GetWorld()->SpawnActor<AActor>(
    ItemClass,
    GetRandomPointInVolume(),
    FRotator::ZeroRotator
);

여기서 각각의 인자를 구분해서 이해했다.

ItemClass
→ 무엇을 생성할 것인가?

GetRandomPointInVolume()
→ 어디에 생성할 것인가?

FRotator::ZeroRotator
→ 어떤 회전으로 생성할 것인가?

즉,

아이템의 종류 + 랜덤 위치 + 기본 회전값

을 조합해서 실제 월드에 아이템을 생성한다.

7. 오늘 느낀 점

오늘은 특별히 큰 트러블슈팅이 발생하지는 않았다.

대신 오늘 작업을 하면서 이전과는 조금 다른 느낌을 받았다.

지금까지는 주로 캐릭터를 만들고 움직이게 하거나, 컴포넌트를 붙이고 애니메이션을 적용하는 등 게임의 기능을 직접 구현하는 과정에 집중했다.

그런데 이번에 DataTable과 랜덤 스폰 시스템을 만들어보면서 처음으로 "게임이 실제로 데이터를 이용해서 돌아간다"는 느낌이 강하게 들었다.

특히 DataTable에 아이템의 이름, 클래스, 스폰 확률을 넣고 그것을 코드에서 가져와 실제 월드에 아이템으로 생성하는 과정을 보면서 게임의 시스템이 조금씩 연결되고 있다는 느낌을 받았다.

그리고 DataTable은 게임의 기획자가 데이터를 관리할 때도 활용할 수 있다는 점이 흥미로웠다.

코드를 직접 수정하지 않고 DataTable의 값을 변경하는 것만으로 아이템의 종류나 스폰 확률 등을 조정할 수 있기 때문에, 프로그래머와 기획자가 역할을 나누어 작업하는 게임 개발 과정도 조금은 이해할 수 있었다.

무엇보다 지금까지의 실습은 "기능을 하나 구현했다"는 느낌이 강했다면, 오늘은 "게임을 구성하는 시스템 하나를 만들었다"는 느낌이 들어서 재미있었다.

앞으로 아이템 종류가 늘어나고 스폰 규칙이나 확률까지 연결된다면 DataTable을 활용하는 이유를 더 확실하게 이해할 수 있을 것 같다.

Unreal C++ TIL — 지뢰 피하기 게임 3-2 (아이템 상속 구조와 virtual / override)

view29579 — Thu, 20 Aug 2026 15:34:02 +0900

Date: 2026.08.20

오늘 배운 것

Unreal C++에서 아이템 클래스의 상속 구조 구현
ActorHasTag("Player")를 이용한 플레이어 판별
GEngine->AddOnScreenDebugMessage()를 이용한 디버깅
부모 클래스의 함수를 자식 클래스가 상속받아 사용하는 과정
virtual과 override의 관계
자식 클래스에서 함수를 재정의하면 부모의 기능이 가려질 수 있다는 것
공통 기능은 부모 클래스에 작성하고, 자식 클래스에서는 필요한 값만 변경하는 구조

1. 아이템 클래스의 기본 상속 구조

오늘 만든 아이템 구조는 다음과 같다.

ABaseItem
│
├── AMineItem
│
├── AHealingItem
│
└── ACoinItem
     │
     ├── ABigCoinItem
     │
     └── ASmallCoinItem

BaseItem을 가장 상위 부모 클래스로 두고,

지뢰
회복 아이템
코인

을 각각 자식 클래스로 만들었다.

그리고 코인은 다시:

BigCoin
SmallCoin

으로 한 단계 더 상속했다.

2. HealingItem 구현

AHealingItem에는 회복량을 저장할 변수로 HealAmount를 만들었다.

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Item")

float HealAmount;

생성자에서 기본값을 설정했다.

AHealingItem::AHealingItem()

{

HealAmount = 20.0f;

ItemType = "Healing";

}

처음에는 ActivateItem()에서 단순히 아이템만 삭제했다.

void AHealingItem::ActivateItem(AActor* Activator)

{

DestroyItem();

}

이후 실제 기능을 구현하기 전에 아이템이 정상적으로 활성화되는지 확인하기 위해 디버그 메시지를 추가했다.

GEngine->AddOnScreenDebugMessage(

-1,

2.0f,

FColor::Green,

FString::Printf(TEXT("Player healing %.0f by HealingItem"), HealAmount)

);

여기서 HealAmount가 float이므로 %d가 아니라 %.0f를 사용했다.

3. FString::Printf()의 형식 지정자 문제

처음에는 다음과 같이 작성했다.

FString::Printf(

TEXT("Player damaged %d by MineItem"),

ExplosionDamage

)

그런데 컴파일 과정에서 C7595 오류가 발생했다.

원인은 ExplosionDamage가 float인데 %d를 사용했기 때문이다.

%d → int

%f → float

따라서:

TEXT("Player damaged %.0f by MineItem")

처럼 수정했다.

이 과정을 통해 문자열 안의 포맷 지정자와 실제 전달하는 변수의 타입이 맞아야 한다는 것을 확인했다.

4. CoinItem 구현

코인은 ACoinItem을 부모로 두고 BigCoin과 SmallCoin을 자식으로 만들었다.

ACoinItem

├── ABigCoinItem

└── ASmallCoinItem

코인마다 획득하는 점수가 다르므로:

int32 PointValue;

를 만들었다.

그리고 CoinItem.cpp에서는 공통적인 코인 기능을 구현했다.

void ACoinItem::ActivateItem(AActor* Activator)

{

if (Activator && Activator->ActorHasTag("Player"))

{

GEngine->AddOnScreenDebugMessage(

-1,

2.0f,

FColor::Green,

FString::Printf(TEXT("Player gained %d points!"), PointValue)

);

DestroyItem();

}

여기서:

Activator->ActorHasTag("Player")

를 통해 현재 아이템을 활성화시킨 Actor가 플레이어인지 확인했다.

5. BigCoin에서 부모 기능을 상속받도록 수정

BigCoin에서는 생성자에서 점수만 다르게 설정했다.

ABigCoinItem::ABigCoinItem()

{

PointValue = 50;

ItemType = "BigCoin";

}

처음에는 BigCoin에도 다음 코드가 있었다.

virtual void ActivateItem(AActor* Activator) override;

그리고 .cpp에는:

void ABigCoinItem::ActivateItem(AActor* Activator)

{

DestroyItem();

}

가 있었다.

그런데 이렇게 하면 BigCoin이 ACoinItem의 ActivateItem()을 사용하는 것이 아니라 자기 자신의 ActivateItem()을 실행한다.

따라서:

BigCoin

↓

ABigCoinItem::ActivateItem()

↓

DestroyItem()

만 실행되고,

부모인 ACoinItem의:

"Player gained %d points!"

메시지는 실행되지 않았다.

6. 트러블슈팅 — 왜 String이 안 떴을까?

문제 상황:

BigCoin과 Overlap

↓

BigCoin 사라짐

↓

그런데 "Player gained 50 points!"가 안 나옴

처음에는 Overlap 자체의 문제라고 생각할 수도 있었지만, 아이템이 정상적으로 Destroy되는 것을 통해 Overlap과 ActivateItem() 자체는 실행되고 있다는 것을 확인했다.

결국 BigCoin에 있던:

void ABigCoinItem::ActivateItem(AActor* Activator)

{

DestroyItem();

}

이 원인이었다.

이 함수가 존재하기 때문에 BigCoin은 부모의 ActivateItem()을 사용하지 않고 자기 자신의 함수를 실행하고 있었던 것이다.

7. virtual / override를 직접 이해한 순간

BigCoin의 ActivateItem()을 삭제하고,

헤더의:

virtual void ActivateItem(AActor* Activator) override;

도 삭제했다.

그러자 BigCoin이 부모인 ACoinItem의 ActivateItem()을 그대로 사용하기 시작했다.

BigCoin에서는:

PointValue = 50;

만 설정되어 있으므로 부모의 함수가 실행될 때:

FString::Printf(

TEXT("Player gained %d points!"),

PointValue

);

의 PointValue에 50이 들어갔다.

결과:

Player gained 50 points!

정상적으로 출력됐다.

8. 오늘 가장 중요했던 이해

이번 과정을 통해 단순히

"virtual은 가상 함수다."

라고 외우는 것보다 실제로 부모와 자식의 함수를 비교하면서 이해할 수 있었다.

현재 구조는:

ACoinItem

│

├── ActivateItem()

│ └── 코인을 먹으면 점수 출력 + 아이템 삭제

│

└── PointValue

↑

│

├── BigCoin → 50

│

└── SmallCoin → 작은 값

이렇게 구성할 수 있다.

즉 공통적인 기능은 부모 클래스에 작성하고, 자식 클래스에서는 자신에게 필요한 값만 변경하면 된다.

그래서 BigCoin과 SmallCoin에 똑같은 ActivateItem() 코드를 복붙할 필요가 없다.

오늘의 핵심 정리

virtual

부모 클래스에서:

virtual void ActivateItem(AActor* Activator);

라고 선언하면 자식 클래스가 이 함수를 재정의할 수 있도록 열어두는 것이다.

override

자식 클래스에서:

virtual void ActivateItem(AActor* Activator) override;

라고 하면 부모의 virtual 함수를 자식이 자기 방식으로 재정의한다는 의미다.

그리고 중요한 것은:

자식에서 함수를 override하면 부모의 함수가 자동으로 같이 실행되는 것이 아니다.

자식 함수가 실행되기 때문에 부모 함수의 기능이 필요하다면 별도로 처리해야 한다.

반대로 자식에서 ActivateItem() 자체를 만들지 않으면 부모의 구현을 그대로 물려받아 사용할 수 있다.

오늘 얻은 가장 큰 깨달음

처음에는 상속 구조를:

"부모 → 자식으로 코드를 물려준다."

정도로 생각했는데, 오늘 직접 코드를 수정하면서 조금 더 구체적으로 이해하게 되었다.

부모

→ 공통적인 행동을 담당

자식

→ 부모의 행동을 그대로 사용할 수도 있고

→ 필요하다면 override해서 행동을 바꿀 수도 있고

→ 공통 기능은 그대로 두고 값만 다르게 설정할 수도 있다.

특히 BigCoin의 문제를 해결하면서

"왜 BigCoin에서는 부모의 String이 안 뜨지?"

↓

"아, BigCoin이 ActivateItem을 자기 것으로 재정의했네."

↓

"그걸 지우니까 부모의 ActivateItem을 사용하는구나."

라는 흐름을 직접 경험했다.

오늘은 virtual과 override를 문법으로 외운 게 아니라 실제 트러블슈팅을 통해 이해한 날이었다.