옆히

TIL260616 - Ch3 - 2 - 카툰 렌더링

옆집히드라 — Tue, 16 Jun 2026 18:32:21 +0900

1. 핵심 개념

하프 램버트 & 램버트
MPC
블린-퐁 스페큘러

2. 상세 내용

관련 문서에 참고한 이득우의 카룬 렌더링 강의 내용을 정리함

2.1. 카툰 렌더링

2.1.1. 카툰 렌더링의 기본 원리

렌더링, 메터리얼, Diffuse, Specular, BRDF 기본 개념(램버트 디퓨즈, 램버트 BRDF가 원론적)

반사량에 따라 정해지는 표면에 들어오는 빛의 양 > Illuminance
디퓨즈 계산 식은 $cos \theta$ (세타는 점 p에서 노말 벡터 N과 빛의 방향 라이트 벡터 L 사이의 각)

이때 벡터의 크기가 1이라면 $\vec{a} \cdot \vec{b} = a_x b_x + a_y b_y = \Vert{}\vec{a}\Vert{} \Vert{}\vec{b}\Vert{} \cos\theta$ 에 의해서 컴퓨터에 유리한 덧셈, 곱셈 연산만으로 사잇각을 구할 수 있음

램버트 연산은 직접광 연산을 위한 것으로 간접광 연산을 위해서는 또 다른 모델이 필요하다. 과거에는 이 간접광 연산이 매우 무거웠기 때문에 하프 램버트 같은 경량 모델을 사용했다.

하프 램버트

Half Lambert lighting is a technique designed to prevent the rear of an object losing its shape and looking too flat.

Half Lambert is a completely non-physical technique and gives a purely percieved visual enhancement and is an example of a forgiving lighting model.

// 라이트 값 계산
float difLight = dot(s.Normal, lightDir);
// 라이트 값을 하프 램버트 값으로
float hLambert = difLight * 0.5 + 0.5;

하프 램버트 = cos에(normalized 된 두 벡터의 dot)에 0.5를 곱하고 0.5를 더해서 모든 영역에 그림자가 지게 함

밴드(Band) 셰이딩

하프 램버트에서 ceil 함수를 사용하면 그림자 영역을 띠로 나누어 그리는 밴드 셰이딩을 할 수 있다. 이는 카툰 렌더링의 기초가 된다.

올림 함수(치역 0

~~1)에 나눌 영역의 수인 N을 곱한 뒤에 floor(또는 ceil, round) 함수를 취한 뒤에 나온 값을 다시 N으로 나누면(치역 0~~

1 맞춤) 밴딩 효과를 구현할 수 있다.

2.1.2. 카툰 명암을 조절하고 색을 입히는 방법

가산 모델(RGB)

색에 흑백 그레이디언트를 곱하면 밝은 곳에서 점차 어두워지는 음영 표현이 가능(색 * 무채색(어둡기))

그레이디언트에 색을 곱하는 것만으로 모델에 음영 표현이 가능하다.

lerp

이때 선형 보간 $lerp(A, B, \alpha) = A + \alpha (B - A)$ 를 사용해서 어두운 영역과 밝은 영역의 컬러를 각각 A, B로 두어서 보간할 수 있다.

2.1.1에서 언급한 밴드 쉐이딩을 사용하여 암부와 명부에 컬러를 지정해서 lerp로 보간한 메테리얼의 모습이다.

step

step(y, x) y를 기준으로 반올림(round) 한다. 위와 같이 구성하면 매초 0->1, 1->0으로 왕복하는 모습을 볼 수 있다.

Smooth step

TIL260518 - VFX

SmoothStep graph

입력값 $x$를 $min$과 $max$ 사이의 $0$ ~ $1$ 범위로 정규화($t$)한 뒤, 부드러운 곡선을 만드는 3차 다항식에 대입합니다.

[1단계: 클램핑 및 정규화]

정규화는 Min-Max 정규화 사용

$$t = max(0, {min}(1, \frac{x - min}{max - min}))$$
[2단계: 3차 에르미트 보간(Hermite Interpolation)]

$${SmoothStep}(x) = 3t^2 - 2t^3$$

상황	max−min (거리)	보간 구간	시각적 효과
max 증가 ↑	멀어짐	넓어짐	더 부드럽고 완만한 전환
max 감소 ↓	가까워짐	좁아짐	더 급격하고 뚜렷한 전환
min 증가 ↑	가까워짐	좁아짐	더 늦게 시작해서 급하게 변함
min 감소 ↓	멀어짐	넓어짐	더 일찍 시작해서 천천히 변함

step보다 보간 영역이 더 넓고 부드러운 것을 알 수 있다.

Ramp 텍스처 셰이딩

Ramp는 경사로를 의미하나 그래픽스에서는 한 색에서 다른 색으로 서서히 이동하는 디자인 기법을 의미한다.

앞서 배운 공식들과 같이 수치적으로 계산할 수 있지만 램프 텍스처를 준비해서 각 영역(0~1)에 램프 텍스처를 매핑하는 식으로 그림자를 표현할 수도 있다.

(번외) MPC와 메테리얼

MPC(Material Parameter Collection)은 모든 메테리얼에서 참조 가능한 글로벌 변수 구조체이다. 만약 MPC가 없다면 메테리얼마다 Dynamic Material instance를 생성해서 일일히 값을 변경해줘야 한다.

따라서 다음과 같은 경우에서 MPC를 사용하는 것이 유리하다.

글로벌 날씨 시스템: 맵 전체에 비가 와서 오브젝트가 젖음
바람 시스템: 맵 전체의 나무, 풀, 깃발이 흔들리는 방향과 강도를 한 번에 제어할 때
플레이어 상호작용: 플레이어의 현재 위치를 실시간으로 MPC에 업데이트해서, 플레이어가 지나갈 때마 주변 풀들이 알아서 구부러지는 효과 등

이렇게 등록한 MPC는 Directional light 블루프린트에서 수치를 변경한다. 변경된 수치는 앞서 사용한 메테리얼 그래프에서 사용하고 있다.

위 이미지는 밴드 쉐이딩이 적용되고 있는 예시이다.

2.1.3. 빛의 반사 영역은 어떻게 만들어지는가?

스페큘러 로브의 BRDF(램버트 BRDF, 퐁 BRDF)

퐁 BRDF에서 반사 벡터 R을 구하는 식($R = 2 ( N \cdot L) N - L$) 유도는 How to calculate the reflection vector에서 스크랩한 글 참고

반사 벡터 R과 카메라 벡터 V와의 사잇각으로 스페큘러를 구현한다.

내적으로 만든 그레이디언트를 쨍하게(집중되게) 변형할 때는 거듭 제곱 연산(pow)을 사용하자

20번부터 스페큘러와 비슷하게 상이 맺히는 것을 볼 수 있다.

표면이 매우 거친 경우 스페큘러 로브의 크기가 90도를 넘어갈 수 있는데(2.1.3. 상단 그림의 3번째 예시) 퐁 스페큘러 모델에서는 이런 90도가 넘어가는 영역을 모두 검정(0)으로 처리하는 문제가 있다.

퐁 모델이 가진 문제를 보완하기 위해 나온 것이 블린-퐁 스페큘러 모델이다. 블린-퐁 스페큘러 모델은 노말 벡터를 사용하여 명암을 계산하기 때문에 하프 벡터 H와 N 벡터 사이가 90도를 넘을 일이 없다.

하프 벡터 H는 빛 벡터 L과 카메라 벡터 V를 더해줘서 normalize 하면 구할 수 있다. 이렇게 구한 하프 벡터 H와 노말 벡터 N의 사잇각을 사용해서 명암을 표현한다.

현재는 퐁, 블린-퐁이 아닌 GGX 모델을 사용한다고 한다.

위부터 하프 램버트, 램버트, 하프 램버트와 Smooth step을 사용한 diffuse, lerp를 사용한 ColorDiffuse를 구현한 예제

블린-퐁 구현 예제

앞서 구한 diffuse, specular를 lerp로 보간하여 최종적으로 완성된 셰이더 예제

두 RGB 색의 혼합

색을 곱할 때 multiply로 표현한다면 색이 점점 어두워지는 문제가 있다. 이때 multiply로 구한 색과 add로 구한 두 색을 lerp로 보간하면 원래의 색을 살리면서 어두워지지 않게 색을 혼합해서 사용할 수 있다.

3. 질문 및 해결 (Q&A)

GGX 모델은?
Hermit 보간은?

4. 관련 문서 (Links)

TIL260615 - Ch3 - 1 - 표정, 메테리얼 슬롯, 양면 렌더

옆집히드라 — Mon, 15 Jun 2026 21:02:07 +0900

1. 핵심 개념

표정 구현

2. 상세 내용

챕터3 팀프로젝트를 기획하면서 전체적인 아트워크를 아이돌과 아이돌을 쫓는 육수(?) 팬덤으로 카툰풍에 에셋을 준비해야 할 필요가 생겼다.

우선 캐릭터 에셋을 준비하기 위해 자료를 찾는 중 personal 기준으로 무료로 제공하는 에셋을 찾았다.

CiciToon Character Shader Pak V3.5 | Fab

CiciToon Character Shader Pak V3.5

You can find my other project in:MrCici | PatreonYou can find toon shader tutorial in:MrCici - YouTubeStill struggling with complex cartoon rendering nodes? This out-of-the-box cartoon shading package designed for indie developers comes with complete chara

www.fab.com

위 에셋은 툰 쉐이더 + 캐주얼한 캐릭터 모델을 제공하지만 옷이 교복 밖에 없어서 아이돌 색이 적다.

☆無料☆ももか専用衣装No.87 - るるくショップ - BOOTH

※アバターは付属しませんこちらの衣装データはショップ「T.GardeN」ちゅばき様が制作した子「ももか」　https://booth.pm/ja/items/2309079 のオリジナル3Dモデル専用の衣装になります Unityで着せ

booth.pm

그래서 BOOTH에서 위와 같은 아이돌 복 FBX를 구해서 직접 블렌더로 합치기로 했다.

2.1. 옷 변경 작업

에셋을 직접 블렌더로 Asset Action -> export 하니 블렌더에서 위와 같이 inverted 된 아웃라인 메시랑 Shape key(언리얼에서는 Morph target)에 쓰이는 마스크나 안경 같이 안쓰는 메시가 통짜메시로 임포트 되었다.

이중에서 안쓰는 메시는 제거하고 분리할 메시는 분리하면서 메시를 정리하고 안쓰는 본을 제거했다.

위와 같이 캐릭터 메시를 조정하고 옷을 직접 붙였다.(옷 아래에 body는 벗을 때를 고려해서 일부로 남겨두었다.(추가할지는...))

이후 옷에 리본과 치마를 kawaii physics를 이용해서 팔랑임을 구현하도록 직접 본을 조정하고 웨이트 페인팅을 다시 해두었다.

추가로 옷 메시는 부스에서 단일 메시면으로 제작이 되어서 실제 엔진에서 백페이스 컬링이 일어나서 위에 치마 아래 부분 이미지가 렌더링이 안됐다.

그래서 팬티를 그리는 텍스처 작업을 하면서 동시에 치마면을 양면으로 하게 메시를 조정했다.(사타구니 영역이 모호해서 텍스처링할 때 UV layout을 팬티가 입혀질 메시영역을 선택해서 클립스튜디오에서 그렸다.)

이 부분을 조정하면서 메테리얼에 양면 렌더링 옵션을 키는 것이 성능상 메시를 추가하는 것보다 더 부하가 있지 않을까 싶어서 막연하게 작업했다. 그래서 이 부분을 제미나이 사고 모델에 질의해서 더 찾아봤다.

머티리얼 옵션 사용 (Two-Sided Material)

단일 페이스 메시를 그대로 두고, 언리얼 머티리얼 에디터에서 Two Sided를 체크하는 방식

장점:
- 메모리 및 성능: 폴리곤 수가 증가하지 않아 렌더링 부하가 적다.
- 애니메이션 작업 용이: 리깅(Rigging) 시 웨이트 페인팅(Weight Painting)을 한 겹만 칠하면 되므로 작업이 매우 빠르다. 물리 시뮬레이션 시 옷이 겹쳐서 깨지는 현상도 없다.
단점:
- 물리적 두께감 부재: 옆에서 단면을 보았을 때 옷감이 종이장처럼 얇아 보임
- 라이팅/노멀 계산의 한계: 언리얼의 Default Lit 셰이딩 모델에서 Two-Sided를 켜면, 뒷면의 노멀(법선)이 앞면의 반대 방향으로 강제 복사됩니다. 환경광(GI)이나 그림자가 뒷면에 맺힐 때 다소 평면적이거나 어색하게 렌더링될 수 있다. (이를 보완하기 위해 Two-Sided Foliage나 Cloth 셰이딩 모델이 필요)

메시를 양면으로 모델링 (Double-Sided Geometry)

블렌더 등에서 Solidify 모디파이어나 Extrude를 사용해 치마에 실제 두께(안감)를 만들어주는 방식

장점:
- 시각적 디테일과 현실감: 실제 옷감처럼 두께와 단면(Rim)이 생겨 렌더링 퀄리티가 상승. 특히 천의 끝단 처리가 자연스럽스럽다.
- 완벽한 라이팅 통제: 앞면과 뒷면이 독립된 폴리곤이므로, 언리얼의 라이팅과 그림자 계산이 물리적으로 완벽하게 들어맞는다.
- 자유로운 텍스처링: 안감과 겉감의 UV를 완전히 분리하여 전혀 다른 재질이나 패턴을 입히기 쉽다.
단점:
- 최적화 부담: 버텍스 수가 2배로 뛰어 드로우 콜 처리에 부담
- 웨이트 페인팅 지옥: 치마가 움직일 때 안감 버텍스와 겉감 버텍스가 정확히 동일한 가중치로 움직이지 않으면 안감이 겉감을 뚫고 나온다(Clipping). 언리얼의 Chaos Cloth 물리 시뮬레이션을 적용하기 까다로워짐

오히려 내 방식이 더 무겁고 퀄리티를 치중한 방식이였다.(의도와 정반대) 물론 드로우 콜을 수행할 cpu 성능이 떨어지는 환경이나 대량의 군중을 표시해야 해서 드로우 콜 증가가 더 치명적인 경우에는 전자의 방식이 더 무거울 수도 있지만 현재 나는 치마를 물리 시뮬레이션 해야하는 상황이여서 좋지 못한 선택을 한 것 같다.

이는 프로젝트가 진행됨에 따라 추가적인 변경을 고려해봐야겠다.(실제로 프로파일링 해보면서)

2.2. 표정 구현

한편, 캐릭터 모델을 다시 편집하는 과정에서 표정을 어떻게 구현하는지 알아냈다.

캐릭터 얼굴에 표정을 띄울 메시를 만든다.(얼굴에 띄워질 공간을 ctrl + d로 복제해서 살짝 위로 옮김)
만든 메시를 머리 안쪽에 작게 해서 숨긴다.
표정용 텍스처를 준비해서 미리 만들어둔 표정 메시에 UV 맵을 만든다.
이렇게 만든 메시는 쉐이프키를 이용해서 1.0 지점에 얼굴에 완전히 띄워지도록 설정한다.
설정된 쉐이프 키는 언리얼의 Morph target을 조정해서 사용한다.

적용된 모습

2.3. 메테리얼 슬롯

위와 같은 과정을 거쳐서 새로 만든 몸통 부분은 실제 원본 캐릭터 모델과 비교해서(highlight 옵션을 켜서 확인) 올바른 곳에 적당한 메테리얼을 다시 할당해줬다.

최초에는 원본 모델과 동일한 순서로 메테리얼을 임포트했는데 블렌더에서 변경이 일어난 메테리얼 목록은 언리얼로 임포트할 때 메테리얼이 저장된 배열 형태의 인덱스가 재조정돼서 원래 위치와 다른 곳에 메테리얼이 할당되거나 새로 생겨났다. 따라서 메테리얼을 직접 어느 메시에 사용되는지 일일이 비교해가면서 넣었다.

제미나이에게 질의한 결과 위와 같은 문제가 발생했을 때 다음과 같이 해결할 수 있다고 한다.

언리얼 엔진의 FBX Import Options에서 머티리얼 매칭 방식을 인덱스가 아닌 이름(Name) 기반으로 변경
블렌더 측에서 머티리얼 슬롯의 순서를 원본과 동일하게 맞춘다.

이 과정에서 특정 메시 영역만 블렌더에서 select 해서 메테리얼 슬롯을 추가해서 다르게 렌더링 할 수 있는 것을 알았다. 하지만 이 방식은 다음과 같은 사항을 고려해야 한다.

드로우 콜 증가
그래픽스 API(DirectX, Vulkan 등) 관점에서, 하나의 메시에 적용된 머티리얼이 N개라면, 렌더링 엔진은 이 메시를 N개의 별도 서브 메시(Sub-mesh)로 분리하여 처리한다 따라서 머티리얼 슬롯이 1개 추가될 때마다 드로우 콜이 1회 추가된다.
버텍스 분할 (Vertex Splitting / Duplication)
래픽 카드 파이프라인에서 하나의 버텍스(Vertex)는 단 하나의 머티리얼 ID(Draw call 그룹)에만 속할 수 있기 때문에 서로 다른 두 머티리얼이 맞닿는 경계면(Seam)에 위치한 버텍스들은 게임 엔진 내부적으로 물리적인 위치가 같더라도 강제로 복제(Split)됩니다. 따라서 블렌더에서 확인한 버텍스 개수보다 언리얼 엔진 내부에서 처리하는 실제 버텍스 개수가 증가할 수 있다.

현재 제공받은 무료 에셋 기준의 멀티 메테리얼 방식은 드로우 콜과 버텍스가 증가하는 대신에 각 부위별로 텍스처 해상도를 독립적으로 높게 가져갈 수 있다. 추가로 완전히 다른 셰이딩 모델을 적용하기 유리하다.

만약 이 방식을 최적화 한다면 텍스처 마스킹 / ID 맵 방식으로 모델을 단일 메테리얼 슬롯 1개로 합친 다음에 RGB 마스크 텍스처나 Color ID 맵을 사용해서 영역을 관리하는 방법을 사용할 수 있다.

이후 성공적으로 아이돌 옷을 입힌 캐릭터를 언리얼로 포팅했다.

3. 질문 및 해결 (Q&A)

현재 캐릭터에 아이돌 옷은 입힌 것은 좋은데 아웃라인 적용이 하나도 안되어 있다. 실제 카툰 느낌을 살리려면 아웃라인 느낌과 툰 쉐이딩이 필수인데 cicitoon의 세팅을 따라서 이 부분을 어떻게 적용해야 할지 고민해야 할 것 같다.

추가적으로 카툰 렌더링을 기반 캐릭터 작업을 새로운 용어들이 등장하는데 이를 알아야 할 필요가 있다.

NPR 렌더링
SDF의 개념과 SDF를 사용한 캐릭터 얼굴 음영 구현
SSS, OMR 텍스처의 개념과 사용법(packing 방법)

4. 관련 문서 (Links)

[[이전 관련 노트]]
참고한 외부 링크

TIL260612 - Unreal

옆집히드라 — Fri, 12 Jun 2026 23:46:42 +0900

1. 핵심 개념

오늘 한 일 리깅하기

2. 상세 내용

3. 질문 및 해결 (Q&A)

TODO: 치마 본에 물리 넣기(kawaii physisc)
옷에 대하여 아웃라인 쉐이더 적용
애니메이션 리타게터로 라이라 프로젝트와 동기화
IMC, IA 설계 후 애니메이션 정상 동작하는지 실험
사용된 카툰렌더링, 텍스처 매핑 분석
안쓰는 쉐이프키 정리

4. 관련 문서 (Links)

[[이전 관련 노트]]
참고한 외부 링크

TIL260611 - Unreal - GAS4

옆집히드라 — Thu, 11 Jun 2026 21:04:27 +0900

1. 핵심 개념

GE링 ASC에 태그 부여하는 방식 고민

2. 상세 내용

3. 질문 및 해결 (Q&A)

Q1

언리얼 GAS에서 ASC에 태그를 부여할 때
SetAndApplyTargetTagChanges
ApplyGameplayEffectSpecToTarget는 각각 무슨 차이가 있어?

후자는
// GameplayEffectAggregator.cpp
FActiveGameplayEffectHandle FActiveGameplayEffectsContainer::ApplyGameplayEffectSpec(
    const FGameplayEffectSpec& Spec)
{
    // ① 태그 조건 검사
    // Owner(Target)가 Blocked 태그 갖고 있으면 차단
    if (Owner->AreAbilityTagsBlocked(Spec.Def->InheritableGrantedTagsContainer.CombinedTags))
        return FActiveGameplayEffectHandle();

    // ② Required 태그 검사
    // Application Required Tags 없으면 차단
    if (!Spec.Def->ApplicationTagRequirements.RequirementsMet(
        Owner->GetOwnedGameplayTags()))
        return FActiveGameplayEffectHandle();

    // ③ FActiveGameplayEffect 생성 (런타임 인스턴스)
    FActiveGameplayEffect NewEffect(
        GenerateNewActiveEffectHandle(), Spec, GetWorldTime());

    // ④ 실제 컨테이너에 등록
    GameplayEffects_Internal.Add(NewEffect);

    // ⑤ Modifier 적용 (어트리뷰트 수치 변경)
    ApplyModifiersToAttribute(Spec);

    // ⑥ 태그 부여
    Owner->AddLooseGameplayTags(
        Spec.Def->InheritableGrantedTagsContainer.CombinedTags);

    // ⑦ Duration 타이머 등록
    if (Spec.Def->DurationPolicy == EGameplayEffectDurationType::HasDuration)
    {
        FTimerDelegate Delegate;
        Delegate.BindUObject(this, 
            &FActiveGameplayEffectsContainer::OnActiveGameplayEffectExpired,
            NewEffect.Handle);
        Owner->GetWorld()->GetTimerManager().SetTimer(
            NewEffect.DurationHandle, Delegate, Spec.Duration, false);
    }

    // ⑧ 복제 (멀티플레이)
    Owner->MarkArrayDirty();

    return NewEffect.Handle;
}
와 같이 위에 명시적인 과정을 거치고 나서 AddLooseGameplayTags를 붙여서 ASC에 태그가 들어오는데

전자는 
FInheritedTagContainer TagContainer;
TagContainer.Added.AddTag(FGameplayTag::RequestGameplayTag(FName("State.Stun")));
TagsComp->SetAndApplyTargetTagChanges(TagContainer);
와 같이 직접 태그 컨테이너를 넣어서 조정이 가능하거든? 공식적인 루트는 후자인 ApplyGameplayEffectSpecToTarget를 사용하는 것 같은데
SetAndApplyTargetTagChanges로 태그를 넣는 방식도 존재해서 둘이 무슨 차이인지 알려줘

전자 방식인 SetAndApplyTargetTagChanges는 내부 소스코드를 봐도

#endif // WITH_EDITOR

void UTargetTagsGameplayEffectComponent::SetAndApplyTargetTagChanges(const FInheritedTagContainer& TagContainerMods)
{
    InheritableGrantedTagsContainer = TagContainerMods;

    // Try to find the parent and update the inherited tags
    const UTargetTagsGameplayEffectComponent* Parent = FindParentComponent(*this);
    InheritableGrantedTagsContainer.UpdateInheritedTagProperties(Parent ? &Parent->InheritableGrantedTagsContainer : nullptr);

    // Apply to the owning Gameplay Effect Component
    ApplyTargetTagChanges();
}

void UTargetTagsGameplayEffectComponent::ApplyTargetTagChanges() const
{
    UGameplayEffect* Owner = GetOwner();
    InheritableGrantedTagsContainer.ApplyTo(Owner->CachedGrantedTags);
}

#undef LOCTEXT_NAMESPACE

어디서 어떻게 태그가 ASC로 들어가는지 알기 힘들어.

최종적으로 다음의 2개의 질문을 답해
1. 왜 ASC에 태그를 붙이는 방식이 2가지인가? 무엇을 사용해야하고, 전자 방식을 사용한다면 무슨 이점을 얻을 수 있는가?
2. 전자 방식을 사용한다면 어느 코드에서 구체적으로 ASC에 태그를 넣는가? 이렇게 넣은 태그는 영구적인가? 아니면 후자의 방식 같이 GE 적용이 끝나면 사라지는가?

A1

핵심 구분

먼저 두 함수가 작동하는 레이어 자체가 다르다.

	`SetAndApplyTargetTagChanges`	`ApplyGameplayEffectSpecToTarget`
레이어	GE 에셋 정의 수정	GE 런타임 인스턴스 적용
대상	`UGameplayEffect` CDO/에셋	`ASC`의 `FActiveGameplayEffectsContainer`
시점	에셋 로드 후, 적용 전	실제 전투/게임플레이 중
영속성	에셋에 반영 → 이후 모든 적용에 영향	Duration/Instant/Infinite 정책에 따라 결정

Q1. 왜 2가지인가? 무엇을 써야 하는가?

SetAndApplyTargetTagChanges는 GE 에셋의 "부여할 태그 목록"을 런타임에 변경하는 함수다.
ASC에 태그를 직접 넣는 게 아니라, GE가 "나중에 적용될 때 어떤 태그를 줄지"를 결정하는 GE 에셋 자체를 수정한다.

소스 코드를 다시 보면:

cpp

void UTargetTagsGameplayEffectComponent::ApplyTargetTagChanges() const {
    UGameplayEffect* Owner = GetOwner();
    InheritableGrantedTagsContainer.ApplyTo(Owner->CachedGrantedTags); // ← GE 에셋의 CachedGrantedTags 갱신
}

CachedGrantedTags는 GE 에셋이 들고 있는 "줄 태그 목록" 캐시다.
이 시점에선 ASC에 아무것도 들어가지 않는다.

이 방식을 쓰는 이유와 이점:

데이터 드리븐 GE 커스터마이징: 같은 GE 블루프린트를 재사용하면서 부여 태그만 C++/BP로 런타임 교체
GE 파생(Inheritance) 시스템 활용: UpdateInheritedTagProperties로 부모 GE Component의 태그를 상속받아 오버라이드 가능 — 에셋 중복 없이 태그 변형
에디터 워크플로우: WITH_EDITOR 분기가 있는 이유가 이것 — 에디터에서 GE를 편집할 때 태그 미리보기/검증용으로도 동작

결론: 일반적인 게임플레이 태그 부여는 ApplyGameplayEffectSpecToTarget가 공식 루트.
SetAndApplyTargetTagChanges는 "이 GE가 앞으로 줄 태그를 프로그래밍적으로 바꾸고 싶을 때" — 즉 GE 에셋을 동적으로 구성하는 도구다.

Q2. 전자 방식에서 ASC에 실제로 태그가 들어가는 시점과 영속성

SetAndApplyTargetTagChanges → ApplyTargetTagChanges → Owner->CachedGrantedTags 갱신까지는 GE 에셋 레이어다.

실제 ASC 진입은 이후 GE가 적용될 때 일반 경로를 그대로 탄다:

SetAndApplyTargetTagChanges()
    └─ Owner->CachedGrantedTags 갱신 (GE 에셋)
           ↓ (이후 별도로)
ASC->ApplyGameplayEffectSpecToSelf(Spec)
    └─ FActiveGameplayEffectsContainer::ApplyGameplayEffectSpec()
           └─ Owner->AddLooseGameplayTags(
                  Spec.Def->CachedGrantedTags  ← 여기서 수정된 값이 사용됨
              )

즉 CachedGrantedTags를 바꿔놓고, GE를 ASC에 Apply하는 순간 AddLooseGameplayTags를 통해 ASC에 들어간다.

영속성은 GE의 Duration Policy가 결정한다 — SetAndApplyTargetTagChanges가 아니라.

Duration Policy	태그 수명
`Instant`	태그 부여 자체가 의미없음 (즉시 제거)
`HasDuration`	Duration 만료 시 `RemoveLooseGameplayTags` 호출로 제거
`Infinite`	GE가 명시적으로 제거될 때까지 유지

따라서 SetAndApplyTargetTagChanges로 넣은 태그가 영구적인지 여부는 그 GE의 Duration Policy에 달려 있다. 전자 방식이라서 특별히 영구적이거나 임시적인 게 아니다.

요약

SetAndApplyTargetTagChanges
= "이 GE가 줄 태그 목록을 런타임에 바꾼다" (GE 에셋 조작)

ApplyGameplayEffectSpecToTarget  
= "이 GE를 지금 대상 ASC에 적용한다" (런타임 인스턴스 생성)

ASC에 태그가 실제로 들어가는 건 항상 후자의 경로.
전자는 후자가 참조할 CachedGrantedTags를 미리 세팅하는 것.

GAS는 수치/상태 변화 + 행동 중에 캔슬/금지/쿨타임 등 필요하면 검토

4. 관련 문서 (Links)

[(연구) SDF 텍스처는 직접 그려서 쓸 수 있을까? - 3DCG 채널](https://arca.live/b/3d3d/141290850

TIL260610 - Unreal - GAS3

옆집히드라 — Wed, 10 Jun 2026 23:28:07 +0900

1. 핵심 개념

Gameplay Cue

2. 상세 내용

2.1. Gameplay Cue

Gameplay Cue는 게임플레이 로직에 영향을 주지 않는 부가 효과(FX) 전용 기능이다. 하나의 게임플레이 태그가 하나의 게임플레이 큐에 대응되며 독립된 GameplayCueManager가 태그를 기반으로 FX 효과를 재생한다.

GameplayCue는 게임플레이 이펙트에서 태그를 지정해서 자동 발동할 수 있으며, 태그를 사용하여 원하는 타이밍에 직접 호출도 가능하다. 또한 Gameplay Cue에 사용되는 태그는 특정 폴더 내에 블루프린트 이름과 자동으로 매칭하는 기능을 지원한다.(GC_DAMAGE_EFFECT 블루 프린트를 GameplayCue.Damage.Effect 태그에 대응하는 식)

GameplayCue의 종류

Static: 일순간(Burst) -> Instant 타입의 GE와 연계
Actor: 살아있는 동안 지속 -> Duration 타입의 GE와 연계

Event Functions

GameplayCue Static: 발동 시 OnExecute 함수를 실행함
GameplayCue Actor: 반복되는 주기(Period)마다 Executed 이벤트를 발생시킴

GAS에서의 데이터

수치 데이터

AttributeSet과 FGameplayAttributeData를 통해 관리한다. GAS의 코어 시스템(클라이언트 예측, 네트워크 롤백, 수치 중첩 및 계수 곱연산 파이프라인 등)은 성능 최적화와 연산의 통일성을 위해 내부적으로 오직 float으로만 구현되어 있다.

// 1. 선언은 무조건 float 기반으로 진행
UPROPERTY(BlueprintReadOnly, Category = "Ammo")
FGameplayAttributeData CurrentAmmo;
ATTRIBUTE_ACCESSORS(UMyAttributeSet, CurrentAmmo)

// 2. 로직에서 꺼내 쓸 때 형변환 (C++)
int32 DisplayAmmo = FMath::RoundToInt(GetCurrentAmmo());

논리 데이터

Gameplay Tag로 관리한다.

// ASC에서 특정 상태(Tag)를 가지고 있는지 검사하여 bool처럼 활용
if (TargetASC->HasMatchingGameplayTag(FGameplayTag::RequestGameplayTag(FName("Status.Debuff.Stun"))))
{
    // 기절 상태일 때의 처리 로직
    return; 
}

그외 데이터

Gameplay Effect Context에 상속해 Pre(Post)GameplayEffectExecute에서 사용한다.

// 1. 커스텀 Context 구조체 선언
USTRUCT()
struct FMyCustomEffectContext : public FGameplayEffectContext
{
    GENERATED_BODY()

    // 원하는 데이터를 자유롭게 선언
    UPROPERTY()
    FVector HitImpactLocation;

    UPROPERTY()
    FString UsedWeaponName;
};

// 2. 타겟의 AttributeSet(PostGameplayEffectExecute)에서 데이터 추출
void UMyAttributeSet::PostGameplayEffectExecute(const FGameplayEffectModCallbackData& Data)
{
    Super::PostGameplayEffectExecute(Data);

    // 전달받은 봉투(Context)를 열어서 커스텀 타입으로 캐스팅
    if (const FMyCustomEffectContext* CustomContext = static_cast<const FMyCustomEffectContext*>(Data.EffectSpec.GetContext().Get()))
    {
        FVector ImpactPoint = CustomContext->HitImpactLocation;
        UE_LOG(LogTemp, Log, TEXT("타격당한 위치: %s"), *ImpactPoint.ToString());
    }
}

info, handle, spec

1. Info (정보 / 신분증)

대표 구조체: FGameplayAbilityActorInfo

비유: 스킬을 사용하는 주체의 "종합 신분증명서"

[역할과 특징]

스킬(GA)이 실행될 때, *"내 주인이 누구지? 내 애니메이션은 어디서 틀어야 하지? 내 컨트롤러는 뭐지?"*를 알기 위해 매번 Cast<ACharacter>를 하는 것은 성능상 매우 비효율적입니다.

그래서 GAS는 InitAbilityActorInfo()가 호출되는 순간, 이 스킬을 쓸 액터의 필수 컴포넌트(포인터)들을 미리 싹 다 캐싱(저장)해 둡니다. 이 캐싱된 데이터 묶음이 바로 ActorInfo입니다.

[주요 포함 데이터]

OwnerActor: ASC를 소유한 논리적 액터 (예: PlayerState)
AvatarActor: 월드에 존재하는 물리적 액터 (예: Character)
PlayerController, SkeletalMeshComponent, MovementComponent 등

[실제 사용 예시]

스킬(GA) 내부에서 주인의 캐릭터 무브먼트에 접근하고 싶을 때 사용합니다.

C++

// GA 내부에서 매번 Cast 할 필요 없이 Info에서 바로 꺼내 씁니다.
UCharacterMovementComponent* MoveComp = GetCurrentActorInfo()->MovementComponent.Get();

2. Handle (핸들 / 영수증 번호)

대표 구조체: FGameplayAbilitySpecHandle, FActiveGameplayEffectHandle, FGameplayAbilityTargetDataHandle

비유: 포인터 대신 사용하는 "안전한 식별표(티켓 번호)"

[역할과 특징]

멀티플레이 게임에서는 스킬이나 이펙트가 언제 파괴되거나 지연(Lag)될지 모릅니다. 만약 C++ 원시 포인터(*)를 주고받다가 대상이 삭제되면 게임이 크래시(Crash)됩니다.

이를 막기 위해 GAS는 객체 자체를 넘기지 않고, 고유한 ID 번호가 적힌 가벼운 구조체인 Handle을 발급합니다. 시스템에 *"이 핸들 번호 가진 이펙트 좀 지워줘"*라고 요청하면, 시스템이 알아서 안전하게 찾아 지워줍니다.

[주요 사용처]

FGameplayAbilitySpecHandle: 장착된 스킬을 특정해서 발동(TryActivateAbility)하거나 해제할 때 사용.
FActiveGameplayEffectHandle: 타겟에게 걸어둔 독(Poison) 데미지를 5초 뒤에 추적해서 강제로 지울 때 사용.

[실제 사용 예시]

C++

// 1. 적에게 이펙트를 적용하고 '영수증 번호(Handle)'를 받음
FActiveGameplayEffectHandle PoisonHandle = TargetASC->ApplyGameplayEffectSpecToSelf(*Spec);

// 2. 나중에 해독제를 먹으면 그 영수증 번호로 이펙트를 지움
TargetASC->RemoveActiveGameplayEffect(PoisonHandle);

3. Spec (명세서 / 주문서)

대표 구조체: FGameplayAbilitySpec, FGameplayEffectSpec

비유: 원본 클래스(설계도)를 바탕으로 구체적인 수치를 적어 넣은 "실행 주문서"

[역할과 특징]

언리얼의 클래스(Class)나 CDO는 원본 데이터이므로 게임 중에 함부로 수정할 수 없습니다. 따라서 원본 클래스를 바탕으로 "현재 레벨", "시전자 정보", "동적 태그" 등을 조합한 인스턴스화된 데이터를 만들어야 하는데, 이것이 Spec입니다.

[주요 사용처]

FGameplayAbilitySpec: 캐릭터에게 스킬을 부여(GiveAbility)할 때, 단순히 '파이어볼 클래스'만 주는 게 아니라 *"파이어볼 클래스, 스킬 레벨 3, 입력 키 Q"*를 묶어서 Spec으로 만들어 줍니다.
FGameplayEffectSpec: 적에게 데미지를 줄 때 적용됩니다. 단순히 '데미지 GE'를 넣는 게 아니라, *"데미지 GE, 시전자의 현재 레벨, 시전자의 공격력 계수"*를 모두 담은 명세서(Spec)를 만들어서 타겟에게 날립니다.

[실제 사용 예시]

C++

// 1. GE 클래스를 기반으로 빈 명세서(Spec)를 만듭니다.
FGameplayEffectSpecHandle SpecHandle = MakeOutgoingGameplayEffectSpec(DamageEffectClass, Level);

// 2. 명세서에 방금 타겟팅한 정보를 추가로 적어 넣습니다.
SpecHandle.Data.Get()->AddDynamicAssetTags(MyTags);

// 3. 완성된 명세서를 타겟의 ASC에 제출(Apply)합니다.
TargetASC->ApplyGameplayEffectSpecToSelf(*SpecHandle.Data.Get());

3줄 요약 테이블

용어	풀네임 예시	비유	핵심 역할
Info	`FGameplayAbilityActorInfo`	신분증	"내가 누구고 어떤 컴포넌트를 가졌는가?" (캐싱된 포인터 모음)
Handle	`FActiveGameplayEffectHandle`	티켓 / 번호표	"포인터 대신 쓰는 안전한 ID 번호" (크래시 방지용 참조 객체)
Spec	`FGameplayEffectSpec`	주문서 / 명세서	"클래스 + 레벨 + 동적 변수"가 결합된 실질적인 실행 데이터

3. 질문 및 해결 (Q&A)

ASC의 레플리케이션 정책은? 언리얼에서의 레플리케이션의 개념은 구체적으로 무엇?
ASC에서 AttributeSet은 어디에?
GA 없이 GE만으로 AttributeSet 변경 가능?
AbilityTask는 비동기 구현용?

4. 관련 문서 (Links)

[[이전 관련 노트]]
참고한 외부 링크

TIL260609 - Unreal - GAS2

옆집히드라 — Tue, 9 Jun 2026 21:03:15 +0900

1. 핵심 개념

GameFeature 플러그인
AttributeSet
GameplayEffect

2. 상세 내용

2.1. AttributeSet

AttrubuteSet은 다수의 FGameplayAttributeData를 묶어 관리하는 언리얼 오브젝트로 5.6버전 기준 cpp로만 생성이 가능하다.

하나의 스탯에 대해서 max값을 GameplayAbilityData로 추가 설정하는 것을 권장한다.

보유한 스탯의 BaseValue가 변하면 AttributeSet의 이벤트 함수가 호출된다.

FGameplayAttributeData

FGameplayAttributeData는 단일 float 값이 아니라 내부적으로 BaseValue(기본값)와 CurrentValue(현재값) 두 가지 상태를 유지하며, Gameplay Effect(GE)의 지속 시간(Duration Policy)에 따라 다르게 반응한다.

Instant GE (즉발형): 데미지나 영구적인 스탯 상승처럼 즉시 적용되는 효과. BaseValue 자체를 영구적으로 변경한다.
Duration / Infinite GE (지속/무한형): 10초간 공격력 증가 버프와 같은 효과. BaseValue는 원래 상태로 보존하고 CurrentValue만 일시적으로 변경한다. 버프가 종료되면 CurrentValue는 자동으로 BaseValue로 롤백된다.

매크로

AttributeSet을 만들 때는 UAttributeSet을 상속해서 만든다. 아래 테이블과 같이 매크로를 사용하여 게터, 세터, 초기화 함수를 설정할 수 있다.

매크로(파라미터)	생성된 함수의 시그니처	행동/사용
`GAMEPLAYATTRIBUTE_PROPERTY_GETTER(UMyAttributeSet, Health)`	`static FGameplayAttribute GetHealth()`	스태틱 함수이며, 엔진의 리플렉션 시스템으로부터 `FGameplayAttribute` 구조체를 반환합니다.
`GAMEPLAYATTRIBUTE_VALUE_GETTER(Health)`	`float GetHealth() const`	게임플레이 어트리뷰트 'Health'의 현재 값을 반환합니다.
`GAMEPLAYATTRIBUTE_VALUE_SETTER(Health)`	`void SetHealth(float NewVal)`	게임플레이 어트리뷰트 'Health'의 값을 `NewVal` 로 설정합니다.
`GAMEPLAYATTRIBUTE_VALUE_INITTER(Health)`	`void InitHealth(float NewVal)`	게임플레이 어트리뷰트 'Health'의 값을 `NewVal` 로 초기화합니다.

        UCLASS()
    class MYPROJECT_API UMyAttributeSet : public UAttributeSet
    {
        GENERATED_BODY()

        protected:
        /** 샘플 어트리뷰트 'Health'*/
        UPROPERTY(EditAnywhere, BlueprintReadOnly)
        FGameplayAttributeData Health;

        //~ ... 여기에 다른 게임플레이 어트리뷰트...

        public:
        //~ 어트리뷰트 'Health'의 헬퍼 함수
        GAMEPLAYATTRIBUTE_PROPERTY_GETTER(UMyAttributeSet, Health);
        GAMEPLAYATTRIBUTE_VALUE_GETTER(Health);
        GAMEPLAYATTRIBUTE_VALUE_SETTER(Health);
        GAMEPLAYATTRIBUTE_VALUE_INITTER(Health);

        //~ ... 여기에 다른 게임플레이 어트리뷰트의 헬퍼 함수...
    };

이때 Attribute의 초기화는 'AttributeMetaData'라는 게임플레이 어빌리티 시스템 행 타입을 사용하는 데이터 테이블로 초기화할 수 있다.

Meta Attribute (메타 어트리뷰트)

메타 어트리뷰트는 체력(Health)이나 마나(Mana)처럼 지속적으로 유지되는 스탯이 아니라, 데미지나 치유량 등 중간 연산을 위해 일회성으로 사용되는 임시 스탯(상태)을 의미한다.

설계 목적: 공격(GE)이 타겟의 체력을 직접 깎아버리면 무적 상태나 방어력 계산 등을 중간에 개입시키기 어렵다. 따라서 GE는 타겟의 체력이 아닌 'Damage'라는 임시 스탯을 증가시키고, AttributeSet에서 이를 확인하여 최종 체력을 깎는 완충 지대 역할을 한다.
특징: 서버와 클라이언트 간에 동기화(Replication)할 필요가 없으며, 연산이 끝나면 즉시 0으로 초기화해야 한다.

UI와 연동

AttributeSet에는 PreAttributeChange와 PostAttributeChange가 존재한다. clmap와 같은 스탯의 사전 설정은 pre에서, BaseValue가 변경된 후의 값 처리는 Post에서 처리한다.(OldValue, NewValue 모두 알려줌)

ASC는 InitializeComponent 함수에서 액터에 설정된 모든 AttributeSet 객체를 자동으로 찾아서 등록한다. 이 작업이 끝나면 PostInitializeComponents 함수가 실행되는데, 이 때 확정된 AttributeSet 정보를 UI와 연동하는 것을 권장한다.(위 시퀀스 참고)

2.2. GameplayEffect

GameplayEffect는 블루프린트 에디터에서 설정하는 것을 권장한다.

하나의 게임플레이 이펙트는 독립적으로 동작하기 위해 다양한 정보를 받아 실행된다.

GameplayEffectSpec: 다양한 정보를 담은 데이터이다.
- GameplayEffect Class: 이펙트를 발동한 GA와 이를 수행한 ASC 관련 액터 정보(ActorInfo)
- GameplayEffect Context: 발동할 게임플레이 이펙트 클래스 정보
- GameplayEffect Context: 게임플레이 이펙트가 발동했던 상황정보
- Level & Stack Count: 레벨 및 스택 카운트

GameplayEffectSpec을 기반으로 자신에게 발동 혹은 다른 액터에게 발동 가능(레벨업으로 자신의 능력치 상승, 공격으로 상대방의 Health Attribute 차감 등)

2.3. AttributeSet과 GameplayEffect 연동

Attribute Set에서는 Gameplay Effect 적용에 관련된 가상 함수(virtual function)를 제공한다.
각각 BaseValue 변경에 대해서만 반응

PreGameplayEffectExecute: Attribute가 변경되기 전, 현재 진행 중인 Gameplay Effect를 진행할 것인확인하는 함수
PostGameplayEffectExecute: Gameplay Effect가 확정되기 직전에 BaseValue를 수정할 수 있는 최종함수

3. 질문 및 해결 (Q&A)

내일 Gameplay Cue 파트 추가로 본 다음 전체적인 흐름도 다이어그램으로 정리하자

4. 관련 문서 (Links)

TIL260608 - Unreal

옆집히드라 — Mon, 8 Jun 2026 20:52:54 +0900

1. 핵심 개념

GameMode & States

2. 상세 내용

2.1. GameMode & States

게임 플레이에 관한 정보는 GameMode와 GameStates에 의해 관리된다.

게임을 구성하는 규칙들은 게임 모드를 구성한다. 이때 게임모드는 다음과 같은 룰을 포함한다.

플레이어(또는 spectators)의 목록
게임을 어떻게 들어오는지, 스폰 지역과 스폰 행동
게임이 정지되었는지, 정지 되었다면 어떻게 처리되는지
레벨 간 전환

룰과 관련된 이벤트는 다른 모든 플레이어들에 의해 추적되거나(tracked) 공유될 수 있어야 한다. 이러한 정보는 GameState에 의해 저장되고 동기화 된다. 이때 GameState는 다음과 같은 정보(information)를 포함한다.

러닝 타임
각 플레이어가 언제 접속(join) 했는지, 그리고 각 플레이어의 현재 상태
현재 Game Mode의 베이스 클래스
게임이 시작되었는지, 아닌지

Game Modes

AGameModeBase: 모든 게임 모드의 베이스 클래스로 부적인 구현이 없어서 가벼움(simplicity & efficiency)
AGameMode: AGameModeBase의 파생 클래스로 match state 개념이 추가되어서 멀티플레이 슈터 장르 같은 게임에 적합하다.

1. AGameModeBase (기본 게임 모드) 모든 게임 모드의 최상위 기본 클래스이며, 게임의 전반적인 뼈대와 플레이어 접속 관리를 담당합니다.

서버 전용: 이 클래스는 오직 서버에만 존재하며 클라이언트에는 복제(Replication)되지 않습니다. 클라이언트는 현재 어떤 게임 모드 클래스가 쓰이는지만 알 수 있고, 내부 변수에는 접근할 수 없습니다.
주요 함수:
- InitGame: 다른 스크립트나 컴포넌트가 초기화되기 전 가장 먼저 호출되어 게임 모드의 파라미터 등을 세팅합니다.
- PreLogin / PostLogin: 플레이어의 서버 접속 시도를 승인/거절(PreLogin)하고, 접속이 완료된 후(PostLogin) 컨트롤러에 안전하게 복제 함수를 호출할 수 있게 합니다.
- HandleStartingNewPlayer / RestartPlayer / SpawnDefaultPawnAtTransform: 플레이어의 폰(Pawn)을 생성하고 알맞은 위치(PlayerStart 등)에 스폰시킵니다.
- Logout: 플레이어가 게임을 떠나거나 파괴될 때 호출됩니다.

2. AGameMode (멀티플레이어 게임 모드) AGameModeBase의 하위 클래스로, 멀티플레이어 매치의 흐름을 제어하기 위한 상태기(State Machine) 기능이 추가되어 있습니다. *

주요 매치 상태 (Match States):
- EnteringMap: 맵 로딩 상태. 아직 틱(Tick)이 돌지 않습니다.
- WaitingToStart: 틱은 돌고 있지만 아직 플레이어들이 스폰되지 않은 대기 상태입니다.
- InProgress: 본격적인 게임 진행 상태입니다. 모든 액터의 BeginPlay가 호출됩니다.
- WaitingPostMatch: 게임이 끝난 후 다른 맵으로 이동하기 전의 대기 상태입니다. 신규 유저 접속이 차단됩니다.
- LeavingMap / Aborted: 맵 전환 중이거나 치명적인 오류로 경기가 중단된 상태입니다.

3. 블루프린트 게임 모드 (Game Mode Blueprints) C++ 코드를 건드리지 않고도 에디터 내에서 변수를 수정하거나 맵마다 쉽게 적용하기 위해 게임 모드를 블루프린트로 상속받아 사용합니다.

기본 설정 클래스: 사용할 Default Pawn, HUD, PlayerController, Game State, Player State 등을 여기서 지정합니다.

4. 게임 모드 적용 우선순위 (Setting the Game Mode) 특정 맵에 게임 모드가 적용되는 순서입니다. (1번이 가장 우선순위가 높습니다)

URL 인자: 게임 실행 시 명령줄에 ?game=MyGameMode 파라미터를 강제로 전달할 때.
맵 접두사 (Map Prefixes): DefaultEngine.ini에 규칙을 정해둘 때 (예: 맵 이름이 DM-으로 시작하면 데스매치 모드 자동 적용).
월드 세팅 (World Settings): 에디터 내부의 개별 맵 세팅 창에서 덮어쓰기(Override)할 때.
프로젝트 세팅: 기본 세팅(GlobalDefaultGameMode)에 설정된 값.

5. 게임 스테이트 (Game State) 서버에서 관리되는 게임의 전반적인 상황을 모든 클라이언트에게 동기화(Replication)하는 역할을 합니다.

관리 목적: '팀 전체 점수', '접속된 플레이어 목록', '완료된 퀘스트' 등 특정 개인이 아닌 모두가 공유해야 하는 정보를 담는 데 사용합니다. (개인의 킬/데스 점수는 PlayerState에서 관리하는 것이 맞습니다.)
주요 기능 (AGameStateBase):
- GetServerWorldTimeSeconds(): 서버와 클라이언트 간에 오차가 없는 동기화된 서버 시간을 반환합니다.
- PlayerArray: 현재 게임에 접속한 모든 플레이어의 상태(APlayerState)를 담고 있는 배열입니다.
- HasBegunPlay(): 게임이 본격적으로 시작되어 BeginPlay가 호출되었는지 여부를 확인합니다.
플레이어 스테이트(Player State)
A PlayerState is created for every player on a server (or in a standalone game). PlayerStates are replicated to all clients, and contain network game relevant information about the player, such as playername, score, etc.

3. 질문 및 해결 (Q&A)

언리얼 인풋 라우팅 되는 구조 좀 봐야겠다.(PlayerController best practices. - Programming & Scripting / Blueprint - Epic Developer Community Forums)
AGameSession, Steam, Epic Online Services(EOS) 등 온라인 서브시스템(OSS)

4. 관련 문서 (Links)

Game Mode and Game State | Unreal Engine 4.27 Documentation | Epic Developer Community

TIL260605 - Unreal - GAS1

옆집히드라 — Fri, 5 Jun 2026 21:00:07 +0900

1. 핵심 개념

TMI) 젭에서 희성님 생축함

UIManager 변경안
GAS
Named Slot: UMG에서 위젯은 자식을 가질 수 없는데 Named Slot을 사용하면 가능

2. 상세 내용

2.1. UIManager 변경안(메모)

기존에 만들어둔 MVP 패턴 기반 UIManager-UIBase-UIRoot 구조를 Lyra 프로젝트의 구현을 반영하고 MVVM 패턴을 적용하는 식으로 리팩토링 하려고 한다.

MVVM 패턴 적용: 기존 리플렉션 기반 Presenter 바인딩 구조를 엎고 MVVM 패턴을 적용한다.
UI Extension System(동적 UI 슬롯 주입) 반영
Soft Reference 기반의 지연 로딩
config = Game을 활용한 데이터 주도 설계 (Data-Driven):
Abstract 키워드로 블루프린트 강제

2.2. Input 흐름

UEnhancedInputLocalPlayerSubsystem에 Input Map Context 등록
Input Action 정의
정의된 Input Action을 IMC에 등록
조작 받을 폰에 IA에 맞는 논리 구현 후 SetupPlayerInputComponent에서 IMC와 바인딩

2.3. Game Ability System(GAS)

![[Pasted image 20260605151430.png]]

GAS는 어빌리티의 소유 및 활성화 기능을 제공하고 어빌리티/액터 간 상호작용을 지원하는 프레임워크이다. 기본 구조는 cpp로 잡고 자주 변겨오디는 설정이나 로직은 블루프린트를 사용하는 것을 추천한다.

GAS의 핵심 구성 요소

ASC: GAS를 구동하는 핵심 컴포넌트로 액터에 해당 컴포넌트를 부착하면 GAS를 사용할 수 있다. GAS의 다른 요소를 쌓아올릴 수 있는 기반 요소; ASC를 부착한 액터끼리 GAS 사용 가능
Gameplay Tag: 계층적인 태깅; 하나의 어빌리티에 여러 개의 게임플레이 태그를 할당한다면 Gameplay Tag Container를 사용할 수 있다.
GA: 모든 행동은 GA로 만들어질 수 있다. 주로 플레이어의 직접적인 입력을 통해 발동되도록 설계
Attrubute Set: 영구적 또는 일시적 스탯을 표시하는데 사용
GE: 단순한 데미지 계산을 넘어 복잡한 효과를 계산 구현 가능
GC(Gameplay Cue): 치장(Cosmetic) 효과 처리를 위한 시스템

GAS의 게임 플레이 루프

ASC는 모든 상호작용의 허브로 GAS의 각 컴포넌트들은 서로를 직접 참조하지 않고 ASC를 통해 통신한다.

GAS의 게임플레이 루프는 Gameplay Tag를 규칙으로 진행한다. 스킬이 시작할 때(GA), 데미지가 들어갈 때(GE) 등 모든 단계에서 태그가 검사되어서 통과 여부를 결정한다.

Gameplay Ability (행동): 애니메이션을 재생하고, 타겟을 찾고, 데미지 데이터를 조립하는 '행동'의 주체
Gameplay Effect (변화 지시): GA가 만들어낸 '데이터 명세서'입니다. 타겟의 스탯을 어떻게 바꿀지(예: 빙결 시 체력 -100)를 담고 있다.
Attribute Set (결과 적용): GE의 지시를 받아 실제 캐릭터의 스탯 수치(메모리 값)가 변동되는 종착지
Feedback (반응): 스탯이 변동되거나 타격이 적중했을 때, Gameplay Cue(얼음 깨지는 파티클/사운드)나 UI 업데이트 델리게이트를 통해 플레이어에게 시각적/청각적 피드백을 반환합니다.

이때 GAS에서의 GA는 아래와 같이 부여된다.

Give (부여 = 스킬 장착):
- 상단의 Gameplay Ability Class는 에디터에서 만든 블루프린트(설계도, UClass)입니다.
- 캐릭터가 태어날 때 이 클래스를 ASC에게 줍니다(GiveAbility). 그러면 ASC는 스킬을 즉시 실행하는 게 아니라, SpecHandle (빨간 원, FGameplayAbilitySpec)이라는 '티켓'을 발급하여 자신의 목록에 저장합니다. (RPG 게임에서 단축키 슬롯에 스킬을 올려둔 상태와 같습니다.)
Activate (실행 = 스킬 사용):
- 플레이어가 단축키를 누르면 ASC는 해당 SpecHandle 티켓을 사용해 스킬을 가동시킵니다(TryActivateAbility).
- 이때 비로소 우측의 Gameplay Ability Instance (실제 메모리에 올라가 실행되는 스킬 객체)가 만들어지거나 활성화됩니다.
AbilityActorInfo (문맥 정보의 전달):
- 왼쪽 ASC 안에 있던 하얀 박스(AbilityActorInfo)가 우측 인스턴스 안으로 화살표 없이 동일하게 존재하는 것이 보이실 겁니다.
- 이 구조체 안에는 "로직의 주인(Owner)은 누구고, 실제 월드에서 움직이는 육신(Avatar)은 누구인가?" 같은 핵심 포인터들이 들어있습니다. ASC가 스킬을 실행할 때 이 문맥 정보를 인스턴스에게 쥐여주기 때문에, 스킬 코드 내부에서 언제든 시전자의 위치나 상태를 쉽게 꺼내 볼 수 있습니다.

3. 질문 및 해결 (Q&A)

Component 리얼 타임에서 생성 절차
ActorLifeCycle
GameMode - GameState
GameMode - GameModeBase
GameplayMessageSubststem

4. 관련 문서 (Links)

TIL260604 - Unreal

옆집히드라 — Thu, 4 Jun 2026 21:53:28 +0900

아이돌 데뷔

1. 핵심 개념

TMap<Key, TArray<Value>> 쓰는 법
CDO

2. 상세 내용

2.1. TMap<Key, TArray<Value>> 쓰는 법

언리얼 엔진의 리플렉션 시스템(UPROPERTY 매크로)은 중첩된 컨테이너(Nested Containers)를 지원하지 않는다. 내용물의 포인터들이 가비지 컬렉터(GC)에 의해 메모리에서 날아가는 것을 방지하려면 UPROPERTY() 선언이 필수적인데, 이 규칙이 충돌하여 UHT(Unreal Header Tool) 컴파일 에러가 발생함

2.2. CDO(Class Default Object)

CDO의 성능상 이점

언리얼 엔진에서UCLASS() 매크로가 붙은 모든 클래스는 메모리 상에 CDO를 생성하고 유지한다.

액터를 스폰할 때마다 생성자를 호출하고 컴포넌트를 새로 조립한다면 성능 저하가 발생하지만, 언리얼에서는 메모리에 이미 생성자를 호출해서 완성된 CDO를 복사하는 방식으로 액터를 생성한다.

또한 언리얼 에디터에서는 맵, 블루프린트를 저장할 때 모든 데이터를 저장하지 않고 CDO에서 변경된 값만을 저장하기 때문에 프로젝트 용량과 메모리 사용량을 아낄 수 있다.

GetDefault<AMonster>()를 사용해서 객체 생성 없이 기본 값 확인이 가능

CDO의 생명 주기

엔진 초기화 단계: 언리얼 에디터를 실행하기 위해 로딩 창이 뜰 때, 엔진은 모든 C++ 코드를 훑어보며 클래스들을 수집합니다.
생성자 일괄 호출: 수집된 모든 클래스의 C++ 생성자를 단 한 번씩만 일괄적으로 쫙 호출합니다. 이때 생성된 결과물이 CDO로 메모리에 고정됩니다.
블루프린트 적용: C++ CDO를 기반으로 블루프린트 CDO가 파생되어 만들어집니다.
게임 플레이 (BeginPlay): 우리가 Play 버튼을 누르면, 이 CDO들을 복사하여 실제 월드에 객체들이 던져지고 그때서야 BeginPlay()가 호출됩니다.

주의점

언리얼에서 CDO는 에디터가 로딩될 때 실행되기 때문에 생성자 시점에서는 게임 월드 자체가 존재하지 않는다. 따라서 생성자 안에서 특정 액터를 찾는다거나, 물리 엔진 조작, 다른 객체 스폰과 같이 월드를 사용하는 작업을 하는 경우 무조건 크래시가 발생한다.

따라서 언리얼에서 동적인 런타임 로직은 생성자가 아닌 BeginPlay()에 넣는게 바람직하다.

3. 질문 및 해결 (Q&A)

4. 관련 문서 (Links)

이미지 출처: 나만의 연습장 :: Unreal Engine Class Default Object (CDO)

TIL260602 - 개인

옆집히드라 — Tue, 2 Jun 2026 21:03:25 +0900

딴짓금지

1. 핵심 개념

이력서를 못쓰는 나에 대한 성찰

2. 상세 내용

오늘은 일기장처럼 진행하겠다.

오늘은 내일배움캠프에서 커리어데이 파트가 진행되는 날이었다. 이력서를 작성하는 세션이였는데 이력서에 넣을 학력이며, 자격증, 경력, 대외활동이 그 무엇하나 없었다. 말 그대로 텅 빈 이력서였다.

불행 중 다행인 것은, 게임 업계에서는 포트폴리오가 특출나면 어필할 여지가 있다는 것이다. 하지만 포트폴리오를 보이기에는 나의 개발 이력이 너무 짧았다. 24년도에 개발 공부를 해서 25년에 그나마 유니티로 친구 졸업프로젝트 8달 같이 진행한 것이 나의 개발 포폴에 전부다.

나는 스스로 그래도 아트워크도 약간이나마 가능하고, 기획을 명세서부터 위키로 총 정리한 경험이 있으니 제너럴리스트? 라는 점에서 차별점이 있을까 여겼지만 클라이언트 개발자로써의 내 역량을 보여주기에는 전혀 장르가 달랐다.(자기소개서 정도는 채울 수 있을지도...)

비록 원하던 기획은 도달하지 못했지만, 졸업 프로젝트로 작성한 포트폴리오라도 작성하고 싶었지만 전혀 쓰기에 정돈된 상태가 아니였다. 프로젝트를 했던 경험만으로는 이력서에 넣지 못하고, 이것을 회고하고 완전히 보여주기 좋은 상태로 정돈(유튜브 시연까지 찍어서)해서 외관으로 보여줘야 비로서 이력서에 넣을 수 있는 것이다.

이력서에 작성할 내력 하나 없는게 절망적이였지만 그래도 오늘 교훈은 얻었다. 내가 작업한 프로젝트는 반드시 문서화를 생활화하고 회고를 거쳐서 완벽하게 남에게 어필할 수 있는 상태로 만드는 것이다.

이번에 드러난 나의 문제점

프로젝트를 하면 회고를 하지 않는다. 보여줄 요소가 없다.
아직도 아트에 매몰된 것 같다. 인디겜 만들기에는 훌륭한 요소지만 회사 취업하기에는 별로 도움이 되 않는다.
나를 보여주는 일에 전혀 능숙하지 못하다.

앞으로 프로젝트를 하면은

개발 도중에 겪은 트러블 슈팅은 기록해놓는다.
유튜브에 시연 영상을 올린다.
프로젝트를 회고하면서 내가 맡은 구현부에 대한 기술 내역서를 작성한다.(남에게 보여주기 좋은 형태 정돈할 것)
기술 내역서에 내 구현력을 어필할만한 어려운 파트를 도전하고 맡는다.

앞으로는 공부하는데 정신 팔리지 말고 기록도 생활화하면서 취업을 염두해야 할 것 같다. 추가로 내년에 부캠 끝나서 상대적으로 널럴해지면 자격증 도전 좀 해야겠다. 채울게 하나도 없어서 너무 부끄럽다...

그럼 의미에서 내 TODO 리스트를 추가해야겠다.

#TODO ProjecYec에서 얻은 경험을 회고한다.
#TODO 내일배움캠프 챕터1에서 만든 피빨이 서바이벌을 회고한다.
#TODO 이세계해방 프로젝트에서 겪은 경험을 회고한다.
#TODO 텍스트 알피지에서 겪은 경험을 회고한다.

3. 질문 및 해결 (Q&A)

아래 같이 기술 내역서를 작성했더라

서머리(뭐잘한다, 팀 플젝 협업, 구현역량), 학력사항, 어쩌구…),
프로젝트(소개, 개발 기간, 기술, 담당 역할,
기타(링크, 브로셔, 영상 링크, 메타휴먼?)),
기술내역서(설계 배경, 핵심 구조 및 설계, 구현 중 해결한 기술적 과제)
문제 해결 사례(트러블 슈팅)

배울 점

자신이 구현한 기능은 모두 블로그에 정리하고 시연 영상까지 잊지 않고 찍는다.
면접을 하지 않더라도 꾸준히 이력서를 작성하면서 갱신했다.
AI에 토큰처럼 자신의 이력을 쌓어서 도움이 되는 결과를 얻어냈다.(채팅 내역이 너무 길때 로드가 느려면 확장 플러그인으로 갱신하는 것이 있더라)

언오더맵에 스트링 키값 쓸 때 비교 연산 줄이기

4. 관련 문서 (Links)

[[이전 관련 노트]]
참고한 외부 링크