인터페이스에서 BlueprintNativeEvent 함수와 기본 UFUNCTION 함수의 차이점

BlueprintNativeEvent는 Unreal Engine에서 C++과 블루프린트 간의 상호작용을 위해 제공하는 중요한 기능입니다. 주로 C++에서 함수를 정의하고, 해당 함수를 블루프린트에서도 오버라이드하여 사용할 수 있게 할 때 사용됩니다. 이 기능은 C++에서 기본 구현을 제공하면서도, 블루프린트에서 추가적으로 함수 로직을 확장하거나 오버라이드하는 것이 가능하다는 장점이 있습니다.

1. BlueprintNativeEvent의 기본 개념

• C++ 기본 구현: C++에서 기본 구현을 제공할 수 있으며, 이 기본 구현을 블루프린트에서도 호출할 수 있습니다.
• 블루프린트 오버라이드: 블루프린트에서 이 함수를 오버라이드하여 C++에서 제공된 기본 구현을 덮어쓸 수 있습니다.
• 유연성: 블루프린트로 프로젝트를 확장할 때, C++ 로직을 유지하면서 블루프린트로도 자유롭게 상호작용할 수 있는 구조를 제공합니다.

2. BlueprintNativeEvent의 사용 방법

2.1. 함수 선언

C++에서 BlueprintNativeEvent 로 함수를 선언할 때는 UFUNCTION 매크로를 사용하여 지정합니다. 중요한 것은, 이 함수는 두 가지로 나뉩니다:

1. _Implementation 함수: C++에서 기본 로직을 작성하는 함수.
2. 원래 함수: 블루프린트에서 오버라이드할 함수.

UFUNCTION(BlueprintNativeEvent, Category = "Item")
void OnItemPickedUp();

 

void AMyCharacter::OnItemPickedUp_Implementation()
{
    UE_LOG(LogTemp, Warning, TEXT("Item picked up in C++"));
}

void AMyCharacter::SomeFunction()
{
    // OnItemPickedUp 호출 - 블루프린트에서 오버라이드했으면 그 구현이 실행됨
    OnItemPickedUp();
}

UCLASS()
class MYGAME_API AMyCharacter : public ACharacter
{
    GENERATED_BODY()
 
public:
    // BlueprintNativeEvent 선언
    UFUNCTION(BlueprintNativeEvent, Category = "Item")
    void OnItemPickedUp();
 
    // 기본 C++ 구현
    virtual void OnItemPickedUp_Implementation();
};

 

 

UFUNCTION(BlueprintNativeEvent) 로 선언된 interface 함수와 UFUNCTION() 으로 선언된 interface 함수의 차이점

1. UFUNCTION()만 사용한 경우 (기본 가상 함수)

UFUNCTION()
virtual void AddToItem(FGameplayTag ItemTag);

UFUNCTION(BlueprintNativeEvent)
void AddToItem(FGameplayTag ItemTag);

UFUNCTION(BlueprintNativeEvent) 로 선언된 interface 함수와 UFUNCTION() 으로 선언된 interface 함수의 호출방식 차이점

                                           
실행방식 :  

	UFUNCTION()	UFUNCTION( BlueprintNativeEvent)
호출 방식	PlayerInterface->AddToItem()	IPlayerInterface::Execute_AddToItem()
호출 방식	직접 호출	간접 호출
성능	더 빠를 수 있음 (추가 확인 절차 없음)	약간 느림 (간접 호출 + 추가적인 객체 확인 로직)
Blueprint 지원	지원하지 않음 (C++ 기본 구현만 호출)	Blueprint 오버라이드도 호출 가능
호출 로직	객체가 인터페이스를 구현하면 바로 함수 호출	Unreal이 생성한 Execute 함수를 통해 인터페이스 구현을 확인
실행 흐름	C++에서 구현된 함수 호출	블루프린트 또는 C++에서 오버라이드된 함수 호출 가능

 

언제 각각의 방식을 사용해야 하나?

1. PlayerInterface->AddToItem() 방식:
   • 성능이 중요한 상황에서 블루프린트 오버라이드가 필요 없는 경우.
   • C++에서만 동작하며, 블루프린트에서 추가적인 동작을 제공할 필요가 없는 함수.
   • 인터페이스의 C++ 기본 구현만 사용하고 싶을 때.
2. IPlayerInterface::Execute_AddToItem() 방식:
   • 블루프린트에서 해당 함수를 오버라이드할 수 있는 가능성이 있을 때.
   • 게임플레이에서 C++과 블루프린트 간의 상호작용을 지원해야 할 때.
   • 블루프린트에서 로직이 변경될 수 있는 경우, 또는 유연한 함수 호출이 필요한 경우.

결론

• PlayerInterface->AddToItem() 방식은 직접 호출을 통해 성능 면에서 이점이 있을 수 있지만, 블루프린트에서 오버라이드된 함수는 호출되지 않습니다.
• IPlayerInterface::Execute_AddToItem() 방식은 간접 호출을 통해 블루프린트에서 오버라이드된 구현까지도 실행할 수 있습니다. 따라서, 유연하게 사용할 수 있지만, 성능 측면에서는 약간의 오버헤드가 발생할 수 있습니다.

IPlayerInterface::Execute_AddToItem()와 같은 간접 호출 방식은 다음과 같은 이유로 더 안전하고 유연한 방식입니다:

• 블루프린트 오버라이드 지원: 블루프린트에서 구현된 함수까지 호출 가능하여 확장성을 보장.
• 다형성 지원: 객체가 인터페이스를 구현했는지 확인 후 적절한 함수 호출.
• 객체 상태 관리: 객체가 인터페이스를 구현하고 있지 않더라도 안전하게 처리.
• 호환성: C++ 및 블루프린트에서 동일하게 동작하도록 보장.

안정적인 인터페이스 처리

• 객체가 인터페이스를 구현하는지 확인: Execute 함수는 객체가 해당 인터페이스를 구현하고 있는지 먼저 확인한 후 함수를 호출합니다. 이를 통해 잘못된 함수 호출을 방지할 수 있습니다. 즉, Execute_AddToItem를 호출할 때 객체가 인터페이스를 구현하지 않았더라도 안전하게 처리되며, 강제적인 호출로 인한 크래시 가능성을 낮춥니다.

PlayerInterface->AddToItem()  같은 직접 호출방식은 더 단순한 방식이지만, 특정한 제약이 있습니다.

2.1. 블루프린트 오버라이드 무시

• 오버라이드 미지원: 직접 호출 방식은 C++ 기본 구현만 호출할 수 있으며, 블루프린트에서 오버라이드된 함수는 호출할 수 없습니다. 이는 후에 블루프린트에서 기능을 확장하거나 변경하고 싶을 때 유연성이 떨어지고, 기능이 예상대로 동작하지 않을 수 있습니다.
• 불안정한 코드 변경: 게임 개발이 진행됨에 따라 함수의 구현이 바뀌고 블루프린트에서 구현된 로직이 필요해질 때, 직접 호출 방식은 이러한 변경을 처리하지 못해 기능이 누락되거나 코드가 불안정해질 수 있습니다.

2.2. 객체 상태 확인 필요

• 직접 호출 방식은 호출하려는 객체가 인터페이스를 구현하고 있는지 직접 확인해야 합니다. 이를 위한 Cast나 dynamic_cast 같은 추가적인 작업이 필요하며, 이러한 확인을 누락하거나 잘못 처리할 경우 프로그램이 예기치 않게 크래시할 가능성이 있습니다.
• 반면에, Execute 함수는 이러한 객체 상태 확인을 자동으로 처리하므로, 호출자 측에서 추가적인 확인 로직이 필요 없습니다.