언리얼 엔진 이해하기

▣ 왜 언리얼 엔진을 쓰는가? 

1.  내 손으로 직접 멋진 것을 만들고 싶어서 
2.  앞으로도 계속 쓰일 엔진 
3.  좀 더 공부를 많이 하고 싶어서 
4. 게임 엔진을 더욱 깊숙히 알고 싶은 자유 

▣ 언리얼 엔진의 철학

1. 모든 직군이 프로그래밍을 몰라도 컨텐츠를 제작할 수 있도록 설계한다. 

2. 게임을 제작한 경험을 바탕으로, 최대한 완성된 프레임웍을 만들어 제공한다. 

3. 프레임웍의 설계는 (초) 대형 게임을 제작할 수 있는 스케일로 기획한

 

---

 Modern Game Engine 

 

▣ Modern Game Engine Architecture 

최신 게임 엔진은 세 개의 계층으로 구분할 수 있다.

 

 

▣ Modern Game Engine Architecture - Runtime

• 단단하고 빠른 게임 엔진의 심장 
• 일반적으로 개발 언어는 C++를 많이 사용 
• 사소한 오류에도 결과는 크리티컬하기 때문에 코딩에 엄격한 룰을 적용 • 컨텐츠 제작자에게 노출하지 않는다.

 

▣ Modern Game Engine Architecture - RuntimeDeveloper

• 컨텐츠 개발에 보조로 사용되는 개발 도구. 
• 방대한 엔진 기능 관리를 위해 다양한 도구의 개발이 필요. 
• 사용 프레임웍에 따라 구현. C++ 을 그대로 쓰거나 C#로 변경하거나. 
• 컨텐츠 제작자에게 노출하지 않음. 

 

▣  Modern Game Engine Architecture – Editor 

• 게임 컨텐츠 개발을 위한 에디터 UI의 제공 
• 다양한 외부 파일을 엔진 파일로 변환시켜주는 변환 기능 
• 3차원 공간을 다룰 수 있는 뷰포트 제공 
• 컨텐츠 제작자가 직접 활용하고 결과물을 디스크에 저장 

▣  Modern Game Engine Architecture – Contents 제작 

•  컨텐츠를 개발하고 결과물을 디스크에 저장 
• 생산성 : 빠른 컴파일, 스크립트와 전문 개발 도구 연동 
• 안정성 : 실행 영역의 분리 : 안전한 메모리관리 

---

▣ Modern Game Engine Architecture – C# 스크립팅 

 

• 이미 산업적으로 널리 쓰이는 완성도 높은 언어 
• 업계 최강의 개발도구 Visual Studio 
• MS 표준 Runtime에서 안전하게 실행 
• 전문가의 눈높이를 맞출 만큼 탄탄한 설계가 가능 
• Native 라이브러리와 연동(Interop) 및 확장 가능한 설계 
• Assembly Component의 공유 ( GAC ) – 코드 재사용, 컴파일 타임을 단축 
• Native 못지 않는 빠른 성능 ( JIT / AOT 컴파일 ) 
 
 ※ 초급/고급 프로그래머 모두를 만족시키는 프로그래밍 환경 

 

▣ Modern Game Engine Architecture – 블루프린트 

○ 장점

• 에픽 게임스가 만든 시각적 프로그래밍 언어 ( Visual Programming Language ) 
• 자체 개발 도구를 제공 ( Blueprint Editor ) 
• 자체 제작한 Runtime에서 안전하게 실행 
• 빠른 컴파일 속도  
• 가독성 높은 디자인 

 ※  프로그래밍이라는 진입 장벽이 없어 모든 직군이 사용 가능 

 

○ 단점

• 전문가의 눈높이를 맞출 만큼 설계 구조가 탄탄하지 못함. 
• 블루프린트 시스템 밖으로는 확장할 수 없다.  
• 컴파일은 빠르나 실행 속도는 느리다. ( 그렇다고 게임을 못 만들 성능은 아님 ) 
• 복잡도가 증가할 수록 사용하는 리소스가 늘어나고 가독성이 떨어짐. 

 ※ 블루프린트는 만능이 아니다. 


▶ 대신 프로그래머를 위해 C++을 제공한다

 

---

유니티와 언리얼 비교

 

유니티 - 언리얼 차이점

 

---

소스 코드를 얻게 되면 생기는 문제점 

 

• 소스 코드 양이 너무 어마어마하다.  
• 개발 할 때 이를 함께 가지고 가야 한다. 
• 부수적으로 따르는 부작용 
• 느린 컴파일 속도 
• 느린 인텔리센스 기능 
• 엄청난 용량의 결과물 

이런 문제들은 빠른 C++ 언어의 자체적인 문제 

---

자동으로 완성해주는 마법의 빌드 툴 - Unreal Build Tool 

프로젝트의 Target.cs와 모듈의 Build.cs 를 통해 설정 가능 

• 멀티플랫폼 빌드 툴 
• Private 영역과 Public 영역을 구분해 빌드 목록 생성 
• 의존성을 파악하고 빌드 순서 지정 
• Modular  ( 에디터 ) / Monolithic ( 게임 ) 방식의 빌드 지원 
• 프리컴파일드헤더 컴파일 지원 
• Static Library 지원 ( 플러그인 ) 
• 유니티 빌드 방식 지원 ( 대용량 컴파일을 묶어서 빠르게 ) 

 

---

 관리받는 코드와 Native 코드의 혼합 

 

▣ C++ 언어의 생산성을 높이자 

• 객체의 초기 설정 값을 손쉽게 관리 
• 런타임에서 클래스와 인스턴스 정보를 검색 
• 객체의 저장과 로딩을 간편하게 
• 메모리 관리를 편하게 
• 함수를 묶어서 한번에 호출  
• 모든 플랫폼에 안정적으로 동작하는 API  

※ 언리얼은 C#과 같은 C++ 프레임웍의 제공한다

 

▣ 관리받는 코드와 Native 코드의 혼합 

 

생산성을 높이기 위해 관리받는 C++ 클래스 프레임웍을 구축 

  소스코드에 특별한 매크로가 있으면 파싱을 시도하고 규칙에 맞으면 엔진에서 관리 

 

▣ 관리받는 코드와 Native 코드의 혼합 – 모듈 초기화 

 

하지만, 편리한 기능으로 인해 고려해야 할 것이 늘어난다

 

언리얼 엔진의 실행의 처음에는 항상 모듈 단위로, 언리얼 오브젝트 초기화 과정이 들어간다.

 

▣ 관리받는 코드와 Native 코드의 혼합 – 모듈 초기화 

 

 

DLL 단위로 모듈 내 모든 언리얼 오브젝트 초기화가 완성되면 %가 올라간다. 

 

▣ 관리받는 코드와 Native 코드의 혼합 – UClass

 

하나의 언리얼 오브젝트에는 상응하는 UClass가 존재한다

 

초기화 단계에서 모듈 별로 자신이 속한 언리얼 오브젝트의 UClass DB를 구축한다. 
언리얼 엔진에서는 “/Script/모듈이름.클래스이름” 형식으로 고유 주소를 부여한다

▣ 관리받는 코드와 Native 코드의 혼합 – UClass

CDO – Class Default Object ( 클래스 기본 객체 ) 

언리얼 오브젝트는 CDO를 복제해 인스턴스를 생성하도록 설계되어 있다. 

 

▣ 관리받는 코드와 Native 코드의 혼합 – 모듈 초기화 

 

초기화 단계에서 복제하기 쉽게 미리 CDO를 만들어준다. 

초기화가 끝나면 대략 위와 같은 형태로 메모리가 완성된다. 

 

▣ 관리받는 코드와 Native 코드의 혼합 – CDO

CDO는 생성자 코드를 실행하면서 완성된다. 즉, 생성자 코드는 엔진 초기화 단계에서 실행된다. 

생성자 코드에서는 게임에 대한 내용을 전혀 알수가 없다!

---

각 언어 별, 난이도/확장성 분석

 

 

---

결론

• 빠르게 프로토타입 컨텐츠를 만들려면 (방식이) 맘에 안들어도 블루프린트가 맘 편하다. 

• 블루프린트는 확장성에 한계가 있으니, 어디까지 할 수 있는지 미리 조사하자. 

• 제대로 엔진을 다루고 싶다면 C++로 가야 한다. 

• 자유에는 (엄청난) 대가가 따른다!  ( 컴파일  타임 , 인텔리센스  ㅜㅜ ) 

• C# 개발환경보다 (많이) 불편할지라도 익숙해지려고 노력하자. 

• 하나씩 차근차근 따라오면 세계 최고 엔진이 내 것이 된다. 

 

 

 

참고// 언리얼 서밋 :: 언리얼 튜토리얼만 쌓여가는 유니티 개발자를 위한 조언