park94128 님의 블로그

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (7)

park94128 — Wed, 1 Apr 2026 23:23:46 +0900

● 버튼이 100개면 함수를 100개 만들 것인가?

1. 이전에도 언급했지만 마음에 들지 않는 코드

private:
	//클래스 선택 버튼1
	UFUNCTION()
	void OnClickSelectClassButton1();
	
	//클래스 선택 버튼2
	UFUNCTION()
	void OnClickSelectClassButton2();
	
	//클래스 선택 버튼3
	UFUNCTION()
	void OnClickSelectClassButton3();
	
	//클래스 선택
	void SelectClass(int32 ClassNum);
	
	//클래스 버튼1
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectClassButton1;
	
	//클래스 버튼2
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectClassButton2;
	
	//클래스 버튼3
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectClassButton3;

클래스 선택 화면의 위젯 코드는 마음에 들지 않는 구조로 짜여있다. 왜냐하면 버튼이 3개라고 함수를 3개 만들어서 바인딩 했기 때문이다. 이 3개의 버튼의 목적이 완전히 다르다면 모르겠는데 이들은 선택에 따라 값 1개만 달라질 뿐 나머지는 동일하다. 그런 상황에서 함수를 각각 따로 만든 것은 비효율적인 코드다. 이 구조를 따를경우, 버튼이 100개라면 함수를 100개 만들어야 한다. 설마 진짜로 그러지는 않겠지...

2. 생각하거나 시도했지만 정답이 아닌 경우

void UT3SelectClassWidget::NativeConstruct()
{
	for (int32 iNum = 0; iNum < 3; iNum++)
	{
		//에러가 발생함
		ClassButtons[iNum]->OnClicked.AddDynamic(this, &ThisClass::SelectClass);
	}
}

void UT3SelectClassWidget::SelectClass(int32 ClassNum)
{
	
}

처음에는 매개변수 1개를 받는 함수를 for문으로 돌려서 버튼에 바인딩할까 생각했지만 버튼의 OnClicked는 매개변수가 없는 함수만 받을 수 있는 델리게이트라서 그럴 수는 없다. 위 코드는 에러가 발생한다.

void UT3SelectClassWidget::NativeConstruct()
{
	for (int32 iNum = 0; iNum < 3; iNum++)
	{
		//이런게 실제로 존재할까?
		ClassButtons[iNum]->OnClicked.AddDynamic(this, () =>
		{
			SelectClass(iNum)
		});
	}
}

void UT3SelectClassWidget::SelectClass(int32 ClassNum)
{
	
}

OnClicked에 람다 함수 같은걸 만들어서 할당할 수는 없을까? 아쉽게도 언리언 엔진에서 사용하는 코드는 C++라서 C#과 같은 람다식은 존재하지 않는다. 그래서 위 코드와 같은 구조는 불가능하다.

혹시나 언리얼 엔진에서 구현한 람다 생성 함수(ex : TimerManager의 SetTimer함수를 사용할 경우) 중에서 위젯 버튼에 사용가능한 것이 존재할까 해서 정보를 찾아봤다. 그리고 나는 답을 찾았다. 과정은 다소 복잡하니 제작한 코드에 대한 개념을 순서대로 밟아본다.

3. User위젯 내부에는 Slate위젯이 포함된다.

버튼인 UButton 클래스 내부에 존재하는 SButton

언리얼 엔진에서 UI를 만들때 사용하는 버튼, 텍스트 등의 위젯은 내부에 Slate 위젯이 있다. 언리얼 엔진에서 제공되는 User 위젯의 기능은 내장된 Slate 위젯을 빌려서 구현된 경우가 많다. 당장 지금 다루는 중인 버튼도 마찬가지다.

그래서 이 Slate위젯이 왜 언급됐을까? 바로 Slate위젯용 람다 생성 함수가 존재하기 때문이다.

SlateButton->SetOnClicked(FOnClicked::CreateLambda([this, TempClassValue]()
{
	OnClickSelectClassButton(TempClassValue);
	return FReply::Handled(); 
}));

버튼을 예로 들자면, SButton에 있는 SetOnClicked 함수로 클릭시 실행할 기능을 부여할 수 있다. 이 함수의 매개변수로 람다 함수를 넣을 수 있는데 FOnClicked::CreateLambda함수를 사용하면 된다.

주의할 점으로 이 람다 함수는 FReply::Handled()가 반환 값인 함수로 만들어야 한다.

TSharedPtr<SButton> SlateButton = StaticCastSharedPtr<SButton>(MyUserButton->GetCachedWidget());

다만 이 Slate위젯은 public으로 선언된 상태가 아니라서 직접 참조할 수 없다. 대신 여기에 접근할 수 있는 함수인 GetChachedWidget()이 존재한다. 이 함수의 반환값은 C스타일 포인터라서 TSharedPtr로 사용하려면 변환 함수인 StaticCastCharedPtr()를 사용해야 한다.

4. 선언된 버튼 변수를 제거하고 그 부모인 변수를 선언한다.

//T3SelectClassWidget.h

private:
	//캐릭터 선택 버튼이 있는 패널
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UHorizontalBox> SelectClassBox;

이렇게 하는 데에는 이유가 있다. 원래는 그 버튼으로 구성된 TArray를 선언하려고 했다. 하지만 생각해보니 이러면 버튼을 생성할 때마다 일일이 그 TArray에 추가해줘야 하니 불편할 것이다. 그래서 생각한 것은 부모인 가로 박스(Horizontal Box)에서 그 자식인 위젯을 가져오게 하는 것이다. 이러면 코드에 직접 추가하지 않아도, 디테일 패널에 일일이 추가하지 않아도 자식을 가져오는 함수 하나만으로 가져올 수 있게 된다.

5. 그래서 완성된 코드

//각 클래스 버튼은 SButton에 Lambda로 바인딩한다.
int32 TempClassValue = 0;
for (TObjectPtr<UWidget> ChildWidget : SelectClassBox->GetAllChildren())
{
	TObjectPtr<UButton> ChildButton = Cast<UButton>(ChildWidget);
	if (!ChildButton)
	{
		UE_LOG(LogTemp, Warning, TEXT("%s : 버튼이 아님"), *ChildWidget.GetName());
		continue;
	}
	TSharedPtr<SButton> SlateButton = StaticCastSharedPtr<SButton>(ChildButton->GetCachedWidget());
	SlateButton->SetOnClicked(FOnClicked::CreateLambda([this, TempClassValue]()
	{
		SelectClass(TempClassValue);
		return FReply::Handled(); 
	}));
		
	++TempClassValue;
}

- 버튼의 부모인 SelectClassBox에서 GetAllChildren() 함수를 사용하면 모든 자식으로 구성된 위젯 배열이 반환된다.

- 이 위젯 배열을 for문을 통해 순회한다.

- 만약을 위해 자식 위젯마다 버튼 위젯인지 검증하는 구간이 필요하다. GetAllChildren()는 자식이 어떤 종류인지는 가르쳐 주지 않는다.

- 버튼 위젯이면 여기서 Slate위젯을 추출한다. 그리고 OnClicked에서 람다를 생성하여 여기에 매개변수가 있는 함수를 집어넣는다.

이 과정을 통해 아무리 버튼이 많이 추가되어도 동일한 함수 1개를 사용할 수 있게 됐다.

● 확인 좀 하겠습니다

1. 기획상 어디서 확인을 요구하는가

현재 내가 담당한 범위 중 확인을 요구하는 것은 타이틀 화면에만 있다.

- 게임을 새로 시작할 때(이미 저장된 게임이 있다면)

- 저장된 게임을 이어할 때

- 종료할 때.

하지만 지금 여기에는 확인을 거치는 과정이 없으며 무조건 그 기능을 실행한다. 이제 그 기능을 구현해야겠다.

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (6)

park94128 — Wed, 25 Mar 2026 21:56:06 +0900

● 너의 이름은

지금 구현한 클래스 선택 레벨에서 당장 추가할 것을 말하자면 현재 이름 입력 기능이 없다. 기획에 따르면 클래스를 선택하면 이름을 입력한 뒤에 튜토리얼을 시작해야 하지만 지금은 그런거 없이 바로 튜토리얼을 시작한다. 그래서 이름 입력 기능을 구현해야 한다.

1. 코드 구성

class DESECRATION_API UT3InputNamePanel : public UUserWidget
{
	GENERATED_BODY()
	
	friend UT3SelectClassWidget;

protected:
	virtual void NativeOnInitialized() override;
	
private:	
	//확인 버튼
	UFUNCTION()
	void OnClickConfirmButton();
	
	//취소 버튼
	UFUNCTION()
	void OnClickCancelButton();
	
	//이름 입력 칸
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UEditableTextBox> InputNameBox;
	
	//확인 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> ConfirmButton;
	
	//취소 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> CancelButton;
	
	//클래스 선택 위젯
	UPROPERTY()
	TWeakObjectPtr<UT3SelectClassWidget> SelectClassWidget;
};

이름 입력 패널인 유저 위젯 클래스다. 여기서 몇 가지 설명할 것이 있다.

- friend 키워드로 특정 클래스를 지정하면 그 클래스는 이 클래스의 protected 및 private를 public인 것처럼 접근할 수 있다. (객체 지향 프로그래밍 관점에서는 은닉성을 망치는 기능이니 적당히 사용하자) 여기서는 클래스 선택 위젯이 이 패널 클래스 내 모든 것을 접근할 수 있다.

- 새로 알게 된 언리얼 엔진 함수 : NativeOnInitialized는 객체 자체가 파괴되지 않는 이상 단 1번만 실행되는 함수라고 한다. 나는 NativeConstruct 함수가 1번만 실행되는 함수인 줄 알았는데 그게 아니었다. 이 프로젝트에서는 보여주고 숨길 때 SetVisibility를 사용하여 보여주고 숨기기 때문에 다시 실행될 일은 없지만, 만약 패널을 닫기 위해 뷰포트에서 뺀 다음 다시 뷰포트에 추가하면 NativeConstruct 함수가 실행된다고 한다. NativeConstruct 함수는 뷰 포트에 추가되는 시점에서 실행하고 NativeOnInitialized함수는 CreateWidget 시점에서 실행되기 때문이다.

- 이 패널은 이름 입력 칸인 EditableTextBox와 확인, 취소 버튼이 있다.

- 클래스 선택 위젯 내에 배치되는 위젯으로 만들 생각이다. 그래서 클래스 선택 위젯을 캐싱할 변수를 선언한다. (클래스 선택 위젯 클래스에 friend 키워드를 사용한 이유) 다만 TObjectPtr로 선언하면 순환 참조 문제가 발생할 염려가 있어 약한 참조인 TWeakObjectPtr로 선언한다.

- 확인, 취소 버튼에 대응되는 함수를 선언한 상태다.

void UT3InputNamePanel::NativeOnInitialized()
{
	Super::NativeOnInitialized();
	
	//버튼 바인딩
	ConfirmButton->OnClicked.AddDynamic(this, &ThisClass::OnClickConfirmButton);
	CancelButton->OnClicked.AddDynamic(this, &ThisClass::OnClickCancelButton);
	
	//이름 입력 칸 초기화
	InputNameBox->SetText(FText::GetEmpty());
}

void UT3InputNamePanel::OnClickConfirmButton()
{
	//이름 미입력시 무시
	const FString InputName = InputNameBox->GetText().ToString();
	if (InputName.IsEmpty())
	{
		return;
	}
	
	//튜토리얼 시작
	if (const TObjectPtr<UT3SelectClassWidget> WidgetInstance = SelectClassWidget.Get())
	{
		WidgetInstance->TutorialStart(InputName);
	}
}

void UT3InputNamePanel::OnClickCancelButton()
{
	SetVisibility(ESlateVisibility::Collapsed);
}

NativeOnInitialized함수에서는 함수 바인딩과 같은 기본적인 초기화를 진행한다.

확인 버튼을 누르면 클래스 선택 위젯의 튜토리얼 시작 함수를 실행한다. 이때 이름 입력칸에 입력한 이름을 가져와서 매개변수로 넘겨준다. 만약 가져온 이름이 빈 값이면 실행하지 않는다.

취소 버튼의 함수에서는 이 패널을 닫도록 한다.

2. 이게 무슨 버그야

위 함수 중 확인 버튼의 함수를 처음 만들었을 때는 아래와 같은 모습이었다.

void UT3InputNamePanel::OnClickConfirmButton()
{
	//이름 미입력시 무시
	const FText InputName = InputNameBox->GetText();
	if (InputName.IsEmpty())
	{
		return;
	}
    
    UE_LOG(LogTemp, Warning, TEXT("이름 입력함"));
}

이름 입력칸을 FText로 가져온 다음 변환하려는 생각이었고 일단 잘 가져오는지 부터 확인하려고 했다. 그런데 여기서 문제가 발생했다. 저 FText 변수를 디버그로 확인해보면 빈 값으로 나온다. 그래서 매우 당황했다.

UPROPERTY(BlueprintReadWrite, meta = (AllowPrivateAccess = true))
FText InputNameBoxText;

심지어는 FText를 블루프린트에 노출시키고 블루프린트에서 입력을 하는 경우에도 코드에서는 빈 값으로 나온다.

UPROPERTY(BlueprintReadWrite, meta = (AllowPrivateAccess = true))
FString InputNameBoxString;

그런데 여기서 이상한 현상을 발견했다. FText 대신 FString을 사용하면 정상적으로 값을 받아온다.

FString InputName = InputNameBox->GetText().ToString();

이 현상을 발견한 직후 혹시나 하는 마음에 C++ 코드에서도 FText를 받자마자 바로 FString으로 변환하니 값이 정상적으로 확인 가능했다. 분명 FText일때는 빈 값이던 것이 FString으로 변환하니 문자열이 되살아났다. 이게 무슨 어처구니 없는 상황인가...

이 상황을 해결하고자 찾아본 자료에 따르면 언리얼 엔진의 버그로 추측된다. 나만 겪은 현상이 아니었다. 황당한 문제였지만 어쨌든 FString으로 사용하면 문제가 없을 것이고 그 결과로 위에 적어둔 확인 버튼의 함수 형태다.

3. 위젯 블루프린트 제작 및 클래스 선택 위젯에 배치하기

이름 입력 패널은 화면에 가득 찬 모습이 아니라서 작은 크기로 제작된다. 커스텀(Custom) 크기를 사용하는데 너비를 600, 높이를 400으로 정했다.

기획서에 있는 내용대로 위젯을 배치한다. 그리고 코드의 변수와 연동이 잘되는지도 확인한다.

그리고 배치해봤는데 여기서 문제점이 하나 예상된다. 이름 입력 패널이 띄워지면 패널 뒤에 있는 버튼은 눌려지면 안되는데 그걸 막아낼 것이 없다.

여기서 내가 선택한 것은 패널을 바로 배치하는 것이 아니라 보더를 먼저 배치한 다음 보더 안에 패널을 배치하는 방법이다. 이때 패널 크기를 조절해야 하니 캔버스 패널까지 포함해서 2중으로 감싼 형태가 됐다.

보더를 화면 전체로 늘려서 뒤쪽 버튼을 누르지 못하게 만든다. 이때 보더의 색상은 반투명한 검은색으로 만든다. 그리고 보더의 자식인 캔버스 패널의 크기는 보더 전체에 채우도록 만든다. 이제 패널은 캔버스 패널의 자식으로 배치하면 된다. 이르면 패널이 띄워진 동안 클래스 선택 위젯의 버튼은 건드릴 수 없다.

다만 이렇게 만든 다음 이름 입력 패널의 취소 버튼을 누르면 이 보더는 사라지지 않고 패널만 사라진다. 그래서 코드를 수정할 겸 클래스 선택 위젯 C++ 클래스에서도 이 패널을 추가한다..

//T3SelectClassWidget.h

public:
	//이름 입력 패널 활성화 여부
	void SetActiveInputNamePanel(bool bActive);

private:
	//이름 입력 패널이 있는 부모 위젯
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UWidget> InputNamePanelParent;
	
	//이름 입력 패널
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UT3InputNamePanel> InputNamePanel;

보더 와 이름 입력 패널을 클래스 선택 위젯에 추가한다. 보더는 비지빌리티만 건드리니 변수 타입을 UWidget으로 해도 상관없다. 그리고 이름 입력 패널을 보여주고 숨기는 것을 이 보더의 비지빌리티로 구현할 것인데 그 내용을 담을 함수도 선언한다.

void UT3SelectClassWidget::NativeConstruct()
{
	Super::NativeConstruct();
	
	...
    
	//이름 입력 패널 초기화
	SetActiveInputNamePanel(false);
	InputNamePanel->SelectClassWidget = this;
    
	//그외 나머지 초기화
	SelectedPlayerClass = -1;
}

void UT3SelectClassWidget::SetActiveInputNamePanel(bool bActive)
{
	InputNamePanelParent->SetVisibility(bActive ? ESlateVisibility::Visible : ESlateVisibility::Collapsed);
}

이름 입력 패널을 초기화 한다. 해당 패널 클래스에서 이 위젯 클래스를 friend로 선언했으니 마음대로 변수에 접근할 수 있다. 이름 입력 패널은 시작시 숨긴다.

//T3InputNamePanel.cpp


void UT3InputNamePanel::OnClickCancelButton()
{
	if (const TObjectPtr<UT3SelectClassWidget> WidgetInstance = SelectClassWidget.Get())
	{
		WidgetInstance->SetActiveInputNamePanel(false);
	}
}

이름 입력 패널의 취소 버튼의 내용은 자기 자신을 직접 숨기는 것이 아니라 클래스 선택 위젯을 통해 숨기도록 한다.

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (5)

park94128 — Tue, 24 Mar 2026 22:25:30 +0900

● 블루프린트 생성

C++ 클래스를 만들었으니 이를 기반으로 하는 블루프린트를 만들 차례다.

1. 게임 모드

타이틀 화면의 게임 모드처럼 얘도 블루프린트에서 딱히 추가로 해줄 것은 없다. 역시 동일하게 월드 세팅에서 이 블루프린트를 현재 레벨의 게임 모드로 지정해준다. 이후 플레이어 컨트롤러 블루프린트를 만들면 여기서 지정해준다.

2. UI

플레이어 컨트롤러 블루프린트를 만들기 전에 이 위젯 블루프린트를 먼저 만든다.

가로 박스(HorizontalBox)에 3개의 버튼을 넣음으로 클래스 선택 버튼을 만들었다. 그 외 나머지 선택 버튼과 돌아가기 버튼은 기획서대로 밑에 배치한다.

각 버튼 위젯은 C++코드에서 선언한 변수명과 동일한 이름으로 명명하여 잘 연결됐는지 확인한다.

3. 플레이어 컨트롤러

플레이어 컨트롤러에서 해줄 것은 딱하나, 위젯 블루프린트 작업을 했으니 여기서 지정해준다. 그리고 월드 세팅에서 게임 모드의 플레이어 컨트롤러를 이것으로 지정해준다.

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (4)

park94128 — Mon, 23 Mar 2026 23:47:36 +0900

● 클래스 선택 레벨

타이틀 화면 레벨은 이정도로 하고 클래스 선택 레벨에서 기능을 구현할 차례다. 레벨 자체는 타이틀 화면의 기능 구현을 위해 이미 생성해뒀지만 구현한 것은 아무것도 없으니 그냥 빈 깡통 수준이다.

플레이어 클래스를 선택하는 기능이라서 들어가는 기능은 다르겠지만 여기도도 UI 외에는 출력할 것이 없기 때문에 대략적인 C++ 클래스 구조는 타이틀 레벨과 다르지 않다. 게임 인스턴스는 이미 만든 상태라서 이를 제외한 나머지를 만들면 된다.

● 게임 모드

UCLASS()
class DESECRATION_API AT3SelectClassGameMode : public AGameModeBase
{
	GENERATED_BODY()
	
protected:
	virtual void BeginPlay() override;
	
public:
	//튜토리얼 시작
	void TutorialStart();
	
	//타이틀 레벨로 돌아가기
	void ReturnToTitleLevel();
	
private:
	//게임 인스턴스
	UPROPERTY()
	TObjectPtr<UT3GameInstance> T3GameInstance;
};

지금 게임 모드에서는 튜토리얼 시작 기능과 타이틀로 돌아가는 기능만 있으면 된다.

void AT3SelectClassGameMode::BeginPlay()
{
	Super::BeginPlay();
	
	//게임 인스턴스
	T3GameInstance = Cast<UT3GameInstance>(GetGameInstance());
	if (!T3GameInstance)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : T3GameInstance is NULL"), *GetNameSafe(this));
		return;
	}
}

void AT3SelectClassGameMode::TutorialStart()
{
	UGameplayStatics::OpenLevel(CurrentWorld, TEXT("T3TutorialLevel"));
}

void AT3SelectClassGameMode::ReturnToTitleLevel()
{
	UGameplayStatics::OpenLevel(CurrentWorld, TEXT("T3TitleLevel"));
}

타이틀 화면의 게임모드 처럼 시작시 게임 인스턴스를 캐싱한다. 튜토리얼 시작은 튜토리얼 레벨을 열고, 타이틀로 돌아가기는 타이틀 레벨을 연다. 튜토리얼 레벨은 다른 분이 만들고 있으니 임시로 예상하여 이름을 넣었다.

● 플레이어 컨트롤러

UCLASS()
class DESECRATION_API AT3SelectClassPlayerController : public APlayerController
{
	GENERATED_BODY()
	
protected:
	virtual void BeginPlay() override;
	
public:
	//튜토리얼 시작
	void TutorialStart(const FString& PlayerName, const int32 ClassNum);
	
	//타이틀 화면으로
	void ReturnToTitleLevel();
	
private:	
	//게임 모드
	UPROPERTY()
	TObjectPtr<AT3SelectClassGameMode> SelectClassGameMode;
};

타이틀 화면의 플레이어 컨트롤러처럼 여기서도 위젯과 게임모드를 중계하는 역할이다. 게임 모드에서 선언한 함수에 대응되도록 함수를 만든다. 다만 기획상 선택한 클래스와 이름이 필요하기에 튜토리얼 시작 함수에 매개변수를 넣었다.

void AT3SelectClassPlayerController::BeginPlay()
{
	Super::BeginPlay();
	
	//마우스 사용
	bShowMouseCursor = true;
	const FInputModeUIOnly InputModeUIOnly;
	SetInputMode(InputModeUIOnly);
	
	//게임 모드
	SelectClassGameMode = Cast<AT3SelectClassGameMode>(GetWorld()->GetAuthGameMode());
	if (!SelectClassGameMode)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : TitleGameMode is NULL"), *GetNameSafe(this));
		return;
	}
}

UI만 존재하는 레벨이니 여기서도 마우스 커서를 보이게 하고 입력 모드를 UI 전용으로 한다.

사실 이미 타이틀 화면에서 입력 모드를 UI 전용으로 했으니 여기서는 할 필요가 없는데, 테스트를 위해 이 레벨에서 바로 시작할 때 마우스가 간혹 사라지는 현상이 있어서 이렇게 했다.

void AT3SelectClassPlayerController::TutorialStart(const FString& PlayerName, const int32 ClassNum)
{	
	UE_LOG(LogTemp, Warning, TEXT("Name : %s, Class : %d"), *PlayerName, ClassNum);
	SelectClassGameMode->TutorialStart();
}

void AT3SelectClassPlayerController::ReturnToTitleLevel()
{
	SelectClassGameMode->ReturnToTitleLevel();
}

아직 이름이나 선택 클래스를 처리할 방법이 없으니 로그로 띄우는 용도로만 사용한다. 그 외에는 각 함수는 게임 모드에 대응되는 함수를 호출하도록 만든다.

● UI

UCLASS()
class DESECRATION_API UT3SelectClassWidget : public UUserWidget
{
	GENERATED_BODY()
	
protected:
	virtual void NativeConstruct() override;
	
private:
	//클래스 선택 버튼1
	UFUNCTION()
	void OnClickSelectClassButton1();
	
	//클래스 선택 버튼2
	UFUNCTION()
	void OnClickSelectClassButton2();
	
	//클래스 선택 버튼3
	UFUNCTION()
	void OnClickSelectClassButton3();
	
	//클래스 선택
	void SelectClass(int32 ClassNum);
	
	//선택 버튼
	UFUNCTION()
	void OnClickSelectButton();
	
	//타이틀로 돌아가기
	UFUNCTION()
	void ReturnToTitle();
	
	//클래스 버튼1
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectClassButton1;
	
	//클래스 버튼2
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectClassButton2;
	
	//클래스 버튼3
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectClassButton3;
    
	//선택 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SelectButton;
    
	//돌아가기 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> ReturnButton;
	
	//플레이어 컨트롤러
	UPROPERTY()
	TObjectPtr<AT3SelectClassPlayerController> SelectClassPlayerController;
	
	//마지막으로 선택한 클래스
	int32 SelectedPlayerClass;
};

미리 캐싱할 플레이어 컨트롤러와 각 버튼마다 연결할 변수 및 대응되는 함수를 선언하느라 헤더가 다소 길어졌다. 내가 짠 코드지만 영 마음에 들지 않는다. 이걸 최적화할 방법을 생각해볼 필요가 있다. 하지만 당장 떠오르는 해결책이 없으니 일단 넘어가야겠다.

void UT3SelectClassWidget::NativeConstruct()
{
	Super::NativeConstruct();
	
	//플레이어 컨트롤러
	SelectClassPlayerController = Cast<AT3SelectClassPlayerController>(GetOwningPlayer());
	if (!SelectClassPlayerController)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : SelectClassPlayerController가 NULL"), *GetNameSafe(this));
		return;
	}
	
	//선택 버튼은 비활성화 상태로 시작
	SelectButton->SetIsEnabled(false);
	
	//버튼 바인딩
	SelectClassButton1->OnClicked.AddDynamic(this, &ThisClass::OnClickSelectClassButton1);
	SelectClassButton2->OnClicked.AddDynamic(this, &ThisClass::OnClickSelectClassButton2);
	SelectClassButton3->OnClicked.AddDynamic(this, &ThisClass::OnClickSelectClassButton3);
	SelectButton->OnClicked.AddDynamic(this, &ThisClass::OnClickSelectButton);
	ReturnButton->OnClicked.AddDynamic(this, &ThisClass::ReturnToTitle);
    
	//그외 나머지 초기화
	SelectedPlayerClass = -1;
}

NativeConstruct에서는 플레이어 컨트롤러 캐싱 및 버튼 바인딩 작업을 한다.

void UT3TitleLevelWidget::OnClickSelectClassButton1()
{
	SelectClass(1);
}

void UT3TitleLevelWidget::OnClickSelectClassButton2()
{
	SelectClass(2);
}

void UT3TitleLevelWidget::OnClickSelectClassButton3()
{
	SelectClass(3);
}

void UT3TitleLevelWidget::SelectClass(int32 ClassNum)
{
	//이전에 누른 버튼과 동일하면 선택 버튼을 누른 것으로 간주
	if (ClassNum == SelectedPlayerClass)
	{
		OnClickSelectButton();
		return;
	}
	
	//선택 버튼 활성화
	SelectButton->SetIsEnabled(true);
	
	//누른 버튼 기억
	SelectedPlayerClass = ClassNum;
}

각 클래스 버튼의 함수는 하나의 클래스 선택 함수로 이어진다. 이 함수에서는 이전에 누른 버튼의 번호를 기억한 다음 다시 버튼을 누를 때 그게 동일한 버튼이면 선택 버튼의 함수를 호출하도록 했다.

그리고 클래스 버튼 중 아무거나 눌렀다면 선택 버튼을 활성화한다.

void UT3SelectClassWidget::OnClickSelectButton()
{
	SelectClassPlayerController->TutorialStart(TEXT(""), SelectedPlayerClass);
}
	

void UT3SelectClassWidget::ReturnToTitle()
{
	SelectClassPlayerController->ReturnToTitleLevel()
}

선택 버튼과 타이틀로 돌아가기 버튼의 함수는 플레리어 컨트롤러에서 대응되는 함수를 호출한다. 이름 입력은 아직 구현하지 않았으니 튜토리얼 시작 함수의 첫 번째 매개변수는 임시로 빈 문자열을 넘긴다.

//T3SelectClassPlayerController.h

private:
	//클래스 선택 화면의 위젯
	UPROPERTY(EditDefaultsOnly, Category = "Widget", meta = (AllowPrivateAccess = true))
	TSubclassOf<UT3SelectClassWidget> SelectClassWidgetClass;
	
	UPROPERTY()
	TObjectPtr<UT3SelectClassWidget> SelectClassWidgetInstance;

//T3SelectClassPlayerController.cpp

void AT3SelectClassPlayerController::BeginPlay()
{
	Super::BeginPlay();
	
    
	...
    
	
	//위젯 생성
	SelectClassWidgetInstance = CreateWidget<UT3SelectClassWidget>(this, SelectClassWidgetClass);
	if (!SelectClassWidgetInstance)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : Failed to create TitleLevelWidget"), *GetNameSafe(this));
		return;
	}
	SelectClassWidgetInstance->AddToViewport();
}

위젯 클래스를 만들었으니 플레이어 컨트롤러에서는 해당 위젯을 화면에 출력하도록 한다.

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (3)

park94128 — Fri, 20 Mar 2026 23:21:41 +0900

● 지금 타이틀 레벨에서 추가로 구현할 수 있는 것

1. 새 게임을 누르면 다음 레벨로 이동하기

코드로는 미리 UGameplayStatics의 OpenLevel함수를 사용했지만 정작 그 대상인 클래스 선택 레벨은 없는 상태다. 그래서 그 상태에서는 눌러도 아무 일도 생기지 않는다. 그래서 클래스 선택 레벨을 만들었다.

이 상태에서 작동해보니 아무것도 없는 빈 레벨인 클래스 선택 레벨이 잘 열리는 것을 확인했다.

2. 설정 패널을 누르면 타이틀 버튼을 잠시 숨기기

지금은 만들었던 블루프린트 편집화면대로, 설정 화면을 열면 타이틀 화면 위에 그대로 설정 패널이 출력된다. 패널이 열린 상태지만 뒤에 덮힌 버튼들은 여전히 누를 수 있는 상태다. 어제 잠깐 언급된 내용 중 패널이 열린 동안 버튼이 잠시 사라진다고 했지만 정작 그 기능은 없는 상태다.

private:
    //타이틀 버튼이 있는 세로 박스
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UWidget> TitleButtonsBox;

모든 버튼마다 일일이 숨길 수도 있지만 그것보다는 그 버튼을 자식으로 둔 세로 박스를 숨기는 쪽이 더 편하다. 그래서 세로 박스를 코드에서 다룰 수 있도록 코드의 헤더에서 변수를 선언한다. 그리고 위젯과 잘 연동하는지도 확인한다. 숨기는 것 외에는 다룰 것이 없으니 변수 타입은 세로 박스(UVerticalBox)가 아닌 그냥 위젯(UWidget)으로 선언했다.

public:
	//설정 패널을 닫을 때 버튼 복구
	void RestoreTitleButtons();

설정 패널을 출력하는 함수는 이미 설정 버튼으로서 만들었기 때문에 버튼을 복구하는 함수만 추가로 선언한다.

void UT3TitleLevelWidget::OnClickSettingsButton()
{
	SettingsPanel->OpenSettingsPanel();
	TitleButtonsBox->SetVisibility(ESlateVisibility::Collapsed);
}

void UT3TitleLevelWidget::RestoreTitleButtons()
{
	TitleButtonsBox->SetVisibility(ESlateVisibility::Visible);
}

설정 패널을 여는 함수에서는 설정 패널에 있는 패널 출력 함수를 실행하면서 버튼이 있는 세로 박스를 숨긴다. 그리고 버튼을 복구하는 함수에서는 세로 박스를 다시 보여준다.

2-1. 설정 패널은 게임 내에서도 열 수 있다.

원래라면 타이틀 화면 위젯의 버튼 복구 함수를 설정 패널을 닫는 확인 버튼 함수에서 직접 호출하려고 했다. 하지만 여기서 하나 걸리는 점을 발견했다. 설정 패널은 게임 내에서도 열 수 있어야 한다는 기획이 있기 때문이다. 그러면 이 블루프린트 위젯 그대로 가져다가 사용할텐데, 게임 내에서는 타이틀 화면 위젯이 존재하지 않는다. 따라서 게임 내에서 그대로 쓸거면 타이틀 화면 위젯에 직접 접근하는 코드를 사용하면 안된다.

이러한 문제에 대한 해법은 다음과 같다.

DECLARE_DELEGATE(FOnClosePanel);

UCLASS()
class DESECRATION_API UT3SettingsPanel : public UUserWidget
{
	GENERATED_BODY()
    
    
	...
   
public:
	//설정 패널 닫을 때 실행할 내용
	FOnClosePanel OnClosePanel;
    
    ...
}

델리게이트를 이용하면 된다. 그러면 타이틀 위젯이든, 게임내 다른 위젯이든 이 설정 패널을 가지고 있다면 설정 패널의 델리게이트에 설정 패널을 닫을 때 실행할 내용을 등록하면 된다. 타이틀 위젯에서는 버튼을 복구하는 함수를 등록하면 된다.

void UT3SettingsPanel::OnClickConfirmButton()
{
	//패널 닫기
	SetVisibility(ESlateVisibility::Collapsed);
    
	//패널을 닫을 때 해야할 일
	OnClosePanel.ExecuteIfBound();
}

설정 패널을 닫을 때 이 델리게이트를 실행한다.

void UT3TitleLevelWidget::NativeConstruct()
{

	...
    
	
	//설정 패널을 닫으면 타이틀 버튼을 복구
	SettingsPanel->OnClosePanel.BindUObject(this, &ThisClass::RestoreTitleButtons);
}

앞서 말한대로 타이틀 화면 위젯에서는 설정 패널의 이 델리게이트에 버튼을 복구하는 함수를 등록한다.

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (2)

park94128 — Thu, 19 Mar 2026 23:58:39 +0900

● 레벨 생성

클래스를 만들었다면 그 클래스를 적용할 곳이 필요하다. 바로 레벨(맵)이다. 이 레벨은 타이틀 화면을 보여주는 곳이라서 이 게임의 얼굴을 담당한다고 볼 수 있다. 그래서 여기에서의 기능은 게임 진행하는것 만틈이나 중요하다.

타이틀 화면을 제일 먼저 보여줄거면 프로젝트 세팅에서 게임 기본 맵으로 지정하는 것을 잊지 말자

● 블루프린트 생성

옛날이면 모든 기능을 코드로 구현해야 했지만 요즘은 블루프린트로 충분히 구현할 수 있다. 하지만 모든 것을 블루프린트로 만드는 것은 코딩이라고 할 수 없다. 나같은 경우, 핵심 기능은 코드로 구현하고 변수 값 할당, 간단한 키 입력 등은 블루프린트에서 해결하는 하이브리드 방식을 지향한다. 그리고 블루프린트로 구현하는 것을 선호하는 팀원과의 협업을 하려면 블루프린트를 통해서 연결하야 하니 블루프린트 생성은 반드시 해야한다.

1. 게임 인스턴스

게임 인스턴스 클래스를 기반으로 하는 블루프린트다. 프로젝트 세팅에서 게임 인스턴스 지정시 이 블루프린트를 지정한다. 현 시점에서는 블루프린트에서 따로 구현할 내용은 없다.

2. 게임 모드

게임 모드 클래스를 기반으로 하는 블루프린트다. 이 블루프린트도 추가로 구현할 내용은 없지만 월드 세팅에서 오버라이드할 게임 모드를 이 블루프린트로 지정해야 한다. 위 사진에는 아래의 플레이어 컨트롤러 블루프린트가 지정된 상태다.

3. 위젯 블루프린트

A) 설정 패널

설정 패널은 타이틀 화면 안에 들어갈 것이니 크기를 작게 잡았다. 전체 화면을 1920x1080으로 잡았으니 임시로 1280x720으로 만들었다. 정확한 크기는 차후 아트 담당자 분이 그리는 대로 결정하면 된다.

코드에서는 닫기 버튼, 확인 버튼에 대해서만 선언했지만 기획상 사용할 기능은 많기 때문에 위젯을 미리 구성해놓는다. 지금 이걸 구현하기엔 시간이 부족하니 MVP를 완성한 다음 구현할 생각이다.

닫기 버튼과 확인 버튼은 코드의 변수와 동일한 이름으로 명명하여 코드와 잘 연동됐는지 확인한다.

B ) 타이틀 화면

게임 제목이 들어갈 자리에 이미지를 배치했다. 일부러 눈에 잘 띄라고 마젠타 색상으로 칠했다. 그래야 나중에 안까먹고 텍스쳐를 넣을테니까

타이틀 화면에 사용할 버튼 4개를 배치했다. 각 버튼마다 텍스트를 넣었다.

그리고 설정 패널을 집어넣었는데... 패널에 배경이 없어서 타이틀의 위젯과 구분이 안된다. 설정 패널을 여는 동안 타이틀의 버튼은 잠시 사라지지만 그래도 패널에 배경이 없으니 패널이라는 느낌이 없다. 그래서 회색 배경이라도 넣어줬다. 그러니 패널이라는 느낌이 든다.

타이틀 화면의 버튼과 설정 패널 모두 이름을 코드의 변수와 동일한 이름으로 명명한다. 그리고 코드와 연동됐는지도 확인한다.

4. 플레이어 컨트롤러

플레이어 컨트롤러 클래스 기반인 블루프린트다. 여기서 내가 생성한 타이틀 화면 위젯 블루프린트를 위젯 클래스로 지정한다.

소울라이크 팀 프로젝트 Desecration : 시작부터 MVP까지 (1)

park94128 — Wed, 18 Mar 2026 23:54:47 +0900

● MVP란 무엇인가

스포츠에서 말하는 Most Valuable Player도 아니다. 백화점 같은 곳에서 중요 고객을 칭하는 VIP의 일종 같은것도 아니다. 당연히 메이플스토리의 MVP 시스템도 아니다.

여기서 말하는 MVP는 Minimum Viable Product의 약자로, '최소한의 기능만을 갖춘 상품'이라는 의미다. 어떻게 생각해보면 프로토타입과 비슷하다고 볼 수 있다. 게임이라고 불릴 수 있도록 핵심적인 기능만 구현해둔 상태를 말할 수 있다.

이 MVP라는 것은 완성을 위한 초석이라고 할 수 있는데, 만드려고 하는 게임을 MVP를 거치지 않고 한꺼번에 모든 것을 구현하려고 하면 막대한 분량, 막연한 방향에 의해 진행이 막혀버리고 말 것이다. 하지만 MVP를 먼저 완성하면 이후 추가적인 기능은 MVP에서 붙이거나 수정하는 식으로 구현하면 되기 때문에 만들고자 하는 방향이 명확해지고 많은 분량을 정리할 수 있어서 제작 분량을 수시로 가늠할 수 있다.

이러한 이유로 나와 팀원은 당장에 만들 것, 지금은 만들지 않아도 되는 것을 구분하여 각자 파트에서 필수 기능만을 만들기로 했다.

● 내가 담당할 범위

팀원끼리 설계를 했을때 내가 하기로 한 것은 게임시스템이다. 본 게임을 시작하기전 일어나는 일(새 게임 시작, 이어하기, 종료 등)과 화면에 직접 보이지 않는 기능(진행 상황 저장, 게임 설정 등)을 담당하기로 했다.

● 타이틀 화면을 위한 클래스

내가 생각한 구조를 그려보자면 위와 같다. 레벨내 클래스 구조는 그냥 기본적인 언리얼 엔진의 레벨 구성에 폰(캐릭터)만 빠졌다. UI만 필요할 것이니 폰은 쓸 일이 없고 레벨에 따로 배치될 액터도 없다.

게임 인스턴스는 타이틀 레벨 뿐만이 아니라 전역으로 사용할 것이다. 다만 게임 인스턴스의 Init함수를 통한 초기화 외에도 타이틀 레벨에서 진행할 초기화가 추가된다.

타이틀 레벨에 필요한 기능들은 게임 모드에서 주로 구현할 것이며 일부는 게임 인스턴스를 이용할 생각이다. 플레이어 컨트롤러는 UI 생성 목적으로 사용할 생각이며 UI를 통해 타이틀 화면의 기능을 유저에게 제공하도록 만들 것이다.

일단 이렇게 생각하며 만들고 추가로 필요한 클래스가 생긴다면 그때가서 만들어 본다.

● SaveGame

추가로 필요한 클래스가 바로 생겼다. 나는 게임 데이터를 게임 인스턴스에서 보관하기로 했다. 이 게임 데이터는 게임 구성을 담고 있으며 이 데이터를 저장하도록 만들 것이다. 그리고 게임 불러오기를 하면 이 데이터를 생성하도록 한다.

그러기 위해 필요한 것이 SaveGame이라는 클래스다. 언리얼 엔진은 생각보다 싱글 게임을 위한 기능이 많이 있는데 게임 저장 및 불러오기에 필요한 기능을 이 SaveGame 클래스를 통해 제공하고 있다.

뭔가 설명은 긴데 지금 미리 말하자면 저 설명대로 하기엔 다소 귀찮으니 간단하게 처리할 수 있는 함수를 사용할 것이다.

UCLASS()
class DESECRATION_API UT3SaveGame : public USaveGame
{
	GENERATED_BODY()
}

지금은 게임 데이터의 구성을 생각하지 않았으니 일단 클래스를 만들기만 하고 다음에 내용을 채운다.

● 게임 인스턴스

UCLASS()
class DESECRATION_API UT3GameInstance : public UGameInstance
{
	GENERATED_BODY()
	
public:
	virtual void Init() override;

	/**
	 * 게임 저장하기
	 * @return true : 저장 성공
	 */
	bool SaveGame();
	
	/**
	 * 저장된 게임 불러오기
	 * @return true : 불러오기 성공
	 */
	bool LoadGame();
	
	//저장된 게임
	FORCEINLINE TObjectPtr<UT3SaveGame> GetSavedGameData() { return SavedGameData; }
	
private:
	//현재 설정
	UPROPERTY()
	TObjectPtr<UT3SaveUserSettings> CurrentSettings;
	
	//저장, 불러오기에 사용할 슬롯 이름
	const FString SAVE_GAME_NAME = TEXT("SaveSlot1");
}

말한대로, 게임 데이터를 게임 인스턴스에 보관한다. 그리고 게임 인스턴스에서 게임 데이터를 가지고 있으니 게임 불러오기 및 저장도 게임 인스턴스에서 구현한다.

void UT3GameInstance::Init()
{
	Super::Init();
	
	//게임 데이터
	LoadGame();
}

게임 인스턴스의 시작시 자동으로 실행하는 Init 함수에서 곧바로 저장되 게임 데이터를 가져오는 함수를 실행한다 타이틀 화면에서 불러온 데이터가 있으면 이어하기를 할 수 있고 아니면 할 수 없게 만들도록 구현할 생각이다.

bool UT3GameInstance::SaveGame()
{
	return UGameplayStatics::SaveGameToSlot(SavedGameData, SAVE_GAME_NAME, 0);
}

bool UT3GameInstance::LoadGame()
{
	TObjectPtr<UT3SaveGame> SavedData = Cast<UT3SaveGame>(UGameplayStatics::LoadGameFromSlot(SAVE_GAME_NAME, 0));
	if (!SavedData)
	{
		return false;
	}
	
	SavedGameData = SavedData;
	SavedGameData->bSetLocation = true;
	return true;
}

데이터를 저장하는 함수와 불러오는 함수의 내용이다. 저장과 불러오기 기능은 UGameplayStatics에 있는 함수로 간단하게 만들 수 있다.

- SaveGameToSlot함수를 통해 데이터를 저장할 수 있다. 매게변수는 SaveGame클래스(게임 데이터), FString(이름), int(슬롯 번호)다. 지정한 이름과 슬롯에 게임 데이터를 저장하는 기능이다.

- LoadGameFromSlot함수는 반대로 저장된 데이터를 불러온다. 지정한 이름과 슬롯 번호에 해당되는 데이터를 가져오는데 함수의 결과는 원형인 USaveGame이니 캐스팅할 필요가 있다.

게임을 저장했다면 [프로젝트 폴더]/Saved/SaveGames에 저장된다. 위 두 함수는 이 경로에 있는 파일과 관련 있다.

● 게임 모드

UCLASS()
class DESECRATION_API AT3TitleGameMode : public AGameModeBase
{
	GENERATED_BODY()
	
protected:
	virtual void BeginPlay() override;
	
public:
	//클래스 선택 화면으로
	void MoveToSelectClassLevel();
	
	//마지막 저장 장소에서 계속하기 (저장된 게임 데이터 적용)
	void MoveToLastSavedLevel();
	
	//게임 종료
	void QuitGame();
	
private:
	//게임 인스턴스
	UPROPERTY()
	TObjectPtr<UT3GameInstance> T3GameInstance;
};

타이틀 화면에서 구현할 기능은 게임 모드에서 구현한다.

void AT3TitleGameMode::BeginPlay()
{
	Super::BeginPlay();
	
	//게임 인스턴스
	T3GameInstance = Cast<UT3GameInstance>(GetGameInstance());
	if (!T3GameInstance)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : T3GameInstance is NULL"), *GetNameSafe(this));
		return;
	}
}

게임 모드 시작시 게임 인스턴스를 미리 캐싱한다. 저장된 게임과 관련된 기능이 있기 때문에 게임 인스턴스를 자주 이용할 것이기 때문이다.

void AT3TitleGameMode::MoveToSelectClassLevel()
{
	UGameplayStatics::OpenLevel(GetWorld(), TEXT("T3SelectClassLevel");
}

void AT3TitleGameMode::MoveToLastSavedLevel()
{
	//TODO : 게임 불러오기
}

void AT3TitleGameMode::QuitGame()
{
	UKismetSystemLibrary::QuitGame(GetWorld(), GetWorld()->GetFirstPlayerController(), EQuitPreference::Quit, false);
}

다만 현 시점에서는 아직 게임 불러오기를 구현하지 않는다. 아직 SaveGame클래스의 내용을 정해놓지 않았기 때문에 보류한다. 그래서 새 게임 시작시 클래스 선택 화면으로 넘어가는 것과 게임을 종료하는 기능만 구현한다.

● 플레이어 컨트롤러

UCLASS()
class DESECRATION_API AT3TitlePlayerController : public APlayerController
{
	GENERATED_BODY()
	
protected:
	virtual void BeginPlay() override;
	
public:
	//클래스 선택 화면으로
	void MoveToSelectClassLevel();
	
	//마지막 저장 장소에서 계속하기 (저장된 게임 데이터 적용)
	void MoveToLastSavedLevel();
	
	//저장된 게임 데이터 존재 여부
	bool DoesSavedDataExist();
	
	//게임 종료
	void QuitGame();
	
private:
	//타이틀 화면의 위젯 클래스
	UPROPERTY(EditDefaultsOnly, Category = "Widget", meta = (AllowPrivateAccess = true))
	TSubclassOf<UT3TitleLevelWidget> TitleLevelWidgetClass;
	
	//타이틀 화면의 위젯
	UPROPERTY()
	TObjectPtr<UT3TitleLevelWidget> TitleLevelWidgetInstance;
	
	//게임 모드
	UPROPERTY()
	TObjectPtr<AT3TitleGameMode> TitleGameMode;
	
	//게임 인스턴스
	UPROPERTY()
	TObjectPtr<UT3GameInstance> T3GameInstance;
};

플레이어 컨트롤러는 UI를 생성하고 UI와 기능을 중계하는 역할을 담당한다.

void AT3TitlePlayerController::BeginPlay()
{
	Super::BeginPlay();
	
	//마우스 사용
	bShowMouseCursor = true;
	const FInputModeUIOnly InputModeUIOnly;
	SetInputMode(InputModeUIOnly);
	
	//게임 모드
	TitleGameMode = Cast<AT3TitleGameMode>(GetWorld()->GetAuthGameMode());
	if (!TitleGameMode)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : TitleGameMode is NULL"), *GetNameSafe(this));
		return;
	}
	
	//게임 인스턴스
	T3GameInstance = Cast<UT3GameInstance>(GetGameInstance());
	if (!T3GameInstance)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : T3GameInstance is NULL"), *GetNameSafe(this));
		return;
	}
	
	//위젯 생성
	TitleLevelWidgetInstance = CreateWidget<UT3TitleLevelWidget>(this, TitleLevelWidgetClass);
	if (!TitleLevelWidgetInstance)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : Failed to create TitleLevelWidget"), *GetNameSafe(this));
		return;
	}
	TitleLevelWidgetInstance->AddToViewport();
}

BeginPlay에서는 게임 인스턴스와 게임 모드를 캐싱한다. 그 다음 UI를 화면에 출력한다. 타이틀 화면은 직접 움직일 폰은 없고 UI만 있는 레벨이니 UI전용 입력으로 설정하고 마우스를 보이게 한다.

void AT3TitlePlayerController::MoveToSelectClassLevel()
{
	TitleGameMode->MoveToSelectClassLevel();
}

void AT3TitlePlayerController::MoveToLastSavedLevel()
{	
	TitleGameMode->MoveToLastSavedLevel();
}

bool AT3TitlePlayerController::DoesSavedDataExist()
{
	return T3GameInstance->GetSavedGameData() != nullptr;
}

void AT3TitlePlayerController::QuitGame()
{
	TitleGameMode->QuitGame();
}

나머지 함수는 위젯에서 사용할 것이며 모두 게임 인스턴스 및 게임 모드를 사용한다.

● UI

알다시피 UI를 구현하려면 유저 위젯(UserWidget) 클래스가 필요하다. 이 클래스를 기반으로 위젯 블루프린트를 만들기 때문이다.

1. 타이틀 화면

UCLASS()
class DESECRATION_API UT3TitleLevelWidget : public UUserWidget
{
	GENERATED_BODY()
	
public:
	virtual void NativeConstruct() override;
	
private:
	//새로하기
	UFUNCTION()
	void OnClickNewGameButton();
	
	//이어하기
	UFUNCTION()
	void OnClickLoadButton();
	
	//설정
	UFUNCTION()
	void OnClickSettingsButton();
	
	//나가기
	UFUNCTION()
	void OnClickQuitButton();
	
	//새로하기 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> NewGameButton;
	
	//이어하기 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> LoadButton;
	
	//설정 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> SettingsButton;
	
	//나가기 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> QuitButton;
    
    //풀레이어 컨트롤러
	UPROPERTY()
	TObjectPtr<AT3TitlePlayerController> TitlePlayerController;
}

위젯 블루프린트에 4개의 버튼이 있을 것을 생각해서 4개의 버튼 위젯 변수를 선언한다. 그리고 이 버튼에 사용할 함수도 각각 선언한다. 그 외에 플레이어 컨트롤러를 자주 이용하니 캐싱용으로 해당 변수도 선언한다.

void UT3TitleLevelWidget::NativeConstruct()
{
	Super::NativeConstruct();

	//플레이어 컨트롤러
	TitlePlayerController = Cast<AT3TitlePlayerController>(GetOwningPlayer());
	if (!TitlePlayerController)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : TitlePlayerController is NULL"), *GetNameSafe(this));
		return;
	}
	
	//버튼 바인딩
	NewGameButton->OnClicked.AddDynamic(this, &ThisClass::OnClickNewGameButton);
	SettingsButton->OnClicked.AddDynamic(this, &ThisClass::OnClickSettingsButton);
	QuitButton->OnClicked.AddDynamic(this, &ThisClass::OnClickQuitButton);
	//불러오기는 저장된 게임이 있을 때만 사용
	if (TitlePlayerController->DoesSavedDataExist())
	{
		LoadButton->OnClicked.AddDynamic(this, &ThisClass::OnClickLoadButton);
	}
	else
	{
		LoadButton->SetIsEnabled(false);
	}
}

자주 사용할 플레이어 컨트롤러를 캐싱한다. 그 다음 각 버튼에 알맞는 함수를 바인딩한다. 이때 불러오기 버튼에 대한 바인딩은 저장된 게임 데이터가 존재할 때만 바인딩하도록 하고 아니면 버튼을 사용하지 않는다.

저장된 게임 데이터 존재 여부는 플레이어 컨트롤러에서 구현한 함수를 사용하면 알 수 있다.

void UT3TitleLevelWidget::OnClickNewGameButton()
{
	//TODO : 저장된 게임이 있는 경우 물어보기
	TitlePlayerController->MoveToSelectClassLevel();
}

void UT3TitleLevelWidget::OnClickLoadButton()
{
	//저장된 게임이 없다면 무시
	if (!TitlePlayerController->DoesSavedDataExist())
	{
		return;
	}
	
	//TODO : 저장된 게임을 이어할지 여부를 물어보기
	TitlePlayerController->MoveToLastSavedLevel();
}

void UT3TitleLevelWidget::OnClickSettingsButton()
{
	//TODO : 설정 패널 열기
}

void UT3TitleLevelWidget::OnClickQuitButton()
{
	//TODO : 게임 종료 여부 물어보기
	TitlePlayerController->QuitGame();
}

버튼에 바인딩된 각 함수는 플레이어 컨트롤러의 함수를 사용한다. TODO에 적은 내용을 보면 알겠지만, 지금은 기능을 즉시 실행하지만 차후 유저에게 물어보는 기능을 구현할 예정이다.

2. 설정 패널

UCLASS()
class DESECRATION_API UT3SettingsPanel : public UUserWidget
{
	GENERATED_BODY()
	
public:
	virtual void NativeConstruct() override;
	
private:
	//확인 버튼
	UFUNCTION()
	void OnClickConfirmButton();
	
public:
	//설정 패널 열기
	void OpenSettingsPanel();

private:
	//닫기 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> CloseButton;
	
	//확인 버튼
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UButton> ConfirmButton;
	
	//게임 인스턴스
	UPROPERTY()
	TObjectPtr<UT3GameInstance> T3GameInstance;
}

설정 기획에 있는 각 내용은 나중에 구현하더라도 일단 열고 닫는 것 까지는 필요해 보인다. 그래서 설정 패널에서는 확인, 닫기 버튼과 바인딩할 함수 1개를 만든다. (확인 버튼과 닫기 버튼은 같은 동작을 실행하니 바인딩할 함수가 2개일 필요는 없다.)

void UT3SettingsPanel::NativeConstruct()
{
	Super::NativeConstruct();
	
	//게임 인스턴스
	T3GameInstance = Cast<UT3GameInstance>(GetGameInstance());
	if (!T3GameInstance)
	{
		UE_LOG(LogTemp, Error, TEXT("%s : T3GameInstance가 NULL"), *GetNameSafe(this));
		return;
	}
	
	//버튼 바인딩
	CloseButton->OnClicked.AddDynamic(this, &ThisClass::OnClickConfirmButton);
	ConfirmButton->OnClicked.AddDynamic(this, &ThisClass::OnClickConfirmButton);
	
	//숨김 상태로 시작
	SetVisibility(ESlateVisibility::Collapsed);
}

시작시 캐싱 및 바인딩은 타이틀 화면 위젯과 비슷하지만 숨김 상태로 시작한다는 차이점이 있다. 이때 Hidden대신 Collapsed를 쓰는 것이 좋은데 Hidden은 눈에 보이지만 않을 뿐 Tick이나 크기 계산등 기능이 계속 작동하는 상태지만 Collapsed는 완전히 사용하지 않는 상태이기 때문이다.

void UT3SettingsPanel::OnClickConfirmButton()
{
	//패널 닫기
	SetVisibility(ESlateVisibility::Collapsed);
}

void UT3SettingsPanel::OpenSettingsPanel()
{
	//패널 활성화
	SetVisibility(ESlateVisibility::Visible);
}

버튼에 사용할 함수는 1개 뿐이고 그 내용은 패널을 숨기는 기능을 실행한다. 다른 하나는 반대로 패널을 출력하는 기능을 실행한다.

//T3TitleLevelWidget.h

private:
	//설정 패널 위젯
	UPROPERTY(meta = (AllowPrivateAccess = true, BindWidget))
	TObjectPtr<UT3SettingsPanel> SettingsPanel;

//T3TitleLevelWidget.cpp

void UT3TitleLevelWidget::OnClickSettingsButton()
{
	SettingsPanel->OpenSettingsPanel();
}

설정 패널 클래스의 기초 완성됐으니 타이틀 화면 위젯에서 사용하도록 한다.

소울라이크 팀 프로젝트 Desecration : 설계 (3)

park94128 — Fri, 6 Feb 2026 23:48:37 +0900

● UI 기획 시작

다른 사람이 그린 러프 디자인

앞서 약속한 내용대로 UI 기획을 했다. 여기 부터 UI 나 혼자서 기획하고 남은 내용은 팀장, 부팀장이 기획한다. 다만 나 혼자 완전 독단적으로 만들지는 않고 다른 사람의 의견을 수렴하면서 기획할 것이고 1차로 다 만든 다음에는 팀장의 컨펌을 받을 것이다.

● 기획할 내용

처음부터 완성본을 만들 수는 없다. 괜히 뱁새가 황제 따라가다가 다리 찢어진다는 말이 나온게 아니다. MVP(Minimum Viable Produc)를 먼저 만들고 이를 기반으로 완성 하는 것이 올바른 방법이다. 이 MVP에 사용할 컨텐츠에 대한 UI를 기획하는 것이 나의 목표다.

앞서 간단히 기획했던 내용을 확인해보니 타이틀화면(+ 옵션), 클래스 선택, 기본 UI, 튜토리얼, 인벤토리를 기획하면 되겠다.

● UI 기획을 하는 방법

일단 나는 미술 관련 전공자가 아니라서 무언가를 그릴 실력은 없다. 하지만 기획자는 그리는 것은 중요하지 않고 정보 전달이 중요하다. 어차피 아트 담당자는 따로 있으니까 그 분이 쉽게 이해할 수 있도록 UI 기획을 하는 것이 중요하다.

각 UI 별로 어떤 위치에 어떤 그림이 필요한지를 표현하기 위해 단순한 도형을 사용하여 단순한 그림을 그렸다. 그림만으로 설명이 부족할 경우 그 그림에 화살표를 쳐서 부가 설명을 적었다. 이때 아트담당자 뿐만이 아니라 프로그래머도 이해를 하도록 어떤 기능을 사용할지, 값은 얼마나 되는지 등 다양한 내용을 적었다.

튜토리얼에 사용하는 안내 패널에 대한 기획은 무한도전 밈을 사용했다. 일부러 기억을 잘 하라고 이렇게 만들었다. 이런 식으로 몇 군데는 재밌으라고 넣은 내용이 있는데, 게임 제작에 필요한 내용만 적으면 내용이 심심하고 지루해지니 이런 식의 분위기 띄우기도 좋다고 생각한다.

좌 : MS 파워포인트, 우 : 구글 슬라이드

MS 파워포인트로 내용을 만들다보니 약간 사소한 문제가 생겼다. 기획서를 구글 드라이브를 통해 공유를 하니 구글 슬라이드를 통한 미리보기가 제공되는데, 구글 슬라이드와 MS 파워포인트는 서로 pptx파일을 표현하는 방식에 차이가 있었다. 텍스트 상자의 크기가 조금씩 다른 문제는 예삿일이고, 네온 효과 등 구글 슬라이드에서는 출력되지 않는 표현도 있었다. 다만 다수의 내용은 온전하게 출력되니 큰 문제로 생각하지는 않는다. 그래도 정확하게 보기 위해 다운받아서 MS 파워포인트로 보는 것을 권장한다고 적어두긴 했다.

좌 : 수정 전, 우 : 수정 후

1차로 완성하고 팀장, 부팀장에게 보여주니 몇가지 수정 요청을 받았다. 기획을 잘못 이해하여 잘못 만든 것도 있고 막상 디자인해보니 이상해 보이는 것도 있다. 요청받은 대로 내용을 수정하고 다시 컨펌을 받았다. 그리고 괜찮다고 해서 팀원 모두에게 공개했다. 제일 중요한 것은 아트 담당자분이 기획서대로 그려주는 것이지만 나머지 인원들도 이 기획서를 통해 자신이 만들 게임이 어떤 모습일지 잘 알아야 한다고 생각한다.

소울라이크 팀 프로젝트 Desecration : 설계 (2)

park94128 — Tue, 3 Feb 2026 23:55:06 +0900

● 기획 담당자로 지원하다

모든 팀에게 1명의 기획 담당자를 지명하라는 지시를 받았다. 내가 있는 팀도 마찬가지다. 그래서 팀장인 분이 기획자로 지원할 사람을 구하고 있었다. 이에 내가 지원했다. 비록 기획에 대해선 잘 알지 못하지만 일을 하면서 기획자와 소통을 많이 해보고 기획자가 만든 기획서를 많이 보고 그 기획에 따라 프로그래밍을 해본 적이 많아 내가 해도 되지 않을가 하는 마음이었다. 그리고 가능한 다양한 경험을 쌓고 싶었기 때문이기도 하다.

다만 나 혼자서 나 포험 10명이 만들 내용을 다 만드는 것은 아니고 팀장과 부팀장과 함께 총 3명이서 기획하기로 했다. 애초에 기획자로 지명된 사람 뿐만이 아니라 팀장과 부팀장도 같이 기획 특강 시간을 가졌는데 3명이서 기획을 하라는 교육기관의 의도로 보인다.

● 게임 시스템 기획

기본적인 게임 시스템에 대한 기획은 간단했다. 주로 게임 시작 전 설정이나 진행한 게임의 저장 및 불러오기에 대한 내용이었다.

그 외에는 UI에 대한 기획을 하기로 했는데 이는 내가 자세하게 기획하기로 했다. 우선 당장에 어디어 어떤 내용이 들어가야 할 지만 정해놓고 세부적인 디자인 기획은 내가 할 것이다.

● 플레이어 능력치

우선 단순하게 공격력에서 방어력을 뺀 값을 대미지로 하는 단순 계산으로는 후반 스테이지에서 밸런스 맞추기 어렵다는 것을 발견했다. 이에 대하여 여러가지 의논이 이어졌다. 방어력을 아예 없애고 공격력과 체력만 있는 시스템, 정직한 값이 아닌 최대 체력 비례 대미지를 주는 방식 등 여러가지 기획안이 있었다.

이에 대하여 나온 결론은 공격력과 체력은 특정 값을 가지되 스테이지나 플레이어의 상태에 따라 대미지가 가감되도록 만들었다. 그리고 이 플레이어의 상태 중 하나인 플레이어가 받는 피해를 일정 수치만큼 감소하는 것을 방어력이라고 정의했다. 나중에 몬스터 기획에서 자세하게 다룰 것이지만 몬스터의 능력치가 스테이지에 따라 퍼센트 비율로 강해지는 것도 이 쯤에서 정했다.

여기에 스테이지를 진행할 수록 그에 대한 보상을 받으면서 강해져야 하는데 이 강해지는 요소에 강화 시스템을 넣어서 공격력 및 방어력이 상승하는 것도 정했다.

단순하게 공격을 하고 받는 것만 있다면 소울라이크라고 할 수 없다. 기본적으로 적을 공격하는 방법에 다양성을 주어 일반적인 공격 뿐만이 아니라 스킬에 의한 강력한 공격도 기획했으며 적을 공격을 피하기 위해 막거나 회피하는 것도 기획했다. 다만 좋은 능력에는 대가도 필요한 법, 스테미나 및 마나라는 것이 존재하기 때문에 빠르게 또는 무한하게 사용할 수는 없다.

이것 외에도 록온, 상호작용 등 실제 사람이 할 법한 행동 중 게임에 어울리는 행동 다수를 기획했다.

● 캐릭터 클래스

이 게임에서 플레이어의 캐릭터는 3개의 클래스가 있는데, 다른 게임에서 쉽게 떠올릴 수 있는 검사는 당연히 존재한다. 검과 방패를 가지고 묵직한 공격과 방어를 중시한 성기사 캐릭터로 기획했다.

그 외에 만들기로 확적지은 도사라는 동양풍 캐릭터도 기획했다. 전체적으로 퓨전 판타지를 만들기로 했기 때문에 서양적인 배경에 동양적인 요소를 섞자는 것에서 출발한 기획이다.

나머지 하나는 일단 마법사로 기획했는데, 기획할 때는 확정 지었지만 추후 팀원에서 다른 의견이 나와 보류된 상태다.

● 몬스터

흔히 등장하는 잡몹부터 최종 목표가 될 보스까지 다양하게 기획했다. 던전 하나마다 수 많은 잡몹, 소수의 엘리트 몬스터, 하나의 보스 몬스터를 배치할 예정이고 각각 능력치를 세부 조절했다. 잡몹은 3번 공격에 죽는다던지, 엘리트 몬스터는 추가 패턴을 만든다던지 등 게임의 재미를 위해 다양한 의견을 주고 받았다.

아무래도 플레이어 능력치 및 클래스를 고려하다보니 몬스터의 능력치를 정하는 것에 어려움이 뒤따랐다. 그래서 각자 계산기를 두들겨 보거나 MS오피스의 엑셀을 사용하는 등 최선을 다했다.

소울라이크 팀 프로젝트 Desecration : 설계 (1)

park94128 — Mon, 2 Feb 2026 23:44:37 +0900

최종 팀 프로젝트 제작 단계가 시작됐다. 이 프로젝트는 대형 프로젝트로 내가 지금까지 배운 모든 지식을 쏟아부어 완성을 해야 한다. 마지막 프로젝트를 함께 만들 팀을 찾다가 총원 10명인 조에 합류하여 프로젝트를 시작했다.

● 역할 나누기

총 10명이라서 각자 파트를 어떻게 나눌지가 관건이었다. 이전에 팀 프로젝트를 할 때는 팀원 별로 어떤 역할을 맡을지 정하는 데에 항상 어려움이 뒤따랐는데 다행이도 이번 팀장은 역할 분배를 잘 해줬다.

초기 역할 분배안이다. 이후에 좀 내용이 변경되고 컨텐츠가 추가되긴 했지만 제법 깔끔하게 나누고 정리하는 모습이 좋았다. Miro라는 사이트를 이때 처음 알았는데 팀장이 이 사이트를 이용하는 것이 인상깊었다.

그 중에서 내가 처음에 맡기로 한 것은 게임 시스템이었다. 초안에 적은 내용은 게임 데이터 저장 및 로드, 게임 설정, 게임 진행 관련 내용을 구현하는 것이다.

캐릭터나 맵 디자인 등 다른 사람이 하는 것이 더 멋져보이지만 그냥 이 역할을 하는 것에 동의했다. 이것은 언리얼 엔진, 다양한 기능을 알고 있다면 물론 좋지만 자신이 맡은 분야에 최선을 다하여 협력하는 것이 중요하기 때문이다.

● 게임 내용 정하기

장르는 무엇으로 할 것인가, 스토리는 어떻게 설정할 것인가를 정했다.

우선 팀원 모두가 생각나는대로 아무거나 적어봤다. 지금 나는 몬스터헌터 라이즈를 즐기고 있기에 액션, 보스 사냥등의 의견을 냈다. 여러가지 의견이 난립하는 가운데 괜찮겠다 싶은 부분을 정리한 후 팀원의 투표로 결정했다.

그 내용은 소울라이크 게임을 만드는 것이고 스토리상 내용은 악마의 침공에 맞서는 주인공으로 결정됐다. 프롬 소프트웨어의 다크 소울, 엘든링과 비슷하게 만들어 보자는 취지의 의견이 강했으며 나를 포함한 모두가 이를 따르기로 했다.

게임 내용도 정했다면 제목도 정해야겠지? 이번에도 각자 생각나는대로 어울리겠다 싶은 단어를 적었다. 그리고 동일하게 적당한 제목을 정해놓고 투표를 했다. 그 결과 Desecration이라는 제목으로 정했다.

● 게임 구조 설계

아직 초안 단계지만 게임을 어떤 구조로 만들지도 정했다. 큰 단계로 나누면 다음과 같다.

- 게임 시작을 위해 타이틀 화면에 진입한다.

- 클래스와 이름을 정한다.

- 튜토리얼 진행후 마을 맵으로 진입한다.

- 던전 클리어, 마을 귀환을 반복한다.

- 엔딩

막무가내로 아무거나 만들기 보다는 명확한 방향을 가지고 만드는 것이 중요하다. 그래서 위 내용은 추후 변경되겠지만 대단히 중요한 과정이다.