기록

엔진 실행 도중 C++ 코드 리컴파일 세팅

일반

개발자가 코드 변경 사항을 즉시 테스트하고 결과를 확인할 수 있게 해주는 기능이다. 

라이브 코딩을 사용하면 에디터를 재시작하지 않고도 코드를 수정하고 결과를 실시간으로 확인할 수 있다. 

라이브 코딩 활성화

라이브 코딩 기능을 활성화 또는 비활성화한다. 활성화 시 코드 변경 사항을 실시간으로 컴파일하고 적용할 수 있다.

시작

- Start automatically and show console

- Start automatically but hide console until summoned

- Manual

세가지 선택 옵션이 있으며 기본 설정으로는 'Start automatically but hide console until summoned'로 되어있다.

Start automatically and show console

에디터를 실행할 때마다 라이브 코딩 기능이 자동으로 활성화되며 콘솔 창이 표시되어 현재 라이브 코딩의 상태를 확인할 수 있다. 라이브 코딩 콘솔은 컴파일로 그와 상태 정보를 제공하여 코드 변경 사항을 실시간으로 모니터링할 수 있다.

Start automatically but hide console until summoned

에디터를 실행할 때 라이브 코딩이 백그라운드에서 자동으로 시작되지만, 콘솔 창이 화면에 나타나지 않는다.

콘솔을 확인하려면 수동으로 호출해야 하기 때문에 라이브 코딩의 로그를 지속적으로 확인할 필요가 없고 콘솔 창이 화면을 차지하는 것을 원하지 않을 때 유용하다.

Manual

에디터를 실행한 후 사용자가 직접 라이브 코딩을 시작해야한다. 

이 설정은 라이브 코딩이 항상 필요한 것은 아니고 특정 작업을 할 때만 사용하고자 할 때 유용하다.

리인스턴싱 활성화

라이브 코딩을 통해 컴파일된 코드 변경 사항을 실시간으로 게임에 적용할 때 객체를 재인스턴스 화하여 변경된 코드를 적용하는 방법을 제어한다.

해당 설정의 활성화시 라이브 코딩 기능이 코드 변경 사항을 적용할 때 이미 메모리에 로드된 객체들을 새로 컴파일된 코드로 대체(재인스턴스화)하는 기능을 활성화한다. 기존 객체들이 새로운 코드에 맞게 다시 인스턴스화되어 변경 사항이 즉시 반영되고 게임을 재시작하거나 객체를 수동으로 재로드 하지 않아도 변경 사항을 실시간으로 테스트할 수 있다. 특히 게임 플레이 로직이나 UI와 같이 자주 변경되는 코드에서 유용하다.

새로 추가된 C++ 클래스 자동 컴파일

새로운 C++ 클래스를 추가할 때 이를 자동으로 컴파일하는 기능을 제어하는 설정이다. 

활성화시 새로운 C++ 클래스를 생성할 때마다 자동으로 컴파일이 시작된다. 이를 통해 개발자는 추가한 클래스를 바로 사용할 수 있으며 프로젝트에 제대로 통합이 되었는지 빠르게 확인할 수 있다.

모듈

프로젝트 모듈 미리 로드

라이브 코딩을 시작할 때 필요한 모듈들을 미리 로드하는 기능이다. 

라이브 코딩 중에 모듈이 처음 로드될 때  발생할 수 있는 지연을 줄일 수 있다. 활성화 시 모듈들이 자동으로 미리 로드되며 이는 라이브 코딩 작업 중 처음으로 해당 모듈을 사용할 때의 지연을 방지한다.

프로젝트 플러그인 모듈 미리 로드

라이브 코딩 세션이 시작될 때 프로젝트에 포함된 플러그인 모듈들을 미리 로하는 기능이다. 플러그인 모듈은 프로젝트에 추가적인 기능을 제공하는데 이를 미리 로드하여 최적화할 수 있어 플러그인 로드로 인한 초기 지연을 줄일 수 있다.

네임드 모듈 미리 로드

특정 이름의 모듈들을 미리 로드하는 기능이다.

프로젝트에서 중요한 역할을 하는 특정 모듈의 이름을 지정하면 라이브 코딩을 시작할 때 지정된 모듈들이 미리 로드된다.

모듈들의 이름은 배열에서 추가가 가능하다.

Hot Reload

새로 추가된 C++ 클래스 자동 컴파일

코드를 수정하고 저장하게 되면 로드시간이 발생하게 된다. 이 시간 동안 변경된 사항을 프로젝트에 반영하게 되는데 기본적으로 Hot Load의 새로 추가된 C++ 클래스 자동 컴파일 설정이 활성화되어 있기 때문이다. 

이 설정을 통해서 프로젝트는 변경된 사항을 바로 반영하게 되어 게임이나 애플리케이션을 다시 시작하지 않아도 변경된 내용을 즉시 확인할 수 있어 반복적인 빌드 및 실행 시간을 절약해서 개발 속도를 크게 향상시킬 수 있다.

프로젝트의 규모가 크며 코드의 수정이 많아 저장을 빈번히 하게 되면 매번 컴파일이 실행되기 때문에 작업이 지연될 수 있는데 이런 상황에서는 비활성화를 해두는 방법도 있다.

컴파일 오류 시 컴파일러 로그 표시

에디터에서 컴파일 중 오류가 발생할 때 로그를 표시하여 문제를 빠르게 확인하는데 도움을 준다.

컴파일러 로그에는 오류 메시지 경고, 문제가 발생한 코드상 위치에 대한 정보가 포함되어 있다. 

임포트

리소스를 프로젝트에 가져올 때 관련된 설정들이다.

Fbx 네임스페이스 유지

활성화하면 fbx 파서가 fbx 네임스페이스를 유지하고, 비활성화하면 fbx 노드에 네임스페이스를 덧붙인다.

fbx 파일은 3D 모델, 애니메이션, 재질 등을 저장하고 교환하기 위해 널리 사용되는 파일 형식이다.

이 fbx 파일에는 다양한 3D 소프트웨어 간에 데이터를 전송하기 위한 복잡한 계층 구조와 네임스페이스가 포함될 수 있는데 네임스페이스를 유지하게 되면 이름 충돌을 피하고, 객체를 논리적으로 그룹화하며 특정 객체를 고유하게 식별하는 데 사용된다.

리임포트 시 임포트 대화창 표시

사용자가 fbx를 리임포트 할 때 fbx 옵션 대화창이 표시된다.

리임포트는 이미 가져온 파일을 다시 가져올 때 임포트 대화창을 표시할지 여부를 결정하는 옵션이다. 

리임포트는 한번 가져온 외부 파일을 다시 가져오는 과정으로 외부에서 파일이 수정되었을 때 변경된 내용을 언리얼 엔진 프로젝트에 반영하기 위해 사용된다. 임포트 대화창은 파일을 언리얼 엔진으로 가져올 때 다양한 임포트 옵션을 설정할 수 있는 인터페이스를 제공한다.

리임포트 시 임포트 대화창 표시를 활성화했을 때 리임포트 시 보이는 창

데이터 소스 폴더 

리임포트 프로세스를 편하게 하기 위해 상대 소스 파일 경로를 저장할 프로젝트 데이터 소스 폴더를 지정한다.

특정 폴더를 지정하게 되면 언리얼 엔진에서는 이 폴더를 소스 데이터의 기본 위치로 인식하게 되고 텍스처, 모델, 오디오 파일 등 다양한 에셋을 위치한 폴더에 저장하게 된다.

애니메이션 리임포트 경고

애니메이션의 시퀀스 길이와 커브를 예전 데이터와 비교하고 변경사항이 있을 경우 사용자에게 알려준다.

익스포트

어태치 계층구조 유지

활성화 시 어태치먼트 계층 구조도 익스포트 한다.

어태치먼트 계층구조란 오브젝트 간의 부모-자식 관계를 말한다. 이는 오브젝트를 서로 연결하여 한 오브젝트의 변환(위치, 회전, 크기)이 다른 오브젝트에 영향을 미치도록 설정하는 기능이다.

모델을 언리얼 엔진에 익스포트 할 때 어태치먼트 계층구조를 유지하면 원본 모델의 부모-자식 관계가 언리얼 엔진에서도 동일하게 적용된다. 이는 외부 3D 소프트웨어에서 설정한 계층구조가 언리얼 엔진에서도 동일하게 유지되도록 한다.

어태치먼트 계층구조는 오브젝트 간의 부모-자식 관계를 설정하여 변환 상속 및 조직화를 용이하게 한다. 이를 통해 씬의 복잡한 구조를 간단하게 관리하고 애니메이션이나 움직임을 쉽게 구현할 수 있다. 익스포트 시에도 이 계층구조를 유지하면 외부 소프트웨어와의 호환성을 높일 수 있다.

Unreal Automation Tool(UAT)

UAT 완료 파악

에디터는 UAT 작업(쿠킹 및 패키징)을 완료할 때마다 사용자에게 알릴 시도를 한다.

UAT 항상 빌드

게임을 실행하기 전에 UAT/UBT를 언제나 빌드한다. 비활성화될 경우 반복 소요 시간이 줄어든다.

Developer Tools

에디터에서 개발자를 위한 설정들이 제공된다.

UI 익스텐션 포인트 디스플레이

이 설정을 활성화하면 에디터에서 추가적인 UI 정보가 표시된다.

문서 링크 디스플레이

해당 설정을 활성화하면 마우스 호버시 보이는 툴팁에 추가로 문서 페이지가 제공된다.

프로젝트 배지에 엔진 버전 번호 디스플레이

엔진 버전 번호가 추가로 표시된다.

AI

비헤이비어 트리 디버거 데이터 항상 수집

이 설정은 특정 디버깅 기능과 관련된 옵션으로 AI 컴포넌트의 일부인 비헤이비어 트리(Behaviour Tree)의 동작을 실시간으로 모니터링하고 분석하는 데 사용할 수 있다. 비헤이비어 트리는 주로 NPC나 기타 게임 내 인공지능 캐릭터의 행동을 제어하는 데 사용된다.

설정을 활성화하면 에디터나 게임이 실행되는 동안 비헤이비어 트리의 모든 활동과 상태 변화가 지속적으로 기록되는데 이는 개발자가 AI의 행동 패턴을 더 잘 이해하고 문제를 진단하는데 도움 받을 수 있다.

유용한 기능이지만 데이터를 항상 수집하기 때문에 성능에 영향을 줄 수 있다. 데이터 수집 과정에서 추가적인 처리가 필요하기 때문에 특히 대규모 AI 시스템을 사용하는 게임에서는 성능 저하에 유의해야 한다.

일반적으로 이 설정은 개발 중이나 테스트 단계에서 문제를 해결하기 위한 디버깅 용도로 사용되며 성능을 위해서 릴리즈 버전에서는 비활성화하는 것이 좋다. 수집된 데이터는 언리얼 엔진의 디버거 도구를 통해 시각적으로 표현될 수 있으며 이를 통해 개발자는 비헤이비어 트리의 각 노드에서 발생하는 결정과 변경사항을 보다 쉽게 추적할 수 있다.

블랙보드 키를 알파벳 순으로 디스플레이

비헤이비어 트리의 블랙보드에서 사용되는 키들을 알파벳 순서로 정렬하여 표시하도록 설정하는 기능으로 블랙보드의 데이터를 관리하고 검토할 때 편의성을 높이기 위해 사용된다.

많은 수의 키가 있을 때 알파벳 순으로 정렬하면 필요한 키를 빠르고 쉽게 찾을 수 있고 키들을 체계적으로 정리하여 블랙보드를 보다 효과적으로 관리할 수 있어 가독성과 관리 용이성을 향상할 수 있다. 

비헤이비어 트리 디버거 데이터 항상 수집과 블랙보드 키를 알파벳 순으로 디스플레이 설정은 사용 중인 트리와 블랙보드의 수가 많을 때 유의미한 결과를 확인할 수 있기 때문에 어떤 식으로 표시되는지 정보에 대한 확인은 이후에 다시 작성하도록 한다.

Simplygon Swarm

언리얼 엔진에서는 3D 모델 최적화와 자동 LOD 생성을 위한 소프트웨어인 Simplygon을 사용한다.

Simplygon을 통해서 게임 내에서 3D 모델의 성능을 향상하기 위해 다양한 디테일 레벨을 자동으로 생성하고 관리할 수 있다. 

Simplygon Swarm은 이러한 Simplygon과 관련된 데이터를 분산처리하는 시스템이다. Simplygon은 주로 3D 모델의 폴리곤 수를 줄이는 데 사용되며, 고품질의 LOD(Level of Detail) 모델을 생성하는 데 이러한 최적화 작업을 여러 대의 컴퓨터에 분산시켜 작업 효율성을 극대화한다.

Simplygon 배포 프록시 서버 사용

Simplygon Swarm은 위 작업을 위해서 제안된 기능으로 해당 설정을 활성화하면 작업 처리와 데이터 관리에 있어 중앙 집중화된 접근 방식을 취하게 된다. 배포되기 전 개발 단계에서 사용되는 도구이며 개발 단계에서 자원의 효율성을 증가시키기 위해서 사용한다. 이 설정을 활성화해야 관련된 다른 설정들도 활성화된다.

Simplygon 배포 프록시 서버 IP

분산처리 작업을 위한 프록시 서버 IP를 설정한다.

프록시 서버는 Simplygon Swarm의 네트워크 통신 허브로 작업을 여러 에이전트(작업을 실제로 수행하는 컴퓨터)에게 분산하는 중추 역할을 한다. 이 서버는 각 에이전트의 상태를 모니터링하고 최적의 분산 전략을 수립하여 작업을 효율적으로 할당한다. 

프록시 서버는 각 에이전트의 리소스 사용 상태를 파악하여 특정 에이전트에 과부하가 걸리지 않도록 작업을 분산하여 전체 시스템의 효율성을 높이고 작업 시간을 최소화하는 데 도움을 준다.

스웜 디버깅 활성화

Simplygon Swarm에서 분산 처리 작업을 진행할 때 발생하는 다양한 이벤트와 오류를 모니터링하고 로깅하는 기능이다.

이 설정을 활성화하면 시스템의 동작을 보다 상세하게 이해할 수 있으며 발생하는 문제들을 신속하게 진단하고 해결하는데 도움을 준다.

- 작업 중 발생하는 네트워크 문제, 데이터 처리 오류, 작업 실행 실패 등의 오류를 기록하여 오류를 추적한다.

- 작업 할당, 데이터 전송, 작업 완료 등의 이벤트가 발생할 때마다 로그에 기록되는 이벤트 로깅을 통해서 시스템의 전반적인 흐름과 작업 처리 상태를 확인할 수 있다.

- 시스템의 성능을 실시간으로 모니터링하면서 성능 지표를 기록하여 시스템 최적화와 자원 할당에 중요한 정보를 얻을 수 있다.

- 디버깅 데이터를 분석하여 시스템의 성능을 향상하거나 잠재적인 문제를 사전에 파악하고 수정하는 데 사용할 수 있다.

MS 단위 시간 json 요청 간 딜레이

Simplygon Swarm의 각 노드 간에 발생하는 JSON 데이터 요청들 사이에 설정된 딜레이를 의미한다. 밀리 세컨드 단위로 설정할 수 있으며(기본 5000ms) 네트워크 트래픽을 조절하고 서버의 부하를 관리할 수 있다.

효율적인 시스템 관리와 최적의 성능 유지를 위한 설정 중 하나로 데이터 처리와 네트워크 통신의 안정성을 보장하고 전체적인 시스템 운영의 효율성을 높일 수 있다.

Swarm 시스템에서는 다수의 노드가 서로 데이터를 요청하고 응답하는 과정에서 네트워크 트래픽이 급격히 증가할 수 있는데 이때 딜레이를 설정함으로써 요청이 일정한 간격으로 이루어지게 하여 네트워크의 과부하를 방지한다. 딜레이를 통해 각 요청이 처리되기까지의 시간을 일정하게 하여 서버가 한꺼번에 많은 요청을 처리해야 하는 부담을 줄인다. 이는 서버의 안정적인 운영을 도와주고 시스템의 전반적인 응답성을 개선한다.

너무 많은 요청이 짧은 시간 내에 발생할 경우 일부 요청이 실패할 가능성이 있어 딜레이를 적절히 설정하여 요청 실패율을 줄일 수 있다. 네트워크와 서버의 처리 능력을 고려하여 딜레이를 설정해야 하며 너무 짧은 딜레이는 시스템에 과부하를 주며 너무 긴 딜레이는 전체 작업의 처리 속도를 저하시킨다. 딜레이 설정 후에도 시스템의 성능과 안정성을 지속적으로 모니터링하고 필요에 따라 딜레이 값을 조정하는 것이 중요하다.

Simplygon 그리드 서버에 제출할 동시 작업 수

서버에서 동시에 처리할 수 있는 작업의 수를 지정하는 설정이다. 이 설정은 Simplygon Swarm의 작업 분산 및 처리 효율성을 관리한다. 서버의 리소스를 효율적으로 활용하기 위해 동시에 실행할 수 있는 작업의 수를 조정하여 서버의 처리 능력과 메모리 사용을 고려하여 작업의 처리 속도를 타협하여 균형 있게 조절할 수 있다. 

Simplygon 스웜 zip 파일 최대 업로드 용량(MB)

Simplygon 그리드 서버로 업로드할 수 있는 zip 파일의 최대 크기를 제한하는 설정이다.

이는 서버의 데이터 처리 능력과 네트워크의 대역폭 저장 공간 등을 고려하여 설정하여 네트워크 트래픽과 서버의 저장 공간을 효율적으로 관리한다. 최대 용량보다 큰 파일은 청크로 분할된다.

서버가 한 번에 처리할 수 있는 데이터 양을 제한하여 서버의 과부하를 방지하고 데이터 처리 효율을 유지하며 대용량 파일의 업로드가 네트워크에 미치는 영향을 최소화한다. 시스템의 안정성을 유지하기 위해 각 사용자가 업로드할 수 있는 파일의 크기를 제한함으로써 서버에 발생할 수 있는 예기치 않은 문제들을 사전에 방지한다.

Simplygon 스웜 Intermediate 폴더

작업의 중간 데이터를 저장하는 경로를 지정하는 설정이다. 3D 모델 최적화 프로세스 동안 생성되는 임시 파일들이나 처리 중인 데이터를 보관하는 장소로 사용되며 스웜에 업로드되는 중간 텍스처와 메시 데이터가 저장된다.

처리 중인 3D 모델의 데이터를 체계적으로 관리하여 프로세스의 효율성을 높이고 데이터 접근성을 개선하여 데이터를 조직화하고 프로세스 중 생성되는 임시 파일들을 별도의 위치에 저장함으로써 최종 출력 파일과 중간 파일을 명확히 구분할 수 있어 이는 작업의 명확성과 추적성을 향상해 작업의 효율성을 향상한다. 대용량 데이터의 경우 처리 시 시스템의 리소스를 효과적으로 활용하고 서버의 부하를 분산시키는 역할을 한다.

일반 - 글로벌

모든 에디터에 영향을 끼치는 글로벌 설정이다.

이 설정 내용은 익스포터 하여 저장할 수 있으며 또한 저장된 파일을 임포트 하여 설정값을 불러올 수 있다.

변경된 설정은 프로젝트 폴더의 Saved > Config 폴더에 저장된다.

파생 데이터 캐시

파생 데이터 캐시(Derived Data Cache, DDC)는 개발 과정에서 생성되는 파생 데이터를 저장하는 시스템이다.

파생 데이터에는 텍스처의 압축된 버전, 셰이더의 컴파일된 버전 등을 말하여 이 캐시는 데이터의 재계산이나 재생성 없이 빠르게 로드할 수 있도록 도와줌으로 에디터 및 게임의 런타임 성능을 향상하고 전반적인 컴파일 시간을 단축하는 역할을 한다.

즉 에셋을 처음 처리할 때 필요한 계산을 수행하고 결과를 DDC에 저장하는데 이후 동일한 에셋을 다시 로드할 필요가 있을때 DDC에 저장된 경우 미리 계산된 이 데이터를 즉시 사용할 수 있어 시간을 단축할 수 있다.

빌드 시 재사용 가능한 데이터가 DDC에 존재하면 셰이더 컴파일이나 에셋 변환과 같은 시간 소모적인 작업을 생략할 수 있기 때문에 규모가 큰 프로젝트 같은 경우 작업 시간을 절약할 수 있다.

또한 DDC는 로컬뿐만 아니라 네트워크 상에서도 위치할 수 있기 때문에 이를 통해서 동일한 DDC를 공유할 수 있어 협업에서 모든 팀원이 동일한 파생 데이터에 접근이 가능하며 데이터의 일관성을 유지할 수 있다.

따라서 글로벌 로컬 DDC 패스, 글로벌 공유 DCC 경로 설정을 통해서 필요한 데이터를 더 빠르게 재구성할 수 있기 때문에 프로젝트의 이전 및 이식성의 효율성을 높일 수 있다.

글로벌로 설정하면 모든 에디터에서 공통적으로 적용되며 고급 설정을 확장하여 현재 프로젝트에서만 적용되는 설정을 할 수 있다.

파생 데이터 캐시 알림

DDC와 관련된 작업이 수행될 때 알림을 받을 수 있도록 하는 기능으로 이 설정을 통해서 개발자가 DDC의 상태를 더 잘 파악하고 이해할 수 있도록 하여 관리를 돕는다.

이 기능은 수로 DDC 작업의 시작과 완료 과정에서 발생하는 에러 등을 실시간으로 알려주기 때문에 캐시가 올바르게 작동하고 있는지 또는 문제가 발생했는지를 즉시 파악할 수 있도록 모니터링할 수 있다.

DDC 작업의 모니터링을 통해서 성능에 미치는 영향을 파악하고 캐시된 데이터의 손상여부 확인이나 진단을 할 수 있어 문제의 원인을 빠르게 파악할 수 있기 때문에 성능 최적화와 작업의 효율성을 향상할 수 있다.

파생 데이터 캐시 S3

DDC를 Amazon S3와 함께 사용하는 설정으로 대규모 게임 개발 프로젝트에서 주로 사용되는 설정이다.

S3는 Amazon Simple Storage Services로 AWS에서 제공하는 객체 스토리지 서비스로 인터넷을 통해 데이터를 저장하고 검색할 수 잇는 확장 가능한 스토리지 솔루션이다.

이 기능을 사용하면 어느 위치에서나 접근 가능한 중앙 집중식 DDC를 구축할 수 있기 때문에 전 세계에 분산된 팀원들이 동일한 파생 데이터에 액세스 하고 공유할 수 있다.

이 서비스는 높은 확정성을 제공하고 사용량에 따라 자동으로 저장 용량이 조정되기 때문에 대규모 데이터를 처리하는 상황에서도 안정적인 성능을 유지할 수 있다. 또한 데이터의 내구성과 가용성을 보장하기 위해 여러 지리적 위치에 데이터를 자동으로 복제하여 관리하기 때문에 게임 자산의 안전을 보장하며 데이터 손실의 위험을 최소화할 수 있다.

실제로 사용한 만큼의 비용을 지불하는 요금제를 제공하기 때문에 초기 투자 비용 없이 필요에 따라 스토리지를 조정할 수 있게 하여 비용의 효율성과 아마존의 네트워크 최적화와 캐싱 전략을 통해 빠른 데이터 액세스 속도를 제공한다.

이 설정을 사용하기 위해서는 우선 AWS 계정의 설정이 필요하다.

AWS S3

AWS S3에서 계정을 생성하고 언리얼에서 설정을 통해서 필요한 데이터를 3S 버킷에 저장하여 사용할 수 있다.

글로벌 로컬 S3DDC 패스에서 다운로드 패키지 번들의 로컬 캐시 위치를 설정할 수 있다. 이 설정은 컴퓨터의 전체 프로젝트에 영향을 미친다.

편집

편집 메뉴에는 현재 프로젝트에서 수정과 관련된 작업을 할 수 있다.

실행 취소

최근에 실행된 작업을 취소한다.

다시 실행

실행 취소한 작업을 다시 실행한다.

실행 취소 히스토리 

최근에 실행된 항목들을 리스트로 볼 수 있고 선택하여 되돌릴 수 있다.

실행 취소하거나 다시 실행하거나 선택하여 진행할 수 있다.

그 외에도 잘라내기, 붙여 넣기, 복사하기, 삭제하기 등 일반적인 에디터들에서의 동작들을 사용할 수 있고 단축키도 동일하다. 

에디터 개인설정

현재 에디터의 전체적인 설정을 다룰 수 있다.

개인설정 창에서는 다양한 설정들을 할 수 있으며 다음 포스팅에서 자세히 살펴본다.

프로젝트 세팅

현재 프로젝트의 전체적인 설정을 다룰 수 있다.

마찬가지로 각 설정들에 대한 내용은 추가 포스팅으로 자세히 살펴본다.

플러그인

플러그인에서는 현재 프로젝트의 플러그인에 대해서 다룰 수 있다.

기본적으로 필요한 플러그인들은 설치된 상태이며 추가로 필요 여부에 따라서 선택하여 추가 설치가 가능하다.

다양한 플러그인들이 있기 때문에 이 부분에 대해서도 따로 포스팅을 통해 자세히 다루도록 한다.

Editor

언리얼 프로젝트를 생성하게 되면 에디터가 열리게 되는데 우선 에디터가 어떤 기능들로 구성되어 있는지 살펴본다.

Menu Bar

에디터 상단에는 여러 메뉴들을 선택할 수 있는 메뉴 바가 있다.

File

'파일' 메뉴에는 프로젝트 파일과 관련된 기능들이 있다.

새 레벨

새 레벨을 선택하면 '새 레벨'을 선택하는 팝업창이 뜬다. 

언리얼에서 '레벨'은 게임 내의 오브젝트, 환경, 조명, 카메라 등의 요소를 포함하는 컨테이너 역할을 한다. 

유니티로 치면 '씬'으로 볼 수 있다.

새로 생성된 레벨은 현재 레벨 저장(Ctrl + S)으로 저장하거나 다른 이름으로 저장(Ctrl + Alt + S)으로 저장할 수 있다.

레벨 열기

'레벨 열기'는 저장된 레벨을 선택하여 열 수 있다.

에셋 열기

현재 프로젝트에 설치된 에셋을 열 수 있다.

에셋은 언리얼 엔진 마켓플레이스에서 추가로 다운로드할 수 있다.

모두 저장

작업 중이던 내용 중 저장되지 않은 부분들을 모두 저장하는 기능이다.

저장할 파일 선택

저장되지 않은 변경 사항 중 선택해서 저장할 수 있는 기능이다. 클릭 시 저장할 콘텐츠의 목록 창이 팝업 된다.

레벨로 임포트

fbx 또는 obj 확장자 파일을 현재 레벨로 임포트 할 수 있다. 

언리얼에서는 프로젝트에 사용되는 리소스들이 Content 폴더에 저장되고 콘텐츠들을 fbx 또는 obj 확장자 파일로 내보내기 할 수 있으며 이를 다시 프로젝트에 임포트 할 수 있다.

언리얼 엔진에서 파일과 에셋들은 크게 콘텐츠 폴더와 엔진 폴더에 구분되어서 저장된다.

콘텐츠 폴더에는 특정 프로젝트에 특화된 자산을 저장하는 데 사용되며 게임 플레이와 직접적으로 관련된 모든 콘텐츠가 포함된다. 개발자가 직접 생성하고 관리하는 파일들이 대부분이며 프로젝트별로 독립적이다.

엔진 폴더에는 언리얼 엔진 자체에 필요한 핵심 파일과 자산을 저장하는 데 사용된다. 엔진 코드, 표준 플러그인, 필수 라이브러리, 시스템 설정 파일 등이 포함되어 있다. 이 폴더에 저장된 파일들은 언리얼 엔진을 설치한 모든 프로젝트에서 공통적으로 사용되기 때문에 이 폴더의 내용이 수정되면 모든 프로젝트에 영향을 미칠 수 있다. 일반적으로 엔진 업그레이드 시 업데이트되는 파일들이다.

유니티로 비교하면 Assets, Packages 폴더와 유사하다.

모두 익스포트

전체 레벨을 파일로 내보낸다.

선택 익스포트

선택된 오브젝트를 파일로 내보낸다.

새 프로젝트

새로운 프로젝트를 연다.

프로젝트 열기

프로젝트를 선택하여 연다.

프로젝트 압축

현재 프로젝트를 압축하여 저장한다.

최근 프로젝트

최근에 연 프로젝트 목록이 리스트로 나타나며 선택하여 열 수 있다.

종료

현재 프로젝트를 종료한다.

Epic Games

에픽게임즈는 미국의 게임 개발회사로 게임 유통도 함께 서비스하고 있다.

1998년에 출시한 1인칭 슈팅 게임 <언리얼>을 개발할 때 사용한 자체 개발 게임엔진인 '언리얼 엔진'을 타사에 제공 및 판매하기 시작했으며 이 엔진을 사용하여 다양한 게임들이 출시되었으며 현재는 에픽게임즈를 대표하는 수준의 중요한 서비스 중에 하나가 되었다.

Unreal Engine

이름은 비현실적인 엔진이지만 현재 배포되는 엔진 중에서 가장 현실적으로 그래픽을 표현할 수 있는 엔진 중 하나이다. 따라서 게임뿐만 아니라 영화나 건축 등 고퀄리티의 작업을 위해서 사용되기도 한다.

흔히 말하는 AAA급 게임을 개발하는데 주로 사용되는 엔진으로 또 다른 대표적인 게임 엔진인 유니티와 비교했을 때 상당히 무거운 편이다. 따라서 개발하고자 하는 게임의 수준에 맞춰 엔진을 선택하는 것이 필요하다. 

Project Create 

언리얼 엔진을 설치하고 실행하게 되면 먼저 프로젝트를 생성하게 된다. 참고로 언리얼 엔진은 컴파일러를 비주얼스튜디오를 사용하고 있다.

포스팅에서 사용할 버전은 글을 작성하는 시점에서는 가장 최근에 출시된 5.4 버전을 사용한다.

프로젝트 생성 단계에서는 어떤 프로젝트를 만들 것인지에 따라서 몇 가지 기본 템플릿이 제공된다. 

프로젝트 기본 설정에서는 몇 가지 설정을 선택하여 프로젝트를 초기화할 수 있는데 이 부분은 생성 이후에도 변경이 가능하다.

블루프린트 / C++

언리얼 하면 가장 대표적인 기능이 블루프린트이다. 

블루프린트는 구분하자면 언리얼 엔진으로 개발할 때 사용할 수 있는 프로그래밍 언어 중 한 종류로 볼 수 있다. 이러한 기능을 비주얼 스크립팅이라고도 하는데 유니티에서는 해당 기능은 기본기능으로 제공되지 않지만 스토어에서 구매하여 사용할 수 있다. 대부분 코딩 없이 개발이 가능한 기능으로 표현되는데 이 기능을 사용하기 위해서는 그래도 최소한의 언어적 이해도가 필요하다. 

또 다른 선택 가능한 언어는 C++이다.

이 부분에서 개발자들이 더 선호하기도 한다. 또 다른 대표적인 상용엔진인 유니티의 경우 C#을 프로그래밍 언어로 사용하고 있는데 C#에서는 메모리 관리를 위한 GC가 사용된다. 이는 사용자가 메모리 관리에 대한 신경을 쓸 필요를 덜어주지만 반대로 제어할 수 없다는 점도 있다.

언리얼의 경우에도 자동으로 관리를 해주는 GC나 스마트 포인터가 존재한다. 유니티와의 차이점은 사용자가 이 관리되는 메모리를 직접 제어할 수 있다는 점에서 차이가 있어 게임의 성능을 최적화하는 데에는 언리얼이 더 유리한 측면이 있다고 보인다.

에디터 버전 : 2021.3.28f1 (LTS)

Asset Pipeline

예전 에디터 버전에서는 Asset Pipeline 은 version 1, 2를 구분하여 선택하여 사용할 수 있었지만 최근 버전에서부터는 Asset Pipeline 2로 자동설정되며 선택할 수 없다.

에셋을 처리하는 과정에 대한 설정을 관리하는 항목들이다.

Remove unused Artifacts on Restart

재실행시 사용하지 않는 아티팩트들을 삭제할지 여부에 대한 토글로 기본으로 활성화된 상태이다.

유니티는 에디터가 실행될 때 라이브러리 폴더의 artifact 파일과 에셋 데이터베이스 엔트리에서 제거한다.

가비지 콜렉션의 형태로 이 설정을 비활성화하면 에셋 데이터베이스의 가비지 컬렉션이 비활성화된다.

즉 더 이상 사용하지 않는 수정된 아티팩트가 에디터가 재실행될 때에도 계속 보존되기 때문에 예상하지 못한 임포트 결과를 디버그 할 때 유용하다.

하지만 계속해서 사용하지 않는 데이터들이 쌓여갈 수 있기 때문에 일반적인 상황에서는 활성화해두는게 나을 것 같다.

라이브러리 폴더

유니티에 임포트 된 에셋은 두 가지 버전으로 구분된다. 하나는 사용자가 사용하기 위한 것이고 다른 하나는 유니티가 사용하기 위한 것이다. 이 유니티가 사용하기 위한 에셋은 프로젝트의 라이브러리 폴더에 캐시로 생성된다. 즉 라이브러리 폴더 내의 캐시들은 로컬에서 에디터가 빠르게 작업을 처리하기 위해 사용하는 정보들로 많은 정보들을 계속해서 저장하기 때문에 용량이 큰 편이다.

로컬에서만 필요한 이 정보들은 프로젝트가 켜질 때마다 확인하는 과정을 거치며 폴더가 없으면 다시 생성하기 때문에 프로젝트를 공유하는 경우에는 제외시켜도 되는 파일들이다.

Parallel Import

에셋을 임포트 할 때 동시에 진행하도록 하는 설정이다.

해당옵션은 기본으로 비활성화되어있고 이 경우 에셋을 순차적으로 임포트 하게 된다.

이 기능은 특정 유형의 에셋에서만 지원되며  에디터가 프로젝트 폴더에서 에셋이 새로 임포트 되거나 수정된 에셋을 감지하고 자동으로 임포트 할 때 발생하는 에셋 데이터베이스가 새로고침을 수행할 때만 실행된다. 이때 에셋은 하위 프로세스에서 임포트가 실행된다.

특정유형

- Texture Importer로 가져온 이미지 파일

- Model Importer 로 가져온 모델 파일

특정 유형은 임포트 시간이 오래 걸리는 두 가지로만 구성되며 현재 버전까지는 별도의 스크립터블이 가능한 API는 마련된

지 않은 상태이다.

이외의 유형은 해당 설정이 활성화되어 있어도 순차적으로 임포트 된다.

Desired Import Worker Count

병렬 임포트에서 사용할 작업 프로세스의 최적의 수

Standby Import Worker Count

쉬고 있는 상태에서도 유지시킬 최소의 작업 프로세스의 수

에디터에서 작업에 필요한 프로세스의 수가 최소보다 큰 경우 쉬고있는 프로세스를 중지시키고 시스템 리소스를 확보하도록 한다. 

Idle Import Worker Shutdown Delay

쉬는 상태의 작업 프로세스를 종료할 때 대기하는 시간

또한 Edit > Preferences > Asset Pipeline에서 새 프로젝트에서 필요한 작업 프로세스의 기본 값을 제어할 수 있다.

Import Worker Count % 의 값을 사용하여 Desired Import Worker Count 값을 할당할 수 있다.

이때 할당되는 값은 시스템에서 사용할 수 있는 논리 코어 수의 비율에 해당한다.

(16개의 논리 코어가 있다면 이중 25%를 할당하여  Desired Import Worker Count 값은 4가 할당된다.)

Cache Server (project specific)

Asset Pipeline 1 일 때 사용한 기능으로 버전 2에서는 기본으로 비활성화되어 있고 활성화할 수 없고 Unity Accelerator로 대체되었다.

Accelerator

팀 작업 속도를 높이기 위한 기능이다.

임포트 한 에셋의 사본을 유지하는 캐싱 프락시 에이전트이다. 팀이 동일한 네트워크에서 작업할 때 프로젝트 일부를 다시 임포트 할 필요가 없도록 하여 반복 시간을 줄일 수 있도록 돕는다.

Unity Accelerator

Prefab Mode

프리팹 관련 설정

Allow Auto Save

프리팹 설정 시 자동으로 저장되는 기능을 활성화할지 여부를 정할 수 있다.

활성화된 경우 프리팹 수정 씬에서 자동 저장 기능을 사용할 수 있는 상태가 된다.

Editing Environments

프리팹을 수정하는 환경을 편집하는 기능을 제공한다.

Regular Environment

일반 프리팹을 편집하는 환경에서 사용하고자 하는 신을 할당하면 배경으로 사용할 수 있다.

UI Envrionment

UI 프리팹의 편집하는 환경에서 사용할 수 있다.

Graphics

Show Lightmap Resolution Overlay

씬의 드로우 모드 중에서 Baked Lightmap 모드에 체커보드 오버레이를 그린다. 

여기서 타일 하나는 텍셀에 해당하며 라이트매핑 작업 시 씬의 텍셀 밀도를 확인할 수 있다.

Use legacy Light Probe sample counts

활성화 시 Progressive Lightmapper를 사용하여 베이크 할 때 고정된 라이트 프로브 샘플 수를 사용한다. 

Direct Sample 64, Indirect Sample 2048, Environment Sample 2048

Enable baked cookies support

2020.1 이상의 프로젝트는 기본적으로 베이크 된 쿠키가 Progressive Lightmapper의 베이크된 광원과 혼합 광원에 대해 활성화된다. 이전의 경우 해당 부분이 비활성화되는데 이 옵션은 이전 버전과의 호환성을 위해서 제공되는 기능이다.

Cookie

특정 모양이나 색상의 그림자를 만들기 위해 광원에 배치하는 마스크로 광원의 모양과 강도를 변경한다.

쿠키를 통해 런타임 성능에 최소한 또는 전혀 영향을 미치지 않는 선에서 복잡한 조명 효과를 효율적으로 사용할 수 있다.

바이너리와 텍스트(YAML) 비교

비주얼 스튜디오에서 바이너리를 볼 수 있는 확장 툴을 설치해서 해당 파일을 분석해 본다.

프로젝트 설정 중에서 에셋 데이터를 관리하는 방식인 바이너리와 텍스트 두 가지에 대해서 몇 가지 테스트를 해볼 것이다.

두 방식을 비교해 보기 위해서 프로젝트에서 모든 컴포넌트의 데이터가 동일한 오브젝트를 생성해 보고 차이점을 비교한다. 

하이어라키에서 큐브를 생성하고 프리팹으로 만들어 파일을 확인해 본다.

파일의 크기는 3kb이며 파일 내용은 YAML 형식으로 오브젝트의 모든 컴포넌트의 정보가 저장되어 있다.

길이는 100줄 정도 된다.

데이터 내용을 그대로 보아도 어떤 정보를 담고 있는지 파악하기 쉽다.

그대로 프로젝트 세팅에서 Asset Seriailization 모드를 Force Binary로 변경한다.

용량이 더 줄어들었을 거라고 예상했지만 반대로 증가했다.

파일의 마지막은 다음과 같이 정보를 보여준다.

좌측의 메모리주소와 우측의 아스키코드에 대응하는 문자는 편집기의 기능으로 데이터에 포함되지 않는 정보일 것이다.

맨 앞의 8자리 숫자+알파벳의 조합은 16진수로 보인다.

이 주소가 16 단위로 증가하고 뒤에 오는 정보는 8 + 8 총 16으로 정보의 개수를 의미하는 것 같다.

메모리 주소 뒤에 오는 행렬 형태의 정보는 아스키코드로 보이는데 아스키 테이블에서 20은 공백, 3C는 < 로 확인할 수 있다. 따라서 맨 우측에는 테이블에 대응하는 문자를 확인된다.

마지막 주소가 2030으로 10진법으로 변환 시 8240이다. 즉 총 8240개의 데이터가 담겨있으며 파일의 크기가 9kb인 것으로 생각해 볼 때 하나에 1byte로 떨어지고 각 데이터가 아스키코드이므로 1byte라고 생각하면 얼추 맞아떨어지는 거 같다.

파일크기는 9kb로 나오는데 해당 파일을 속성을 열어서 자세히 보면

더 근접한 크기임을 알 수 있다. 

좀 더 정밀하게 계산하면 마지막 줄에는 데이터 4개가 빠져있어서 8236이다. 즉 최종적으로 16byte가 모자라다.

만약 마지막 메모리가 온전히 16을 차지한다고 해도 8240이 최대일 텐데 그래도 12byte가 채워지지 않는다.

어디서 계산이 잘못된 건지 이 부분은 다시 확인해 볼 필요가 있다.

다시 본래의 목적으로 돌아가서 YAML 형식이 바이너리보다 용량이 적은 것은 의문이 들어서 프리팹의 크기를 키워보기로 한다. 기존의 큐브 프리팹에 자식으로 큐브를 추가해서 수정해 결과를 확인해 본다.

바이너리의 경우 768 byte 가 추가되었다.

모드를 변경해서 Text의 크기를 확인해 보니 6kb로 처음 경우에서 2배로 사이즈가 커졌다. 증가량만 따졌을 때는 엄청난 크기 차이가 있다.

몇 번 더 큐브를 추가해 보면서 살펴본다.

프리팹에 오브젝트가 많이 포함되어 있을수록 파일의 사이즈는 확연히 차이가 난다.

게임을 만들다 보면 프리팹 하나에 여러 오브젝트들이 붙어있게 되는 경우는 많기 때문에 거의 일반적으로 Text 모드가 용량이 크다고 보인다.

비교

테스트 결과로 비교해 보면 바이너리를 사용하는 것이 데이터의 크기를 줄여주기 때문에 프로젝트를 열고 데이터를 저장하는 과정에서 시간이 단축될 수 있다.

하지만 유니티를 사용한 프로젝트를 협업할 때에는 바이너리보다는 Text 가 권장된다. Github에서는 공식문서에서 해당 부분에 대하여 Force Text로 설정해야 한다고 명시해 두었다.

Github - Git and Unity

유니티에서도 기본값은 Force Text이며 이렇게 Force Text를 권장하는 이유는 바이너리 형식으로는 파일을 수정하고 병합하는 것이 불가능하다. 따라서 변경된 사항을 파악하는 것이 불가능한데 협업뿐만 아니라 개인 프로젝트 또한 버전 컨트롤을 사용하는 것이 일반적인데 해당 기능을 사용하지 못하는 Mixed 또는 Binary 모드는 더 이상은 사용되지 않는 기능으로 생각된다.

에디터 버전 : 2021.3.28f1 (LTS)

유니티 에디터의 전체적인 설정을 변경할 수 있는 항목이다.

Unity Remote [Depricated]

Android, iOS 등 앱을 개발할 때 사용하기 위한 기능으로 유니티 플레이 모드에서 화면 출력과 입력이 디바이스와 연결되도록한다. 따라서 빌드 이전 단계에서 타겟 디바이스를 통한 테스트가 가능하다.

2020.1 및 이후 버전에서는 depricated 되었으며 Device Simulator Package가 기능을 대신한다.

Device Simulator Package

2020 이후 버전이라면 에디터에 기능이 포함된 상태로 Window > General > Device Simulator 를 통해 사용할 수 있다.

이전 버전의 경우 패키지를 설치해 주어야 창을 열 수 있다.

패키지 매니저를 통해서 설치가 가능하며 이 때 패키지가 검색해도 나오지 않는 경우 

패키지 매니저 창에서 어드밴스 설정에 들어가서 

Pre-release Package 옵션을 활성한 이후에 패키지를 검색하면 찾을 수 있다.

Asset Serialization

프로젝트를 저장할 때 에셋들의 정보를 저장하는 방식에 대해서 설정할 수 있는 옵션이다.

Serialization 옵션에는 세가지가 있다.

Mixed

에셋이 바이너리와 문자열 각각의 저장된 상태로 유지된다. 새로 추가되는 에셋의 경우 바이너리가 적용된다.

Force Binary

에셋을 바이너리로 저장한다. 

임의의 프리팹을 생성하고 파일을 열어보면 바이너리로 저장된걸 확인할 수 있다.

비주얼 스튜디오에서 파일이 열리지 않는 경우 Extensions > Manage Extensions 에서 HexVisualizer 를 설치하면 된다. 이때 실행중인 비주얼 스튜디오는 모두 종료해야 설치가 진행된다.

Force Text

에셋을 문자열로 저장한다.

저장된 정보는 텍스트 기반으로 데이터 직렬화 언어로 많이 사용되는 YAML 형식이다.

프리팹의 정보가 키&밸류 형태로 정리되어있어  바이너리와 달리 사람이 쉽게 읽을 수 있도록 표현되었다.

Force Text 모드에서 프리팹을 생성하고 Mixed 모드로 변경시 기존 프리팹은 텍스트, 새로 생성된 프리팹은 바이너리로 저장된다.

Mixed 또는 Force Text 를 선택한 경우 Serialize Inline Mappings On One Line 토글이 활성화된다.

이 옵션은 참조 및 인라인 맵핑을 한 줄에 쓸것인지 여부를 정한다. 비활성화시 한 줄의 총 문자가 80자 이상이 되면 텍스트가 분할된다.

Default Behaviour Mode

프로젝트를 처음 생성시 2D 또는 3D를 선택하는데 프로젝트 생성 이후에도 해당 설정에서 변경이 가능하다.

유니티에서는 프로젝트가 Full 2D 인 경우 이외에는 모두 3D 로 작업환경을 정할 것을 추천한다.

2D와 3D 설정에는 프로젝트의 몇가지 기본세팅에서 차이가 있다.

2D

- Import 하는 모든 영상은 2D 이미지로 간주되며 Sprtie로 설정된다.

- Scene View 가 2D로 세팅된다.

- 게임 오브젝트가 기본적으로 실시간 Directional light 의 광원을 받지 않는다.

- 카메라의 기본 위치가 0, 0, -10 으로 설정된다.

- 카메라가 Orthographic 으로 설정된다.

- Lighting 창의 옵션의 경우

   * 새로운 씬에 대해서 Skybox가 비활성화

   * Ambient Source 는 Color(54, 58, 66) 로 설정

   * Realtime Global Illumination(Enlighten) 꺼짐 상태

   * Baked Global Illumination 꺼짐 상태

   * Auto-Building 꺼짐 상태

3D

- Import 한 모든 이미지가 2D 이미지로 간주되지 않는다.

- Sprite Packer 가 비활성화된다.

- Scene View 는 3D로 설정된다.

- 기본 게임 오브젝트가 리얼 타임 Directional Light 광원을 받는다.

- 카메라의 기본 포지션은 0, 1, -10 으로 설정된다.

- 카메라가 Perspective 로 설정된다.

- Lighting 창의 경우

  * Skybox 는 built-in Default Skybox 로 설정

  * Ambient Source 는 Skybox 로 설정

  * Realtime Global Illumination (Enlighten) 켜짐 상태

  * Baked Global Illumination 켜짐 상태

  * Auto-Building 켜짐 상태

차이점을 보면 2D에서 3D 작업을 한다고 해서 치명적인 문제가 발생하지는 않는다.

하지만 몇가지 기본 설정들은 각 상황에서만 사용하는 경우가 많기 때문에 맞춰서 작업하는것이 권장된다.