이벤트 기반 파티클 스폰
피격·획득·충돌 이벤트가 발생한 순간에만 시스템을 스폰하고 위치·충격 강도 같은 데이터를 사용자 변수로 전달합니다.
총알이 벽에 맞는 순간, 아이템을 집는 순간, 발사체가 무언가에 부딪히는 순간처럼 한 번만 일어나는 사건에는, 그 순간에 짧은 나이아가라 시스템을 새로 만들어 재생합니다. 이때 사건이 일어난 위치와 방향, 세기를 초기값으로 넘겨주면 같은 효과를 여러 상황에서 다시 쓸 수 있습니다. 이 글에서는 위치에 만드는 방법과 대상에 붙여 만드는 방법을 비교하고, 초기값을 켜기 전에 넘겨야 하는 이유를 살펴본 뒤, 총알이 맞은 자리에 충격 세기에 맞는 스파크를 만들어 봅니다.
위치에 만들기와 붙여서 만들기
일회성 효과를 만드는 노드는 두 가지입니다. Spawn System at Location은 월드의 정한 위치와 회전에 시스템을 만듭니다. 스파크나 폭발처럼 사건이 일어난 자리에 남아야 하는 효과에 알맞습니다. Spawn System Attached는 씬 컴포넌트에 붙여서 만들며, Attach Point Name과 위치 규칙을 함께 정합니다. 이때 Actor 자체를 Attach To Component 입력에 넣지 않으며, 만든 뒤에 입자까지 대상을 따라갈지는 Local Space 설정으로 확인합니다.
두 노드 모두 돌려받은 나이아가라 컴포넌트와 처음에 켤지 여부, 그리고 효과가 끝난 뒤 정리하고 회수하는 정책을 함께 다뤄야 합니다. 일반 Spawn 노드에는 아무 변수 목록이나 실어 보내는 Parameters 핀이 없다는 점도 기억해 둡니다.
처음 값을 켜기 전에 넘기기
활성화 전에 초기값을 전달하는 스폰
게임 Hit→AutoActivate=false 생성→반환 유효성→User 설정→Activate/첫 Burst 읽기의 초기값 경쟁을 피하는 상태 전이 과정이다.
NIAGARA · CH8-3
User 값을 설정한 뒤 Activate합니다
Auto Activate를 끈 상태로 생성하면 첫 Burst가 필요한 초기값을 읽기 전에 값을 전달할 수 있습니다. 도식은 유효한 반환 컴포넌트의 경로입니다.
유효한 반환값
User 이름과 타입을 시스템에 노출한 값과 맞춥니다. 예제의 User.ImpactStrength 0 / 0.5 / 1은 첫 Burst의 0 / 50 / 100개에 대응합니다.
생성 실패
반환값이 무효라면 User 설정과 Activate를 건너뜁니다. 효과 생성 실패가 게임의 명중·피해 처리와 발사체 정리를 막지 않게 합니다.
위치·정리 책임
Location 생성과 Scene Component에 Attach하는 생성은 다릅니다. Local Space와 회전을 함께 확인하고, 유한 효과의 Auto Destroy와 게임 발사체의 Destroy를 각각 설정합니다.
게임의 Hit 이벤트로 생성하는 효과입니다. Niagara 내부 입자 이벤트와 같은 통로가 아닙니다.
Spawn이 실패해도 게임의 충돌 처리는 완료합니다. 효과는 유한 수명과 Auto Destroy로, 발사체는 게임 로직에서 각각 정리합니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 관계·조건 설명 | 원 도표의 관계/값과 동일하다. 유효하게 생성된 뒤 User 값을 먼저 설정하고 Activate한다. 무효 분기는 패널에서 확인한다. |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 비활성 생성 게임 Hit 뒤 AutoActivate=false로 컴포넌트를 만든다. |
|
|
| User 설정 유효한 반환 컴포넌트에 User 값을 넣는다. |
|
|
| Activate 활성 후 첫 Burst가 설정된 User 값을 읽는다. |
|
|
활성화 전에 초기값을 전달하는 스폰
게임 Hit→AutoActivate=false 생성→반환 유효성→User 설정→Activate/첫 Burst 읽기의 초기값 경쟁을 피하는 상태 전이 과정이다.
NIAGARA · CH8-3
User 값을 설정한 뒤 Activate합니다
Auto Activate를 끈 상태로 생성하면 첫 Burst가 필요한 초기값을 읽기 전에 값을 전달할 수 있습니다. 도식은 유효한 반환 컴포넌트의 경로입니다.
유효한 반환값
User 이름과 타입을 시스템에 노출한 값과 맞춥니다. 예제의 User.ImpactStrength 0 / 0.5 / 1은 첫 Burst의 0 / 50 / 100개에 대응합니다.
생성 실패
반환값이 무효라면 User 설정과 Activate를 건너뜁니다. 효과 생성 실패가 게임의 명중·피해 처리와 발사체 정리를 막지 않게 합니다.
위치·정리 책임
Location 생성과 Scene Component에 Attach하는 생성은 다릅니다. Local Space와 회전을 함께 확인하고, 유한 효과의 Auto Destroy와 게임 발사체의 Destroy를 각각 설정합니다.
게임의 Hit 이벤트로 생성하는 효과입니다. Niagara 내부 입자 이벤트와 같은 통로가 아닙니다.
Spawn이 실패해도 게임의 충돌 처리는 완료합니다. 효과는 유한 수명과 Auto Destroy로, 발사체는 게임 로직에서 각각 정리합니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 관계·조건 설명 | 원 도표의 관계/값과 동일하다. 유효하게 생성된 뒤 User 값을 먼저 설정하고 Activate한다. 무효 분기는 패널에서 확인한다. |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 비활성 생성 게임 Hit 뒤 AutoActivate=false로 컴포넌트를 만든다. |
|
|
| User 설정 유효한 반환 컴포넌트에 User 값을 넣는다. |
|
|
| Activate 활성 후 첫 Burst가 설정된 User 값을 읽는다. |
|
|
위 그림은 초기값을 켜기 전에 넘기는 순서를 네 상자로 보여 줍니다. 먼저 Hit 같은 게임 이벤트에서 위치와 법선, 세기를 얻고, Spawn System at Location을 Auto Activate = false로 불러 꺼진 상태의 시스템을 만듭니다. 그다음 돌려받은 컴포넌트를 검사해 유효할 때만 User. 값들을 넣고, 마지막으로 Activate해 시스템이 시작되면서 첫 버스트가 그 초기값을 읽게 합니다. 그림은 유효한 컴포넌트를 돌려받은 경로를 그린 것이고, 단계 그림은 이 순서를 한 단계씩 짚어 보여 줍니다.
그림 아래의 설명은 몇 가지 조건을 덧붙입니다. 사용자 파라미터의 이름과 타입은 시스템에 노출한 값과 맞추며, 이 예제의 User.ImpactStrength가 0, 0.5, 1이면 첫 버스트가 각각 0개, 50개, 100개를 만듭니다. 생성에 실패해 돌려받은 값이 유효하지 않다면 값 넣기와 Activate를 건너뛰되, 그 실패가 게임의 명중이나 피해 처리, 발사체의 정리를 막지 않게 합니다. 또 위치에 만드는 것과 컴포넌트에 붙여 만드는 것은 다르고, 끝이 있는 효과의 Auto Destroy와 게임 발사체의 Destroy는 따로 설정합니다. 이 효과는 게임의 Hit 이벤트로 만드는 것이라, 나이아가라 안의 입자 이벤트와는 다른 경로입니다.
왜 이 순서가 중요한지 따져 봅니다. 시스템이 시작된 뒤에 Spawn에서 읽는 값만 바꾸면, 이미 만들어진 버스트에는 반영되지 않을 수 있습니다. Float User.ImpactStrength를 선언하는 것만으로 Spawn Count가 바뀌지 않는다는 점도 기억해야 합니다. Count를 계산하는 식이 실제로 이 사용자 파라미터를 읽어야 하고, 블루프린트에서 넣는 값의 이름과 Float 타입, Target 컴포넌트가 모두 맞아야 합니다.
예를 들어 첫 버스트가 기본값 1을 이미 읽어 100개를 요청한 뒤에 값을 0.6으로 바꿨다면, 그 변경은 이미 요청된 첫 버스트를 60개로 되돌리지 않습니다. 이 예는 첫 버스트가 값을 읽은 뒤라는 조건이며, Activate를 부르는 순간과 첫 시뮬레이션이 같은 순간이라고 가정하지는 않습니다. 값을 먼저 넣고 Activate하면 이런 초기값의 경쟁을 피할 수 있습니다.
총알 충격 스파크
나이아가라 시스템 준비하기
먼저 기본 스프라이트 시스템을 복제해 NS_ImpactSparks를 만듭니다. 계속 만드는 Spawn Rate를 지우고, Emitter State는 Life Cycle Mode를 Self, Loop Behavior를 Once로 둡니다. 수명이 다한 입자가 모두 마무리되면 시스템도 끝나도록, Emitter State의 Loop Duration을 유한한 값으로 두고 Inactive Response를 Complete로 확인합니다. 이렇게 하면 새 입자를 더 만들지 않게 된 뒤에도 남은 입자가 수명을 마칩니다. 입자의 Lifetime이 0.5초 이하라는 것만으로 반복 중인 이미터나 시스템까지 끝나지는 않습니다. Auto Destroy는 나이아가라 컴포넌트가 끝난 뒤 회수하는 정책이며, 발사체의 Destroy Actor를 대신하는 노드가 아닙니다.
다음으로 Float User.ImpactStrength를 만들고 기본값을 1로 둡니다. Emitter Update의 Spawn Burst Instantaneous에서 0초에 RoundToInt(Clamp(ImpactStrength, 0, 1) × 100)개를 만들게 합니다. Spawn Count는 정수이며, 세기가 0이면 아무것도 만들지 않는 것이 의도한 결과입니다.
그다음 Particle Spawn의 Initialize Particle에서 Lifetime은 0.2초에서 0.5초 사이, 스프라이트 크기는 2cm에서 5cm 사이, 색은 (1, 0.8, 0, 1)로 둡니다. Add Velocity로는 로컬 +Z를 중심으로 한 좁은 원뿔 방향에 속력 100cm/s를 줍니다. 모든 방향으로 퍼지는 구 모양의 분포라면 시스템의 회전을 바꿔도 벽면의 방향이 드러나지 않기 때문입니다. 초기 속도의 공간은 Local로 두어 시스템의 +Z 회전을 반영하고, 생긴 입자가 월드에 남도록 이미터의 Local Space는 끕니다. Particle Update에는 Particle State, Gravity Force, Drag 5, Solve Forces and Velocity를 둡니다.
마지막으로 Sprite Renderer에 프로젝트의 Additive와 Unlit 스파크 머티리얼을 지정합니다. 머티리얼에 Particle Color의 RGB와 Alpha가 연결되어 있어야 하며, M_Fire_SubUV 같은 특정 에셋이 기본으로 설치되어 있다고 가정하지 않습니다.
발사체 블루프린트
발사체가 아직 없다면 Sphere Collision을 루트로 두고, Projectile Movement의 Updated Component를 그 Sphere로 정합니다. 이동 속도와 벽을 막는 콜리전 프리셋을 정하고, 이동 방식에 맞게 Hit 이벤트가 생기는 설정을 확인합니다.
먼저 BP_BulletProjectile의 Sphere에 On Component Hit 이벤트를 추가합니다. 이 실습은 막히는(blocking) Hit를 씁니다. Overlap은 위치와 법선, 충격량을 같은 방식으로 주지 않으므로 대신 쓸 수 있는 이벤트가 아닙니다. Hit와 Overlap 이벤트가 어떤 콜리전 응답에서 오는지는 콜리전 시스템 기본 개념에서 다룹니다.
다음으로 같은 Hit가 여러 번 처리되지 않도록 처리 여부를 나타내는 Bool을 먼저 검사합니다. Bool이 거짓인 경로에 들어오면 다른 효과를 부르기 전에 곧바로 참으로 바꾸고, 그 뒤에 Spawn이 실패하더라도 이번 충돌을 처리한 상태는 그대로 둡니다. 시각 효과가 실패했다고 Bool을 다시 거짓으로 돌리면, 같은 Hit가 또 들어와 게임플레이 처리까지 두 번 일어날 수 있습니다. 이 Bool은 이 발사체 인스턴스 안에서 중복을 막는 용도입니다. 그리고 Hit 구조체를 Break Hit Result로 나누어 Impact Point와 Impact Normal을 얻습니다.
그다음 충격의 세기를 정합니다. 충돌 전에 미리 저장해 둔 발사체의 속력이나 게임에서 정의한 충격 세기를 Map Range Clamped로 0에서 1 사이로 바꿉니다. 예를 들어 0cm/s에서 3000cm/s를 0에서 1로 바꿀 수 있습니다. 빠르게 쓸고 지나가는(Swept) 이동에서는 Normal Impulse가 0일 수 있고 충돌 뒤의 속도는 이미 바뀌었을 수 있으므로, 충격량 핀에만 기대지 않습니다. 속력은 저장한 Velocity 벡터의 길이이며 X 성분 하나가 아닙니다. 이 0에서 1 사이의 값은 시각 효과를 조절하는 값이므로, 질량이나 충돌 시간을 쓴 물리적인 충격량이나 피해량을 이 비율로 계산했다고 해석하지 않습니다.
이어서 Spawn System at Location의 System Template에 NS_ImpactSparks를 넣고, Location에는 Impact Point를, Rotation에는 Make Rot From Z(Impact Normal)을 연결합니다. Scale은 1, Auto Activate는 false, Auto Destroy는 true, Pooling Method는 None으로 시작합니다. 돌려받은 Return Value가 유효한지 확인해, 유효하다면 그 컴포넌트를 Target으로 Set Niagara Variable (Float)를 불러 User.ImpactStrength를 넘기고 Activate합니다. 유효하지 않더라도 게임플레이의 충돌 처리는 이어서 진행되어야 합니다.
마지막으로 효과를 처리한 뒤 Destroy Actor로 발사체를 파괴합니다. 발사체를 먼저 파괴한 뒤 이어지는 실행 경로에 기대지 않도록 순서를 지킵니다. 컴파일과 저장을 하고 발사 경로에서 시험해, 세기 0, 0.5, 1에서 생성 수가 0개, 50개, 100개라는 예상과 비교합니다.
저장해 둔 충돌 전 속력으로 첫 버스트를 계산해 봅니다. 충돌 전 속력이 1800cm/s이고 0에서 3000을 0에서 1로 바꾼다면 User.ImpactStrength는 1800 ÷ 3000 = 0.6입니다. 유효하고 꺼져 있는 컴포넌트에 이 값을 먼저 넘기고 Activate하면, 버스트의 식은 0.6 × 100 = 60개를 요청합니다. 충돌 뒤 0이 된 속력을 읽어 0개가 되는 경로와는 다릅니다. 같은 발사체의 Hit 알림이 다시 와도 처리 Bool이 이미 켜져 있으므로 두 번째 효과를 만들지 않습니다.
실패한 곳 나누어 찾기
효과가 보이지 않는다면 Hit가 일어났는지, Spawn이 돌려준 값이 유효한지, 사용자 파라미터의 이름과 타입이 맞는지, 버스트와 켜는 순서가 맞는지, 머티리얼과 바운드가 맞는지를 차례로 확인합니다. 스파크가 엉뚱한 방향으로 튄다면 Impact Normal과 시스템의 로컬 +Z, 초기 속도의 좌표 공간을 비교합니다. 효과가 끝나지 않고 남는다면 입자의 Lifetime뿐 아니라 이미터와 시스템이 끝나는 조건과 Auto Destroy를 확인합니다.
결과를 기록할 때는 계산과 화면을 구별합니다. 유효한 컴포넌트에 세기 0을 넘겨 Count가 0이 된 것은 정한 식대로 나온 정상 결과이므로, 돌려받은 값이 유효하지 않아 실패한 경우와 구별합니다. 반대로 Count가 60이라는 것은 버스트가 요청하는 수의 계산일 뿐, 화면에서 60개가 모두 보였다는 뜻은 아닙니다. 머티리얼과 바운드, 스케일러빌리티의 컬링 조건은 따로 확인하며, 생성 수와 화면의 픽셀 수를 같은 확인 항목으로 적지 않습니다.
이 흐름은 블루프린트의 사건이 시스템을 만드는 방식입니다. 나이아가라 안의 이벤트 핸들러가 블루프린트에서 보낸 아무 데이터나 저절로 받는 구조와 헷갈리지 않습니다. 충격이 많이 반복되는 효과라면 내장 풀링이나 데이터 채널(Data Channels)을 따로 비교해 보되, 돌려받은 컴포넌트의 수명 규칙은 지킵니다.
더 깊이: 시스템을 여러 번 만드는 대신 데이터 채널에 쓰기
Niagara Data Channels 문서는 플레이 중에 같은 나이아가라 시스템을 여러 번 만들 수 있고, 짧은 시간에 많이 만들면 비용이 커질 수 있다고 설명합니다. 나이아가라 데이터 채널(Niagara Data Channel, NDC)은 게임 코드와 나이아가라 시스템 사이의 통신을 돕는 기능으로, 정해 둔 페이로드(payload)를 게임 코드나 시스템이 읽고 씁니다. 충격 효과에 쓰면 사건마다 시스템을 따로 만드는 대신, 채널에 할당된 버스트 입자를 모두 처리하는 공유 시뮬레이션 하나를 둘 수 있습니다.
구성은 세 부분으로 나뉩니다. 페이로드와 그 채널을 쓰는 시스템 목록을 정하는 데이터 채널 에셋, 채널의 데이터를 읽어 입자를 만드는 리스너(listener) 시스템, 그리고 채널에 직접 값을 쓰는 블루프린트입니다. 이 글의 흐름에 대입하면 Hit가 일어날 때마다 Spawn System at Location을 부르는 대신, 블루프린트가 Impact Point와 법선, 세기를 채널에 쓰고 리스너 시스템이 그 값을 읽어 스파크를 만드는 구조가 됩니다. 리스너 시스템은 무한 반복(Infinite) 루프로 두고, 이벤트가 더 오지 않으면 정리되도록 Complete if Unused 모듈을 넣습니다.
정리
- 한 번만 일어나는 사건에는
Spawn System at Location이나Spawn System Attached로 짧은 시스템을 만들고, 돌려받은 컴포넌트와 정리 정책을 함께 다룹니다. - 초기값이 필요하면
Auto Activate를 끄고 만들어, 돌려받은 컴포넌트가 유효할 때User.값을 넣은 뒤Activate합니다. - 첫 버스트가 이미 읽은 값은 나중에 바꿔도 되돌아가지 않으며, 사용자 파라미터는 Count 식이 실제로 읽어야 결과를 바꿉니다.
- 충격 세기는 충돌 전에 저장한 속도 벡터의 길이로 정하며, X 성분 하나나 충돌 뒤의 속도를 쓰지 않습니다.
- 중복 Hit는 처리 Bool로 막고, 시각 효과가 실패해도 게임플레이 처리와 발사체 정리는 이어서 진행합니다.
연습 문제
1. 음수 방향의 속도
충돌 전에 저장한 Velocity가 (-1800, 0, 0)cm/s입니다. 본문의 0에서 3000 매핑과 Count 식을 쓸 때, 속력을 cm/s와 m/s로 구하고 사용자 세기와 요청할 Count를 구해 보세요. X 성분을 그대로 세기 계산에 넣으면 왜 다른 결과가 나올까요?
해설 보기
벡터의 길이는 1800cm/s, 즉 18m/s입니다. 세기는 1800 ÷ 3000 = 0.6이고, Count는 RoundToInt(0.6 × 100) = 60개입니다.
X 성분 -1800을 그대로 매핑하면 범위의 아래쪽 한계에 걸려 0이 되므로 스파크가 하나도 생기지 않습니다. 움직이는 방향이 음수라고 해서 속력까지 음수인 것은 아니므로, 속력은 반드시 벡터의 길이로 구합니다.
2. 세기 0과 생성 실패
돌려받은 컴포넌트가 유효하고 세기 0을 먼저 넣은 경우와, 따로 속력 3600cm/s로 계산한 세기는 1이지만 Spawn이 돌려준 값이 유효하지 않은 경우를 비교해 보세요. 각 경로에서 값 넣기와 Activate를 하는지, 요청할 Count 식의 값과 실제 생성은 어떻게 적어야 하는지, 발사체 정리와 게임플레이 처리는 계속되어야 하는지 설명해 보세요.
해설 보기
유효한 경로에서는 세기 0을 넣은 뒤 Activate하며, Count 식은 0입니다. 정한 식대로 아무것도 만들지 않은 정상 결과입니다.
유효하지 않은 경로에서는 3600cm/s가 매핑의 위쪽 한계에 걸려 세기는 1, Count 식은 100입니다. 그러나 유효하지 않은 값에는 값 넣기와 Activate를 하지 않으므로, 100개가 실제로 만들어졌다고 적을 수 없습니다. 두 경로 모두 게임의 충돌 처리를 마치고 발사체를 정리합니다. 효과를 만드는 것은 피해 판정이 성공하기 위한 조건이 아니며, 어느 쪽에서도 계산만으로 화면을 확인한 것을 대신하지 않습니다.
3. 이미 읽힌 첫 버스트
실수로 기본값 1을 읽는 첫 버스트가 이미 실행되어 100개를 요청한 뒤, 사용자 값을 0.6으로 바꿨습니다. 첫 요청이 60개로 바뀔까요? 이 실습에서 어떤 실행 순서를 써야 이 문제를 피할 수 있을까요?
해설 보기
바뀌지 않습니다. 이미 값을 읽어 요청한 첫 100개는 그 뒤에 변수를 바꿔도 60개로 되돌아가지 않습니다.
Auto Activate를 false로 두고 만든 뒤, 돌려받은 컴포넌트가 유효한지 확인하고, 사용자 세기를 넣은 다음 Activate하는 순서를 씁니다. 그러면 첫 버스트가 필요한 초기값을 읽은 상태에서 시작합니다.
4. 두 번 온 Hit 알림
같은 발사체 인스턴스의 처리 Bool은 거짓으로 시작하고, Hit 알림이 두 번 왔습니다. 첫 알림에서 Bool을 먼저 참으로 바꾼 뒤 Spawn이 돌려준 값이 유효하지 않았습니다. 게임플레이 처리와 발사체 정리는 한 번 한다는 정책입니다. Spawn 시도와 값 넣기와 Activate, 게임플레이 처리는 각각 몇 번 일어날까요? 시각 효과가 실패했으니 Bool을 거짓으로 되돌려도 될까요?
해설 보기
Spawn 시도는 첫 알림에서 한 번, 값 넣기와 Activate는 0번, 게임플레이 처리와 정리는 각각 한 번입니다. 두 번째 알림은 Bool이 이미 참이므로 처리 경로를 건너뜁니다.
Bool을 거짓으로 되돌리면 안 됩니다. 실패한 것은 시각 효과의 생성일 뿐이고 충돌 사건은 이미 처리되었으므로, Bool을 되돌리면 다음 알림에서 게임플레이 처리가 중복될 수 있습니다.
Spawn System at Location의 입력과 출력은 Epic의 Spawn System at Location 노드 문서에서 확인할 수 있습니다.
다음 글 게임플레이 요소와 상호작용에서는 아이템이나 스킬 같은 게임플레이 요소의 상태에 효과를 연결하고, 게임 판정과 시각 효과의 역할을 나누는 방법을 살펴봅니다.