멈추지 않고 끈질기게

[Unreal] 최종 프로젝트 17일차 - 감정표현 UI 수정 / 채팅 개선 / BT 이슈 수정 본문

포트폴리오

[Unreal] 최종 프로젝트 17일차 - 감정표현 UI 수정 / 채팅 개선 / BT 이슈 수정

sam0308 2024. 6. 7. 18:33

※ 해당 포스팅은 개인의 공부 정리용 글입니다. 틀린 내용이 있다면 추후 수정될 수 있습니다.

※ 해당 포스팅은 청년취업사관학교 교육 과정의 최종 프로젝트에 관한 내용을 포함하고 있습니다.

 

※ 해당 포스팅은 Unreal 5.4.1 버전을 기준으로 작성되었습니다.

 

 

 

0. 서론 

 사실 하루치 개발일지가 밀렸습니다만, 오늘까지 에셋 관련 회의로 시간을 많이 잡아먹어서 이틀치를 한꺼번에 올리려고 합니다. 밀린 날과 오늘은 에셋 적용 전에 기존 로직 개선 / 이슈 수정 위주로 진행하였습니다. 그리고 용량이 커서 별도로 공유하던 몇몇 메가스캔 에셋들을 실수로 지우는 바람에 맵에 디폴트 머티리얼로 노출되는 부분이 있는 점 양해 부탁드립니다.

 

 

1. 감정표현 UI 수정(너무 밝게 빛나는 UI)

 감정표현 UI를 별도의 테스트 맵에서만 확인해보았었는데, 실제로 사용할 맵에서 테스트해보니 너무 밝게 빛나서 보이지 않는 이슈가 발생하였습니다. 알고보니 팀원분이 작업하신 맵은 Directional Light가 0.1이고 대신 포스트 프로세싱의 Bloom 등으로 보정한 식이었는데, World Space의 UI는 Directional Light가 낮을 때 되려 밝게 빛나는 이슈가 있었습니다.

 

사진 1. 너무 빛나는 UI

 

 그래서 텍스처를 바로 사용하던 방식에서 머티리얼을 생성한 뒤, Domain을 User Interface로 변경하여 사용해보았습니다. 다만 해당 방식으로 수정해도 문제가 해결되지 않아서 잠시 골치를 앓았는데, 해결 방법은 간단했습니다. UI Component에서 Space 옵션을 World에서 Screen으로 수정해주었더니 해결되었습니다. 어차피 항상 플레이어쪽으로 보여야 하는 UI라 빌보드 처리도 따로 해주고 있었는데, 해당 부분까지 해소되어서 Tick을 쓸 필요도 없어졌습니다. 어차피 스크린 상으로 보여도 상관없는 UI였는데 왜 저 방법을 떠올리지 못한건지 다소 허무했지만, 지금이라도 알아서 다행인 듯 합니다.

 

사진 2. UI Component의 Space 옵션
사진 3. 수정된 UI(Screen)

 

 

 

2. 채팅 개선(채팅 상태에서 엔터 입력)

 기존의 채팅 기능에서 사소하게 불편한 점이 있었는데, 바로 채팅을 닫을 때 마우스로 화면을 한번 클릭한 후에 Enter를 눌러야 채팅창이 닫기는 부분이었습니다. 채팅을 킬 때는 FInputModeGameAndUI 로 바꾸고 EditableText의 Focus() 함수를 호출하여 바로 채팅을 칠 수 있도록 했는데, 문제는 해당 상태가 되면 UI 입력상태가 되어 Enter를 눌러도 반응하지 않아 마우스로 화면을 클릭하여 게임 입력상태로 바꾸어줘야 했습니다.

 

 마이크 입력으로 NPC와 대화하는 부분이 메인이긴 하지만, 아무래도 지연 시간이 발생하기도 하고 체험해보는 분들 입장에서 마이크 입력보다 채팅이 편할 수도 있다보니 채팅도 임시 구현이 아닌 정규 기능으로 넣으면서 해당 부분을 수정할 필요가 생겼습니다. 찾아보니 EditableText 위젯의 OnTextCommitted 델리게이트를 이용하여 UI 입력 상태에서도 유저 입력에 반응하도록 할 수 있었습니다.

 

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

	/* 기타 내용*/
    
	ChatUI->GetChatWidget()->OnTextCommitted.AddDynamic(this, &UTextInputComponent::OnChatTextCommitted);
}

void UTextInputComponent::OnChatTextCommitted(const FText& Text, ETextCommit::Type CommitMethod)
{
	// 채팅을 닫는 용도로만 사용
	if(false == InChatting)
	{
		return;
	}
	// 입력된 키가 Enter라면, Chat() 함수를 실행(채팅 닫기)
	if (CommitMethod == ETextCommit::OnEnter)
	{
		Chat();
	}
}

 

 채팅을 닫는 상황에서만 쓰기 위해 InChatting이 true인 상태에서만 실행되도록 했습니다. 입력된 키는 ETextCommit 열거형의 형태로 전달받고, 해당 값이 OnEnter일 때(Enter 키 입력 시) Chat() 함수를 실행하여 채팅을 입력하고 채팅UI를 닫는 로직이 실행되도록 했습니다. 다소 생소한 방식이었지만, 덕분에 자연스럽게 Enter키로 채팅창을 열고 닫을 수 있게 되었습니다.

 

 

3. BT 이슈 수정(부적절한 위치 지정)

 제가 만든 NPC 기능을 베이스로 상세한 NPC 패턴 지정하는 작업을 팀원분과 분담하여 하게 되었는데, 해당 팀원분이 새로 생성한 NPC가 특정 위치로 이동하는 행동을 하지 않는다는 제보가 있었습니다. 저도 클래스를 새로 만든 다음 기존 클래스의 코드를 복사하여 구현한 뒤 확인해보니 정말 해당 패턴이 무시되고 있었습니다.

 

 처음에는 시간 갱신 로직(HourUpdate)이 제대로 작동하지 않는 것인지 의심했으나 로그를 찍어보니 그건 아니었습니다. 실제로 BT를 킨 채로 실행하여 확인해보니 특정 시간에 IsMoving 키는 true로 변경되는데, Decorator 설정이 되어있음에도 바로 해당 패턴으로 이동하지 않고 기존의 행동을 이어서 수행하더니 IsMoving이 false가 되었습니다. 

 

사진 4. Decorator 설정

 

 이슈 자체는 깨닫고보니 별거 아닌 이슈였습니다. 생성자에 입력해놓은 좌표들이 기존의 제가 작업하던 테스트 맵 기준으로 저장해놓은 값이라, 현재 맵에서 이동할 수 없는 위치라 해당 태스크를 수행하지 못한 것이었습니다. 이제보니 기존에 맵에 배치해둔 NPC들은 블루프린트 상에서만 좌표값들을 수정해서 이동 가능하게 해놓고, 해당 수정을 cpp 코드쪽에 반영하지 않아 좌표값을 복사해서 생성한 새로운 클래스들도 전부 같은 이슈가 발생한 것이었습니다. 알고보니 좀 단순한 이슈였지만, 덕분에 임시로 블루프린트에서만 수정하는 것이 얼마나 위험한 행동인지 새삼 깨닫게 되었습니다. 수정한 내용은 반드시 cpp 코드에 반영하여 헷갈리는 일이 없도록 해야겠습니다.