Stingray를 시작하면 컴파일이 자주 진행된다는 것을 알 수 있을 것입니다. 새 프로젝트를 생성할 때에는 편집기가 컴파일을 진행하는 동안 조금 기다려야 하고, 편집기에서 작업하다 보면 리소스를 컴파일 중이라는 메시지를 자주 보게 됩니다.

게임 엔진으로 처음 작업하는 것이라면 이 컴파일은 대체 무엇이고, 왜 진행되는 거지? 하고 의아해 할 수 있습니다.

답을 하자면, 프로젝트를 구성하는 다양한 종류의 자산들이 생성되고 나서 프로젝트에 로드되어 런타임 시 사용되는 단계까지 다양한 단계를 거치기 때문이라고 할 수 있습니다.

이 페이지에서는 이 파이프라인이 작동하는 방식, 게임의 요소들이 생성되어 최종 환경에 빌드되는 방식 등을 자세히 살펴보겠습니다.

Stingray 프로젝트에서 사용하는 많은 컨텐츠를 처음에는 텍스처 아티스트, 모델러, 애니메이터가 Maya, Maya LT 또는 3ds Max 같은 외부 컨텐츠 제작 도구로 생성합니다. 이 "소스 아트" 단계에서 Stingray는 파일 형식, 이 자산을 저장하고 공유하는 위치나 방법에 관해 어떠한 요구사항도 두지 않습니다. 조직을 위해 어떠한 결과물도 사용할 수 있습니다.

(FBX 파일을 통해 가져온 3D 자산의 경우 Stingray Asset Browser가 해당 자산을 원래 생성한 설계 응용프로그램에서 소스 아트 파일을 열 수 있는 바로 가기를 제공합니다. 이 기능을 프로젝트에 이용하려면 몇 가지 구성을 마쳐야 할 수 있습니다. Maya, Maya LT 또는 3ds Max와 상호 운용을 참조하십시오.)

끝으로 외부 자산을 게임 또는 인터랙티브 환경에서 사용하려면 Stingray가 지원하는 파일 형식 중 하나를 통해 Stingray 게임 프로젝트로 이 자산을 가져와야 합니다. 일반적으로 자산을 가져오면 프로젝트의 소스 디렉토리에 새로운 데이터 리소스가 생성됩니다. 자산 가져오기 아래의 항목들도 참조하십시오.

마찬가지로, 수준, 유닛 및 음영 처리 환경 등의 Stingray 편집 도구에서 생성하는 자산 역시 프로젝트 소스 폴더에 저장됩니다.

외부 자산이든 Stingray에서 생성한 자산이든 상관없이 이러한 각 소스 자산은 최대 효율보다 안정성, 호환성 및 유연성을 우선으로 정해지는 "임시" 형식으로 저장됩니다. 예를 들어, 몇몇 리소스는 바이너리 형식(DDS 텍스처 등)을 사용하긴 하지만 대부분의 Stingray 리소스는 판독 가능한 일반 텍스트 SJSON 형식을 임시 저장 형식으로 사용합니다.

일부의 경우 외부 도구에서 자산을 다시 미세 조정할 수 있도록 가져온 데이터 파일 역시 유지됩니다. 예를 들어, 가져온 FBX 파일을 Maya 또는 3ds Max에서 쉽게 열어 이 가져온 파일을 편집하고, 편집 결과를 게임 환경에서 즉시 확인할 수 있습니다. 자세한 내용은 Maya, Maya LT 또는 3ds Max와 상호 운용을 참조하십시오.

리소스를 Stingray 엔진에서 로드하고 사용하려면 먼저 게임을 실행할 대상 플랫폼에 맞는 바이너리 형식으로 컴파일해야 합니다. 이 컴파일 단계를 통해 각각의 특정 플랫폼에 맞게 데이터가 최적화되어 게임 효율이 극대화됩니다.

Stingray 편집기에서 볼 수 있는 대부분의 내용이 실제로는 백그라운드에서 실행되는 Stingray 엔진의 인스턴스에 의해 제공됩니다. 때문에 Stingray 편집기에서 작업하면서 수정하고 생성하는 리소스가 Windows용으로 백그라운드에서 끊임없이 컴파일되고, 컴파일된 데이터가 소스 재질에 대한 최신 변경 사항을 반영하여 최신 상태로 유지되는 것입니다. 다른 대상 플랫폼의 경우 게임을 해당 플랫폼에 대해 플레이 테스트하거나 배포할 때마다 컴파일된 데이터가 업데이트됩니다.

보통 데이터를 컴파일할 때 Stingray는 프로젝트를 해당 플랫폼용으로 마지막으로 컴파일한 시간 이후에 추가되었거나 수정된 리소스만 컴파일하면 됩니다. 이러한 증분 컴파일 방식은 컴파일 단계가 작업 중에도 매우 빠르게 실행될 수 있다는 것을 뜻합니다.

기본적으로 각 Stingray 프로젝트는 항상 프로젝트 소스 디렉토리 옆에 _data라는 접두사가 붙은 별도의 디렉토리로 컴파일됩니다. 각 대상 플랫폼은 win32, android, ios 같은 자체 하위 디렉토리를 가집니다. 이 플랫폼별 컴파일된 데이터 디렉토리에는 소스 디렉토리와 동일한 모든 리소스가 포함되지만 컴파일된 각 파일은 원래 이름을 기반으로 하는 영숫자 해시로 이름이 정해져 data 하위 디렉토리에 저장됩니다. 게임의 마스터 settings.ini 파일 같은 모든 .ini 파일은 컴파일되거나 이름이 다시 정해지지 않습니다.

컴파일된 게임 데이터에는 Stingray 설치 디렉토리에 있는 "코어" 리소스의 컴파일된 버전도 포함됩니다. 여기에는 Appkit뿐 아니라 다른 기본 컨텐츠도 구성하는 Lua 파일들이 포함되어 있습니다. 코어 컨텐츠에 대한 자세한 내용은 코어 리소스 작업도 참조하십시오.

컴파일 단계가 대상 플랫폼에서 사용할 리소스를 준비해주기는 하지만 컴파일된 디렉토리에서 각 데이터 파일을 하나씩 로드하는 작업은 속도가 더딥니다. 운영 체제가 게임이 저장된 하드 디스크나 게임 DVD의 여러 다른 위치에서 작은 파일들을 로드해야 하기 때문입니다. 또한, 게임의 리소스 수가 많아지면 각 리소스를 일일이 제어해야 하는 따분하고 오류도 잘 발생하는 프로세스 없이 메모리에 다양한 리소스를 로드해야 하는 시기를 쉽게 제어할 수 있어야 합니다

이 두 가지 문제를 해결하기 위해 리소스를 리소스 패키지라고 하는 번들로 분할하는 것입니다. 이 패키지는 데이터 리소스로 정의하여 다른 데이터 리소스와 함께 프로젝트 소스 폴더에 저장합니다. 대상 플랫폼용 게임 빌드를 배포할 때 Stingray가 컴파일된 데이터를 보다 큰 규모의 청크로 번들링하는데, 이러한 각 청크가 사용자가 정의하는 리소스 패키지 하나에 해당합니다. 이 번들을 메모리에서 로드 및 언로드하는 시점은 게임 플레이 코드에서 지정합니다. 각 번들은 단일 파일이기 때문에 각각 하드 드라이브 또는 게임 DVD의 인접 블록에 저장됩니다. 덕분에 컴파일된 데이터를 직접 사용하는 것보다 번들이 훨씬 빠르게 로드됩니다.

리소스 패키지 및 번들에 대한 자세한 내용은 런타임 시 컨텐츠 로드 및 언로드를 참조하십시오.

번들링은 작업 중 백그라운드에서 이루어지는 증분 프로세스가 아닙니다. 번들링은 Stingray 편집기의 Deployer 패널을 사용하여 게임을 배포할 때에만 이루어집니다. 배포 및 빌드도 참조하십시오.

이 이미지는 프로젝트 폴더, 컴파일된 데이터 그리고 번들된 데이터의 컨텐츠 레이아웃을 나란히 놓고 비교한 모습입니다. 컴파일된 데이터는 플랫폼별로 다르고, 원래 프로젝트 폴더(그리고 여기에는 나와 있지 않지만 코어 리소스 폴더)의 각 리소스에 대한 컴파일된 데이터 파일을 포함하고 있다는 점에 유의하십시오. 번들된 데이터 폴더에는 데이터 파일이 훨씬 적은데, 각 파일이 많은 컴파일된 데이터 파일을 단일 파일로 통합한 번들이기 때문입니다.