20241219 - 언리얼 내부 코드를 뜯어보자

플랫포머 게임 레벨 디자인 후 애셋 배치하기

이번에 만들어볼 게임은 간단하게 직교 렌더링을 이용한 답답한 시점에서 맵에 최정상을 향해 올라가는 게임입니다.

내일 적용될 기술 목록 

1. 플레이어 시점 직교 렌더링 적용

2. Mover (상하, 좌우) 블루프린트 구현
3. Warp (Start, End, IsActive Trigger) 블루프린트 구현

4. End Trigger 구현

5. 캐릭터 애니메이션 블렌딩 적용

6. 사운드 적용

 

 

인프런 언리얼 C++ 강의 수강

한 번에 완벽하게 이해하기엔 조금 어려웠던 것 같아서 추후 다시 봐야 할 내용들인 것 같다.

 

언리얼에서 스트링을 관리하는 데 있어서는 UTF-16 사용
TEXT()로 감싸서 출력 → 내부 코드에서 UTF-16으로 변환

소스 코드에 한글을 사용할 경우 UTF-8 사용(문제 발생 가능성 있음) 

FString 내부 구조 확인 및 사용 과정 정리

FName

Epic Games Developer 언리얼 엔진 FText 공식문서

애셋 관리를 위해 사용되는 문자열 체계.

• 대소문자 구분 없습니다. -> 중요
• 한번 선언되면 바꿀 수 없다.
• 가볍고 빠른 성능
• 문자를 표현하는 용도가 아닌 애셋 키를 지정하는 용도로 사용, 빌드 시 해시값으로 변환

FName key1(TEXT("PELVIS")); // 대문자
FName key2(TEXT("pelvis")); // 소문자
UE_LOG(LogTemp, Display, TEXT("FName 비교 결과: %s"), key1 == key2 ? TEXT("같음") : TEXT("다름"));
// LogTemp: Display: FName 비교 결과: 같음 -> 대소문자 구분 없음

for (int i = 0; i < 10000; ++i)
{
	// 이런식으로 FName을 선언하면 기존에 FName Pool 안에서 키를 한번씩 찾고 적용이 되므로 오버헤드 발생 가능
	FName SearchInNamePool = FName(TEXT("pelvis"));  
	
	// 한번만 선언하도록 막아두기
	const static FName StaticOnlyOnce(TEXT("pelvis")); 
}

FText

Epic Games Developer언리얼 엔진의 텍스트 현지화 | 언리얼 엔진 5.5 문서 | Epic Developer Community​

다국어 지원을 위한 문자열 관리 체계

• 일종의 키로 작용함
• 별도의 문자열 테이블 정보가 추가로 요구된다.
• 게임 빌드 시 자동으로 다양한 국가별 언어로 변환된다.

게임 프로그래밍의 특수성

• 사용자 : 쾌적한 경험을 위해 단일 컴퓨터에서 최대 성능을 뽑아내야 한다.
• 개발자: 게임의 규모가 커질수록 방대하고 복잡한 기능을 안정적으로 관리해야 한다.

→ 성능과 안정성을 우선해야 한다.

→ 하지만 그 안에서도 우선순위는 성능을 우선시한다.

여기서 나온 결과로 언리얼 엔진은 C++언어를 사용하게 되었다.

모던 객체 지향 설계 원칙

• 디자인 패턴을 필두로 안정적인 설계 방법이 연구됨
• 현재 시점에서 모던(Modern)하다는 뜻은 아님. → 약 20년 지났다..
• 유지보수와 유연함, 확장성 향상을 위한 객체 지향 프로그래밍 원칙(SOLID)
  • Single responsibility principle
    • 하나의 클래스는 하나의 책임만 가져야 한다.
  • Open/Closed principle
    • 클래스 설계를 변경하지 않고 동작을 확장할 수 있어야 한다.
  • Liskov substitution principle
    • 자식 클래스는 부모 클래스를 대체 사용할 수 있어야 한다.
  • Interface segregation principle
    • 작고 명확한 인터페이스들로 분리해 관리해야 한다.
  • Dependency inversion principle
    • 구현을 배제시킨 상위 정책을 바라보며 설계해야 한다.
• 후발 언어(C#, Java)등이 보안한 새로운 기능
  • 인터페이스(Interface): 객체 설계의 틀을 제공하는 추상 클래스
  • 리플렉션(Reflection): 런타임에서 객체의 구초를 파악하고 객체에 메타데이터를 부여
• 델리게이트(Delegate): 프로그램에서 발생한 이벤트를 다수의 객체에 효과적으로 전달하는데 활용

이 부분은 이전에 작성했던 글을 다시 생각하게 되었던 순간이었습니다.

https://sonsazang.tistory.com/43

SOLID(객체 지향 설계)

언리얼 엔진의 선택

• 성능을 위해 기존 C++ 언어를 포기할 수 없어서 언리얼에서 구현

언리얼 C++

• 메모리를 직접 제어
• Cache의 활용 극대화
• 저수준 API의 직접 호출
• 복사 작업의 최소화
• 유지보수성 향상
• 크래시로부터 보호
• 자동 메모리 관리
• 고질적 실수 예방

언리얼 리플렉션

언리얼 프로퍼티 시스템 (리플렉션)

헤더에 리플렉션이 있는 유형으로 마킹을 하려면, 파일 상단에 특수한 include를 추가해야 한다.

#include "FileName.generated.h" -> 많이 봤던 그 Include이다.

그리고 저런 GENERATED_BODY() 위에 Include나 이런 메서드는 Unreal Header Tool(UHT)에서 생성한다.

언리얼 오브젝트

특징

• 관리되는 클래스 멤버 변수 : UPPROPERTY
• 관리되는 클래스 멤버 함수 : UFUNCTION
• 에디터와 연동되는 메타데이터를 심을 수 있음
• 모든 언리얼 오브젝트는 클래스 정보와 함께 한다.

클래스 기본 오브젝트

• 언리얼 클래스 정보에는 클래스 기본 오브젝트(Class Default Object)가 함께 포함되어 있다.
• CDO는 언리얼 객체가 가진 기본 값을 보관하는 템플릿 객체
• 한 클래스에서 다수의 물체를 생성할 때 일관성 있게 기본 값을 조정하는데 유용하게 사용

https://dev.epicgames.com/documentation/ko-kr/unreal-engine/unreal-object-handling-in-unreal-engine?application_version=5.1

강의 내용을 조금 정리하면서 진행할 생각이었으나 생각보다 수준이 높아서 이해를 목적으로 진행했습니다.

내용보단 실습 위주로 기억해 보도록 하겠습니다.

언리얼 C++ 헤더파일 수정 시 적용 안될 경우

1. 헤더파일 수정 시 → 에디터 종료 후 빌드 후 실행
2. 생성자 함수 수정 시 → 에디터 종료 후 빌드 후 실행
3. 나머지 상황에서는 에디터에서 라이브 코딩 가능합니다.