언리얼 엔진 교보재

1. 다수 AI의 이동이 왜 어려운가게임에서 단일 AI 캐릭터를 이동시키는 것은 NavMesh와 AIController만으로 충분합니다. 그러나 AI의 수가 수십 명을 넘어 수백, 수천 명 규모로 증가하면 전통적인 방식은 즉각적으로 한계를 드러냅니다.첫 번째 문제는 회피(Avoidance) 입니다. NavMesh는 정적인 장애물을 우회하는 경로를 계산하지만, AI 캐릭터들은 서로를 동적 장애물로 인식하지 못합니다. 결과적으로 동일한 목표 지점으로 이동하는 여러 AI가 한 곳에 겹쳐 쌓이거나 서로 뚫고 지나가는 현상이 발생합니다. 이를 해결하려면 각 AI가 주변 에이전트의 속도와 위치를 실시간으로 인식하고 이동 궤적을 조정해야 합니다.두 번째 문제는 성능 비용입니다. UE5의 AActor 기반 AI는 각자..

1. 이 기능이 필요한 이유언리얼 엔진의 기본 AI 경로 탐색 시스템은 Recast NavMesh 기반으로 동작합니다. NavMesh는 레벨 전체를 미리 굽는(Bake) 정적 구조이기 때문에, 플레이 중에 장애물이 생기거나 이동하는 경우 실시간으로 반응하는 데 한계가 있습니다.예를 들어 다음과 같은 상황을 생각해볼 수 있습니다.폭발로 인해 특정 구역이 일시적으로 위험해져 AI가 접근하지 말아야 할 때NPC가 지나가면서 좁은 통로를 순간적으로 막고 있을 때플레이어가 설치한 바리케이드가 AI의 이동 경로를 막아야 할 때이러한 경우 NavMesh를 실시간으로 다시 굽는 것은 비용이 매우 크고, RVO(Reciprocal Velocity Obstacles) 회피 시스템은 이미 움직이는 에이전트 간의 충돌을 피하..

1. 이 기능이 필요한 이유AI 에이전트의 이동은 NavMesh(Navigation Mesh) 위에서 이루어집니다. NavMesh는 레벨의 걸을 수 있는 표면을 삼각형 폴리곤으로 구워낸 데이터이므로, 물리적으로 연결되지 않은 두 표면 사이에는 자동으로 경로가 생성되지 않습니다.예를 들어 다음과 같은 상황을 생각해봅니다.적 AI가 2층 발코니에서 1층 아래로 뛰어 내려와야 하는 상황플랫포머 게임에서 AI가 낮은 플랫폼에서 높은 플랫폼으로 점프해야 하는 상황사다리나 로프를 타고 이동해야 하는 구간워프 포탈을 통과해 다른 위치로 순간이동해야 하는 상황이 모든 경우에서 AI의 PathFollowingComponent는 NavMesh 경계에 막혀 더 이상 경로를 계산하지 못합니다. NavMesh가 물리적으로 분리..

1. 이 기능이 필요한 이유게임 속 NPC가 단순히 "A 지점에서 B 지점으로 이동한다"는 행위는 겉보기엔 단순해 보이지만, 실제 게임플레이에서는 훨씬 복잡한 요구사항이 따라옵니다.적 AI는 불길이 타오르는 구역을 가급적 돌아가야 하고, 중장갑 유닛은 좁은 통로보다 넓은 대로를 선호해야 하며, 은밀 임무 중인 캐릭터는 조명이 밝은 구역의 비용을 높게 책정해 어두운 경로를 우선시해야 합니다. 이 모든 요구사항을 단순히 MoveToLocation 한 줄로 해결할 수는 없습니다.언리얼 엔진 5는 이 문제를 두 축으로 해결합니다. AI가 이동을 어떻게 요청하는지(AIController와 MoveTo), 그리고 그 이동 경로의 비용과 규칙을 어떻게 조정하는지(UNavArea와 UNavigationQueryFilt..

1. AI가 '걸어다닐 수 있는 공간'을 어떻게 인식하는가게임에서 AI 캐릭터가 장애물을 피해 목표 지점까지 이동하는 기능은, 구현하기 어려운 시스템 중 하나입니다. AI는 사람처럼 눈으로 지형을 파악하는 것이 아니라, 수학적으로 정의된 데이터 구조를 통해 "이 공간을 걸어갈 수 있는가"를 판단합니다.직관적으로 생각해보면, 레벨에는 수만 개의 삼각형 폴리곤으로 이루어진 렌더 메시가 존재합니다. 그 모든 면을 AI가 직접 검사하면서 경로를 계산하는 것은 현실적으로 불가능합니다. 이 문제를 해결하기 위해 게임 업계에서 표준으로 자리잡은 방식이 Navigation Mesh(NavMesh) 입니다.NavMesh는 레벨 지오메트리를 분석하여 "AI가 걸을 수 있는 표면"을 단순화된 볼록 다각형(Convex Pol..

1. 길찾기 시스템이 필요한 이유게임에서 AI 캐릭터가 장애물을 피해 목적지까지 이동하려면, 맵의 어떤 공간이 이동 가능하고 어떤 공간은 불가능한지를 기계가 이해할 수 있는 형태로 표현해야 합니다. 단순히 장애물 충돌 검사만으로는 AI가 최적 경로를 미리 계산할 수 없으며, 실시간으로 수천 번의 레이캐스트를 발사하는 방식은 성능상 현실적이지 않습니다.이 문제를 해결하기 위해 등장한 것이 내비게이션 메시(Navigation Mesh, NavMesh)입니다. NavMesh는 씬의 이동 가능한 표면을 미리 폴리곤 네트워크로 변환해두어, AI가 런타임에 빠르게 경로를 탐색할 수 있는 기반 데이터를 제공합니다. 언리얼 엔진 5는 이 NavMesh 데이터의 생성, 저장, 질의, 갱신을 하나의 통합 시스템으로 관리합..

1. 바운딩 박스가 필요한 이유게임에서 두 오브젝트가 겹치는지 판단하려면, 오브젝트를 구성하는 수천 개의 폴리곤을 전부 비교하는 것은 현실적으로 불가능합니다. 대신, 오브젝트를 단순한 기하도형으로 근사하여 먼저 빠르게 걸러내고, 그 이후에만 정밀 검사를 수행합니다. 이 근사 도형 중 가장 널리 쓰이는 것이 바로 바운딩 박스(Bounding Box) 입니다.언리얼 엔진에서는 모든 UPrimitiveComponent가 바운딩 박스를 내부적으로 유지합니다. 이 바운딩 박스는 렌더링 컬링(Frustum Culling), 물리 브로드페이즈(Broad Phase), 네비게이션 메시 생성, 레벨 스트리밍 등 엔진 전반에서 광범위하게 사용됩니다. 게임플레이 코드에서도 바운딩 박스를 직접 조회하면 값비싼 트레이스(Tra..

1. 인터페이스가 필요한 이유게임 오브젝트 간의 상호작용을 구현할 때 가장 흔히 쓰는 방법은 캐스팅(Cast)입니다. 플레이어 캐릭터가 어떤 오브젝트를 향해 상호작용 키를 누를 때, 대상이 ADoor인지 AChest인지 ANpc인지 확인한 뒤 각각에 맞는 캐스팅을 수행하는 식입니다.이 방식은 당장은 동작하지만 오브젝트 종류가 늘어날수록 조건 분기가 함께 늘어납니다. 호출 측 코드가 모든 피호출 타입을 직접 알고 있어야 하기 때문에, 두 클래스 사이에 강한 결합(Strong Coupling)이 생깁니다. 새로운 상호작용 가능 오브젝트를 추가할 때마다 호출 측 코드를 수정해야 하는 것이 대표적인 문제입니다.UInterface는 이 문제를 해결하기 위한 언리얼 엔진의 인터페이스 시스템입니다. 호출자는 대상 오..

1. 세이브 시스템이 필요한 이유게임을 종료했다가 다시 켰을 때 플레이어의 진행 상황이 사라진다면, 그 게임은 상품으로서의 가치를 잃습니다. 현대 게임에서 세이브와 로드 기능은 선택 사항이 아니라 기본 요건입니다. 플레이어의 위치, 인벤토리, 퀘스트 진행 상황, 레벨 내 오브젝트 상태 등 수많은 데이터를 디스크에 기록하고 다시 복원하는 작업이 바로 세이브 시스템의 핵심입니다.언리얼 엔진은 이 문제를 해결하기 위해 USaveGame 클래스와 UGameplayStatics의 저장/로드 API를 기본으로 제공합니다. 별도의 파일 I/O 코드 없이도 데이터를 디스크에 안전하게 쓰고 읽을 수 있습니다. 직접 파일 시스템을 다루는 방식을 채택할 수도 있지만, 플랫폼별 저장 경로, 직렬화 처리, 오류 복구 등의 복잡..

1. 기존 입력 시스템의 한계언리얼 엔진 4까지 사용되던 기존 입력 시스템은 Action Mapping과 Axis Mapping이라는 두 가지 방식으로 입력을 처리했습니다. Action Mapping은 점프나 공격처럼 눌림/해제만 판별하는 불리언 입력을, Axis Mapping은 캐릭터 이동이나 카메라 회전처럼 연속적인 값(-1.0 ~ 1.0)을 반환하는 입력을 담당했습니다.이 방식은 간단한 프로젝트에서는 충분했지만, 프로젝트 규모가 커질수록 다음과 같은 문제가 드러났습니다.첫째, 모든 입력 설정이 프로젝트 설정(DefaultInput.ini)에 중앙 집중되어 있었습니다. 하나의 파일에 모든 입력 바인딩이 모여 있으니, 여러 개발자가 동시에 작업하거나 다양한 입력 모드를 관리할 때 충돌이 빈번했습니다.둘..