언리얼 엔진 교보재

[UE5] 언리얼 오브젝트 생성과 소멸

1. 언리얼만의 오브젝트 생성 방식이 필요한 이유C++ 개발자라면 객체를 생성할 때 new 키워드를 사용하고, 사용이 끝나면 delete로 해제하는 것이 자연스럽습니다. 그러나 언리얼 엔진에서는 UObject 파생 클래스에 대해 new와 delete를 직접 사용하는 것이 금지되어 있습니다.그 이유는 언리얼 엔진의 핵심 시스템들이 오브젝트의 생성과 소멸 과정에 깊이 관여하기 때문입니다. 리플렉션 시스템은 오브젝트가 생성될 때 클래스 정보를 등록해야 하고, 가비지 컬렉션(GC) 시스템은 오브젝트의 참조 관계를 추적하여 자동으로 메모리를 회수해야 합니다. 시리얼라이제이션 시스템은 오브젝트를 저장하거나 불러올 때 올바른 초기화 순서를 보장해야 합니다. new를 직접 사용하면 이러한 시스템들이 오브젝트를 인식하지..

[UE5] 컨테이너(TArray, TMap, TSet)

1. 언리얼 엔진에 자체 컨테이너가 필요한 이유게임 프로젝트에서는 수천 개의 액터 목록, 인벤토리 아이템, 퀘스트 데이터 등 대량의 데이터를 효율적으로 관리해야 합니다. C++ 표준 라이브러리(STL)에도 std::vector, std::unordered_map, std::unordered_set 같은 훌륭한 컨테이너가 있지만, 언리얼 엔진은 이를 직접 사용하지 않고 자체 컨테이너 라이브러리(UCL)를 구현하여 사용합니다.그 이유는 크게 세 가지입니다. 첫째, STL은 범용성을 중시하여 컴파일 시간이 길어지는 경향이 있으며, 대규모 게임 프로젝트에서는 이 비용이 누적되어 빌드 시간에 상당한 영향을 줍니다. 둘째, 언리얼 엔진의 리플렉션 시스템과 가비지 컬렉션을 지원하려면 UPROPERTY 매크로와 연동되..

1. 성능 문제가 시작되는 곳게임을 개발하다 보면 초반에는 문제가 없던 프로젝트가 액터 수가 늘어날수록 점점 프레임이 떨어지는 경험을 하게 됩니다. 원인을 추적해보면 상당수는 동일한 패턴에서 비롯됩니다. 매 프레임 실행되는 Tick 함수에 무거운 로직이 들어가 있거나, 컴포넌트를 조회할 때마다 선형 탐색을 반복하거나, 필요 없는 컴포넌트들이 여전히 매 프레임 업데이트되고 있는 경우입니다.언리얼 엔진 5는 액터와 컴포넌트를 효율적으로 운용하기 위한 다양한 도구를 제공합니다. 이 글에서는 그 도구들을 어떻게 올바르게 사용하는지, 그리고 어떤 실수가 성능 병목을 만드는지를 중심으로 설명합니다.2. 액터와 컴포넌트의 구조언리얼 엔진에서 AActor는 월드에 존재하는 모든 객체의 기반 클래스입니다. 액터 자체는 ..

1. 가비지 컬렉션이 필요한 이유C++은 메모리 관리를 개발자에게 전적으로 맡기는 언어입니다. new로 할당한 메모리는 반드시 delete로 해제해야 하며, 이 규칙을 지키지 않으면 메모리 누수가 발생합니다. 반대로 이미 해제한 메모리에 다시 접근하면 댕글링 포인터(Dangling Pointer) 문제가 생기고, 이는 즉시 크래시로 이어지거나 더 위험하게는 눈에 보이지 않는 정의되지 않은 동작(Undefined Behavior)을 유발합니다.게임 엔진처럼 수천 개의 객체가 생성되고 파괴되는 환경에서는 이러한 수동 메모리 관리의 부담이 극도로 커집니다. 레벨을 전환하며 액터를 파괴하고, 스트리밍으로 서브레벨을 로드·언로드하고, 에디터에서 실시간으로 객체를 추가·삭제하는 상황을 모두 수동으로 관리한다면 버그..

1. 리플렉션이 필요한 이유C++은 기본적으로 런타임에 클래스나 구조체가 어떤 멤버를 갖고 있는지 알아낼 수 있는 방법을 제공하지 않습니다. C++ 표준에 포함된 RTTI(Run-Time Type Information)는 typeid와 dynamic_cast 정도의 제한적인 기능만 지원하며, "이 클래스에 어떤 프로퍼티가 있고, 각각의 타입은 무엇인가?"와 같은 질문에는 답할 수 없습니다.그런데 게임 엔진은 런타임에 클래스 정보를 반드시 알아야 합니다. 에디터의 디테일 패널에 프로퍼티를 표시하려면 해당 클래스에 어떤 변수가 있는지 알아야 하고, 저장·로딩(시리얼라이제이션)을 하려면 객체가 가진 데이터를 순회할 수 있어야 합니다. 네트워크 리플리케이션에서 변경된 프로퍼티만 골라서 전송하는 것도 마찬가지입니..

Memento 패턴은 객체의 상태 정보를 가지는 클래스를 따로 생성하여, 객체의 상태를 저장하거나 이전 상태로 복원할 수 있게 해주는 패턴입니다. 구조 Originator Memento 객체와 Memento 객체 상태를 복원하는 Caretaker 객체에 상태를 만들고 저장하는 클래스입니다. Memento Originator의 상태 정보를 저장하는 클래스입니다. Caretaker Originator의 저장과 복원을 제어하는 클래스입니다. 각 시점의 Memento 객체들을 저장하는 Stack 자료구조를 가지고 있습니다. 활용 상황 객체를 이전의 상태로 복구시켜야 하는 경우가 존재할때 유용합니다. Memento 패턴의 장단점 장점 저장된 상태를 핵심 객체와는 다른 별도의 객체에 보관하기 때문에 안전합니다. 핵..

Mediator 패턴은 모든 클래스간의 복잡한 상호작용을 캡슐화하여 하나의 클래스에 위임하여 처리하는 패턴입니다. 즉, M:N의 관계에서 M:1의 관계로 복잡도를 떨어뜨려 유지 보수 및 재사용의 확장성을 유리하게 해주는 패턴입니다. 구조 Mediator 여러 Colleague 객체들을 중재해주는 인터페이스를 정의한 추상 클래스입니다. ConcreteMediator Colleague 객체들을 가지고 있으면서 중재해주는 역할을 하는 클래스입니다. Colleague Mediator 객체에 의해서 관리 및 중재를 받을 기본 클래스입니다. ColleagueA, ColleagueB 실제로 Mediator 객체에 의해서 관리 및 중재를 받는 클래스를 구현한 클래스입니다. 활용 상황 서로 전혀 다른 객체간의 상호 통신..

Template Method 패턴은 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화하여 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 변경하는 패턴입니다. 구조 AbstractClass 템플릿 메서드를 정의하는 클래스입니다. 서브 클래스의 공통 알고리즘을 정의하고 서브 클래스에서 구현될 기능을 primitive 메서드로 정의합니다. ConcreteClass 상속받은 primitive 메서드 또는 hook 메서드를 구현하는 클래스입니다. 슈퍼 클래스에 구현된 템플릿 메서드의 일반적인 알고리즘 흐름에서 서브 클래스의 특색에 맞게 primitive 메서드 등을 구현하는 클래스입니다. 활용 상황 전체적인 알고리즘의 흐름은 동일하지만 알고리즘의 각 부분에서 구현을 다르게 하고 싶을때..

Strategy 패턴은 행위를 클래스로 캡슐화하여 동적으로 행위를 자유롭게 변경할 수 있도록 해주는 패턴입니다. 같은 문제를 해결하는 여러 알고리즘이 클래스별로 캡슐화되어 있고 이들이 필요할때 교체할 수 있도록 함으로써 동일한 문제를 다른 알고리즘으로 해결할 수 있도록 해줍니다. 구조 Strategy 외부에서 동일한 방식으로 알고리즘을 호출하기 위한 메서드를 명시하는 인터페이스 클래스입니다. ConcreteStrategy Strategy 클래스에서 명시한 알고리즘을 실제로 구현한 클래스입니다. Context Strategy 클래스를 사용하는 역할을 수행합니다. 필요에 따라 동적으로 구체적인 전략을 변경할 수 있도록 setter 메서드를 제공합니다. 활용 상황 구현된 알고리즘은 다르지만 동일한 목적을 지닌..

Interpreter 패턴은 문법 규칙을 클래스화한 구조로, 일련의 규칙으로 정의된 문법적 언어를 해석하는 패턴입니다. Interpreter 패턴은 SQL과 같은 계층적 언어를 해석하기 위해 계층 구조를 표현할 수 있습니다. 구조 AbstractExpression 문장을 해석하기 위한 해석자 인터페이스 클래스입니다. TerminalExpression 문장의 종료를 나타내는 해석자 클래스 구현체입니다. NonTerminalExpression 문장의 비종료를 나타내는 해석자 클래스 구현체입니다. Context 문장을 저장하고 관리하는 클래스입니다. Client 실제로 Interpret 메서드를 호출하는 사용자 클래스입니다. 활용 상황 간단한 언어를 구현할때 유용합니다. 문법이 간단하며, 효율보다는 단순하게 ..