Unreal 주특기 입문 (아타니) (AI) 개념 정리 + 문제 풀이 | 코드 카타: (푸드 파이트 대회 & 가장 가까운 같은 글자)

 

 

Unreal 주특기 입문 (아타니) (AI) 개념 정리 + 문제 풀이

 

개념정리

Enhanced Input System의 구조와 차이점 분석

  • Enhanced Input System의 핵심 구성 요소는 Input Action(입력 동작), Input Mapping Context(입력 매핑 컨텍스트), Input Modifier(입력 수정자)입니다.
    • Input Handler는 Enhanced Input System의 공식적인 구성 요소가 아니며, 기존 입력 시스템에서 사용되던 일반적인 용어.
  • 런타임에 동적으로 입력 매핑을 변경할 수 있다
  • 하나의 액션에 여러 키를 쉽게 바인딩할 수 있다
  • 입력 값에 대한 전처리(Modifier)와 조건(Trigger)을 적용할 수 있다
  • 프로젝트 설정뿐만 아니라 Input Mapping Context를 통해 다양한 방식으로 입력을 관리할 수 있어 기존 입력 시스템보단 오히려 더 복잡하고 유연합니다. 기존 시스템이 프로젝트 설정에서만 관리되어 상대적으로 단순했습니다.
  • Input Modifier는 입력 값이 최종적으로 액션에 전달되기 전에 값을 변환하거나 수정하는 역할을 합니다. 예를 들어, 입력 값의 범위를 조정하거나, 데드존을 적용하거나, 부호를 반전시키는 등의 작업을 수행합니다.
  • Input Trigger: 입력이 트리거되는 조건을 정의한다
  • Input Mapping Context: 입력 액션과 물리적 키를 연결한다
    • “입력 매핑 묶음”
  • 매핑 컨텍스트의 Priority 속성: 여러 입력 매핑 컨텍스트 간의 우선순위를 결정한다
  • Input Mapping Context는 Enhanced Input Local Player Subsystem의 Add Mapping Context 함수를 사용하여 런타임에 동적으로 추가합니다.
    • 이를 통해 상황에 따라 다른 입력 매핑을 적용할 수 있습니다. 일반적으로 캐릭터의 BeginPlay나 Pawn이 Possess될 때 추가합니다.
  • Input Mapping Context는 입력 키 설정표이고, Enhanced Input에서는 이 설정표를 Enhanced Input Local Player Subsystem에 Add Mapping Context로 등록해야 실제 플레이어 입력으로 동작합니다.

PlayerController와 GameInstance의 역할 이해

  • PlayerController: 현재 레벨에서 플레이어를 조작하는 리모컨
  • PlayerController는 레벨이 전환되면 소멸됩니다.
  • PlayerController는 플레이어의 입력 처리, Pawn 제어, 카메라 관리 등을 담당하며, 각 레벨마다 새로 생성됩니다.
  • GameInstance: 게임 앱 전체를 관리하는 사용자 프로필/세이브 노트
  • GameInstance는 레벨 전환 시에도 데이터를 보존하는 역할.
  • GameInstance는 게임 애플리케이션이 시작될 때 생성되어 게임이 종료될 때까지 유지되는 싱글톤 객체입니다. 레벨 전환, 플레이어 사망 등의 이벤트와 무관하게 지속되므로 전역 데이터 저장에 적합합니다.
  • GameInstance는 게임 전체 생명주기 동안 유지되는 반면, PlayerController는 레벨마다 생성/소멸됩니다. 따라서 레벨 간 유지해야 할 데이터(점수, 인벤토리 등)는 GameInstance에 저장하고, PlayerController에서 이를 참조하는 구조로 사용됩니다.

충돌 이벤트 처리와 충돌 타입 구분

  • 충돌 감지 → 콜리전 채널 확인 → 충돌 응답 결정 → 이벤트 발생 순서로 처리된다
  • 충돌 이벤트는 먼저 물리적 충돌을 감지하고, 각 오브젝트의 콜리전 채널을 확인한 후, 설정된 충돌 응답(Block, Overlap, Ignore)을 결정하여 최종적으로 적절한 이벤트를 발생시킵니다. 이 순서는 엔진의 물리 시스템이 효율적으로 작동하기 위한 표준 흐름입니다.
  • Overlap은 감지 중심, Block은 물리적 차단 중심
  • Overlap은 오브젝트가 서로 겹칠 수 있지만, Block은 물리적으로 막힌다.
  • Block은 OnComponentHit 이벤트를 발생시키고, Overlap은 OnComponentBeginOverlap 이벤트를 발생시킨다
  • Block은 물리 시뮬레이션에 영향을 주지만, Overlap은 트리거 용도로만 사용된다
  • Overlap과 Block은 성능상 차이가 있다.
    • Block은 물리 계산과 충돌 해결(collision resolution)을 수행하므로 더 많은 연산이 필요하지만, Overlap은 단순히 겹침 여부만 확인하므로 상대적으로 가볍습니다. 따라서 트리거나 감지 영역에는 Overlap을 사용하는 것이 효율적입니다.
  • Block 충돌 응답은 두 오브젝트가 물리적으로 서로를 막아 통과할 수 없게 만들며, 이때 OnComponentHit 또는 OnActorHit 같은 Hit 이벤트가 발생합니다. 이는 벽, 바닥, 장애물 등 실제 물리적 충돌이 필요한 경우에 사용됩니다.

인터페이스(Interface) 와 다형성 이해

  • 인터페이스는 구현부 없이 함수의 선언(시그니처)만을 포함하며, 이를 구현하는 클래스들이 반드시 해당 함수를 구현하도록 강제하는 계약입니다.
  • 인터페이스는 서로 다른 클래스들이 공통된 함수 이름을 갖도록 보장하는 계약
  • “이 객체가 정확히 어떤 클래스인지”보다, “이 객체가 어떤 기능을 수행할 수 있는지”에 집중하는 설계 방식
  • 게임 개발에서는 상호작용, 데미지 처리, 아이템 사용, UI 갱신처럼 여러 객체가 공통 행동을 가져야 할 때 인터페이스를 자주 사용합니다.
  • 인터페이스의 핵심은
    • 무엇을 할 수 있는지를 정의한다
    • 어떻게 할지는 각 클래스가 직접 정한다
    • 서로 다른 클래스들을 같은 방식으로 다룰 수 있게 한다
    • 다형성을 활용해 코드 결합도를 낮춘다
  • 인터페이스의 목적:
    • 느슨한 결합(loose coupling)을 통해 코드의 유연성과 유지보수성을 높이는 것이 목적입니다
    • 서로 다른 클래스들이 동일한 함수 시그니처를 공유하도록 강제
    • 다형성을 통해 다양한 타입의 객체를 일관된 방식으로 처리
    • C++ 다중 상속의 문제를 피하면서 여러 인터페이스 구현 가능
  • Unreal Engine에서 인터페이스는 UInterface(리플렉션 시스템용)와 IInterface(실제 구현 및 사용용) 두 개의 클래스로 구성됩니다

Data Table 구조와 게임 데이터 관리

  • Data Table은 구조체(Struct)를 기반으로 행과 열 형태로 게임 데이터를 체계적으로 관리할 수 있는 에셋.
  • Data Table에서 각 행은 고유한 Row Name으로 식별됩니다. Row Name은 문자열 형태로 지정되며, 블루프린트나 C++에서 특정 데이터를 조회할 때 사용됩니다.
  • Data Table은 게임 데이터를 코드에 하드코딩하지 않고, 표 형태로 관리하는 언리얼의 데이터 관리 방식
  • Data Table 보통 구성 (먼저 구조체로 데이터 모양을 정하고, 그 구조체를 기반으로 Data Table을 만듬)
    • Row: 한 줄의 데이터 예: Sword_001
    • Column: 데이터 항목 예: 이름, 공격력, 가격
    • Struct: 표의 한 줄이 어떤 형태인지 정의하는 설계도
  • Data Table은 밸런스 조정이 잦은 데이터에 특히 좋다
    • 아이템 정보
    • 몬스터 능력치
    • 스킬 정보
    • 퀘스트 데이터
    • 대사 데이터
  • 코드를 수정하지 않고 데이터만 바꿀 수 있어서, 게임 개발에서 굉장히 자주 사용됩니다
  • 예제 코드
    • 아이템 데이터 구조체 
      #pragma once

#include "CoreMinimal.h"
#include "Engine/DataTable.h"
#include "ItemData.generated.h"

USTRUCT(BlueprintType)
struct FItemData : public FTableRowBase
{
    GENERATED_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FString ItemName;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    int32 AttackPower;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    int32 Price;
};
    • 이 구조체는 Data Table의 한 행이 가져야 할 컬럼 구조를 정의해요.
    • Data Table에서 행 가져오기해당 행을 찾아서 아이템 이름, 공격력, 가격을 가져오는 흐름
    • FName RowName = TEXT("Sword_001"); FItemData* ItemData = ItemDataTable->FindRow<FItemData>( RowName, TEXT("Item Lookup") ); if (ItemData) { UE_LOG(LogTemp, Log, TEXT("Item: %s"), *ItemData->ItemName); UE_LOG(LogTemp, Log, TEXT("Attack: %d"), ItemData->AttackPower); UE_LOG(LogTemp, Log, TEXT("Price: %d"), ItemData->Price); }
    • 여기서 "Sword_001" 은 Data Table의 Row Name

UMG 위젯 구조와 데이터 바인딩

  • UMG(Unreal Motion Graphics)는 언리얼 엔진의 UI 제작 시스템으로, 위젯 블루프린트를 통해 비주얼 방식으로 사용자 인터페이스를 디자인하고 구현할 수 있다.
  • UMG(Unreal Motion Graphics)는 언리얼에서 게임 UI를 만드는 시스템
    • 게임 화면 위에 올리는 체력바, 점수판, 인벤토리, 버튼 메뉴를 만드는 도구
  • 데이터 바인딩은 위젯의 속성에 함수를 바인딩하여 자동으로 값을 갱신하는 방식
  • 핵심 구성
    • Widget Blueprint
      • UI 화면을 직접 배치하는 블루프린트
      • 버튼, 텍스트, 이미지, Progress Bar 등을 배치.
    • UserWidget
      • C++에서 UMG 위젯을 다룰 때 사용하는 기본 클래스.
    • Viewport
      • 실제 플레이어 화면
      • 만든 위젯을 화면에 보이게 하려면 Viewport에 추가해야 해함.
  • UMG 위젯 구조:
  • Widget Blueprint ├─ Canvas Panel │ ├─ TextBlock │ ├─ ProgressBar │ └─ Button
  • Canvas Panel은 UMG 위젯의 계층 구조에서 최상위 루트 요소로 가장 많이 사용되는 패널 위젯입니다. 캔버스 패널은 자식 위젯들을 자유롭게 배치할 수 있으며, 절대 좌표와 앵커를 통해 위치를 지정할 수 있습니다. Text Block, Image, Button은 모두 하위 위젯 요소들입니다.
  • 코드 예시
    • C++에서 위젯을 화면에 띄우기 
      // MyHUDWidget.h
#pragma once

#include "CoreMinimal.h"
#include "Blueprint/UserWidget.h"
#include "MyHUDWidget.generated.h"

UCLASS()
class MYPROJECT_API UMyHUDWidget : public UUserWidget
{
    GENERATED_BODY()
};

      // MyPlayerController.cpp
#include "MyPlayerController.h"
#include "MyHUDWidget.h"

void AMyPlayerController::BeginPlay()
{
    Super::BeginPlay();

    if (HUDWidgetClass)
    {
        UMyHUDWidget* HUD = CreateWidget<UMyHUDWidget>(this, HUDWidgetClass);

        if (HUD)
        {
            HUD->AddToViewport();
        }
    }
}

      // MyPlayerController.h 일부
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category="UI")
TSubclassOf<class UMyHUDWidget> HUDWidgetClass;
    • 흐름은 위젯 클래스 지정 → 위젯 생성 → 화면에 추가
    • 체력 값을 Progress Bar에 반영하기
      • BindWidget은 C++ 변수와 Widget Blueprint 안의 UI 요소를 연결해주는 역할이에요.
      // MyHUDWidget.h
#pragma once

#include "CoreMinimal.h"
#include "Blueprint/UserWidget.h"
#include "Components/ProgressBar.h"
#include "MyHUDWidget.generated.h"

UCLASS()
class MYPROJECT_API UMyHUDWidget : public UUserWidget
{
    GENERATED_BODY()

public:
    UFUNCTION(BlueprintCallable)
    void SetHealthPercent(float Percent);

protected:
    UPROPERTY(meta = (BindWidget))
    UProgressBar* HealthBar;
};

      // MyHUDWidget.cpp
#include "MyHUDWidget.h"

void UMyHUDWidget::SetHealthPercent(float Percent)
{
    if (HealthBar)
    {
        HealthBar->SetPercent(Percent);
    }
}
      =

애니메이션 블루프린트와 캐릭터 애니메이션 처리

  • Animation Blueprint는 애니메이션 로직을 처리하는 시스템.
  • Animation Blueprint는 언리얼 엔진에서 캐릭터의 애니메이션을 제어하는 블루프린트. (애니메이션 감독)
  • Animation Blueprint는 캐릭터의 현재 상태를 읽고, 그 상태에 맞는 애니메이션을 선택·전환·혼합해서 자연스러운 움직임을 만드는 시스템
  • Animation Blueprint의 주요 역할은 상태 머신 구성, 블렌드 스페이스 활용, 상태에 따른 애니메이션 선택 및 재생 등 애니메이션 제어와 관련된 작업입니다.
  • Animation Blueprint는 EventGraph와 AnimGraph 두 개의 주요 그래프로 구성됩니다. EventGraph는 Blueprint Update Animation 같은 이벤트에서 캐릭터의 상태를 읽어와 Speed, IsInAir 같은 변수를 업데이트합니다. AnimGraph는 이 변수들을 사용하여 State Machine, Blend Space 등을 통해 최종 애니메이션 포즈를 계산하고 출력합니다.
  • Event Graph는 캐릭터의 현재 상태 값을 계산하는 곳 (상태 데이터 계산)
  • Anim Graph는 실제로 어떤 애니메이션을 출력할지 결정하는 곳 (상태 데이터 기반으로 애니메이션 출력)
  • State Machine은 애니메이션 상태와 전환 조건을 관리하는 구조

파티클 시스템과 사운드 컴포넌트 이해

파티클 시스템

  • 파티클 시스템은 이미터(Emitter)를 통해 파티클을 생성하고 관리한다
  • 파티클 시스템은 불, 연기, 비, 눈과 같은 시각 효과를 구현하는 데 사용된다
  • 파티클 시스템은 Cascade 또는 Niagara 에디터를 사용하여 제작할 수 있다
    • Cascade : 언리얼의 기존 파티클 제작 시스템
    • Niagara : 더 최신의 강력한 VFX 제작 시스템
    • 요즘 언리얼에서는 보통 Niagara를 더 많이 사용
    • Niagara는 데이터 기반으로 파티클을 더 세밀하게 제어할 수 있고, 복잡한 이펙트를 만들기에 적합
  • 파티클 시스템은 런타임 중에도 블루프린트나 C++ 코드를 통해 속성을 동적으로 변경할 수 있습니다.
    • 예를 들어 파티클의 색상, 크기, 속도, 발생률 등을 게임 진행 상황에 따라 실시간으로 조정할 수 있습니다.
  • 이미터 (Emitter) 는 파티클을 언제, 어디서, 얼마나, 어떤 방향으로 생성할지 관리하는 핵심 단위
  • Particle : 파티클은 실제로 화면에 보이는 작은 입자 하나
  • Emitter: 이미터는 파티클을 생성하고 관리하는 장치.
    • 파티클 이미터의 모듈은 파티클의 생명 주기 전반에 걸쳐 다양한 속성을 제어합니다. Spawn 모듈은 파티클 생성률을 제어하고, Lifetime 모듈은 수명을, Velocity 모듈은 속도를, Color Over Life 모듈은 색상 변화를 제어하는 등 파티클의 동작, 외형, 물리적 특성을 세밀하게 조정할 수 있습니다.
  • 파티클 시스템의 동작 흐름
    1. Emitter가 파티클을 생성
    2. 파티클에 초기 속성 부여
    3. 매 프레임마다 위치, 크기, 색상 등 갱신
    4. 수명이 끝나면 파티클 제거
    5. 필요하면 계속 새 파티클 생성
    • 예를 들어 불꽃 효과는: 생성 → 위로 이동 → 점점 작아짐 → 색이 흐려짐 → 사라짐
    • 연기는 반대로: 생성 → 위로 천천히 이동 → 점점 커짐 → 투명해짐 → 사라짐
  • 핵심 정리: 파티클 시스템은 UE에서 입자 기반 시각 효과를 만드는 시스템이에요.
    • Particle: 화면에 보이는 작은 입자
    • Emitter: 파티클을 생성하고 관리하는 장치
    • Cascade: 기존 파티클 시스템
    • Niagara: 최신 파티클/VFX 시스템
    • 런타임 제어 가능: 색상, 크기, 발생량, 활성화 상태 등을 변경 가능
  • 대표적인 모듈 종류
    • 파티클을 얼마나 자주, 얼마나 많이 생성할지 정합니다.
    • 예시로 비 효과라면 Spawn이 많을수록 빗방울이 많이 생기고, 적으면 가랑비처럼 보일 수 있어요.
    2. Lifetime 모듈
    • 파티클이 얼마나 오래 살아있을지 정합니다.
    • 연기는 오래 남아야 자연스럽고, 폭죽의 불꽃은 짧게 사라지는 편이 자연스럽겠죠.
    3. Initial Size 모듈
    • 파티클이 처음 생성될 때의 크기를 정합니다.
    • 작은 먼지, 큰 폭발 조각처럼 시작 크기를 조절할 수 있어요.
    4. Initial Velocity 모듈폭발은 바깥쪽으로 빠르게 퍼지고, 연기는 천천히 위로 올라가야 자연스럽습니다.파티클의 생명 주기 동안 색이 어떻게 변할지 정합니다.6. Size Over Life 모듈
    • 시간이 지나면서 파티클의 크기가 어떻게 변할지 정합니다.
    • 연기는 점점 커지며 퍼지고, 불꽃은 점점 작아지며 사라지는 식입니다.
    7. Rotation / Rotation Rate 모듈
    • 파티클의 회전이나 회전 속도를 정합니다.
    • 나뭇잎, 불꽃 조각, 마법 문양처럼 회전이 있으면 훨씬 자연스럽게 보입니다.
    8. Acceleration / Gravity 관련 모듈
    • 파티클에 가속도나 중력 같은 힘을 적용합니다.
    • 불꽃 조각이 아래로 떨어지거나, 연기가 위로 떠오르는 느낌을 만들 때 사용합니다.
    핵심 정리
    • 생성: 얼마나 많이 만들까?
    • 수명: 얼마나 오래 남을까?
    • 움직임: 어디로, 얼마나 빠르게 움직일까?
    • 외형 변화: 색, 크기, 투명도, 회전이 어떻게 바뀔까?
    한 줄로 정리하면,모듈은 파티클 효과를 자연스럽고 의도한 모습으로 보이게 만드는 세부 규칙들
  • 파티클 모듈은 크게 보면 다음 네 가지를 조절합니다.
  • 예를 들어 불꽃은 처음엔 노란색, 중간엔 주황색, 마지막엔 어두운 회색처럼 변할 수 있어요.
  • 5. Color Over Life 모듈
  • 파티클이 처음 생성될 때의 속도와 방향을 정합니다.
  • 1. Spawn 모듈
  • C++에서 파티클 또는 Niagara 사용 예시
    • Niagara 이펙트 스폰
    • #include "NiagaraFunctionLibrary.h" #include "NiagaraSystem.h" void AMyActor::PlayEffect() { if (HitEffect) { UNiagaraFunctionLibrary::SpawnSystemAtLocation( GetWorld(), HitEffect, GetActorLocation() ); } }
    • 파티클 컴포넌트 켜고 끄기
    • #include "NiagaraComponent.h" void AMyActor::StartAura() { if (AuraEffect) { AuraEffect->Activate(); } } void AMyActor::StopAura() { if (AuraEffect) { AuraEffect->Deactivate(); } }

사운드 컴포넌트(Audio Component)

  • 언리얼 엔진에서는 Audio Component를 액터에 추가하여 사운드를 재생합니다. Audio Component는 Sound Wave나 Sound Cue 같은 사운드 애셋을 참조하여 3D 공간 상에서 사운드를 재생할 수 있으며, 볼륨, 피치, 감쇠(Attenuation) 등의 속성을 제어할 수 있습니다
  • 사운드 컴포넌트는 액터에 붙어서 소리를 재생하고 제어하는 부품
  • 사운드 컴포넌트가 하는 일
    • 사운드 재생
    • 사운드 정지
    • 일시정지
    • 볼륨 조절
    • 피치 조절
    • 반복 재생
    • 3D 위치 기반 사운드 처리
    • 특정 액터에 붙어 함께 이동
  • 짧은 효과음: PlaySoundAtLocation() 같은 방식으로도 충분
  • 지속 사운드: AudioComponent로 제어하는 것이 좋음
  • 액터와 함께 움직이는 소리: 사운드 컴포넌트가 적합
  • 런타임 중 재생, 정지, 볼륨, 피치 등을 조절 가능
  • C++ 에서 사용 예시
    • 한 번만 재생하는 사운드
    • #include "Kismet/GameplayStatics.h" void AMyActor::PlayHitSound() { if (HitSound) { UGameplayStatics::PlaySoundAtLocation( this, HitSound, GetActorLocation() ); } }
    • 계속 제어해야 하는 사운드
    • #include "Components/AudioComponent.h" void AMyActor::StartLoopSound() { if (LoopAudioComponent) { LoopAudioComponent->Play(); } } void AMyActor::StopLoopSound() { if (LoopAudioComponent) { LoopAudioComponent->Stop(); } }
    AudioComponent->Play();
AudioComponent->Stop();
    중간에 볼륨이나 피치를 바꿔야 할 때액터와 함께 움직이는 소리
    • 이런 3D 위치 기반 사운드에 잘 맞습니다.
    일시정지, 재개, 페이드 처리가 필요할 때
    • 예를 들어 경보음이 갑자기 꺼지지 않고 서서히 작아져야 한다면 Audio Component가 적합
    AudioComponent->FadeOut(1.0f, 0.0f);
    • 짧게 한 번만 나는 소리는 굳이 Audio Component까지 안 써도 됩니다.
      • 이런 건 보통 PlaySoundAtLocation() 또는 PlaySound2D()로 충분해요.
    =
  • AudioComponent->SetVolumeMultiplier(0.8f); AudioComponent->SetPitchMultiplier(1.2f);

 

문제풀이

블루프린트와 C++ 연동 방식 이해

  • 블루프린트의 장점으로 옳은 것을 모두 고른 것은?
    블루프린트의 주요 장점은 빠른 반복 개발(가), 접근성(다), 실시간 개발(라)입니다. 나는 틀린 설명으로, 블루프린트는 비주얼 스크립팅이므로 복잡한 알고리즘 구현 시 C++보다 성능이 낮습니다. 성능이 중요한 로직은 C++로 작성하는 것이 권장됩니다.
  • 가. 컴파일 시간이 짧아 빠른 반복 개발이 가능하다 나. 복잡한 알고리즘 구현 시 C++보다 성능이 우수하다 다. 비프로그래머도 게임 로직을 구현할 수 있다 라. 실시간으로 결과를 확인하며 개발할 수 있다
  • C++의 장점과 블루프린트의 장점을 올바르게 연결한 것은?
    C++는 복잡한 로직을 효율적으로 구현할 수 있고 성능이 우수하며, 블루프린트는 빠른 프로토타이핑과 반복 개발에 유리합니다. A는 장점이 반대로 연결되었고, C와 D도 각각의 실제 장점과 다릅니다. C++는 성능과 코드 관리, 블루프린트는 접근성과 빠른 개발이 주요 장점입니다.
  • A.C++ - 시각적 디버깅 용이 / 블루프린트 - 높은 실행 성능 B.C++ - 복잡한 로직 구현 효율적 / 블루프린트 - 빠른 프로토타이핑 C.C++ - 비프로그래머 접근성 높음 / 블루프린트 - 소스 코드 관리 용이 D.C++ - 컴파일 시간 짧음 / 블루프린트 - 메모리 사용 효율적

Enhanced Input System의 구조와 차이점 분석

  • Enhanced Input System의 가장 핵심적인 구성 요소가 아닌 것은?
    Enhanced Input System의 핵심 구성 요소는 Input Action(입력 동작), Input Mapping Context(입력 매핑 컨텍스트), Input Modifier(입력 수정자)입니다. Input Handler는 Enhanced Input System의 공식적인 구성 요소가 아니며, 기존 입력 시스템에서 사용되던 일반적인 용어입니다.
  • A.Input Action B.Input Mapping Context C.Input Modifier D.Input Handler
  • 기존 입력 시스템과 비교했을 때, Enhanced Input System의 주요 장점으로 옳지 않은 것은?
    Enhanced Input System은 프로젝트 설정뿐만 아니라 Input Mapping Context를 통해 다양한 방식으로 입력을 관리할 수 있어 오히려 더 복잡하고 유연합니다. 기존 시스템이 프로젝트 설정에서만 관리되어 상대적으로 단순했습니다. A, B, D는 모두 Enhanced Input System의 장점입니다.
  • A.런타임에 동적으로 입력 매핑을 변경할 수 있다 B.하나의 액션에 여러 키를 쉽게 바인딩할 수 있다 C.프로젝트 설정에서만 입력을 관리하여 더 간단하다 D.입력 값에 대한 전처리(Modifier)와 조건(Trigger)을 적용할 수 있다
  • Input Modifier의 역할로 가장 옳은 것은?
    Input Modifier는 입력 값이 최종적으로 액션에 전달되기 전에 값을 변환하거나 수정하는 역할을 합니다. 예를 들어, 입력 값의 범위를 조정하거나, 데드존을 적용하거나, 부호를 반전시키는 등의 작업을 수행합니다. A는 Input Trigger의 역할, C는 Input Mapping Context의 역할, D는 매핑 컨텍스트의 Priority 속성에 해당합니다.
  • A.입력이 트리거되는 조건을 정의한다 B.입력 값이 최종적으로 전달되기 전에 변환 또는 수정한다 C.입력 액션과 물리적 키를 연결한다 D.여러 입력 매핑 컨텍스트 간의 우선순위를 결정한다
  • Input Mapping Context를 캐릭터에 적용하는 올바른 방법은?
    Input Mapping Context는 Enhanced Input Local Player Subsystem의 Add Mapping Context 함수를 사용하여 런타임에 동적으로 추가합니다. 이를 통해 상황에 따라 다른 입력 매핑을 적용할 수 있습니다. 일반적으로 캐릭터의 BeginPlay나 Pawn이 Possess될 때 추가합니다.
  • A.프로젝트 설정의 Input 섹션에 자동으로 등록된다 B.Enhanced Input Local Player Subsystem을 통해 Add Mapping Context 함수로 추가한다 C.Input Action 생성 시 자동으로 연결된다 D.Level Blueprint에서만 설정할 수 있다

PlayerController와 GameInstance의 역할 이해

  • Unreal Engine에서 PlayerController의 주요 역할로 옳지 않은 것은?
    PlayerController는 레벨이 전환되면 소멸됩니다. 레벨 전환 시에도 데이터를 보존하는 것은 GameInstance의 역할입니다. PlayerController는 플레이어의 입력 처리, Pawn 제어, 카메라 관리 등을 담당하며, 각 레벨마다 새로 생성됩니다.
  • A.플레이어의 입력을 처리하고 Pawn에게 전달 B.레벨 전환 시에도 유지되어 데이터를 보존 C.카메라 제어 및 시점 관리 D.AI가 아닌 사람 플레이어의 제어를 담당
  • GameInstance의 생명주기에 대한 설명으로 옳은 것은?
    GameInstance는 게임 애플리케이션이 시작될 때 생성되어 게임이 종료될 때까지 유지되는 싱글톤 객체입니다. 레벨 전환, 플레이어 사망 등의 이벤트와 무관하게 지속되므로 전역 데이터 저장에 적합합니다.
  • A.레벨이 전환될 때마다 새로 생성되고 이전 인스턴스는 소멸된다 B.게임 시작부터 종료까지 단 한 번만 생성되어 유지된다 C.플레이어가 죽을 때마다 리셋된다 D.각 플레이어마다 별도의 인스턴스가 생성된다
  • 다음 중 PlayerController와 GameInstance의 관계를 가장 정확하게 설명한 것은?
    GameInstance는 게임 전체 생명주기 동안 유지되는 반면, PlayerController는 레벨마다 생성/소멸됩니다. 따라서 레벨 간 유지해야 할 데이터(점수, 인벤토리 등)는 GameInstance에 저장하고, PlayerController에서 이를 참조하는 구조로 사용됩니다.
  • A.PlayerController가 GameInstance를 포함하고 관리한다 B.GameInstance가 PlayerController보다 생명주기가 길어 영구 데이터 저장에 사용된다 C.둘은 서로 독립적이며 데이터를 공유할 수 없다 D.PlayerController와 GameInstance는 동일한 생명주기를 가진다

충돌 이벤트 처리와 충돌 타입 구분

  • Unreal Engine에서 충돌 이벤트 처리 흐름에 대한 설명으로 옳은 것은?
    충돌 이벤트는 먼저 물리적 충돌을 감지하고, 각 오브젝트의 콜리전 채널을 확인한 후, 설정된 충돌 응답(Block, Overlap, Ignore)을 결정하여 최종적으로 적절한 이벤트를 발생시킵니다. 이 순서는 엔진의 물리 시스템이 효율적으로 작동하기 위한 표준 흐름입니다.
  • A.충돌 감지 → 콜리전 채널 확인 → 충돌 응답 결정 → 이벤트 발생 순서로 처리된다 B.이벤트 발생 → 충돌 감지 → 콜리전 채널 확인 → 충돌 응답 결정 순서로 처리된다 C.충돌 응답 결정 → 충돌 감지 → 이벤트 발생 → 콜리전 채널 확인 순서로 처리된다 D.콜리전 채널 확인 → 이벤트 발생 → 충돌 감지 → 충돌 응답 결정 순서로 처리된다
  • Overlap과 Block의 차이점에 대한 설명으로 옳지 않은 것은?
    Overlap과 Block은 성능상 차이가 있습니다. Block은 물리 계산과 충돌 해결(collision resolution)을 수행하므로 더 많은 연산이 필요하지만, Overlap은 단순히 겹침 여부만 확인하므로 상대적으로 가볍습니다. 따라서 트리거나 감지 영역에는 Overlap을 사용하는 것이 효율적입니다.
  • A.Overlap은 오브젝트가 서로 겹칠 수 있지만, Block은 물리적으로 막힌다 B.Block은 OnComponentHit 이벤트를 발생시키고, Overlap은 OnComponentBeginOverlap 이벤트를 발생시킨다 C.Overlap과 Block 모두 충돌 이벤트를 발생시키므로 성능상 차이가 없다 D.Block은 물리 시뮬레이션에 영향을 주지만, Overlap은 트리거 용도로만 사용된다
  • 다음 중 Block 충돌 응답이 발생했을 때의 특징으로 옳은 것은?
    Block 충돌 응답은 두 오브젝트가 물리적으로 서로를 막아 통과할 수 없게 만들며, 이때 OnComponentHit 또는 OnActorHit 같은 Hit 이벤트가 발생합니다. 이는 벽, 바닥, 장애물 등 실제 물리적 충돌이 필요한 경우에 사용됩니다.
  • A.두 오브젝트가 서로를 통과하며 BeginOverlap 이벤트가 발생한다 B.두 오브젝트가 물리적으로 막히며 Hit 이벤트가 발생한다 C.충돌이 감지되지만 어떠한 이벤트도 발생하지 않는다 D.오브젝트가 서로를 무시하고 통과한다

인터페이스와 다형성 이해

  • Unreal Engine에서 인터페이스(Interface)의 정의로 옳은 것은?
    인터페이스는 구현부 없이 함수의 선언(시그니처)만을 포함하며, 이를 구현하는 클래스들이 반드시 해당 함수를 구현하도록 강제하는 계약입니다. A는 추상 클래스에 대한 설명이며, C는 인터페이스가 다중 구현을 지원하지만 다중 상속과는 다른 개념입니다. D는 블루프린트의 다른 기능에 대한 설명입니다.
  • A.클래스 간의 계층 구조를 강제하는 추상 클래스 B.구현부 없이 함수 선언만을 포함하며, 여러 클래스가 동일한 함수를 구현하도록 보장하는 계약 C.다중 상속을 가능하게 하는 부모 클래스 D.블루프린트에서만 사용 가능한 이벤트 디스패처
  • 인터페이스를 사용하는 주요 목적으로 옳지 않은 것은?
    인터페이스는 오히려 클래스 간의 결합도를 낮추기 위해 사용됩니다. 느슨한 결합(loose coupling)을 통해 코드의 유연성과 유지보수성을 높이는 것이 목적입니다. A, B, D는 모두 인터페이스의 올바른 사용 목적입니다.
  • A.서로 다른 클래스들이 동일한 함수 시그니처를 공유하도록 강제 B.다형성을 통해 다양한 타입의 객체를 일관된 방식으로 처리 C.클래스 간의 강한 결합도를 높여 코드 재사용성 향상 D.C++ 다중 상속의 문제를 피하면서 여러 인터페이스 구현 가능
  • 다음 중 Unreal Engine의 인터페이스 구현 방식으로 옳은 것은?
    Unreal Engine에서 인터페이스는 UInterface(리플렉션 시스템용)와 IInterface(실제 구현 및 사용용) 두 개의 클래스로 구성됩니다. B는 C#의 방식이며, C는 추상 클래스에 대한 설명입니다. D는 잘못된 설명으로, C++에서도 인터페이스를 구현할 수 있습니다.
  • A.UInterface와 IInterface 두 개의 클래스로 구성되며, U 접두사 클래스는 리플렉션용, I 접두사 클래스는 실제 구현용이다 B.interface 키워드를 사용하여 선언하며, 자동으로 컴파일러가 처리한다 C.추상 클래스를 사용하여 순수 가상 함수로만 구현한다 D.블루프린트 인터페이스만 사용 가능하며 C++에서는 직접 구현할 수 없다

Data Table 구조와 게임 데이터 관리

  • Unreal Engine에서 Data Table의 정의로 옳은 것은?
    Data Table은 구조체(Struct)를 기반으로 행과 열 형태로 게임 데이터를 체계적으로 관리할 수 있는 에셋입니다. A는 그래프 편집과 관련된 내용이며, C는 UV 매핑과 관련된 내용, D는 메모리 관리와 관련된 내용으로 Data Table과는 무관합니다.
  • A.블루프린트 노드를 시각적으로 정리하는 도구 B.구조체를 기반으로 행과 열 형태로 게임 데이터를 관리하는 에셋 C.게임 내 3D 모델의 UV 좌표를 저장하는 시스템 D.레벨 간 데이터 전달을 위한 임시 메모리 버퍼
  • Data Table을 생성하기 위해 먼저 필요한 것은?
    Data Table을 생성하려면 먼저 데이터의 구조를 정의하는 Struct(구조체)가 필요합니다. 구조체는 Data Table의 열(Column) 구조를 정의하며, 각 행(Row)은 이 구조체를 기반으로 데이터를 저장합니다. A, B, D는 모두 다른 용도의 에셋입니다.
  • A.Animation Montage B.Material Instance C.Struct(구조체) D.Widget Blueprint
  • Data Table에서 각 행(Row)을 식별하는 데 사용되는 것은?
    Data Table에서 각 행은 고유한 Row Name으로 식별됩니다. Row Name은 문자열 형태로 지정되며, 블루프린트나 C++에서 특정 데이터를 조회할 때 사용됩니다. Primary Key는 데이터베이스 용어이고, Index Number는 배열에서 사용되며, GUID는 Unreal의 에셋 식별자입니다.
  • A.Primary Key B.Row Name C.Index Number D.GUID

UMG 위젯 구조와 데이터 바인딩

  • UMG(Unreal Motion Graphics)에 대한 설명으로 옳은 것은?
    UMG(Unreal Motion Graphics)는 언리얼 엔진의 UI 제작 시스템으로, 위젯 블루프린트를 통해 비주얼 방식으로 사용자 인터페이스를 디자인하고 구현할 수 있습니다. B는 3D 모델링 도구에 대한 설명이고, C는 UMG가 블루프린트에서 사용 가능하므로 틀렸으며, D는 물리 엔진에 대한 설명입니다.
  • A.UMG는 언리얼 엔진의 UI 제작 도구로, 위젯 블루프린트를 통해 시각적으로 UI를 디자인할 수 있다. B.UMG는 3D 모델링 전용 도구로, 캐릭터와 오브젝트를 제작하는 데 사용된다. C.UMG는 C++ 코드로만 작성할 수 있으며, 블루프린트에서는 사용할 수 없다. D.UMG는 게임 물리 시뮬레이션을 담당하는 언리얼 엔진의 물리 엔진이다.
  • UMG 위젯의 계층 구조에서 최상위 루트 요소로 사용되는 것은?
    Canvas Panel은 UMG 위젯의 계층 구조에서 최상위 루트 요소로 가장 많이 사용되는 패널 위젯입니다. 캔버스 패널은 자식 위젯들을 자유롭게 배치할 수 있으며, 절대 좌표와 앵커를 통해 위치를 지정할 수 있습니다. Text Block, Image, Button은 모두 하위 위젯 요소들입니다.
  • A.Text Block B.Canvas Panel C.Image D.Button
  • 데이터 바인딩(Data Binding)을 사용하여 HUD에 플레이어의 체력을 실시간으로 표시하려고 할 때, 옳지 않은 방법은?
    Tick 이벤트에서 매 프레임마다 Set Text를 호출하는 것은 데이터 바인딩 방식이 아니라 수동 업데이트 방식입니다. 데이터 바인딩은 위젯의 속성에 함수를 바인딩하여 자동으로 값을 갱신하는 방식입니다. A, B, D는 모두 올바른 데이터 바인딩 방법입니다. Tick을 사용한 방법도 작동하지만 성능상 비효율적이며 바인딩 방식이 아닙니다.
  • A.Text Block의 Text 속성에 바인딩 함수를 연결하여 체력 값을 반환한다. B.Progress Bar의 Percent 속성에 바인딩 함수를 연결하여 0.0~1.0 사이의 체력 비율을 반환한다. C.블루프린트에서 Tick 이벤트마다 Set Text 노드를 사용하여 체력 텍스트를 업데이트한다. D.위젯 블루프린트에서 Get Player Character 노드를 통해 캐릭터의 체력 변수에 접근한다.

애니메이션 블루프린트와 캐릭터 애니메이션 처리

  • 언리얼 엔진에서 Animation Blueprint의 주요 역할로 옳지 않은 것은?
    Animation Blueprint는 애니메이션 로직을 처리하는 시스템으로, 3D 메시 모델링은 별도의 3D 툴(Maya, Blender 등)에서 수행됩니다. Animation Blueprint의 주요 역할은 상태 머신 구성(B), 블렌드 스페이스 활용(C), 상태에 따른 애니메이션 선택 및 재생(D) 등 애니메이션 제어와 관련된 작업입니다.
  • A.캐릭터의 3D 메시 모델링을 직접 생성한다 B.애니메이션 상태 머신을 구성하여 애니메이션 전환을 관리한다 C.블렌드 스페이스를 활용하여 여러 애니메이션을 혼합한다 D.캐릭터의 현재 상태에 따라 적절한 애니메이션을 선택하고 재생한다
  • Animation Blueprint의 EventGraph에서 캐릭터의 이동 속도를 계산하여 저장하는 과정으로 옳은 것은?
    캐릭터의 이동 속도는 Try Get Pawn Owner로 캐릭터를 가져온 후, Get Velocity 노드로 속도 벡터를 얻고, Vector Length 노드로 벡터의 크기(스칼라 값)를 계산하여 Speed 같은 변수에 저장하는 것이 일반적인 방법입니다. 이 Speed 변수는 이후 AnimGraph에서 애니메이션 블렌딩이나 상태 전환 조건으로 사용됩니다.
  • A.Get Velocity 노드로 속도 벡터를 가져와 Vector Length 노드로 크기를 계산한 후 변수에 저장한다 B.Get Location 노드로 위치를 가져와 Delta Time으로 나눈 후 변수에 저장한다 C.Get Rotation 노드로 회전값을 가져와 각속도를 계산한 후 변수에 저장한다 D.Get Animation Asset 노드로 현재 애니메이션의 재생 속도를 가져와 변수에 저장한다
  • Animation Blueprint의 두 가지 주요 그래프에 대한 설명으로 옳은 것은?
    Animation Blueprint는 EventGraph와 AnimGraph 두 개의 주요 그래프로 구성됩니다. EventGraph는 Blueprint Update Animation 같은 이벤트에서 캐릭터의 상태를 읽어와 Speed, IsInAir 같은 변수를 업데이트합니다. AnimGraph는 이 변수들을 사용하여 State Machine, Blend Space 등을 통해 최종 애니메이션 포즈를 계산하고 출력합니다.
  • A.EventGraph는 애니메이션 로직과 변수를 업데이트하고, AnimGraph는 최종 포즈를 출력한다 B.EventGraph는 최종 포즈를 출력하고, AnimGraph는 애니메이션 변수를 업데이트한다 C.EventGraph는 UI를 제어하고, AnimGraph는 사운드를 재생한다 D.EventGraph는 물리 시뮬레이션을 담당하고, AnimGraph는 파티클 효과를 관리한다

파티클 시스템과 사운드 컴포넌트 이해

  • 언리얼 엔진의 파티클 시스템(Particle System)에 대한 설명으로 옳지 않은 것은?
    파티클 시스템은 런타임 중에도 블루프린트나 C++ 코드를 통해 속성을 동적으로 변경할 수 있습니다. 예를 들어 파티클의 색상, 크기, 속도, 발생률 등을 게임 진행 상황에 따라 실시간으로 조정할 수 있습니다. A는 파티클 시스템의 기본 구조, B는 주요 사용 용도, D는 언리얼에서 제공하는 파티클 제작 도구에 대한 올바른 설명입니다.
  • A.파티클 시스템은 이미터(Emitter)를 통해 파티클을 생성하고 관리한다 B.파티클 시스템은 불, 연기, 비, 눈과 같은 시각 효과를 구현하는 데 사용된다 C.파티클 시스템은 한 번 생성되면 런타임 중에 속성을 변경할 수 없다 D.파티클 시스템은 Cascade 또는 Niagara 에디터를 사용하여 제작할 수 있다
  • 언리얼 엔진에서 사운드를 재생하기 위해 액터에 추가하는 컴포넌트는?
    언리얼 엔진에서는 Audio Component를 액터에 추가하여 사운드를 재생합니다. Audio Component는 Sound Wave나 Sound Cue 같은 사운드 애셋을 참조하여 3D 공간 상에서 사운드를 재생할 수 있으며, 볼륨, 피치, 감쇠(Attenuation) 등의 속성을 제어할 수 있습니다. B, C, D는 언리얼 엔진에 존재하지 않는 컴포넌트 이름입니다.
  • A.Audio Component B.Sound Player Component C.Music Component D.Speaker Component
  • 파티클 시스템의 이미터(Emitter)에서 설정할 수 있는 모듈의 역할로 옳은 것은?
    파티클 이미터의 모듈은 파티클의 생명 주기 전반에 걸쳐 다양한 속성을 제어합니다. Spawn 모듈은 파티클 생성률을 제어하고, Lifetime 모듈은 수명을, Velocity 모듈은 속도를, Color Over Life 모듈은 색상 변화를 제어하는 등 파티클의 동작, 외형, 물리적 특성을 세밀하게 조정할 수 있습니다. B, C, D는 모듈의 실제 기능과 무관한 잘못된 설명입니다.
  • A.모듈은 파티클의 생명 주기 동안 파티클의 동작, 외형, 물리적 특성을 제어한다 B.모듈은 게임의 프레임률을 조절하는 역할만 수행한다 C.모듈은 파티클의 개수를 항상 고정된 값으로 유지한다 D.모듈은 사운드 재생 기능만을 담당한다

코드 카타: (푸드 파이트 대회 | 가장 가까운 같은 글자) 

저작자표시 동일조건 (새창열림)
  • hELLO · Designed By 정상우.v4.10.6

    • 티스토리툴바