에픽 게임스 디자인 작업방식

개념에서 완성에 이르기까지

이 문서는 Epic Games에서 레벨 작성을 위한 사내 작업의 흐름에 대해 다소의 통찰력을 제공하기 위한 의도에서 작성되었습니다.

아트의 개념으로부터 시작

환경에 대한 개념이 아트 디렉터와 선임 프로젝트 디자이너의 승인을 받으면 이제 작업이 레벨 디자이너(LD)와 환경 아티스트에게 주어집니다.

개념의 분석

LD는 빌딩이 어디에 놓여질지, 그리고 레벨을 프로토타입하는데 대략 어떤 형태가 사용될지 등 맵에서의 단순한 구조를 식별하는 것으로부터 시작합니다.

핵심 구조 식별하기

아티스트들은 그들의 지도자와 함께 게임의 특정 지역에서의 상징이 될 주요 피스의 세트(히로 피스)를 식별합니다. 이 과정은 보통 프로젝트의 후반으로 미루어집니다. 대다수의 메쉬 작업이 세계의 90%에서 사용되는 모듈러 세트이기 때문입니다.

모듈러 메쉬 세트의 파생

LD는 환경 아티스트와 함께 작업해서 아티스트가 작성하게 될 일련의 모듈 피스를 정의합니다. 여기에는 트림 피스, 문, 창, 벽, 코너 및 이들의 변형과 같은 메쉬가 포함됩니다.

게임플레이 개념

"개념" 에 대해서는 아트의 개념과 gameplay의 개념에 큰 차이가 있으며, 이 둘은 각각 중요한 역할을 합니다. Gameplay의 개념에는 초기 단계에서 아티스트와 프로그래머의 상호작용이 크게 관여되어 있습니다. 아트의 개념에는 디자이너와 아티스트의 상호작용이 크게 관여되어 있으며, 대개 게임플레이의 프로토타입이 완성되기 전까지는 시작조차 하지 못하는 일이 많습니다.

디자이너/프로그래머 상호작용

LD는 프로그래머와의 공동 작업으로, Unreal의 Kismet 및 기존의 엔진내 작용을 조합해서 게임플레이 구상의 프로토타입을 만듭니다. 이는 대개 관련 시스템을 정확하게 시험하는데 필요한 도형 및 애셋만을 포함하는 Proof of Concept(개념의 검증) 단계에서 행해집니다. 프로젝트가 진행되는 동안 LD는 현재 존재하지 않는 행동을 요청, 주어진 시간과 게임 프로젝트의 요구에 따라 우선 순위를 매기게 됩니다.

Kismet에서의 게임플레이 프로토타입

이 행동은 Kismet에 추가되거나 게임 코드를 통해 제공됩니다. 많은 경우에 LD는 Kismet에서 필요한 행동을 만들어내어, 프로그래머가 평가하고 효율화할 수 있도록 합니다.

메쉬 작성

저희 아티스트들은 다양한 툴을 사용해서 캐릭터와 환경을 작성합니다.

고폴리곤 메쉬에 사용되는 툴

초기의 메쉬 작성은 3D Studio Max에서 행해지며, 모델링 및 상세화를 위한 다수의 작업은 Z-Brush로 옮겨져 실행됩니다.

저폴리곤 메쉬

저폴리곤 메쉬 모델링은 거의 3D Studio Max에서만 실시됩니다. 아티스트는 Z-Brush로 옮겨져 세부화되는 중간 해상도의 메쉬를 작성하며, 이는저폴리곤 메쉬로 다듬어지는 데에도 사용됩니다.

UV 맵 풀기

저폴리곤 메쉬가 완성된 후에, 주로 3D Studio Max의 UVMap 및 UnwrapUVW 변경자를 사용해서 메쉬의 UV 맵이 작성됩니다. 3D Studio Max 8은 3D Studio Max 7보다 앞선 기능의 세트를 가지고 있습니다.

메쉬로부터 노멀 맵 작성하기

아티스트들이 메쉬에서 법선 맵을 제작하는데 있어서 몇 가지 다른 방법이 있습니다. 이전 방법은 SHTools를 사용하여 하이 및 로우 폴리 메쉬를 함께 처리합니다. 이 방법에서는 떨어져 있지만 서로 매우 근접한 손가락, 어깨 보호구, 치아와 혀에서와 같은 입 부분의 사물로 인한 추적 오류를 피하기 위해 메쉬들이 흔히 분리됩니다. 또한 3D Studio Max(8 이상) 및 Maya의 새로운 버전은 메쉬를 처리할 수 능력 또한 있기에 대부분의 아티스트들은 이 두 가지 소프트웨어를 사용하기 위해 전환하였습니다.

노멀 맵은 직물 패턴 등의 제 2 범프 맵과 조합되는 일이 매우 흔합니다. SHTools는 3D Studio Max의 최신 버전과 마찬가지로 이것을 지원합니다. 또한 리벳, 볼트, 긁힌 자국 그리고 움푹 들어간 곳 등 작고 미세한 부분은 아티스트가 작성한 사전 처리된 노멀 맵의 라이브러리로부터 노멀 맵으로 합성됩니다. 이로써 아주 작은 디테일들이 폴리곤으로 모델링될 필요가 없기 때문에, 모델링 과정이 더 빨라집니다.

머티리얼 작성

Diffuse (확산) 및Specular(반사) 작성

일단 UV 맵이 작성되고 노멀 맵이 처리되면 텍스처 아티스트는 객체 또는 캐릭터에 대한 텍스처 맵 작업을 시작합니다. 이것은 UV 맵으로부터의 레이아웃을 사용해서 실시됩니다. 많은 경우에 Specular 맵은 풀컬러 텍스처로 되어 객체 또는 캐릭터의 여러 부분이 각각 살, 구리, 철 등과 같은 다른 머티리얼로 만들어진 것처럼 보이게 합니다.

UnrealEd 에서의 머티리얼 작성

일단 객체 또는 캐릭터에 대한 메인 텍스처가 거의 완성 단계에 이르면, 엔진으로 텍스처가 임포트되며 그 객체에 대해 머티리얼이 작성됩니다. 임포트중에 DeferCompression 플래그를 사용하면 패키지가 저장될 때까지 텍스처가 DXT1 또는 DXT5로 압축하는 것을 지연시켜서, 최종 텍스처로 실험하고 미조정하는 동안 더 빠른 임포트를 가능하게 하므로 시간이 많이 절약됩니다. 새 머티리얼이 작성되면 새 텍스처가 텍스처 샘플로 되어서 적당한 쉐이더 노드(확산, 반사, 노멀)로 연결됩니다.

레벨의 프로토타입

개념으로부터의 BSP 구도

레벨 디자이너는 레벨이 환경을 시험할 필요가 있는 기본적인 형태와 레이아웃을 결정하고 게임플레이의 프로토타입을 위해서 환경에 대한 컨셉 아트를 사용합니다. 이 단계에서는 레벨의 어느 도형에도 머티리얼이 적용되지 않거나 극히 약간의 머티리얼이 적용되며, 조명도 극히 적은 상태입니다. 구성물은 거의 모두 원시형태의 BSP이며, 이들은 나중에 구조 파이프라인에서 정적 메쉬 또는 Terrain으로 교체됩니다. 매우 소수의 원시 BSP만이 최종 레벨에 있게 되며, 남게 되는 것은 기본적으로 바닥, 천장 또는 간단한 벽에 대해 사용됩니다.

BSP구도의 경로 지정

초기 경로 지정은 매우 간단하며, 모든 플레이어 및 AI 캐릭터가 환경을 탐색할 수 있도록 하는 데에 주로 사용됩니다. 초기 경로가 지정되면 플레이테스트가 시작됩니다.

BSP구도의 플레이테스트

이 시점에서 BSP 레벨은 플레이테스트를 할 준비가 되어 있습니다. 플레이테스트는 먼저 LD와 선임LD가 레벨 전체를 테스트하는 것으로 시작해서, 나머지 디자인 팀이 완성에 이르기까지의 다양한 단계에서 레벨을 시험하는 것으로 진행됩니다. 레벨이 멀티플레이어 맵으로 계획된 경우에는, 저희의 실험실에서 게임플레이 세션의 스케줄을 마련해 플레이 세션 후 코멘트를 제공합니다.

게임플레이의 구도 마련

이것은 게임플레이의 특정 요소가 이 레벨에 적절한지 판단하고, 그리고 일단 스크립팅이 갖춰지면 난이도 및 만날 대상이나 픽업할 아이템의 배치를 조정하는 일입니다. LD는 이 시점에서 무기 픽업 등 게임플레이 객체를 배치하고, 나아가 경로의 배치를 미조정하고 레벨에 대한 기본 스크립팅을 함으로써 레벨을 검토합니다.

스크립팅

Kismet 소개

Unreal의 Kismet은 레벨 및 영화에 대한 거의 모든 게임내 행동을 위해서 Epic이 사용하는 것입니다. LD는 모든 스크립트를 제 자리에 배치하는 것과, 스크립트 요소에 관한 문제에 대한 보고를 담당합니다. 이 시점에서 LD는 레벨이나 게임 특정의 과제를 수행하기 위해 커스텀 Kismet 액션을 요구하기도 합니다.

Matinee를 사용한 수시 이벤트 스크립팅

게임에서 Matinee는 두 가지의 주요과제를 수행하는데 사용됩니다. 그 첫 번째는 게임 이벤트를 수시로 스크립트하는 것입니다. 이것은 열리는 문과 같이 간단한 것이거나, 시간이 지남에 따라 일련의 폭발이 발생, 이로 인해 객체의 머티리얼이 변경되고 여러 개의 Kismet 이벤트가 발생하도록 하는 것과 같이 복잡한 것일 수도 있습니다. Gears에 사용되는 대부분의 Matinee는 문 같이 간단한 액션을 위한 것입니다.

레벨에 효과 추가하기

LD는 연기와 불 등의 주위 입자 효과를 배치하는 초기 작업의 대부분을 하며, 또한 kismet을 사용해서 날아드는 먼지와 같이 나중에 발생할 효과를 배치합니다. 이들 대부분은 Kismet에 의해 구동되어 더 이상 필요하지 않을 때에 실행을 무효화 할 수 있게 합니다.

메쉬 레벨

Placeholders(자리 표시자)

디자이너는 레벨의 프로토타입 단계에서 자리 표시자를 아주 자주 사용합니다. 디자이너는 흔히 아티스트가 제공한 최종 메쉬와 크기 및 형태가 비슷한 객체를 사용합니다.이 객체에는 최종 메쉬와 같은 이름이 주어지며, 패키지에서 같은 위치에 있습니다. 이로써 아티스트는 최종 메쉬와 머티리얼을 임포트하여 이것들을 자동으로 자리 표시자가 사용된 곳에 전달되게 할 수 있습니다.

기존 메쉬의 재사용

Unreal Engine 3는 레벨에 배치된 메쉬의 비균등 스케일링을 허용합니다. 저희들은 레벨의 조립에 이 기능을 광범위하게 사용, 여러 방식으로 메쉬를 사용해서 텍스처 및 메쉬 데이터 모두의 메모리 과부하량을 줄입니다. 이 예로서 도어프레임을 사용해서 빌딩에 창틀을 만들거나, 잡석 더미를 멀리 떨어진 산맥으로 사용하는 것 등을 들 수 있습니다.

메쉬 사용의 최적화

메쉬와 메모리 과부하와 관련해서 한 가지 간단한 최적화 방법은 Generic Browser 의 Primitive Stats 섹션을 사용해서 자주 사용되지 않고 이미 사용중인 다른 메쉬로 대체될 수 있는 메쉬를 식별해내는 것입니다. 이의 한 예는 다른 기둥들과 별 차이가 없지만, 환경 내에서 단지 몇 차례만 사용된 기둥을 대체하는 것입니다. 이것이 객체 당 메모리나 성능을 절약하지는 않지만, 이것과 제거되는 다른 메쉬의 조합이 합산됩니다.

레벨의 조명

정적 조명

정적 조명은 캐릭터, 물리 객체 또는 움직이는 객체와 같은 동적 장면 요소에서 독립하여 장면을 조명하는 데에 사용됩니다. 이것은 주변 환경을 풍성하게 비추는 데에 사용됩니다. L을 누른 상태로 표면을 클릭하면 이들 중의 하나가 추가됩니다. 이들 조명으로부터 만들어지는 그림자는 정적인 것이며, 메쉬상에서 라이트맵 또는 정점 조명으로 구어집니다. 이것이 조명에 대한 기본 설정입니다.

동적 조명

동적 객체에 영향을 주는 조명에는 두 가지 종류가 있습니다. 하나는 조명을 오른 클릭하고 "Set what this light affects (이 조명이 영향을 주는 대상 설정)" 아래의 목록으로부터 'affecting only dynamic objects (동적 객체에만 영향을 줌)' 를 선택함으로써 설정되는 동적 조명입니다. 이들 동적 조명은 캐릭터, 이동체(문 처럼 보간된 액터) 및 물리 객체를 포함하도록 기본 설정된 Dynamic lighting 채널이 설정된 객체에만 영향을 줍니다. 이들 조명은 기본으로 장면에 비용이 많이 먹히는 동적 그림자를 만들어내며, 객체에 영향을 주는 모든 동적 조명은 그 객체에 대해 또 하나의 렌더 패스를 필요로 하므로 신중하게 사용해야 합니다. 'affecting both dynamic and static objects (동적 및 정적 객체에 모두 영향을 줌)' 로 조명을 설정하면 조명이 세계의 모든 것에 대해 영향을 주게 됩니다. 이것은 저희가 장면에 사용하는 주된 투영 조명으로, 가장 비싸게 먹히는 조명 타입이므로 극도의 주의를 기울여서 사용됩니다. 이것처럼 기본 설정되는 유일한 조명은 Directional light(직사조명) 타입이며 자연광을 흉내내기 위해서 사용합니다.

Skylights

Skylights은 세계 위의 반구로부터 확산된 빛을 가상하기 위해서 사용됩니다. 이것은 세계에 주변 조명의 레벨을 제공하기 위해서 사용됩니다. 이것은 매우 저렴합니다.

반사 조명

Shift-L 및 왼쪽 클릭은 클릭된 픽셀의 색상으로부터 취해진 설정으로, 낮은 강도 및 반경을 가진 조명을 추가, 반사 조명을 시뮬레이트합니다. 이것은 더욱 현실감있는 조명 결과를 제공하는데 광범위하게 사용됩니다.

변조된 그림자

기본으로, 모든 투영 조명은 장면에 정확한 그림자를 생성하기 위해 차단되고 있는지 여부를 평가합니다. 변조된 그림자를 사용하도록 조명을 설정하면, 이를 그림자를 던지는 물체의 실루엣이 투사된 텍스처를 사용해서 장면을 변조하는 것으로 대체합니다. 이것은 깊이 버퍼 그림자 방식을 사용하는 것만큼 기술적으로 정확하지는 않지만, 세계에 그림자를 생성하는 매우 고성능의 방법입니다. 이는 또한 그림자의 색상과 강도를 제어할 수 있도록 해줍니다.

스트리밍

집필 예정.

스트리밍 섹션으로 레벨 나누기

집필 예정.

볼륨을 사용해 스트림 하기

집필 예정.

메모리 통계

집필 예정.

성능 최적화

조명 최적화

조명은 Unreal Engine 3에서 가장 비싸게 먹히는 것이므로 주의해서 사용하는 것이 매우 중요합니다. 조명을 최적화하는 데에는 여러 도구가 있으며, 대부분은 UDN에서 상세히 설명되어 있습니다. 레벨 최적화 가이드 에는 조명의 최적화에 대한 여러 토픽이 수록되어 있습니다.

메모리 최적화

UnrealEd^? 의 Generic Browser에는 PrimitiveStats용 탭이 있습니다. 이것은 현재 레벨에서 사용중인 모든 메쉬에 대해 얼마나 많은 메모리가 사용되고 있는가를 보여줍니다. 저희는 메모리 비용을 절약하기 위해 다른 메쉬와 비슷하거나 똑같은, 대체될 수 있는 메쉬가 있는지 조사합니다.

다음은 현재 장면의 분석을 위한 게임내 명령어 목록입니다:

Stat memory –애셋의 타입에 따른 메모리 사용량의 목록을 표시합니다.

Stat d3dscene - Direct3D에 대한 총계의 통계를 표시합니다. 렌더되고 있는 삼각형의 수와 함께, 프레임의 다양한 부분을 렌더하는데 걸리는 시간(1/1000초 단위)에 대한 통계를 보여줍니다(조명 포함).

부록

부록 1: 엔진으로 애셋 임포트하기

대부분의 경우 콘텐츠 작성을 담당하는 아티스트는 또한 엔진으로 그 애셋들을 임포트하는 일도 담당합니다. 모든 정적 메쉬는 3D Studio Max의 Ascii Scene Export (ASE) 포맷을 사용해서 들여옵니다. 이들은 나중에 찾아낼 수 있도록 명명규칙을 사용해서 콘텐츠 패키지 내로 임포트 됩니다. 텍스처는 .TGA 또는 .BMP 포맷으로 임포트됩니다. Targa 포맷이 24비트 또는 32비트 텍스처를 지원하는 반면, 저희들은 .BMP 파일로부터 24비트(알파 없음) 텍스처만을 지원합니다. 저희는 또한 Perforce 저장소의 'artsource' 디포에 모든 소스 애셋을 보관합니다.

부록 2: 애셋에 머티리얼 배정하기

.ase의 임포트중에, 임포터는 객체에 적용된 머티리얼이 현재 에디터에 로드된 머티리얼의 이름과 일치하는지 확인합니다. 일치되는 것을 찾으면 그 머티리얼을 자동 배정합니다.

3D Studio Max에서 이것은 머티리얼에 이름을 붙임으로써 간단히 설정됩니다.

모든 객체의 인스턴스에 대해서 머티리얼을 재배정하고자 하는 경우(도어의 머티리얼을 변경하는 경우 등)에는 Generic Browser 의 정적 메쉬를 클릭해서 LODInfo 필드를 열고, [0]을 연 후에 머티리얼 리스트를 엽니다. 머티리얼 변경은 간단합니다. 변경하고자 하는 머티리얼의 엔트리를 선택하고 Generic Browser 에서 새 머티리얼을 찾아 그것을 선택한 다음 머티리얼 리스트의 초록색 화살표를 클릭합니다.

배치된 메쉬의 머티리얼을 변경하는 것은 그 메쉬의 다른 카피(인스턴스)에는 반영되지 않습니다. 따라서 메모리에 추가로 메쉬를 로드함이 없이 변형을 새로 만들 수 있습니다.

변경하고자 하는 메쉬 인스턴스를 선택합니다. 예를 들어, 두 개의 똑같은 도어가 나란히 배치되어 있습니다. 그런데, 하나가 다른 머티리얼을 가질 필요가 있습니다. 도어중의 하나를 선택하고 F4를 눌러서 StaticMeshActor 속성 창을 엽니다. StaticMeshActor 엔트리를 연 다음 StaticMeshComponent를 엽니다. Rendering으로 스크롤해 내려가서 Materials 엔트리를 클릭합니다. 이것은 아마 비어 있을 것입니다. 초록색 + 아이콘을 클릭합니다. 그 메쉬에 적용된 첫 머티리얼에 상응하는 엔트리가 추가됩니다. 예를 들면 베이스 도어에 하나, 창에 하나, 이렇게 도어에 2가지의 머티리얼을 적용했는데 '두 번째' 것만 변경하고자 하는 경우에는, Materials 배열에 2개의 엔트리를 추가하고 첫번째 것을 그대로 둡니다.

이제 이전과 같은 순서를 사용해서 메쉬에 적용된 머티리얼을 변경합니다. Browser에서 새로운 머티리얼을 찾아 선택한 후, 속성 창에서 머티리얼 엔트리를 선택하고 초록색 화살표를 클릭해서 그곳에 입력합니다. 두 도어가 같은 메쉬를 사용하고 있더라도 한 쪽 도어는 이제 다른 도어와 다른 머티리얼을 가지고 있어야 합니다.

부록 3: 물리 애셋

충돌 참조 페이지는 단순화된 충돌을 가진 정적 메쉬임포트에 관한 정보를 제공합니다. 단순화된 충돌을 가지는 정적 메쉬는 모두 강체(물리적 객체)로서 세계에 추가될 수 있습니다.

PhAT를 사용하여 물리 설정이 작성된 뼈대 메쉬에 대해서는 Physics Asset Tool^? 페이지에 설명되어 있습니다. 이들은 Physics Assets로서 세계에 배치될 수 있으며, 서로 상호작용할 때에 물리적으로 작용합니다.

부록 4: 물리적 머티리얼

물리적 머티리얼은 PhysXKR 시스템이 두 객체가 충돌할 때에 어떻게 행동하는지를 결정하는 방법입니다. 물리적 머티리얼이 무엇이며 이들이 어떻게 작용하는지에 관한 참조 페이지는 Physical Material (물리적 머티리얼) 입니다.

부록 5: 콘솔에서 플레이하기 위한 쿠킹

집필 예정.

부록 6: 소스 콘트롤 통합

저희는 소스 콘트롤 소스 콘트롤 통합을 Generic Browser 로 통합했습니다. 이로써 에디터로부터의 콘텐츠 패키지( 레벨이 아님) 체크인 및 체크아웃이 가능해졌습니다. 중요한 노트: 패키지는 최신 버전이 아니면 체크아웃할 수 없습니다. 그 지점에서 체크아웃을 하기 위해서는 에디터를 닫고 콘텐츠 패키지를 가장 최신 버전으로 동기화해야 합니다.

레벨은 에디터 외부에서 체크인 및 체크아웃 됩니다.

Epic은 내부 소스 콘트롤 시스템으로서 Perforce를 사용합니다.

부록 7: 콘텐츠 관리

Epic은 게임 콘텐츠 관리에도 Perforce를 사용합니다. 아티스트는 보통 소스 패키지를 체크아웃하고, 무엇이든 새로운 콘텐츠가 있으면 패키지에 추가하고 패키지를 저장합니다. 모든 아티스트가 이에 접근권한을 가지며 매일같이 상당히 많은 업데이트를 하기 때문에 항상 최신 콘텐츠를 가집니다. 패키지가 체크아웃되면 체크인을 요청할 수 있습니다.

저희의 패키지 크기는 보통 150 mb가 상한선으로, 특정 환경 설정에서 이 상한이 초과되면 새 패키지를 만듭니다.

예를 들어, 저희는 다음과 비슷하게 보이는 환경 패키지 구조를 설정합니다...

COG_City의 경우:

• COG_City_Doors
• COG_City_Doors02
• COG_City_Doors03
• COG_City_Floors
• COG_City_Floors02
• COG_City_Floors03

부속 8: 빌드

현재, 빌드 스크립트는 날마다 최신 버전의 콘텐츠와 코드를 검색해서 엔진 및 모든 게임 프로젝트를 컴파일하고, 이것에 독특한 라벨을 붙이고, 모든 콘텐츠와 컴파일된 바이너리를 체크인한 다음, 새 버전을 사용할 수 있다는 것을 프로젝트 팀에게 알리는 내부 이메일을 작성합니다. 모든 아티스트와 디자이너는그들의 시스템에 최신의 풀 빌드에 동기화할 수 있도록 해주는 일괄처리 파일을 가지고 있습니다. 이것은 사람들이 어느 빌드로부터 작업하고 있는지에 대한 혼란을 피하는데 도움이 됩니다.