효율적으로 Blueprint 만들기: Unreal Fest 2022 세션 요약

정리의 목적은 장식이 아니라 변경 비용 줄이기#

색상, comment box, node comment, Blueprint bookmark, reroute node는 큰 그래프의 지역과 의도를 빠르게 찾게 해 준다. 팀에서는 색상 자체보다 같은 의미에 같은 규칙을 쓰는가가 중요하다.

• variable과 function 이름에 단위와 책임을 드러낸다. Speed보다 WalkSpeedCmPerSec가 의도를 잘 전달한다.
• comment는 node가 무엇을 하는지 번역하기보다 왜 그 규칙이 필요한지 기록한다.
• 멀리 뻗는 execution wire와 data wire를 줄이고 흐름이 한 방향으로 읽히게 배치한다.
• 자주 돌아오거나 debug할 영역은 bookmark로 남긴다.
• 선택한 node를 무작정 collapse하지 말고 function, macro, collapsed graph 중 의미에 맞는 경계를 고른다.

Math Expression node는 짧은 수식을 한 덩어리로 표현할 때 유용하지만, 복잡한 gameplay 규칙을 숨기는 용도로 쓰면 debug가 어려워진다. 계산의 이름이 필요하거나 여러 곳에서 재사용한다면 function으로 빼는 편이 낫다.

Function, Macro, Collapsed Graph 고르기#

Blueprint Functions와 Blueprint Macros의 차이를 먼저 보고 선택한다.

Pure 함수는 값이 아니라 계산이다#

Pure node에는 execution pin이 없고, 소비하는 impure node가 input을 필요로 할 때 평가된다. 이것을 “한 번 계산된 상수”나 자동 cache처럼 취급하면 안 된다. 같은 결과가 여러 소비자에 연결되거나 loop macro가 매 iteration에 값을 요구하면 비싼 Pure 함수가 반복 호출될 수 있다.

다음 패턴이 특히 위험하다.

1
비싼 Pure 함수 ──> For Each Loop의 Array
2
                     └─ loop 내부에서도 같은 Pure 결과를 다시 참조

배열 생성, component 검색, 복잡한 query처럼 비용 있는 계산은 loop 전에 한 번 실행해 local variable에 저장한다.

1
비싼 계산 ──> Local Array 변수 ──> For Each Loop
2
                        └─────────> 다른 소비자

반대로 단순 getter와 작은 수학 연산까지 모두 impure로 만들 필요는 없다. Pure 함수는 side effect가 없고 호출 비용이 작다는 계약을 지킬 때 그래프를 읽기 좋게 한다. 공식 UFunctions 문서는 Pure 함수의 결과가 cache되지 않으며 연결에 따라 여러 번 호출될 수 있음을 경고한다.

Validated Get은 object reference getter와 validity branch를 한 node로 합쳐 null 검사 흐름을 줄여 준다. 그러나 reference가 왜 유효해야 하는지, 누가 lifetime을 소유하는지, network에서 언제 도착하는지까지 해결해 주는 기능은 아니다. 필수 dependency라면 초기화 시점에 검증하고, 선택적 reference라면 invalid 경로가 정상 상태가 되도록 처리한다.

Blueprint lifetime은 SetLifeSpan으로 명시할 수 있다#

투사체나 일시적 effect Actor는 spawn할 때 수명을 설정해 별도 polling 없이 제거할 수 있다. SetLifeSpan(0)은 기존 timer를 지우며 무한 수명으로 돌아간다는 점, destruction은 authority와 replication 수명주기의 영향을 받는다는 점을 함께 고려한다. gameplay state를 가진 Actor를 단순 시간 초과로 없애기 전에는 owner, component, delegate binding 정리 계약을 확인한다.

Construction Script는 빠르고 멱등하게#

Construction Script는 runtime Tick이 아니다. 다만 editor에서 instance property와 transform을 바꾸거나 Blueprint를 compile하고 reconstruction할 때 반복 실행될 수 있다. Run Construction Script on Drag가 켜져 있으면 이동 중 여러 번 실행될 수 있다.

같은 입력으로 다시 실행해도 같은 결과가 나오도록 만들고 아래 동작은 피한다.

• 이전 결과를 정리하지 않는 누적 spawn·append
• asset 저장, 파일 I/O, network 요청
• World 전체 Actor 검색
• seed 없는 random
• 다른 Actor property를 양방향으로 변경
• 수백·수천 component를 편집할 때마다 파괴·재생성

Spline을 따라 fence, road, cable을 미리보는 것처럼 editor feedback이 중요한 작업에는 잘 맞는다. 무거운 bake는 CallInEditor function이나 Editor Utility로 명시적으로 실행한다. 자세한 lifecycle과 C++ OnConstruction 경계는 Construction Script를 안전하게 사용하는 법에 별도로 정리했다.

Call in Editor, Editor Utility, Geometry Script#

Geometry Script를 쓴다고 모든 작업이 runtime-safe인 것은 아니다. 특정 함수가 editor subsystem, asset modification, platform feature에 의존하는지 API별로 확인한다. Geometry Scripting 소개가 범위와 plugin 상태를 설명한다.

상속은 “is-a”, Component는 재사용 가능한 행동#

parent Blueprint의 상태와 virtual event를 파생 class가 특화하는 진짜 is-a 관계에는 상속과 override가 적합하다. 그러나 서로 다른 Actor 종류에 “체력”, “상호작용”, “inventory” 행동을 재사용하려고 깊은 상속 tree를 만들면 불필요한 state와 hard dependency가 따라온다.

Actor Component는 owner Actor의 수명 안에서 재사용 가능한 state와 behavior를 묶는다. network에서 component state를 복제하려면 owner Actor가 replicate되고 component도 replication 대상으로 설정돼야 한다. Component를 붙였다는 사실만으로 client에 state가 자동 복제되지는 않는다.

Data Table, Data Asset, Primary Data Asset#

Data Table을 “모든 공유 데이터의 database”로 만들지 않는다. row가 서로 다른 수명과 대형 dependency를 가진다면 Data Asset과 soft reference가 더 자연스러울 수 있다. 반대로 수백 개의 단순 수치 row를 각각 UObject asset으로 만들면 관리 비용이 커진다. Data-driven Gameplay와 Data Assets를 기준으로 고른다.

Subsystem은 수명 범위가 명확한 service#

UE5에서 공용 service가 필요하면 무조건 GameInstance에 변수를 몰아넣기보다 Engine, Editor, GameInstance, World, LocalPlayer Subsystem의 수명을 비교한다.

• World마다 달라야 하는 runtime service는 World Subsystem 후보
• local player마다 다른 input·UI state는 LocalPlayer Subsystem 후보
• process의 game session 동안 공유하는 service는 GameInstance Subsystem 후보
• editor workflow만 담당하면 Editor Subsystem 후보

Subsystem은 global 잡동사니 보관소나 Actor별 mutable state를 대신하지 않는다. network state도 자동 복제되지 않는다. server authoritative state는 replicated Actor/Component 등 network lifetime이 있는 객체에 두고 subsystem은 조정·조회 service로 제한한다. Programming Subsystems가 수명 종류를 설명한다.

Multiplayer에서는 호출 구조와 replication을 별도로 설계하기#

Blueprint Interface call이나 dispatcher broadcast가 server state를 client로 전송하지 않는다. gameplay state는 server authority에서 변경하고 replicated property 또는 RPC로 동기화한다. local reference가 client에도 존재하는지, owner connection이 누구인지, call이 어느 machine에서 실행되는지를 따로 확인한다.

• client input → 소유 Actor의 validated Server RPC
• server gameplay state 변경 → replicated property와 RepNotify
• client-only UI 갱신 → local dispatcher 또는 view model
• 모든 peer가 같은 object를 가질 것이라는 가정 → NetGUID, relevancy, spawn timing 검증

통신 node를 깔끔하게 골라도 network authority가 잘못되면 correctness는 확보되지 않는다.

Blueprint Header View는 변환기가 아니다#

UE 5.1의 Header View는 C++ 선언 학습과 전환할 class의 형태를 살피는 데 유용하지만, generated output을 복사해 build한다고 Blueprint가 자동 전환되는 것은 아니다. module dependency, export macro, include, UObject lifetime, implementation과 test를 수동으로 설계한다.

Blueprint Nativization은 제거됐다#

UE4의 Blueprint Nativization framework는 UE 5.0에서 제거됐다. Header View는 이를 대체하지 않는다. “모든 Blueprint를 자동 C++ 변환”하기보다 다음 순서로 필요한 부분을 고른다.

1. Blueprint profiler와 Unreal Insights로 hot path를 찾는다.
2. 불필요한 Tick, search, allocation, hard load를 먼저 줄인다.
3. stable API와 designer iteration이 필요한 경계를 정한다.
4. 실제 병목인 계산이나 core system만 C++로 옮긴다.
5. Blueprint child와 data asset이 사용할 작고 명확한 API를 노출한다.

Blueprint와 C++ 비교는 둘을 섞어 각 장점을 쓰는 방식을 권장한다. “Blueprint라서 느리다”보다 어느 function이 얼마나 자주 무엇을 하는지 측정하는 것이 먼저다.

Graph와 계산#

• 이름과 comment가 구현이 아니라 의도와 단위를 설명하는가?
• 비싼 Pure 함수가 여러 consumer나 loop에서 반복 평가되지 않는가?
• function, macro, collapsed graph가 실제 책임과 재사용 범위에 맞는가?
• invalid reference가 정상 분기인지 초기화 실패인지 구분했는가?

Performance와 reference#

• Tick이 연속 update에 필요한가, event·delegate·timer가 더 자연스러운가?
• dumpticks, profiler, Insights로 instance 수와 실제 비용을 측정했는가?
• hard dependency tree를 Reference Viewer와 Size Map으로 확인했는가?
• soft load의 loading, failure, cancellation, lifetime을 처리했는가?

Creation과 architecture#

• Construction Script가 반복 실행돼도 같은 결과를 만드는가?
• 무거운 editor 작업은 명시적 command로 분리했는가?
• 상속, Actor Component, Data Table, Data Asset, Subsystem의 소유권과 수명이 맞는가?
• Geometry Script의 Beta 상태와 function별 runtime 지원을 확인했는가?

Communication#

• target discovery와 호출 contract를 분리했는가?
• cast/interface/dispatcher/tag가 서로 다른 문제를 푸는 도구임을 구분했는가?
• World scan을 매 frame 수행하지 않는가?
• binding과 cached reference의 해제·invalid 시점을 처리했는가?
• multiplayer authority, ownership, relevancy, replication을 별도로 설계했는가?