3D 액션 어드벤처 미니게임 완성하기

이제 '기능 모음'이 아니라 '게임'입니다

지금까지 우리는 언리얼 엔진의 주요 부품을 하나씩 만져 보았습니다. 입력을 처리했고, 캐릭터를 움직였고, 블루프린트로 로직을 만들었고, 머티리얼과 라이팅으로 장면을 꾸몄으며, 메타휴먼과 애니메이션도 다뤘습니다. 그런데 각각의 기능이 잘 작동한다고 해서 곧바로 게임이 되는 것은 아닙니다.

게임은 기능의 합이 아니라 목표가 있는 경험입니다. 플레이어가 어디로 가야 하는지 알고, 무엇을 피하거나 쓰러뜨려야 하는지 이해하며, 성공했을 때 기분 좋은 피드백을 받고, 실패했을 때 다시 도전하고 싶어야 합니다. 이제부터의 작업은 "대시 기능을 만들었다", "적이 따라온다", "체력바가 보인다" 같은 개별 체크리스트를 넘어섭니다. 이 모든 것을 하나의 흐름으로 엮어야 합니다.

이번 장에서 완성할 미니게임은 단순합니다. 플레이어는 짧은 폐허 숲 지형에 진입하고, 적을 피하거나 처치하면서 목표 오브젝트를 찾아 상호작용한 뒤 탈출 지점으로 돌아옵니다. 상용 게임의 한 스테이지라고 부르기에는 작지만, 언리얼 입문자의 첫 완성작으로는 충분히 큽니다. 이동, 전투, 적 AI, UI, 사운드, 파티클, 빌드까지 모두 들어가기 때문입니다.

Unity 경험자라면 이 단계를 "씬 안에 프리팹과 스크립트를 조립해 플레이 가능한 프로토타입을 만드는 과정"으로 이해하면 됩니다. 다만 언리얼에서는 GameMode, PlayerController, Character, AIController, Widget, Level 같은 역할이 더 뚜렷하게 나뉩니다. 처음에는 제약처럼 보였던 이 구조가, 게임을 끝까지 묶는 단계에서는 오히려 큰 장점이 됩니다.

한 페이지 게임 디자인 문서부터 고정하기

초보자가 미니게임을 만들 때 가장 자주 빠지는 함정은 "일단 만들면서 정하자"는 태도입니다. 실험은 중요하지만, 기준 없이 기능을 추가하면 프로젝트는 금방 부풀어 오릅니다. 그래서 이번 장에서는 먼저 한 페이지 게임 디자인 문서, 줄여서 1-page GDD를 만듭니다.

AI 어시스턴트는 이 단계에서 훌륭한 기획 파트너가 됩니다. Epic Developer Assistant는 언리얼 개발 과정에서 질문에 답하고 팁을 제공하며 코드 생성에도 도움을 주는 AI 도우미로 소개되어 있고,¹ Ludus AI 같은 도구도 UE5 질문 응답, C++ 코드, 블루프린트, 3D 모델 생성 보조를 내세웁니다.² 이런 도구는 노드 자동 생성뿐 아니라, 범위를 줄이고 완성 가능한 게임으로 압축하는 데 사용할 수 있습니다.

AI에게 처음부터 "재미있는 게임 기획해 줘"라고 요청하면 범위가 너무 커지기 쉽습니다. 대신 이렇게 제약을 명확히 주세요.

너는 언리얼 엔진 5를 사용하는 게임 디자이너이자 테크니컬 디렉터야.
나는 Unity 경험이 있고, 지금 UE5 블루프린트로 3D 액션 어드벤처 미니게임을 만들고 있어.
아래 조건에 맞춰 한 페이지 게임 디자인 문서를 작성해 줘.

조건:
- 플레이 시간은 3~5분
- Third Person 템플릿 기반
- 전투는 근접 또는 간단한 발사체 1종만 사용
- 적은 2종 이하
- 레벨은 작은 폐허 또는 숲길 하나
- 승리 조건과 실패 조건이 명확해야 함
- 블루프린트 입문자가 구현 가능한 범위여야 함

포함할 항목:
1. 게임 한 줄 소개
2. 플레이어 목표
3. 핵심 루프
4. 승리 조건
5. 실패 조건
6. 필수 기능
7. 시간이 남으면 추가할 기능
8. 구현하지 않을 기능

이번 장에서 사용할 예시 GDD는 다음과 같습니다.

이 표는 프로젝트의 안전장치입니다. 작업 중간에 "랜덤 아이템도 넣을까?", "NPC 대화도 붙일까?"라는 생각이 들 때마다 이 문서로 돌아오세요. 필수 기능에 없으면 일단 보류합니다. 완성한 뒤에 추가해도 늦지 않습니다.

프로젝트 구조를 먼저 정리하기

작은 프로젝트일수록 폴더 정리를 대충 하기 쉽습니다. 하지만 언리얼의 에셋은 단순 파일이 아니라 서로 참조 관계를 갖는 패키지입니다. 이름을 자주 바꾸고 위치를 마구 옮기면 리다이렉터가 쌓이고, 나중에 참조 문제가 생길 수 있습니다.

권장 폴더 구조는 다음 정도면 충분합니다.

Content/
  MiniAdventure/
    Blueprints/
      Character/
      Enemy/
      Interactables/
      Game/
    UI/
    Maps/
    Materials/
    VFX/
    Audio/
    Data/
    Props/

이번 프로젝트에서 핵심 블루프린트는 다음처럼 구성합니다.

싱글플레이 미니게임에서는 레벨에 배치한 BP_GameManager 액터가 직관적일 수 있습니다. 멀티플레이어까지 생각한다면 GameState 쪽이 더 언리얼다운 선택입니다. 중요한 것은 "목표를 먹었는가?", "게임이 끝났는가?" 같은 전역 상태를 아무 블루프린트에나 흩뿌리지 않는 것입니다.

AI에게 구조 검토를 맡길 때는 이렇게 요청하세요.

다음은 UE5 블루프린트 기반 3D 액션 미니게임의 에셋 구조야.
싱글플레이 기준으로 역할이 겹치거나 나중에 유지보수하기 어려운 부분이 있는지 검토해 줘.
Unity 개발자에게 설명하듯, 어떤 블루프린트가 어떤 책임을 가져야 하는지도 함께 알려 줘.

[블루프린트 목록 붙여넣기]

좋은 AI 답변은 "UI가 게임 상태를 직접 바꾸지 말고 이벤트를 받아 표시만 하게 하라"처럼 책임 분리를 짚어 줍니다. 반대로 "모든 것을 Level Blueprint에 넣으세요"라는 식의 답변은 조심해야 합니다.

레벨 블로킹: 예쁜 맵보다 먼저 길을 만드세요

게임의 첫 버전에서 레벨은 예쁘지 않아도 됩니다. 오히려 처음부터 예쁘게 만들면 플레이 흐름을 보기 어렵습니다. 우리는 먼저 회색 박스와 단순 지형으로 이동 경로, 적을 만나는 위치, 목표물을 발견하는 순간을 검증해야 합니다. 이것을 레벨 블로킹이라고 부릅니다.

이번 미니게임의 레벨 구조는 짧게 설계합니다.

[Start]
   ↓
[좁은 숲길 / 이동 튜토리얼]
   ↓
[첫 적 1마리 / 전투 테스트]
   ↓
[넓은 폐허 광장 / 회피와 추적]
   ↓
[Core Objective]
   ↓
[되돌아가는 길 / 압박]
   ↓
[Exit Portal]

처음부터 고급 에셋을 쓰지 말고 큐브와 기본 지오메트리로 길만 만드세요. 플레이어 캡슐이 지나갈 수 있는지, 점프가 필요한 높이가 적절한지, 카메라가 벽에 너무 자주 걸리지 않는지 확인합니다. Third Person 템플릿 기준으로 통로 폭이 너무 좁으면 캐릭터보다 카메라가 먼저 답답해집니다.

블로킹 단계에서 반드시 확인할 것은 세 가지입니다.

• 플레이어가 목표 방향을 직관적으로 이해하는가.

• 전투 공간에 회피할 여백이 있는가.

• 실패 후 다시 플레이했을 때 목표까지 1분 안에 도달할 수 있는가.

탐험의 깊이는 거리에서 나오지 않습니다. 선택, 위험, 보상, 시야 연출에서 나옵니다. 3~5분짜리 미니게임이라면 레벨은 생각보다 훨씬 작아야 합니다.

PCG와 월드 빌딩 도구는 '완성도 보정'에 씁니다

레벨 블로킹이 끝났다면 공간을 조금씩 자연스럽게 만듭니다. 언리얼 5의 PCG, 즉 Procedural Content Generation은 규칙에 따라 오브젝트를 배치하는 기능입니다. 예를 들어 지형의 특정 영역에 바위와 풀을 뿌리거나, 길 주변에 나무를 배치하거나, 폐허 벽 조각을 랜덤하게 흩뿌릴 수 있습니다.

다만 PCG를 처음부터 게임 규칙의 중심에 두지는 마세요. 이번 장의 목표는 절차적 월드 생성 시스템을 깊이 배우는 것이 아니라, 짧은 레벨을 빠르게 그럴듯하게 만드는 것입니다. 블로킹으로 검증한 이동 경로는 유지하고, PCG는 주변부를 채우는 데 사용합니다.

Dash 같은 월드 빌딩 플러그인도 같은 관점으로 접근하면 좋습니다. Dash는 언리얼 엔진 5용 월드 빌딩 플러그인으로, 콘텐츠 탐색부터 절차적 생성과 카메라 그레이딩까지 포함하는 도구로 소개됩니다.³ 이런 도구는 반복 작업을 줄여 주지만, 설계를 대신해 주지는 않습니다.

작은 폐허 숲 레벨을 만들 때는 다음 순서가 안전합니다.

1. Landscape 또는 단순 Static Mesh 바닥으로 이동 영역을 만듭니다.

2. 큰 바위, 벽, 기둥으로 시야를 나누고 전투 공간의 경계를 잡습니다.

3. NavMesh가 끊기지 않는지 확인합니다.

4. PCG나 수동 배치로 풀, 작은 바위, 나뭇가지, 파편을 추가합니다.

5. 주요 길에는 색, 조명, 실루엣으로 방향성을 줍니다.

6. 플레이 테스트 후 이동을 방해하는 장식물을 제거합니다.

적 AI의 첫 단계: 랜덤 이동과 플레이어 추적

이제 레벨에 생명체를 넣을 차례입니다. 적이 가만히 서 있으면 아무리 모델이 멋져도 게임이 멈춘 것처럼 느껴집니다. 이번 장에서는 기본적인 적 AI 흐름부터 만듭니다. 플레이어를 발견하지 못했을 때는 주변을 랜덤하게 돌아다니고, 플레이어를 감지하면 따라오며, 가까워지면 공격합니다.

언리얼에서 AI 이동을 구현할 때 가장 먼저 필요한 것은 NavMesh입니다. Nav Mesh Bounds Volume을 레벨에 배치하고, 적이 이동해야 하는 영역 전체를 덮도록 크기를 조절합니다. 에디터에서 내비게이션 표시를 켜면 이동 가능한 영역이 녹색으로 보입니다. 언리얼 공식 문서는 내비게이션 메시를 수정하고 생성 영역을 조정하는 방법을 설명합니다.⁴

기본 구성은 다음과 같습니다.

AI Move To 노드는 AI Pawn을 목적지나 타깃 액터로 이동시키는 기본 노드입니다. 입력에는 Pawn, Destination 또는 Target Actor, Acceptance Radius 등이 있으며, Acceptance Radius는 목표에 얼마나 가까워지면 도착으로 볼지를 정하는 값입니다.⁵ 초보자는 이 반경을 너무 작게 설정해서 적이 플레이어 주변에서 떨거나 계속 미세하게 위치를 보정하는 문제를 자주 겪습니다. 근접 공격 적이라면 100~180 정도부터 테스트해 보세요.

랜덤 이동은 다음 흐름으로 시작합니다.

Event BeginPlay
→ RandomMove 호출

RandomMove
→ 현재 적 위치 가져오기
→ Get Random Reachable Point in Radius
→ AI Move To로 해당 위치 이동
→ 이동 성공 또는 실패 후 Delay
→ 플레이어를 발견하지 않은 상태라면 다시 RandomMove

핵심은 "랜덤 위치"가 아니라 "도달 가능한 랜덤 위치"를 찾는 것입니다. 그냥 임의 좌표를 만들면 벽 안쪽, 절벽 아래, NavMesh 밖이 나올 수 있습니다.

플레이어 발견은 처음에는 PawnSensing으로 충분합니다. 적 블루프린트에 PawnSensing 컴포넌트를 추가하고, 시야각과 감지 거리를 조정합니다. OnSeePawn 이벤트에서 감지한 Pawn이 플레이어인지 확인한 뒤, TargetPlayer 변수에 저장하고 추적 이벤트를 호출합니다.

Behavior Tree와 Blackboard로 상태를 구조화하기

랜덤 이동과 추적을 커스텀 이벤트만으로 만들 수는 있습니다. 하지만 적 상태가 늘어나면 이벤트 그래프가 금방 복잡해집니다. 이때 Behavior Tree와 Blackboard를 쓰면 AI 판단을 더 명확하게 나눌 수 있습니다.

Behavior Tree는 AI의 행동 흐름을 트리 형태로 표현하는 도구입니다. Blackboard는 그 행동 판단에 필요한 기억 공간입니다. 이번 미니게임의 적은 다음 세 상태만 가져도 충분합니다.

Blackboard에는 다음 키를 만듭니다.

Behavior Tree의 큰 흐름은 Selector 아래에 우선순위 순서로 배치합니다.

Root
└─ Selector
   ├─ Sequence: Dead
   │  └─ IsDead == true
   ├─ Sequence: Attack
   │  ├─ TargetActor Is Set
   │  ├─ CanAttack == true
   │  └─ Task_Attack
   ├─ Sequence: Chase
   │  ├─ TargetActor Is Set
   │  └─ Move To TargetActor
   └─ Sequence: Patrol
      ├─ Find Random Patrol Location
      ├─ Move To PatrolLocation
      └─ Wait

Tom Looman의 Action Roguelike 샘플 프로젝트는 UE5.6 기반으로 유지되고 있으며, Enhanced Input, 체력 같은 AttributeComponent, 이벤트 기반 UI 반응, Behavior Tree 기반 미니언 AI 등 액션 게임에 필요한 구조를 폭넓게 보여 주는 예시입니다.⁶ 지금 우리가 만드는 미니게임은 그보다 작지만 방향은 같습니다. 플레이어 액션, 적 AI, UI, 게임 모드가 서로 이벤트로 연결될 때 게임이 깔끔해집니다.

AI에게 Behavior Tree 설계를 요청할 때는 "노드 이름만 알려 줘"보다 "상태와 전이 조건을 표로 정리해 줘"가 더 좋습니다.

UE5 블루프린트로 초보자용 근접 적 AI를 만들고 있어.
적은 순찰, 추적, 공격 세 상태만 가진다.
PawnSensing 또는 AI Perception으로 플레이어를 감지하고,
Behavior Tree와 Blackboard로 상태를 관리하려고 해.

다음을 작성해 줘.
1. Blackboard 키 목록
2. Behavior Tree 구조
3. 각 Task가 해야 할 일
4. 초보자가 자주 실수하는 설정
5. AI Move To가 실패할 때 확인할 항목

전투 흐름을 게임 규칙과 연결하기

이제 적이 움직입니다. 하지만 적이 따라오기만 해서는 게임이 아닙니다. 플레이어가 맞고, 적도 맞고, 체력이 줄고, 죽으면 사라지거나 비활성화되어야 합니다. 이전 장에서 체력과 데미지 시스템을 만들었다면 여기서는 그것을 게임 흐름에 연결합니다.

플레이어와 적 모두에게 BP_HealthComponent를 붙이는 구조를 추천합니다. 기본 체력 흐름은 다음과 같습니다.

TakeDamage(DamageAmount)
→ CurrentHealth = CurrentHealth - DamageAmount
→ CurrentHealth를 0~MaxHealth 사이로 Clamp
→ OnHealthChanged 이벤트 호출
→ CurrentHealth <= 0이면 Die 호출

플레이어가 죽으면 GameManager에 실패를 알립니다.

Player Die
→ GameManager.GameOver 호출
→ 입력 비활성화
→ 게임오버 UI 표시
→ 마우스 커서 표시

적이 죽으면 즉시 Destroy Actor를 호출해도 되지만, 가능하면 사망 애니메이션이나 파티클을 재생한 뒤 제거하세요.

Enemy Die
→ IsDead = true
→ AIController Stop Movement
→ Capsule Collision 비활성 또는 Pawn 충돌 변경
→ 사망 VFX/SFX 재생
→ Delay 2초
→ Destroy Actor

근접 공격은 처음에는 Sphere Trace나 Box Collision으로 만들면 충분합니다. 공격 거리 안에 있다고 Tick마다 데미지를 주면 플레이어 체력이 순식간에 사라지므로, bCanAttack 같은 Bool 변수와 AttackCooldown을 반드시 둡니다.

목표 오브젝트와 탈출 조건 만들기

이 미니게임의 승리 조건은 "코어를 획득한 상태로 탈출 포털에 도달한다"입니다. 구현에는 두 개의 상태가 필요합니다. 첫째, 플레이어가 코어를 획득했는가. 둘째, 플레이어가 탈출 포털에 들어왔는가. 이 두 조건이 모두 참일 때 클리어입니다.

BP_CoreObjective는 레벨 중앙 제단에 배치합니다. Static Mesh, 충돌 영역, 빛나는 머티리얼, 약한 Niagara 효과를 붙이면 목표물처럼 보입니다. 플레이어가 가까이 가면 "E: 코어 회수" 같은 상호작용 안내를 띄우고, E 키를 누르면 GameManager의 SetCoreCollected(true)를 호출합니다.

BP_CoreObjective
OnComponentBeginOverlap(Player)
→ Player의 CurrentInteractable = Self
→ HUD에 상호작용 안내 표시

Interact
→ GameManager.SetCoreCollected(true)
→ 코어 획득 사운드/VFX 재생
→ 코어 Mesh 숨기기 또는 Destroy
→ HUD 목표 텍스트 갱신

가능하면 BPI_Interactable 같은 Blueprint Interface를 사용하세요. 플레이어는 "내 앞의 오브젝트가 어떤 종류인지" 몰라도 됩니다. 그저 Interact 메시지를 보내면 됩니다.

탈출 포털은 더 단순합니다.

BP_ExitPortal
OnComponentBeginOverlap(Player)
→ GameManager의 bCoreCollected 확인
→ true라면 ClearGame 호출
→ false라면 HUD에 "아직 코어를 회수하지 않았습니다" 표시

조건이 충족되지 않았을 때도 반드시 이유를 알려 줘야 합니다. 아무 반응 없이 포털이 작동하지 않으면 플레이어는 버그라고 생각합니다.

UMG HUD: 화면은 게임 상태의 번역기입니다

UI는 단순히 예쁜 그림이 아닙니다. UI는 게임 상태를 플레이어가 이해할 수 있는 언어로 번역하는 장치입니다. bCoreCollected == true라는 Bool 변수는 개발자에게만 의미가 있지만, "목표: 탈출 포털로 돌아가세요"라는 문장은 플레이어의 행동을 바꿉니다.

이번 미니게임에 필요한 UI는 많지 않습니다.

WBP_HUD에는 Progress Bar로 체력바를 만듭니다. 좋은 구조는 HUD가 매 Tick마다 플레이어 체력을 훔쳐보는 것이 아니라, 체력이 변할 때 이벤트를 받아 갱신하는 방식입니다.

Player HealthComponent
→ OnHealthChanged(Current, Max) 이벤트 디스패처 호출

HUD
→ BeginPlay 또는 Init 시 OnHealthChanged에 바인딩
→ ProgressBar Percent = Current / Max

목표 텍스트는 GameManager가 관리하는 편이 좋습니다. 처음에는 "목표: 숲의 제단에서 코어를 찾으세요"라고 표시합니다. 코어를 얻으면 "목표: 탈출 포털로 돌아가세요"로 바뀝니다. 클리어하면 HUD를 숨기고 결과 화면을 띄웁니다.

시작 화면과 결과 화면에는 입력 모드 처리가 중요합니다.

게임 시작 전
→ StartMenu 표시
→ Set Input Mode UI Only
→ Show Mouse Cursor = true

Start 버튼 클릭
→ StartMenu 제거
→ HUD 표시
→ Set Input Mode Game Only
→ Show Mouse Cursor = false
→ 플레이어 입력 활성화

게임오버/클리어
→ Result 표시
→ Set Input Mode UI Only
→ Show Mouse Cursor = true
→ 플레이어 입력 비활성화

AI에게 UMG 설계를 요청할 때는 이렇게 물어보면 좋습니다.

UE5 UMG로 3D 액션 미니게임 HUD를 만들고 있어.
표시해야 할 것은 체력바, 현재 목표 텍스트, 상호작용 안내, 클리어/게임오버 화면이야.
블루프린트 입문자가 구현하기 쉬운 구조로 위젯 목록, 변수, 이벤트 흐름을 설계해 줘.
단, HUD가 Tick마다 모든 값을 조회하는 방식은 피하고 싶어.

사운드, Niagara, 카메라 흔들림으로 손맛 만들기

기능이 모두 연결되었는데도 게임이 밋밋하다면 대개 피드백이 부족한 것입니다. 플레이어가 적을 때렸는데 소리도 없고, 파티클도 없고, 카메라도 반응하지 않으면 데미지가 들어가도 손맛이 없습니다.

이번 프로젝트에 필요한 피드백은 크게 세 종류입니다.

타격 피드백 흐름은 다음처럼 구성할 수 있습니다.

Player Attack Trace 성공
→ Hit Actor가 Enemy인지 확인
→ Enemy.TakeDamage 호출
→ Hit Location에 Niagara Spawn System at Location
→ 타격 Sound 재생
→ Camera Shake 재생

카메라 흔들림은 약하게 시작하세요. 일반 공격은 짧고 약하게, 피격이나 강한 공격은 조금 더 강하게 줍니다. 사운드도 마찬가지입니다. 공격 휘두름 소리는 가볍게, 실제 타격음은 더 선명하게, 목표 달성음은 다른 소리보다 조금 특별하게 만듭니다.

GameMode와 GameManager로 전체 흐름 묶기

이제 개별 기능이 거의 준비되었습니다. 하지만 "게임이 시작되고, 플레이되고, 끝나는 흐름"은 별도로 묶어야 합니다. 이 역할을 BP_MiniAdventureGameMode와 BP_GameManager가 나눠 맡습니다.

GameMode는 주로 클래스 구성을 담당합니다. 어떤 PlayerController를 쓸지, 어떤 Pawn을 기본 플레이어로 쓸지, 어떤 HUD 클래스를 사용할지 지정합니다. 실제 플레이 중 목표 상태와 클리어 여부는 GameManager 또는 GameState가 관리합니다.

간단한 싱글플레이 흐름은 다음과 같습니다.

Level BeginPlay
→ GameManager가 StartMenu 표시
→ 플레이어 입력 비활성화

Start 버튼 클릭
→ GameManager.StartGame
→ HUD 표시
→ 플레이어 입력 활성화
→ 목표 텍스트 설정

Core 획득
→ GameManager.bCoreCollected = true
→ HUD 목표 갱신
→ 필요하면 적 추가 스폰

ExitPortal 도달
→ bCoreCollected가 true면 ClearGame
→ 아니면 안내 메시지 표시

Player 체력 0
→ GameManager.GameOver

여기서 중요한 원칙은 UI가 게임 규칙을 직접 소유하지 않는 것입니다. Start 버튼이 눌리면 GameManager에게 "게임 시작해"라고 요청합니다. GameManager가 입력 모드, HUD 표시, 목표 상태를 정리합니다. 포털도 직접 결과 UI를 마음대로 띄우기보다 GameManager의 ClearGame을 호출하고, GameManager가 결과를 처리하게 합니다.

GameManager에 들어갈 변수는 많지 않습니다.

빌드와 패키징: 완성의 마지막 확인

에디터에서 PIE로 잘 돌아가는 것과 실행 파일로 잘 돌아가는 것은 다릅니다. 마지막에는 반드시 Windows 패키징을 해보세요. Project Settings에서 시작 맵이 올바른지, 사용하지 않는 테스트 맵이 기본으로 열리지 않는지, 플러그인 오류가 없는지 확인합니다.

패키징 전 체크리스트는 다음과 같습니다.

• 시작 맵과 GameMode가 의도한 설정인가.

• 모든 블루프린트가 Compile 오류 없이 저장되었는가.

• Redirector를 정리했는가.

• UI 입력 모드가 시작/플레이/결과 화면에서 정상적으로 전환되는가.

• 에셋 경로가 하드코딩되어 있지 않은가.

• 패키징 로그의 첫 번째 Error를 확인했는가.

빌드가 성공하면 실행 파일을 직접 열어보세요. 에디터 없이도 시작 화면이 뜨고, 플레이가 가능하고, 클리어 또는 게임오버까지 도달해야 합니다. 여기까지 왔다면 여러분은 언리얼을 "조금 만져 본 사람"이 아니라, 작은 게임 하나를 끝까지 완성해 본 사람입니다.

마무리: 작지만 끝난 게임은 강합니다

이번 장에서 우리는 입력, 캐릭터, 전투, 적 AI, 목표 오브젝트, UI, 사운드, 파티클, 게임 흐름, 패키징을 하나로 묶었습니다. 각각은 단순한 기능입니다. 하지만 함께 연결되면 플레이 가능한 경험이 됩니다.

첫 미니게임은 작아야 합니다. 작아야 끝까지 갑니다. 끝까지 간 프로젝트는 다음 프로젝트의 기준이 됩니다. 이제 여러분은 "언리얼에서 대시를 만들 수 있다"를 넘어 "언리얼로 작은 게임을 완성할 수 있다"는 경험을 갖게 되었습니다.

다음 장에서는 완성 과정에서 반드시 만나는 문제들, 즉 디버깅, 최적화, 트러블슈팅을 다룹니다. 게임을 끝까지 만들었다면 버그도 끝까지 만나게 됩니다. 이제 그 버그를 엔진을 이해하는 통로로 바꿔 보겠습니다.

참고

¹Epic Developer Assistant For Unreal Engine

²Ludus AI — The Complete AI Toolkit for Unreal Engine Developers

³Dash for Unreal Engine

⁴Modifying the Navigation Mesh in Unreal Engine

⁵AI MoveTo

⁶Action Roguelike Game Sample