editor66484 님의 블로그

유닛 이동 불량 문제 해결: 부착 무기의 Collision 설정

editor66484 — Wed, 23 Sep 2026 21:53:04 +0900

문제 상황

병영에서 생산된 유닛에게 집결지 또는 특정 위치로 이동 명령을 내렸을 때, 다음과 같은 문제가 발생했다.

목적지를 향해 자연스럽게 이동하지 못함
이동 도중 다른 유닛 주변에서 끼는 현상 발생
방향을 반복해서 변경하며 비비는 듯한 움직임 발생
목적지 근처까지 정상적으로 이동하지 못함
동일한 이동 코드를 사용하는 다른 유닛은 정상적으로 움직임

처음에는 AI 이동이나 NavMesh 문제처럼 보였지만, 실제 원인은 유닛에 부착된 무기의 충돌 설정이었다.

원인 분석 과정

1. 이동 명령 전달 여부 확인

녹화 영상을 통해 유닛의 움직임을 확인했다.

유닛이 완전히 정지한 것은 아니었으며 다음 동작은 정상적으로 실행되고 있었다.

이동 명령이 전달됨
이동 목적지 표시가 생성됨
유닛의 월드 위치가 변경됨

따라서 이동 명령이나 MoveTo가 전혀 실행되지 않는 문제는 아니라고 판단했다.

2. 의심했던 항목

초기에는 다음 항목들을 원인으로 의심했다.

NavMesh가 목적지까지 연결되지 않은 문제
Capsule Component 크기가 지나치게 큰 문제
Detour Crowd 회피 처리 문제
이동 Blend Space 또는 Root Motion 문제
집결지가 NavMesh 바깥에 배치된 문제
여러 유닛이 동일한 목적지로 이동하며 발생한 충돌

하지만 같은 환경에서 다른 유닛은 정상적으로 이동했기 때문에, 문제가 발생하는 유닛 BP의 컴포넌트 설정을 비교했다.

실제 원인

문제 유닛의 Weapon 컴포넌트에 다음 충돌 설정이 적용되어 있었다.

Collision Presets       = BlockAllDynamic
Collision Enabled       = Query and Physics
Generate Overlap Events = 활성화

유닛 이동 불량 문제 해결: 부착 무기의 Collision 설정

문제 상황

병영에서 생산된 유닛에게 집결지 또는 특정 위치로 이동 명령을 내렸을 때, 다음과 같은 문제가 발생했다.

목적지를 향해 자연스럽게 이동하지 못함
이동 도중 다른 유닛 주변에서 끼는 현상 발생
방향을 반복해서 변경하며 비비는 듯한 움직임 발생
목적지 근처까지 정상적으로 이동하지 못함
동일한 이동 코드를 사용하는 다른 유닛은 정상적으로 움직임

처음에는 AI 이동이나 NavMesh 문제처럼 보였지만, 실제 원인은 유닛에 부착된 무기의 충돌 설정이었다.

원인 분석 과정

1. 이동 명령 전달 여부 확인

녹화 영상을 통해 유닛의 움직임을 확인했다.

유닛이 완전히 정지한 것은 아니었으며 다음 동작은 정상적으로 실행되고 있었다.

이동 명령이 전달됨
이동 목적지 표시가 생성됨
유닛의 월드 위치가 변경됨

따라서 이동 명령이나 MoveTo가 전혀 실행되지 않는 문제는 아니라고 판단했다.

2. 의심했던 항목

초기에는 다음 항목들을 원인으로 의심했다.

NavMesh가 목적지까지 연결되지 않은 문제
Capsule Component 크기가 지나치게 큰 문제
Detour Crowd 회피 처리 문제
이동 Blend Space 또는 Root Motion 문제
집결지가 NavMesh 바깥에 배치된 문제
여러 유닛이 동일한 목적지로 이동하며 발생한 충돌

하지만 같은 환경에서 다른 유닛은 정상적으로 이동했기 때문에, 문제가 발생하는 유닛 BP의 컴포넌트 설정을 비교했다.

실제 원인

문제 유닛의 Weapon 컴포넌트에 다음 충돌 설정이 적용되어 있었다.

Collision Presets       = BlockAllDynamic
Collision Enabled       = Query and Physics
Generate Overlap Events = 활성화

무기는 캐릭터의 손에 부착된 시각적 컴포넌트였지만, BlockAllDynamic이 적용되어 다른 유닛 및 오브젝트와 실제로 충돌하고 있었다.

특히 무기 메시가 캐릭터의 Capsule 바깥으로 길게 돌출되어 있었기 때문에 다음 현상이 발생했다.

유닛 이동
→ 무기가 다른 유닛과 충돌
→ 이동 방향 변경
→ Crowd Avoidance가 새로운 경로 계산
→ 무기가 다시 충돌
→ 끼거나 비비는 것처럼 보임

즉, 캐릭터의 Capsule뿐만 아니라 부착된 무기까지 이동 충돌에 관여하고 있었던 것이 원인이었다.

해결 방법

문제가 발생한 유닛 BP를 열고 Weapon 컴포넌트의 설정을 변경했다.

Components
└─ Weapon
   └─ Details
      └─ Collision

변경 전:

Collision Presets       = BlockAllDynamic
Generate Overlap Events = 활성화
Can Character Step Up On = Yes

변경 후:

Collision Presets       = NoCollision
Generate Overlap Events = 비활성화
Can Character Step Up On = No

Physics 항목도 다음과 같이 설정했다.

Simulate Physics = 비활성화
Enable Gravity   = 비활성화

정상적인 충돌 구성

캐릭터 유닛은 이동 충돌을 Capsule Component 하나에서 담당하도록 구성하는 것이 안전하다.

Capsule Component
└─ 이동 및 월드 충돌 담당

Character Mesh
└─ NoCollision

Weapon
└─ NoCollision

장식용 Static/Skeletal Mesh
└─ NoCollision

Capsule Component까지 NoCollision으로 변경하면 안 된다. Capsule은 캐릭터 이동과 월드 충돌 판정에 필요하다.

결과

Weapon의 Collision Presets를 NoCollision으로 변경한 후 다음 결과를 확인했다.

유닛이 목적지를 향해 정상적으로 이동함
다른 유닛 주변에서 끼는 현상이 사라짐
방향을 반복해서 바꾸는 현상이 사라짐
집결지 이동이 정상적으로 완료됨
별도의 AI 이동 코드 수정 없이 문제가 해결됨

트러블슈팅을 통해 알게 된 점

유닛 이동이 이상하다고 해서 반드시 NavMesh나 AI 코드 문제인 것은 아니다.

캐릭터에 부착된 다음 컴포넌트들도 이동을 방해할 수 있다.

무기
방패
장식품
투구
가방
이펙트용 Static Mesh
충돌이 활성화된 자식 컴포넌트

특히 메시가 Capsule 바깥으로 돌출되어 있다면 BlockAllDynamic 설정이 이동에 큰 영향을 줄 수 있다.

신규 유닛 점검 항목

새로운 유닛 BP를 만들거나 무기를 부착한 후에는 다음 항목을 확인한다.

[ ] Capsule Component만 이동 충돌을 담당하는가?
[ ] Character Mesh가 NoCollision인가?
[ ] Weapon이 NoCollision인가?
[ ] Weapon의 Generate Overlap Events가 꺼져 있는가?
[ ] Weapon의 Simulate Physics가 꺼져 있는가?
[ ] Weapon의 Enable Gravity가 꺼져 있는가?
[ ] 이동 Blend Space가 실제 속도를 입력받는가?
[ ] Root Motion이 의도하지 않게 활성화되어 있지 않은가?
[ ] 목적지가 NavMesh 영역 안에 있는가?

결론

이번 이동 불량 문제는 AI 이동 코드가 아니라, 유닛에 부착된 무기 메시의 BlockAllDynamic 충돌 설정 때문에 발생했다.

시각적 표현만 담당하는 무기와 장식 컴포넌트에는 원칙적으로 NoCollision을 적용하고, 캐릭터 이동 충돌은 Capsule Component에서 일관되게 처리해야 한다.

유닛 이동 불량 원인 분석과 생산·튜토리얼 스폰 구조 정리

editor66484 — Wed, 23 Sep 2026 21:50:30 +0900

1. 유닛 이동 이상 현상 분석

병영에서 생산된 유닛이 목표 지점으로 자연스럽게 이동하지 못하고, 주변에서 끼거나 비비는 듯한 현상이 발생했다.

처음에는 다음 원인들을 의심했다.

NavMesh 경로 문제
유닛 Capsule 크기 문제
Crowd Avoidance 문제
이동 애니메이션 또는 Root Motion 문제
집결지 위치 문제

녹화 영상을 확인한 결과, 이동 명령 자체는 정상적으로 전달되고 있었으며 유닛의 위치도 실제로 변경되고 있었다. 따라서 경로 탐색보다는 개별 컴포넌트의 충돌 설정을 우선 확인했다.

2. 이동 문제의 실제 원인 발견

문제 유닛의 무기 Static Mesh Component에 다음 설정이 적용되어 있었다.

Collision Presets       = BlockAllDynamic
Generate Overlap Events = 활성화

무기 메시가 캐릭터의 Capsule 바깥으로 길게 돌출되어 있어, 다른 유닛이나 월드 오브젝트와 충돌하면서 이동을 방해하고 있었다.

다음과 같이 변경했다.

Weapon
├─ Collision Presets       = NoCollision
├─ Generate Overlap Events = 비활성화
├─ Simulate Physics        = 비활성화
└─ Enable Gravity          = 비활성화

변경 후 유닛 이동이 정상적으로 돌아오는 것을 확인했다.

알게 된 점

캐릭터의 이동 충돌은 기본적으로 Capsule Component가 담당해야 한다.

Capsule Component → 이동 충돌 담당
Character Mesh    → NoCollision
Weapon Mesh       → NoCollision

캐릭터에 부착된 무기나 장식용 메시가 BlockAllDynamic으로 설정되어 있으면 다음 문제가 발생할 수 있다.

다른 유닛과 서로 걸림
이동 중 방향을 반복해서 변경함
목적지 주변에서 비비는 현상
좁은 위치를 통과하지 못함
Crowd Avoidance가 비정상적으로 보임

따라서 새로운 무기 메시를 부착할 때는 가장 먼저 충돌 설정을 확인해야 한다.

튜토리얼 적 스폰 구조 확인

튜토리얼 진행에 맞춰 적을 생성하려면 맵의 UnitSpawner와 튜토리얼의 Gameplay Tag를 연결해야 한다.

DT_SFStageIntro 목표 완료
        ↓
Gameplay Tag 신호 발생
        ↓
UnitSpawner의 Activation Objective Tag와 비교
        ↓
Spawner 활성화
        ↓
Initial Delay 이후 적 생성

튜토리얼 진행을 기다리는 스포너는 다음과 같이 설정한다.

Start Active             = 비활성화
Activation Objective Tag = 튜토리얼에서 발생하는 목표 태그

Start Active가 활성화되어 있으면 튜토리얼 목표와 관계없이 게임 시작 시 바로 적을 생성한다.

생산 건물 데이터 구조 확인

생산 건물에서 표시되는 유닛 목록은 건물 BP에 직접 들어 있는 것이 아니라 건물 Definition의 Tiers → Spawnable Units에서 결정된다.

여우 진영 아카데미 데이터 위치:

Content/Core/Primary/Buildings/Definitions/Animal/DA_AnimalRanged

유닛 생성 흐름:

DA_AnimalRanged
→ 티어별 Spawnable Units
→ DT_Units의 Row Name 검색
→ 해당 행의 Unit Class 로드
→ 실제 유닛 생성

따라서 생산 버튼은 보이지만 엉뚱한 유닛이 생성된다면 DT_Units → 해당 행 → Unit Class 연결을 확인해야 한다.

오늘 해결한 문제

병영 생산 유닛이 주변에서 끼며 비정상적으로 움직이던 문제
무기 메시의 충돌이 유닛 이동에 영향을 주는 원인 확인
튜토리얼 목표와 UnitSpawner 활성화 연결 구조 확인
생산 건물과 DT_Units 사이의 유닛 생성 구조 확인

다음 작업

새 유닛 BP를 만들 때 무기 및 장식 메시의 충돌 설정 점검
아카데미 건물이 실제 건설 목록에 표시되는지 확인
아카데미 티어별 생산 목록 확인
1티어 유닛부터 순서대로 기능 테스트
각 유닛 생산 후 집결지 이동이 정상인지 재검증

Unit 적 RowName설정 오류 및 공격 설정 변경

editor66484 — Tue, 8 Sep 2026 23:15:43 +0900

1. 적 유닛 체력이 1로 시작하는 문제

문제 상황

공격 Anim Notify의 피해량을 검증하려고 했지만 적 유닛이 한 번의 공격에 바로 사망했다. 처음에는 적 유닛의 체력이 실제로 1로 설정된 것으로 의심했다.

원인 확인

적 유닛 스포너에는 다음 Row Name이 설정되어 있었다.

Infantry

하지만 DT_Units를 확인한 결과 Infantry라는 Row Name은 존재하지 않았다.

유닛 스탯 초기화 구조는 다음과 같다.

UnitSpawner의 Unit Row Name
→ DT_Units에서 동일한 행 검색
→ FUnitStatData 로드
→ HealthComponent 초기화

Infantry 행을 찾지 못하면서 다음 초기화가 실행되지 않았다.

HealthComponent->InitializeHealth(InRow.MaxHealth);

따라서 적 유닛에는 HealthComponent의 초기 기본값이 남았다.

Current Health = 1
Max Health = 100

해결 방향

스포너의 Unit Row Name을 실제 데이터 테이블에 존재하는 행으로 변경해야 한다.

현재 데이터 연결은 다음과 같다.

Brawler   → BP_TestUnit
Berserker → BP_TestUnit2

따라서 생성되는 적 유닛 클래스에 맞춰 Brawler 또는 Berserker를 사용한다. 별도의 적 스탯이 필요하면 추후 Infantry 행을 새로 추가하는 방법도 사용할 수 있다.

배운 점

데이터 테이블 기반 초기화에 실패하면 객체의 기본값이 남기 때문에, 단순히 “체력이 잘못 설정됐다”고 판단하기보다 다음 항목을 먼저 확인해야 한다.

스포너의 Row Name
데이터 테이블에 해당 행이 존재하는지
Row Name의 철자와 대소문자
실행 로그의 데이터 조회 실패 경고

2. 공격 애니메이션 한 번에 피해가 여러 번 들어가는 문제

문제 상황

공격 애니메이션은 한 번 재생됐지만 실제로는 피해가 2~3회 적용되어 적이 예상보다 빠르게 사망했다.

특히 여우 유닛은 한 공격 애니메이션에 두 번의 타격 동작이 있어서 일반 공격과 동일하게 처리하기 어려웠다.

기존 구조의 문제

기존 공격 처리는 애니메이션의 타격 프레임과 관계없이 PerformAttack() 실행 시점에 즉시 피해를 적용했다.

공격 조건 만족
→ PerformAttack 실행
→ 즉시 피해 적용
→ 공격 애니메이션 재생

이 구조에서는 공격 Tick, 쿨다운, 몽타주 재호출 등의 상황에 따라 애니메이션과 피해 횟수가 어긋날 수 있었다.

해결 방법

실제 피해 계산을 Anim Notify가 실행되는 순간으로 이동했다.

PerformAttack
→ 공격 대상 임시 저장
→ 공격 몽타주 재생
→ 타격 프레임에서 BP_AN_AttackHit 실행
→ HandleAttackHit 호출
→ 실제 피해 적용

BP_AN_AttackHit에서는 Notify를 발생시킨 Skeletal Mesh의 소유자를 찾아 UnitBase로 변환한 후 공격 피해 함수를 호출한다.

DamageRatio 적용

같은 Notify 블루프린트를 일반 공격과 2연타 공격에서 공통으로 사용하기 위해 DamageRatio 변수를 추가했다.

Received Notify
→ Get Owner
→ Cast To UnitBase
→ HandleAttackHit(DamageRatio)
→ Return True

공격 방식별 설정은 다음과 같다.

공격 종류Notify 개수각 DamageRatio총 피해

휴먼 일반 공격	1개	1.0	공격력의 100%
여우 2연타	2개	각각 0.5	공격력의 50% + 50%

예를 들어 공격력이 10인 여우 유닛은 한 공격 주기에서 5 + 5의 피해를 적용한다.

추가 안전장치

Notify가 실수로 중복 배치되어도 피해가 무한히 적용되지 않도록 유닛별 AttackHitCount를 사용했다.

휴먼: AttackHitCount = 1
여우: AttackHitCount = 2

배운 점

Anim Notify의 개수는 애니메이션의 실제 타격 횟수와 일치시켜야 한다. 또한 다단 공격에서는 각 타격 피해의 합이 데이터 테이블의 최종 공격력과 일치하는지 확인해야 한다.

3. 공격 중 후퇴 명령이 적용되지 않는 문제

문제 상황

유닛이 적을 공격하는 도중 뒤쪽을 클릭해도 공격을 중단하지 않고 계속 같은 적을 공격했다.

원인

일반 우클릭 이동도 현재 구조에서는 AttackMove로 처리된다. 공격을 취소해도 바로 다음 Tick에서 가까운 적을 다시 탐색하면서 같은 적과 다시 교전했다.

단순히 명령을 Move로 바꾸면 후퇴는 가능하지만, 기존 요구사항인 다음 기능이 사라지는 문제가 있었다.

이동 중 적 발견
→ 자동으로 이동 중단
→ 적 공격

해결 방법

AttackMove는 유지하면서 새로운 이동 명령 직후에만 짧은 재탐색 유예시간을 적용했다.

공격 중 뒤쪽 클릭
→ 기존 공격 대상 해제
→ 공격 몽타주 중단
→ 남아 있는 Notify 대상 제거
→ 0.3초 동안 이동 우선
→ 유예시간 종료
→ 적 자동 탐색 재개

이를 위해 CommandAttackMoveGraceRemaining을 추가하고 Tick에서 감소시켰다.

if (CommandAttackMoveGraceRemaining > 0.f)
{
    CommandAttackMoveGraceRemaining =
        FMath::Max(
            0.f,
            CommandAttackMoveGraceRemaining - DeltaSeconds
        );
}

유예시간 동안에는 공격 이동 명령이어도 목적지 이동을 우선하도록 조건을 변경했다.

if (bHasCommandedDestination &&
    (!bCommandIsAttackMove ||
     CommandAttackMoveGraceRemaining > 0.f))

배운 점

입력 문제처럼 보여도 실제 원인은 상태 머신이 다음 Tick에서 명령을 덮어쓰는 것일 수 있다. 기존 자동 전투 기능을 제거하지 않고 사용자의 새 명령에 우선권을 주려면 짧은 상태 전환 유예시간을 사용할 수 있다.

트러블 슈팅 결과

오늘 확인한 문제들은 서로 연결되어 있었다.

잘못된 Row Name
→ 체력 초기화 실패
→ 적 유닛이 즉시 사망
→ 공격 Notify 피해량 검증 불가능

즉시 피해 방식
→ 애니메이션과 타격 횟수 불일치
→ Notify 기반 피해 처리로 변경

AttackMove의 즉각적인 재탐색
→ 후퇴 명령 무시
→ 0.3초 이동 우선시간 적용

다음 작업에서는 BP_AN_DeathPose를 사망 몽타주의 완전히 누운 프레임에 배치하고, HandleDeathPose()와 연결하여 다시 일어나는 사망 애니메이션 문제를 처리할 예정이다.

유닛 공격 판정 및 애니메이션 개선

editor66484 — Tue, 8 Sep 2026 23:11:29 +0900

오늘 작업한 내용

오늘은 유닛 선택 정보 오류를 확인하고, 공격 피해가 애니메이션과 정확히 일치하도록 Anim Notify 기반 공격 시스템을 구성했다. 추가로 공격 중 이동 명령 처리와 사망 애니메이션 개선 작업을 시작했다.

1. 유닛 선택 정보가 출력되지 않는 문제 확인

BP_TestUnit의 GetSelectableInfo에 내용이 없는 재정의 함수가 생성되어 있었다.

이 빈 재정의가 부모 C++ 함수인 AUnitBase::GetSelectableInfo_Implementation()의 실행을 막으면서 다음 정보가 기본값으로 반환되고 있었다.

유닛 이름
체력
공격력
이동속도
유닛 타입
초상화 애니메이션

빈 재정의를 제거하여 부모 C++의 선택 정보 처리 함수를 사용하도록 정리했다.

2. 공격 피해를 Anim Notify 방식으로 변경

기존에는 공격 함수가 실행되는 시점에 피해가 즉시 적용되어, 애니메이션의 실제 타격 순간과 피해 발생 시점이 일치하지 않았다.

이를 개선하기 위해 다음처럼 역할을 분리했다.

PerformAttack
→ 공격 대상 저장
→ 공격 몽타주 재생
→ 타격 프레임에서 Anim Notify 실행
→ HandleAttackHit 호출
→ 실제 피해 적용

PerformAttack() 내부의 기존 즉시 피해 계산을 분리하고, HandleAttackHit()와 ApplyAttackDamage()를 통해 Notify 시점에 피해가 적용되도록 구성했다.

3. 공격용 Anim Notify 제작

BP_AN_AttackHit을 생성하고 Received Notify에서 공격 중인 UnitBase를 찾아 HandleAttackHit()을 호출하도록 연결했다.

연결 구조는 다음과 같다.

Received Notify
→ Mesh Comp
→ Get Owner
→ Cast To UnitBase
→ Handle Attack Hit
→ Return True

DamageRatio 변수를 Handle Attack Hit의 입력으로 연결하여 몽타주마다 피해 비율을 다르게 설정할 수 있도록 만들었다.

4. 일반 공격과 2연타 공격 구분

휴먼 공격은 한 번 타격하고, 여우 공격은 한 번의 공격 애니메이션에서 두 번 타격한다. 같은 BP_AN_AttackHit을 사용하되 Notify 개수와 DamageRatio 값으로 공격 방식을 구분했다.

휴먼 일반 공격

Notify 개수: 1개
Damage Ratio: 1.0
Attack Hit Count: 1

여우 2연타 공격

Notify 개수: 2개
첫 번째 Damage Ratio: 0.5
두 번째 Damage Ratio: 0.5
Attack Hit Count: 2

예를 들어 데이터 테이블 공격력이 10이면 여우는 다음처럼 피해를 적용한다.

1타: 10 × 0.5 = 5
2타: 10 × 0.5 = 5
총 피해: 10

이를 통해 2연타 애니메이션을 유지하면서도 한 공격 주기의 총 피해가 과도하게 증가하지 않도록 했다.

5. 적 유닛 체력이 1로 시작하는 문제 확인

적 스포너에 설정된 Row Name은 Infantry였지만, 현재 DT_Units에는 Infantry 행이 존재하지 않았다.

데이터 테이블 조회에 실패하면 HealthComponent가 정상적으로 초기화되지 않아 기본값이 남는다.

Current Health = 1
Max Health = 100

따라서 실제로 체력이 1로 설계된 것이 아니라, 데이터 테이블 행 이름 불일치로 초기화가 실패한 문제였다.

현재 연결 가능한 주요 행은 다음과 같다.

Brawler   → BP_TestUnit
Berserker → BP_TestUnit2

적 스포너의 Unit Row Name을 실제 유닛 클래스와 일치하는 데이터 행으로 변경해야 한다.

6. 공격 중 이동 명령 반응 개선

공격 도중 뒤쪽을 클릭해도 유닛이 바로 이동하지 않는 문제가 있었다.

현재 일반 우클릭이 AttackMove로 처리되기 때문에 공격을 취소한 직후 같은 적을 다시 탐색하는 것이 원인이었다. 기존의 “이동 중 적을 발견하면 자동 공격” 기능을 유지하기 위해 일반 Move로 변경하지 않고 짧은 재탐색 유예시간을 추가했다.

공격 중 이동 명령
→ 현재 공격 대상 해제
→ 공격 몽타주 중단
→ PendingAttackTarget 초기화
→ 0.3초간 목적지 이동 우선
→ 유예시간 종료 후 적 자동 탐색 재개

추가된 주요 처리:

CommandAttackMoveGraceRemaining
공격 이동 명령 시 0.3초 설정
Tick에서 유예시간 감소
유예시간 동안 목적지 이동 우선
취소된 공격의 늦은 Notify 피해 방지

7. 사망 모션 개선 작업 시작

사망 애니메이션에 쓰러진 뒤 다시 일어나는 구간이 포함되어 있어, 완전히 누운 순간 애니메이션을 정지하기 위한 BP_AN_DeathPose를 생성했다.

현재 생성된 Notify:

BP_AN_AttackHit: 실제 타격 시점에 피해 적용
BP_AN_DeathPose: 완전히 누운 사망 자세에서 애니메이션 정지 예정

사망 Notify는 에셋 생성까지만 완료했으며 C++ 연결과 사망 몽타주 배치는 다음 작업으로 남겨두었다.

다음 작업

UnitBase에 HandleDeathPose() 추가
BP_AN_DeathPose의 Received Notify 연결
휴먼과 여우 사망 몽타주에서 완전히 누운 프레임에 Notify 배치
사망 자세가 고정되고 다시 일어나지 않는지 확인
공격 Notify 피해량과 2연타 횟수 실전 검증
적 스포너의 Infantry Row Name 수정 및 체력 초기화 확인

UE5 RTS 유닛 자동 전투 개선 및 주변 아군 타겟 공유 설계

editor66484 — Wed, 2 Sep 2026 23:01:05 +0900

오늘은 RTS 유닛 전투 시스템을 전체적으로 점검하고, 플레이어 유닛의 자동 공격이 자연스럽게 이어지도록 개선 방향을 정리했다.

주요 목표는 다음과 같다.

플레이어 및 적 AI의 자동 전투 구조 확인
뒤쪽 유닛이 전투에 참여하지 않는 원인 분석
일반 이동 중 적 발견 시 자동 교전하도록 개선
한 유닛이 발견한 적을 주변 아군에게 공유하는 기능 설계
유닛이 한 대상에게 몰릴 때 발생할 수 있는 문제 검토

1. 현재 유닛 전투 구조 확인

프로젝트의 팀 구분은 TeamIndex를 사용한다.

진영TeamIndex

플레이어	0
적 AI	1

양쪽 유닛 모두 공격 자체는 자동으로 수행한다.

플레이어 유닛

플레이어가 목적지를 지정할 수 있다.
주변에서 적 유닛이나 적 건물을 발견하면 자동으로 공격한다.
일반 이동과 공격 이동을 구분할 수 있다.

적 AI 유닛

스폰 시스템을 통해 생성된다.
플레이어 유닛이나 건물을 탐색한다.
적을 발견하면 자동으로 이동하고 공격한다.

2. 뒤쪽 유닛이 공격하지 않는 문제

여러 플레이어 유닛이 뭉쳐 있을 때 앞쪽 유닛은 적을 발견하고 공격하지만, 뒤쪽 유닛은 가만히 서 있는 문제가 있었다.

뒤쪽 유닛을 직접 선택하여 앞으로 이동시키면 정상적으로 적을 발견하고 공격하는 것은 확인했다.

이를 통해 공격 기능 자체보다는 다음 문제가 원인일 가능성이 높다고 판단했다.

뒤쪽 유닛이 AggroRadius 밖에 있음
각 유닛이 서로 독립적으로 적을 탐색함
앞쪽 유닛의 적 발견 정보가 뒤쪽 유닛에게 전달되지 않음

즉, 앞 유닛이 교전을 시작하더라도 뒤 유닛은 자신의 탐색 범위 안에 적이 들어오기 전까지 전투에 참여하지 않는 구조였다.

3. 일반 이동을 공격 이동으로 처리

플레이어가 유닛을 이동시켰을 때 이동 도중 적을 발견하면 전투에 참여할 수 있도록, 일반 이동 명령을 공격 이동으로 전달하는 방향으로 수정했다.

수정 위치:

SFInGamePlayerController.cpp

기존 코드:

case ESFUnitCommandMode::Move:
    UnitCommand = ESFUnitCommand::Move;
    break;

변경 코드:

case ESFUnitCommandMode::Move:
    UnitCommand = ESFUnitCommand::AttackMove;
    break;

이 변경을 적용하면 플레이어 유닛은 목적지로 이동하면서도 주변 적을 탐색할 수 있다.

다만 일반 이동과 공격 이동이 완전히 같은 동작이 되므로, 추후에는 다음과 같이 명령을 다시 구분할 필요가 있다.

일반 이동: 적을 무시하고 목적지까지 이동
공격 이동: 이동 중 적을 발견하면 교전
강제 공격: 플레이어가 지정한 대상만 추적

4. 주변 아군에게 적 공유 기능 설계

뒤쪽 유닛까지 자연스럽게 전투에 참여시키기 위해, 한 유닛이 발견한 적을 주변 아군에게 전달하는 기능을 설계했다.

전체 처리 과정은 다음과 같다.

```mermaid
flowchart LR
    A["유닛이 적 발견"] --> B["주변 아군 검색"]
    B --> C["TeamIndex 비교"]
    C --> D["같은 팀의 유닛만 선택"]
    D --> E["발견한 적 전달"]
    E --> F["아군의 CurrentTarget 설정"]
    F --> G["경로 재탐색"]
    G --> H["전투 합류"]
```

이번 기능은 전 맵의 모든 아군에게 적을 전달하는 방식이 아니다.

AllyAssistRadius 안에 있는 같은 팀의 유닛만 지원 요청을 받도록 설계했다.

5. UnitBase에 추가한 선언

UnitBase.h에 적 공유를 담당할 함수 두 개를 선언했다.

/** 발견한 적을 일정 거리 안의 아군에게grade 전달한다 */
void AlertNearbyAllies(AActor* InTarget);

/** 주변 아군의 지원 요청으로 전달된 적을 받아들인다 */
void ReceiveAssistTarget(AActor* InTarget);

각 함수의 역할은 다음과 같다.

AlertNearbyAllies

자신이 발견한 적을 주변 아군에게 전달한다.

ReceiveAssistTarget

다른 아군에게 전달받은 적이 유효한지 확인하고 자신의 공격 대상으로 받아들인다.

6. 아군 지원 범위 추가

UnitBase.h의 전투 설정 영역에 아군 지원 범위를 추가했다.

/** 주변 아군이 발견한 적에게 합류하는 거리 */
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "Combat",
    meta = (AllowPrivateAccess = true, ClampMin = "0.0"))
float AllyAssistRadius = 1500.f;

기존 적 탐색 범위는 다음과 같다.

float AggroRadius = 1050.f;

두 범위의 역할은 서로 다르다.

설정역할

AggroRadius	유닛이 직접 적을 발견하는 범위
AllyAssistRadius	아군이 발견한 적 정보를 전달받는 범위

초기 테스트에서는 전투 참여 범위가 너무 넓어지지 않도록 AllyAssistRadius를 약 1200.f부터 확인하는 것이 좋다.

float AllyAssistRadius = 1200.f;

뒤쪽 유닛의 반응이 부족하면 1300 → 1500 순서로 증가시킬 예정이다.

7. SFCombatSubsystem 활용

프로젝트에는 이미 공간 그리드를 이용하여 주변 아군을 찾는 함수가 구현되어 있었다.

void GetNearbyAlliesForSeparation(
    const AActor* InSelf,
    int32 InTeamIndex,
    float InRadius,
    TArray<AActor*>& OutActors
) const;

이 함수는 다음 조건을 검사한다.

전달받은 TeamIndex와 같은 유닛
CombatUnit 유형
지정한 반경 안에 있는 유닛
자기 자신이 아닌 유닛
현재 유효한 액터

따라서 월드에 존재하는 모든 유닛을 직접 반복하지 않고, 기존 전투 서브시스템의 공간 검색 기능을 활용할 수 있다.

다만 함수 이름에 ForSeparation이 포함되어 있기 때문에 추후 구조를 정리할 때는 범용 주변 아군 조회 함수를 따로 만드는 것도 고려할 수 있다.

void GetNearbyAlliedUnits(
    const AActor* InSelf,
    int32 InTeamIndex,
    float InRadius,
    TArray<AActor*>& OutActors
) const;

8. 주변 아군에게 적 전달

AlertNearbyAllies()에서는 전투 서브시스템을 통해 주변 아군을 찾고, 각 아군에게 적을 전달하도록 설계했다.

void AUnitBase::AlertNearbyAllies(AActor* InTarget)
{
    if (!IsTargetUsable(InTarget))
    {
        return;
    }

    USFCombatSubsystem* Combat = USFCombatSubsystem::Get(this);
    if (!IsValid(Combat))
    {
        return;
    }

    TArray<AActor*> NearbyAllies;

    Combat->GetNearbyAlliesForSeparation(
        this,
        GetTeamIndex(),
        AllyAssistRadius,
        NearbyAllies
    );

    for (AActor* AllyActor : NearbyAllies)
    {
        AUnitBase* AllyUnit = Cast<AUnitBase>(AllyActor);
        if (!IsValid(AllyUnit))
        {
            continue;
        }

        AllyUnit->ReceiveAssistTarget(InTarget);
    }
}

공유받은 유닛이 다시 주변에 전달하지 않도록 구성하여, 전 맵으로 지원 요청이 연쇄적으로 퍼지는 현상을 방지했다.

9. 공유된 적을 공격 대상으로 설정

ReceiveAssistTarget()에서는 지원 요청을 무조건 받아들이지 않고 현재 유닛 상태를 검사해야 한다.

void AUnitBase::ReceiveAssistTarget(AActor* InTarget)
{
    if (CurrentCombatState == EUnitCombatState::Dead)
    {
        return;
    }

    if (!IsTargetUsable(InTarget))
    {
        return;
    }

    if (IsValid(ForcedTarget))
    {
        return;
    }

    if (bHoldGround)
    {
        return;
    }

    if (IsTargetUsable(CurrentTarget))
    {
        return;
    }

    CurrentTarget = InTarget;
    RetargetTimer = RetargetInterval;

    bSightBlockedReported = false;
    bRangeUnreachableReported = false;
    bNoTargetReported = false;
    bAdvanceTargetReported = false;

    if (AUnitAIController* AI = GetUnitAI())
    {
        AI->ForceRepath();
    }
}

다음 우선순위를 유지하도록 했다.

플레이어가 직접 지정한 ForcedTarget
현재 교전 중인 CurrentTarget
주변 아군에게 전달받은 지원 대상
일반 자동 탐색 대상

10. 공격 시 끊김 가능성 검토

주변 아군에게 같은 적을 전달하면 여러 유닛이 동시에 하나의 적에게 접근할 수 있다.

이 과정에서 발생할 수 있는 현상은 다음과 같다.

여러 유닛이 하나의 적 주변으로 몰림
공격 위치를 확보하지 못한 유닛이 계속 이동함
좁은 공간에서 분리 조향과 공격 이동이 충돌함
공유 범위가 너무 넓으면 먼 유닛까지 전투에 끌려감
경로 재탐색이 반복되면 순간적으로 이동이 끊김

이를 방지하기 위해 다음 조건을 적용했다.

if (IsTargetUsable(CurrentTarget))
{
    return;
}

이미 정상적으로 싸우고 있는 유닛은 전달받은 대상으로 타겟을 변경하지 않는다.

또한 ForceRepath()는 공유된 대상을 처음 받아들였을 때 한 번만 실행하고, StopMovement()는 호출하지 않는다. 이로 인해 공격 도중 이동이 반복적으로 끊기는 현상을 줄일 수 있다.

오늘의 작업 결과

오늘은 실제 전투 문제를 다음 두 단계로 나누어 개선 방향을 잡았다.

1차 수정

플레이어 유닛이 이동 중 적을 발견하면 자동으로 교전할 수 있도록 일반 이동 명령을 공격 이동으로 연결했다.

2차 수정

앞쪽 유닛이 발견한 적을 일정 범위 안의 아군에게 공유하여, 탐색 범위 밖에 있던 뒤쪽 유닛도 전투에 합류할 수 있도록 구조를 설계했다.

현재 UnitBase.h에는 관련 함수 선언과 AllyAssistRadius 설정이 추가된 상태다. 다음 작업에서는 UnitBase.cpp의 함수 구현과 실제 호출 부분을 완성한 뒤 에디터에서 전투 테스트를 진행할 예정이다.

다음 테스트 항목

아군 네 명을 앞뒤로 배치
앞쪽 유닛만 적을 직접 발견하도록 설정
뒤쪽 유닛이 공유받은 적에게 이동하는지 확인
TeamIndex가 다른 유닛에게 정보가 전달되지 않는지 확인
공격 중인 유닛의 타겟이 불필요하게 변경되지 않는지 확인
유닛이 제자리에서 떨거나 반복적으로 멈추는지 확인
적 제거 후 다음 타겟을 정상적으로 탐색하는지 확인
AllyAssistRadius를 1200, 1300, 1500 순서로 비교

느낀 점

유닛이 자동 공격 기능을 가지고 있더라도 각 유닛이 독립적으로만 적을 탐색하면 부대 단위의 전투처럼 보이지 않을 수 있다.

이번 작업을 통해 개별 유닛의 탐색 범위를 무작정 넓히는 것보다, 적을 먼저 발견한 유닛이 제한된 범위 안의 아군에게 정보를 전달하도록 만드는 것이 자연스러운 집단 전투 구현에 더 적합하다는 점을 확인했다.

선택한 유닛의 3D 초상화가 표시되지 않는 문제

editor66484 — Mon, 31 Aug 2026 00:38:08 +0900

문제 상황

지휘관이나 유닛을 선택하면 체력과 이동속도 같은 정보는 정상적으로 갱신됐지만, 왼쪽의 초상화 영역에는 선택한 캐릭터가 나타나지 않았다.

이를 통해 다음 내용은 정상이라는 것을 확인할 수 있었다.

유닛 선택 이벤트는 정상적으로 발생함
선택 정보가 InGameUI까지 전달됨
선택 정보 패널의 표시 및 텍스트 갱신은 정상 작동함
문제 범위는 Scene Capture → Render Target → UI Material 출력 과정으로 좁혀짐

원인 분석

Scene Capture Component 2D가 실제 게임 월드를 기준으로 촬영하면서, 초상화용 캐릭터뿐만 아니라 하늘과 지형, 주변 오브젝트까지 함께 렌더링하고 있었다.

배경을 투명하게 만드는 머티리얼만으로는 카메라에 들어오는 월드 오브젝트를 완전히 제외할 수 없었다. 반대로 캡처 설정이 올바르지 않으면 배경과 함께 초상화용 메시도 표시되지 않는 문제가 발생했다.

결국 초상화 카메라가 촬영해야 할 대상을 명확하게 제한할 필요가 있었다.

해결 과정

BP_SFUnitPortraitActor의 이벤트 그래프에서 BeginPlay 시점에 Show Only Component를 호출하도록 구성했다.

노드 연결은 다음과 같다.

Event BeginPlay
    → Show Only Component

Target
    → Portrait Capture

In Component
    → Portrait Mesh

그리고 Portrait Capture의 Primitive Render Mode를 Use ShowOnly List 방식으로 설정했다.

이 설정으로 Scene Capture Component 2D가 전체 게임 월드를 촬영하지 않고, 초상화 액터가 가진 Portrait Mesh만 Render Target에 출력하도록 제한했다.

처리 흐름

flowchart LR A["게임 시작"] --> B["BP_SFUnitPortraitActor BeginPlay"] B --> C["Show Only Component 호출"] C --> D["Portrait Mesh를 ShowOnly 목록에 등록"] D --> E["Scene Capture가 Portrait Mesh만 촬영"] E --> F["Render Target에 캐릭터만 출력"] F --> G["UI Material을 통해 초상화 표시"]

추가로 확인한 문제

문제 해결 과정에서 UI의 기존 Set Brush From Texture가 Render Target 머티리얼 출력을 다시 덮어쓰는 현상도 확인했다.

이를 해결하기 위해 선택 대상의 종류를 검사하여 출력 방식을 분리했다.

Commander, Unit
- Set Brush From Material
- Render Target 기반 3D 초상화 출력
건물, 광물 등
- 기존 Set Brush From Texture
- 데이터 테이블 기반 2D 이미지 출력

이 구조를 사용하면 기존 UI 데이터 테이블을 제거하지 않고도 2D 이미지와 3D 초상화를 함께 사용할 수 있다.

결과

Show Only Component 적용 후에는 다음과 같은 효과를 얻을 수 있었다.

월드 배경, 하늘, 지형이 초상화에 포함되는 현상 방지
선택한 지휘관과 유닛의 Skeletal Mesh만 출력
기존 건물 및 광물의 2D 이미지 출력 방식 유지
하나의 선택 정보 패널에서 2D와 3D 초상화를 대상 종류에 따라 구분하여 사용

고찰

Render Target의 알파 값을 조절하는 것은 촬영된 결과의 투명도를 처리하는 작업이다. 하지만 촬영 단계에서 불필요한 월드 오브젝트가 포함된 경우에는 머티리얼 처리만으로 문제를 해결하기 어렵다.

따라서 이번 작업에서는 다음 순서가 중요했다.

Scene Capture가 촬영할 대상을 Show Only Component로 제한한다.
Render Target의 알파 채널을 UI 머티리얼에서 처리한다.
선택 대상의 종류에 따라 3D 머티리얼과 2D 텍스처 출력을 분기한다.

즉, 배경 투명화와 촬영 대상 제한은 서로 다른 역할이며 두 설정을 함께 적용해야 안정적인 3D 초상화를 구현할 수 있었다.

RTS 선택 UI에 3D 초상화 연동

editor66484 — Sun, 30 Aug 2026 22:29:49 +0900

오늘의 목표

기존 InGameUI의 선택 정보 패널에 Render Target 기반 3D 초상화를 연결하고, 선택 대상에 따라 2D 이미지와 3D 초상화를 구분해 출력하는 작업을 진행했다.

지휘관·전투 유닛: 실시간 3D 초상화
건물·광물: 기존 데이터테이블의 2D 이미지
선택 해제: 선택 정보 패널 숨김

1. 기존 2D 초상화 출력 구조 확인

기존 WBP_SFSelectedInfoPanel에서는 데이터테이블에서 가져온 PortraitImage를 SelectedPortraitImage에 적용하고 있었다.

FSFSelectableInfo.PortraitImage
→ Set Brush From Texture
→ SelectedPortraitImage

이 구조는 건물이나 광물처럼 정적인 2D 이미지를 표시하는 데 적합하다. 하지만 지휘관과 전투 유닛에는 Render Target Material을 사용해야 하므로 선택 대상에 따른 분기가 필요했다.

2. 2D 이미지와 3D 초상화 출력 분기

SelectableType을 기준으로 지휘관과 유닛을 확인하도록 구성했다.

SelectableType == Commander
SelectableType == Unit
→ OR
→ Branch

분기 결과:

True
→ Set Brush From Material
→ M_SFUnitPortraitUI

False
→ Set Brush From Texture
→ 데이터테이블의 PortraitImage

이 구조를 통해 기존 건물·광물 이미지 기능을 제거하지 않고, 지휘관과 유닛에만 3D 초상화를 적용할 수 있게 되었다.

최종 분기 구조

Commander 또는 Unit
→ Render Target Material

MainBuilding
NormalBuilding
ProductionBuilding
ResourceBuilding
→ 기존 PortraitImage

3. HUD와 Portrait Actor 연결

SFInGameHUDWidget에서 실제 선택된 캐릭터의 Skeletal Mesh를 가져와 공용 SFUnitPortraitActor에 전달하도록 연결했다.

유닛 선택
→ SelectedActor 확인
→ ACharacter Cast
→ SkeletalMeshComponent 조회
→ Skeletal Mesh Asset 획득
→ ApplyPortrait 호출

핵심 호출 구조:

UnitPortraitActor->ApplyPortrait(
    SelectedSkeletalMesh,
    nullptr
);

현재는 선택한 유닛의 Mesh를 교체하는 기능까지 연결되어 있으며, Animation은 아직 nullptr로 전달하고 있다.

또한 다음 선택 흐름에서도 초상화가 갱신되도록 구성했다.

단일 유닛 선택
다중 선택에서 대표 유닛 변경
선택 해제
선택 대상 파괴

4. Render Target 배경 투명화

Scene Capture 결과에 인게임 배경이 함께 촬영되는 문제가 있었다. Render Target의 Alpha 채널과 UI Material을 이용해 배경을 투명하게 처리했다.

Render Target

Clear Color
R = 0
G = 0
B = 0
A = 0

Scene Capture

Capture Source
→ SceneColor (HDR) in RGB, Inv Opacity in A

UI Material

Render Target RGB
→ Final Color

Render Target Alpha
→ OneMinus
→ Opacity

처음에는 Alpha 방향이 반대로 적용되어 캐릭터가 사라지고 배경만 출력되는 문제가 있었다. OneMinus를 적용하여 캐릭터 영역은 표시하고 배경 영역은 투명하게 처리했다.

실제 인게임 맵에서는 하늘, 나무, 지형 등이 불투명 오브젝트로 함께 촬영될 수 있기 때문에 PortraitMesh만 촬영하도록 제한하는 과정도 필요했다.

Primitive Render Mode
→ Use ShowOnly List

Show Only Component
→ PortraitMesh

5. 초상화 조명 변경

기존 Rect Light Component를 Spot Light Component로 교체했다.

변경된 파일:

SFUnitPortraitActor.h
- URectLightComponent 제거
- USpotLightComponent 추가
SFUnitPortraitActor.cpp
- RectLightComponent.h 제거
- SpotLightComponent.h 추가
- PortraitSpotLight 생성

조명의 위치와 밝기는 코드에 고정하지 않고 BP_SFUnitPortraitActor에서 직접 조정할 수 있도록 유지했다.

6. 실제 지휘관 선택 결과

지휘관을 선택했을 때 실제 선택 정보 패널의 초상화 영역에 지휘관 Skeletal Mesh가 출력되는 것을 확인했다.

확인된 처리 흐름:

지휘관 클릭
→ SelectableType = Commander
→ Set Brush From Material
→ 지휘관 Mesh를 Portrait Actor에 적용
→ Render Target 출력
→ 실제 InGameUI에 표시

7. 실제 전투 유닛 선택 결과

전투 유닛을 선택했을 때 같은 PortraitActor와 Render Target을 재사용하면서 선택한 유닛의 Mesh로 교체되는 것을 확인했다.

유닛마다 별도의 카메라나 Render Target을 생성하지 않고, 공용 Portrait Actor 하나를 재사용했다.

지휘관 선택
→ 지휘관 Mesh 출력

전투 유닛 선택
→ 같은 PortraitMesh를 전투 유닛 Mesh로 교체

RTS처럼 다수의 유닛이 생성되는 환경에서 Scene Capture를 유닛마다 생성하지 않아도 된다는 장점이 있다.

[Unreal Engine 5] Scene Capture와 Render Target을 활용한 3D 포트레이트 구현

editor66484 — Wed, 26 Aug 2026 00:14:37 +0900

RTS 게임에서 유닛을 선택했을 때 미니맵 왼쪽에 해당 유닛의 3D 초상화를 표시하기 위한 포트레이트 시스템을 작업했다.

최종적으로 구현하려는 흐름은 다음과 같다.

flowchart LR A["유닛 선택"] --> B["포트레이트 데이터 조회"] B --> C["Skeletal Mesh 및 Animation 적용"] C --> D["Scene Capture Component 2D 촬영"] D --> E["Render Target 출력"] E --> F["InGameUI 포트레이트 표시"]

이번 작업은 크게 다음 두 단계로 나누어 진행했다.

Blueprint를 이용한 Render Target 사전 테스트
재사용 가능한 C++ 포트레이트 액터 작성

1. Blueprint 기반 사전 테스트

C++ 구현에 들어가기 전, Scene Capture Component 2D와 Render Target으로 실제 3D 유닛을 촬영할 수 있는지 Blueprint를 이용해 먼저 검증했다.

테스트에 사용한 구성은 다음과 같다.

BP_SFUnitPortraitTest
├─ DefaultSceneRoot
├─ PortraitMesh
├─ PortraitCapture
└─ PortraitLight

PortraitMesh: 초상화로 출력할 Skeletal Mesh
PortraitCapture: 3D 모델을 촬영할 Scene Capture
PortraitLight: 캐릭터의 얼굴과 상반신을 비추는 조명
RT_SFUnitPortraitTest: 촬영 결과를 저장하는 Render Target

Render Target 생성

Scene Capture Component 2D의 촬영 결과를 저장하기 위해 별도의 Render Target 에셋을 생성했다.

에셋에 캐릭터 모습이 표시된 것을 통해 다음 연결이 정상적으로 동작한다는 것을 확인했다.

PortraitMesh
→ SceneCaptureComponent2D
→ RT_SFUnitPortraitTest

3D 캐릭터 출력 결과

카메라 위치와 회전, FOV를 조절하여 캐릭터의 얼굴과 상반신이 화면 중앙에 나오도록 설정했다.

Render Target에서 다음 사항을 확인할 수 있었다.

Skeletal Mesh가 정상적으로 촬영됨
카메라 구도 조절 가능
게임 실행 중 Idle Animation 재생 가능
Render Target이 실시간으로 갱신됨

처음에는 에디터 화면에서 애니메이션이 움직이지 않아 설정 문제라고 생각했다. 하지만 현재 구성은 PIE 또는 실제 게임 실행 중에 Skeletal Mesh 애니메이션 Tick이 시작되는 구조였다.

에디터 상태
→ 정지된 마지막 프레임이 보일 수 있음

게임 실행
→ Animation Tick
→ Scene Capture 실시간 촬영
→ 움직이는 Render Target 출력

2. 공통 C++ 포트레이트 액터 설계

Blueprint 테스트에서 기능이 정상적으로 동작하는 것을 확인한 후, 유닛마다 포트레이트 Blueprint를 따로 만들지 않도록 공통 C++ 액터를 작성했다.

생성한 클래스는 다음과 같다.

ASFUnitPortraitActor

3. C++ 컴포넌트 구조

ASFUnitPortraitActor는 다음 컴포넌트로 구성했다.

ASFUnitPortraitActor
├─ SceneRoot
├─ PortraitMesh
├─ PortraitCapture
└─ PortraitLight

SceneRoot

포트레이트를 구성하는 모든 컴포넌트의 기준점이다.

SceneRoot =
    CreateDefaultSubobject<USceneComponent>(
        TEXT("SceneRoot")
    );

SetRootComponent(SceneRoot);

PortraitMesh

선택된 유닛의 Skeletal Mesh를 표시한다.

PortraitMesh =
    CreateDefaultSubobject<USkeletalMeshComponent>(
        TEXT("PortraitMesh")
    );

PortraitMesh->SetupAttachment(SceneRoot);

PortraitCapture

3D 캐릭터를 촬영해 Render Target으로 전달한다.

PortraitCapture =
    CreateDefaultSubobject<USceneCaptureComponent2D>(
        TEXT("PortraitCapture")
    );

PortraitCapture->SetupAttachment(SceneRoot);

PortraitLight

Point Light보다 넓은 면에서 빛을 비출 수 있도록 Rect Light Component를 사용했다.

PortraitLight =
    CreateDefaultSubobject<URectLightComponent>(
        TEXT("PortraitLight")
    );

PortraitLight->SetupAttachment(SceneRoot);

Rect Light를 선택한 이유는 얼굴 일부분만 강하게 밝아지는 현상을 줄이고, 캐릭터 전체에 비교적 부드럽게 빛을 전달하기 위해서다.

4. 선택 유닛의 Mesh와 Animation 적용

선택된 유닛에 따라 포트레이트 모델을 교체할 수 있도록 ApplyPortrait() 함수를 구성했다.

bool ASFUnitPortraitActor::ApplyPortrait(
    USkeletalMesh* NewPortraitMesh,
    UAnimationAsset* NewPortraitAnimation
)

Skeletal Mesh 교체

PortraitMesh->SetSkeletalMesh(
    NewPortraitMesh
);

공통 PortraitMesh 하나를 사용하고 선택된 유닛에 따라 메시만 변경한다.

따라서 유닛마다 다음 에셋을 새로 만들 필요가 없다.

Scene Capture
Render Target
포트레이트 액터
UI Material

유닛마다 준비할 데이터는 다음 두 가지다.

Skeletal Mesh
Idle Animation

단일 Animation Asset 재생

포트레이트는 실제 전투 상태를 재현할 필요가 없기 때문에, 복잡한 Animation Blueprint 대신 Idle Animation을 직접 반복 재생하도록 구성했다.

PortraitMesh->SetAnimationMode(
    EAnimationMode::AnimationSingleNode
);

PortraitMesh->SetAnimation(
    NewPortraitAnimation
);

PortraitMesh->Play(true);

이 방식은 다음 의존성이 필요하지 않다는 장점이 있다.

AI Controller
Character Movement
이동 속도
전투 상태
공격 대상

5. 화면에 보이지 않아도 애니메이션 갱신

포트레이트 전용 메시가 일반 게임 카메라에 보이지 않으면 엔진 최적화에 의해 애니메이션 Pose 갱신이 멈출 수 있다.

이를 방지하기 위해 다음 설정을 적용했다.

PortraitMesh->VisibilityBasedAnimTickOption =
    EVisibilityBasedAnimTickOption::
    AlwaysTickPoseAndRefreshBones;

이 설정을 통해 다음 작업을 계속 수행할 수 있다.

Animation Tick
Pose 업데이트
Bone Transform 갱신
Scene Capture에 변경된 자세 반영

Scene Capture 전용 캐릭터에서 애니메이션이 정지하는 문제를 방지하기 위한 중요한 설정이다.

6. Render Target 연결

C++에서 특정 Render Target 경로를 하드코딩하지 않고, Blueprint 자식 클래스에서 Render Target을 지정할 수 있도록 구성했다.

UPROPERTY(
    EditDefaultsOnly,
    BlueprintReadOnly,
    Category = "SF|Portrait"
)
TObjectPtr<UTextureRenderTarget2D>
    PortraitRenderTarget = nullptr;

게임 시작 시 지정된 Render Target을 Scene Capture에 연결한다.

PortraitCapture->TextureTarget =
    PortraitRenderTarget;

이 구조를 사용하면 C++ 코드를 수정하지 않고도 Blueprint에서 다른 Render Target을 교체할 수 있다.

7. 캡처 활성화와 비활성화

Render Target을 매 프레임 갱신하면 추가적인 렌더링 비용이 발생한다.

따라서 포트레이트가 필요할 때만 Scene Capture를 활성화할 수 있도록 함수를 분리했다.

void ASFUnitPortraitActor::
    SetPortraitCaptureEnabled(bool bEnabled)
{
    PortraitCapture->bCaptureEveryFrame =
        bEnabled;

    PortraitCapture->bCaptureOnMovement =
        bEnabled;

    if (bEnabled)
    {
        PortraitCapture->CaptureScene();
    }
}

예상되는 사용 흐름은 다음과 같다.

유닛 선택
→ 포트레이트 Mesh와 Animation 적용
→ Scene Capture 활성화

선택 해제
→ 애니메이션 정지
→ PortraitMesh 숨김
→ Scene Capture 비활성화

RTS 게임에서는 화면에 많은 유닛과 건물이 존재하므로, 포트레이트 렌더링도 필요할 때만 동작하도록 관리하는 것이 중요하다.

8. 최신 InGameUI 구조 확인

최신 병합 소스를 확인한 결과, InGameUI에는 다음 기능이 추가된 상태였다.

단일 유닛 선택
다중 유닛 선택
다중 선택 중 대표 유닛 변경
건설 모드 전환
이동 목적지 표시
스테이지 튜토리얼
결과 UI

포트레이트는 기존 선택 시스템을 새로 만드는 것이 아니라 현재 선택 흐름에 연결할 예정이다.

SFInGameHUDWidget
→ 선택 정보 확정
→ SFUnitPortraitActor::ApplyPortrait()
→ Render Target 갱신
→ 미니맵 왼쪽 포트레이트 UI 출력

특히 다중 선택 중 대표 유닛이 변경될 때도 포트레이트가 함께 변경되어야 한다.

현재 진행 상태

완료

Blueprint 기반 포트레이트 테스트 액터 구성
Scene Capture와 Render Target 연결
3D 캐릭터 얼굴 및 상반신 출력
Idle Animation 반복 재생 확인
C++ ASFUnitPortraitActor 작성
Mesh 교체 함수 작성
Animation Asset 적용 함수 작성
Capture 활성화·비활성화 함수 작성
Rect Light Component 구성

테스트 전

C++ 기반 BP_SFUnitPortraitActor 생성
C++ 컴포넌트 에디터 출력 확인
Render Target 재연결
Rect Light 실제 밝기 조절
카메라 위치와 FOV 조절
ApplyPortrait() 실행 테스트

이후 진행 예정

Render Target 배경 투명화
Scene Capture의 캐릭터 전용 Show Only 설정
UI Material 제작
유닛별 Mesh·Animation 데이터 등록
InGameUI 선택 시스템 연결
미니맵 왼쪽 포트레이트 배치
선택 해제와 유닛 사망 처리
다중 선택 대표 유닛 변경 처리
Scene Capture 성능 테스트

Scene Capture Component와 3D 애니메이션 적용

editor66484 — Mon, 24 Aug 2026 00:12:48 +0900

미니맵 하단 UI에 선택한 유닛의 모습을 표시하기 위해 처음에는 일반적인 2D 이미지를 사용하는 방법을 고려했다.

하지만 유닛의 실제 외형과 애니메이션을 보여주려면 정적인 이미지보다 3D 모델을 직접 UI에 출력하는 방식이 더 적합하다고 판단했다.

1. 발생한 문제

UMG의 Image 위젯은 3D 액터나 Skeletal Mesh를 직접 출력할 수 없다.

따라서 다음 기능을 구현하려면 중간 변환 과정이 필요했다.

선택한 유닛의 3D 모델 출력
유닛의 Idle 애니메이션 재생
미니맵 하단 UI 영역에 모델 표시
유닛이 변경되면 프리뷰 모델도 변경

처음에는 월드에 배치된 실제 유닛을 직접 촬영하는 방법을 생각했지만, 다음과 같은 문제가 있었다.

카메라 주변의 배경이 함께 촬영될 수 있음
실제 유닛이 이동하면 프리뷰 구도가 변경됨
다른 유닛이나 이펙트가 화면에 포함될 수 있음
인게임 애니메이션 상태와 UI 프리뷰 상태가 서로 영향을 받을 수 있음

2. 해결 방향: 프리뷰 전용 액터 구성

실제 게임 유닛을 직접 촬영하는 대신, UI 출력을 담당하는 프리뷰 전용 액터를 구성하는 방향으로 변경했다.

SFUnitPreviewActor
├─ Scene Component
├─ Skeletal Mesh Component
└─ Scene Capture Component 2D

Skeletal Mesh Component: 선택한 유닛의 3D 모델 표시
Scene Capture Component 2D: 프리뷰 모델 촬영
Texture Render Target 2D: 촬영 결과 저장
UMG Image: Render Target 결과 출력

전체 처리 과정은 다음과 같다.

flowchart LR A["유닛 선택"] --> B["프리뷰 메시 변경"] B --> C["Idle 애니메이션 적용"] C --> D["Scene Capture Component 2D 촬영"] D --> E["Render Target 저장"] E --> F["미니맵 하단 UMG Image 출력"]

3. Scene Capture 범위 문제

Scene Capture Component 2D를 단순하게 사용하면 프리뷰 모델뿐만 아니라 주변 배경과 다른 액터도 함께 촬영될 수 있다.

이를 방지하기 위해 프리뷰에 사용할 액터만 렌더링하도록 설정하는 방법을 확인했다.

Primitive Render Mode를 필요한 액터만 표시하도록 설정
프리뷰 액터를 Show Only Actors에 등록
프리뷰용 배경과 조명을 별도로 구성
카메라와 모델의 위치를 고정해 일정한 구도 유지

이 구조를 사용하면 실제 게임 맵의 상태와 관계없이 동일한 유닛 프리뷰 화면을 출력할 수 있다.

4. 애니메이션이 재생되지 않는 문제

프리뷰의 Skeletal Mesh에 인게임용 Animation Blueprint를 그대로 적용하는 방법도 고려했다.

하지만 인게임 Animation Blueprint는 다음 값을 참조할 가능성이 있다.

이동 속도
AI Controller
Character Movement Component
공격 상태
현재 타깃
지상 이동 여부

프리뷰 전용 액터에는 이러한 정보가 없기 때문에 Animation Blueprint의 조건을 충족하지 못하고 기본 포즈로 정지할 수 있다.

5. 해결 방향: 단일 애니메이션 재생

UI 프리뷰에서는 실제 전투 상태를 전부 재현할 필요가 없기 때문에, Idle 애니메이션을 직접 반복 재생하는 방식을 우선 적용하는 것이 적합하다고 판단했다.

PreviewMesh->SetAnimationMode(
    EAnimationMode::AnimationSingleNode
);

PreviewMesh->PlayAnimation(
    PreviewIdleAnimation,
    true
);

이 방식은 다음과 같은 장점이 있다.

AI Controller가 필요하지 않음
이동 속도나 전투 상태가 필요하지 않음
Animation Blueprint의 조건에 영향을 받지 않음
UI 프리뷰에 필요한 애니메이션만 간단하게 재생 가능

추후 공격, 대기, 선택 등의 여러 애니메이션이 필요해지면 프리뷰 전용 Animation Blueprint를 별도로 구성할 수 있다.

6. 성능 문제에 대한 고민

Capture Every Frame을 활성화하면 애니메이션이 자연스럽게 표시되지만, Scene Capture가 매 프레임 렌더링되기 때문에 추가적인 렌더링 비용이 발생한다.

특히 RTS 게임은 다수의 유닛과 건물을 동시에 처리하므로 Scene Capture를 항상 활성화하면 성능에 영향을 줄 수 있다.

이를 줄이기 위해 다음 방식을 고려했다.

유닛 프리뷰 UI가 보일 때만 Scene Capture 활성화
유닛 선택이 해제되면 캡처 비활성화
Render Target 해상도를 UI 크기에 맞게 제한
프리뷰 모델과 필요한 배경만 렌더링
정지 화면만 필요하면 선택 변경 시 한 번만 캡처
애니메이션 출력이 필요할 때만 Capture Every Frame 사용

결과 및 배운 점

이번 트러블슈팅을 통해 UMG에서 3D 모델을 직접 출력하는 것이 아니라 다음과 같은 렌더링 과정이 필요하다는 것을 확인했다.

3D 모델
→ Scene Capture Component 2D
→ Texture Render Target 2D
→ UI Material
→ UMG Image

또한 인게임 Animation Blueprint를 프리뷰에 그대로 재사용하면 의존성 문제로 애니메이션이 동작하지 않을 수 있다는 점을 확인했다.

따라서 현재 구조에서는 다음 방식을 우선 적용하는 것이 적절하다.

프리뷰 전용 액터 사용
필요한 모델만 Scene Capture로 촬영
Idle Animation Sequence 직접 반복 재생
UI가 표시될 때만 Scene Capture 활성화

이를 통해 실제 인게임 로직과 UI 프리뷰를 분리하면서도 선택된 유닛의 3D 외형과 애니메이션을 안정적으로 표현할 수 있는 구조를 마련했다.

[Unreal Engine 5] TeamIndex 기반 자원 관리와 3D 유닛 프리뷰 구현

editor66484 — Mon, 24 Aug 2026 00:11:17 +0900

오늘은 RTS 프로젝트의 팀별 자원 관리 구조를 정리하고, Render Target과 Scene Capture Component를 활용해 UI에 3D 유닛 모델을 표시하는 작업을 진행했다.

1. TeamIndex 기반 상태 관리

기존 자원 데이터가 하나의 공용 값으로 관리되면 플레이어와 AI의 자원이 섞일 수 있다.

예를 들어 AI가 광물을 획득했는데 플레이어의 광물까지 증가하는 문제가 발생할 수 있다. 이를 방지하기 위해 GameState에서 TeamIndex를 기준으로 각 팀의 데이터를 분리하도록 구조를 설계했다.

TeamIndex 0: 플레이어
TeamIndex 1: 적 AI
필요하면 이후 다른 팀도 추가 가능

전체 구조는 다음과 같다.

flowchart LR A["자원 획득"] --> B["TeamIndex 확인"] B --> C["GameState"] C --> D{"TeamIndex"} D -->|"0"| E["플레이어 자원"] D -->|"1"| F["적 AI 자원"]

중요한 점은 TeamIndex가 종족을 나타내는 값이 아니라 해당 액터가 어느 팀에 소속되어 있는지 구분하는 값이라는 것이다.

종족까지 구분해야 한다면 추후 RaceType 같은 별도의 열거형을 사용하는 것이 적절하다.

2. 팀별 자원 구조체 추가

각 팀의 자원을 하나로 묶어 관리할 수 있도록 FSFTeamResourceState 구조체를 구성했다.

USTRUCT(BlueprintType)
struct FSFTeamResourceState
{
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "SF|Resource")
    int32 Mineral = 0;

    UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "SF|Resource")
    int32 Ether = 0;

    UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "SF|Population")
    int32 CurrentPopulation = 0;

    UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = "SF|Population")
    int32 MaximumPopulation = 10;
};

구조체에 포함한 데이터는 다음과 같다.

변수역할

Mineral	일반적인 건설 및 유닛 생산에 사용하는 광물
Ether	특정 건물이나 고급 기능에 사용하는 희귀 자원
CurrentPopulation	현재 생산된 유닛이 사용하는 인구수
MaximumPopulation	현재 생산할 수 있는 최대 인구수

SF 접두어와 Pascal Case 규칙을 적용해 프로젝트의 명명 규칙도 유지했다.

3. GameState에서 팀별 자원 저장

싱글플레이 RTS에서도 플레이어와 AI의 자원 상태는 인게임 도중 계속 변경된다. 따라서 게임 진행 상태를 관리하는 GameState에 팀별 자원 구조체를 저장하도록 구성했다.

UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "SF|Resource")
TMap<int32, FSFTeamResourceState> TeamResources;

TMap의 구성은 다음과 같다.

TeamIndex → 해당 팀의 자원 정보

예를 들면 다음과 같이 저장된다.

0 → 플레이어의 광물, 에테르, 인구수
1 → 적 AI의 광물, 에테르, 인구수

팀별 자원 조회는 다음과 같은 흐름으로 처리한다.

const FSFTeamResourceState* TeamResource =
    TeamResources.Find(TeamIndex);

if (TeamResource == nullptr)
{
    return 0;
}

return TeamResource->Mineral;

이 구조를 사용하면 자원을 획득하거나 소비할 때 반드시 TeamIndex를 함께 전달할 수 있다.

AddMineral(TeamIndex, Amount);
TrySpendResource(TeamIndex, MineralCost, EtherCost);
AddPopulation(TeamIndex, PopulationCost);

UI는 플레이어 팀인 TeamIndex 0의 값만 가져와 출력하면 된다.

4. Render Target을 활용한 3D 유닛 프리뷰

다음으로 미니맵 하단 UI에 선택된 유닛의 3D 모델을 보여주는 기능을 구성했다.

일반적인 이미지 파일을 사용하는 방식이 아니라 별도의 카메라로 실제 유닛 모델을 촬영하고, 그 화면을 UI에 출력하는 방식이다.

전체 흐름은 다음과 같다.

```mermaid
flowchart LR
    A["3D 유닛 모델"] --> B["Scene Capture Component 2D"]
    B --> C["Texture Render Target 2D"]
    C --> D["UI Material"]
    D --> E["UMG Image"]
    E --> F["미니맵 하단 유닛 프리뷰"]
```

이 방식은 정적인 초상화와 다르게 실제 3D 모델과 애니메이션을 UI 안에서 보여줄 수 있다는 장점이 있다.

5. Scene Capture Component 사용

3D 모델을 촬영하기 위해 프리뷰 전용 액터에 다음 컴포넌트를 구성했다.

SFUnitPreviewActor
├─ Scene Component
├─ Skeletal Mesh Component
└─ Scene Capture Component 2D

Scene Capture Component 2D는 게임 월드를 별도의 카메라 시점으로 촬영하고, 결과를 Texture Render Target 2D에 전달한다.

주요 설정은 다음과 같다.

Texture Target: 생성한 Render Target 지정
Capture Source: Final Color 사용
Projection Type: Perspective
Primitive Render Mode: 필요한 액터만 렌더링
Capture Every Frame: 애니메이션을 표시할 경우 활성화
Capture On Movement: 움직일 때만 갱신할 경우 사용

프리뷰에 필요한 유닛만 출력하려면 Show Only Actors를 활용할 수 있다. 이렇게 하면 실제 게임 맵의 배경이나 불필요한 오브젝트가 Render Target에 함께 나타나는 것을 방지할 수 있다.

6. Render Target을 UI에 연결

Scene Capture Component 2D에서 촬영한 화면을 UMG에 표시하기 위해 다음 순서로 연결했다.

Texture Render Target 2D 생성
Render Target을 사용하는 UI Material 생성
Material Domain을 User Interface로 설정
Render Target을 Texture Sample에 연결
UI 위젯의 Image Brush에 해당 Material 적용

SceneCapture2D
    ↓
Texture Render Target 2D
    ↓
UI Material
    ↓
UMG Image

최종적으로 미니맵 하단의 Image 위젯을 통해 선택된 유닛의 3D 모델을 표시할 수 있다.

7. 3D 애니메이션 적용 방법 조사

3D 유닛 프리뷰가 정지된 모델로만 보이지 않도록 Skeletal Mesh Component에 애니메이션을 적용하는 방법도 확인했다.

적용 방식은 크게 두 가지가 있다.

Animation Blueprint 사용

실제 인게임 유닛과 동일한 애니메이션 블루프린트를 적용하는 방식이다.

PreviewMesh->SetAnimInstanceClass(AnimationBlueprintClass);

다만 인게임 애니메이션 블루프린트가 이동 속도나 AI Controller 상태를 요구한다면 프리뷰 액터에서는 정상적으로 동작하지 않을 수 있다.

단일 Animation Sequence 재생

프리뷰용 Idle 애니메이션 하나만 반복 재생하는 방식이다.

PreviewMesh->SetAnimationMode(
    EAnimationMode::AnimationSingleNode
);

PreviewMesh->PlayAnimation(
    PreviewIdleAnimation,
    true
);

유닛 프리뷰에서는 복잡한 인게임 상태가 필요하지 않기 때문에, 우선은 Idle Animation Sequence를 반복 재생하는 방식이 더 단순하고 안정적이다.

작업하면서 확인한 점

팀 데이터와 종족 데이터는 분리해야 한다

TeamIndex는 플레이어와 적 AI를 구분하기 위한 값이다. 비스트, 인간 등의 종족 정보를 함께 처리하려면 별도의 RaceType이 필요하다.

UI가 자원 값을 직접 변경하면 안 된다

UI는 GameState에서 자원 값을 조회하고 화면에 표시하는 역할만 담당해야 한다. 실제 자원 증감은 채집 건물, 생산 시스템 또는 게임 로직을 통해 처리해야 한다.

Scene Capture는 성능을 고려해야 한다

Capture Every Frame을 사용하면 매 프레임 Render Target을 갱신한다. 유닛 프리뷰가 항상 표시될 필요가 없다면 다음과 같이 최적화할 수 있다.

선택된 유닛이 바뀔 때만 캡처
결과창이나 HUD가 열려 있을 때만 활성화
Render Target 해상도를 필요 이상으로 크게 설정하지 않기
프리뷰용 조명과 메시만 렌더링하기

RTS 게임에서는 화면에 많은 유닛이 존재하므로, 프리뷰 UI까지 불필요하게 매 프레임 갱신하지 않도록 주의해야 한다.

작업 결과

이번 작업을 통해 다음 구조를 정리했다.

GameState에서 TeamIndex별 데이터 분리
광물, 에테르, 현재 인구수, 최대 인구수를 하나의 구조체로 관리
플레이어와 AI의 자원이 서로 섞이지 않는 구조 마련
Render Target을 이용한 3D 유닛 프리뷰 흐름 구성
Scene Capture Component 2D와 UMG Image 연결 방식 확인
프리뷰 유닛에 Idle 애니메이션을 적용하는 방법 조사

다음 작업에서는 실제 자원 채집 시스템이 TeamIndex를 전달하도록 연결하고, 선택된 유닛이 변경될 때 프리뷰 메시와 애니메이션도 함께 변경되도록 확장할 예정이다.