때로는 사람들이 그래픽 / 사운드 파일 등을 사용하는 대신 권장하는 것을 보게 될 것입니다. 이렇게 ...
// Game code
Image myImage = new Image("path/to/image.png");
... 대신 매니페스트 파일을 간접적 인 수준으로 사용해야합니다 .
// Manifest file
MY_IMAGE: path/to/image.png
// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");
이런 종류의 접근 방식을 취해야하는 이유는 무엇입니까? 컴파일 된 언어를 사용하지 않는 경우에도 이렇게해야 할 이유가 있습니까?
답변:
대부분의 매니페스트 파일은 일종의 아카이브 파일 형식과 관련이 있습니다. 예를 들어, Java의 JAR 파일은 zip 파일 내의 자산 및 찾을 위치를 나열하는 매니페스트 파일이있는 zip 파일입니다. 이 경우 "path / to / image.png"는 실제 파일 시스템 경로가 아니라 압축 된 아카이브 내에서 객체를 찾는 방법에 대한 정보입니다. 압축의 디스크 공간 이점 외에도 파일 아카이브를 사용하면 소수의 디렉토리에서 수만 개의 개별 파일을 처리하는 데 시간이 많이 걸리기 때문에 파일 아카이브를 사용하면 성능을 향상시킬 수 있습니다.
이런 종류의 매니페스트 파일을 사용하면 주어진 데이터 청크의 출처를 완전히 추상화 할 수 있습니다. 파일이 DVD에 있거나 인터넷에서 또는 zip 파일로 스트리밍되어있을 수 있습니다. 이러한 경우를 처리하기 위해 몇 가지 추가 코드를 작성해야하지만 매니페스트 파일을 사용하면 게임 로직이 무언가가로드 된 곳을 전혀 신경 쓰지 않아도됩니다.
컴파일되지 않은 언어를 사용하는 경우이 매니페스트 파일은 확실히 C # 소스 파일 일 수 있지만 레지스트리 설정 또는 이와 유사한 것을 기반으로 클라이언트 실행 시간에 사용중인 매니페스트 파일을 쉽게 수정할 수 있다면 좋을 것입니다. 예를 들어, 실행 중에 온 하드 드라이브 캐시가 존재하는지 또는 DVD 만 사용 가능한지 점검 할 수 있습니다. 그런 다음 사용 가능한 설정에 따라 사용할 매니페스트를 전환 할 수 있습니다.
한 가지 이유 : 데이터 기반 프로그래밍.
코드는 "LightWood"텍스처가 필요하다는 것을 알고 리소스 관리자가이 키를 사용하여 파일의 올바른 경로를 찾도록 할 수 있습니다. 또한 스크립트에서 사람들은 파일 경로를 기억하고 싶지 않습니다. 지저분하고 틀릴 수 있습니다. 매니페스트가 파일의 위치를 알아 내도록하고, 파일 이름이 아니라 이름으로 필요한 자료를 사람이 알아 내도록합니다.
<material name="wood">
<diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
<normals>environment.zip/wood_normals.jpg</normals>
<shader>environment.zip/wood.fx</shader>
<specular color="1,1,1,1" power="0.5" flat="yes" />
</material>
일반적인 디자인 패턴으로서 매니페스트는 개별 개체 집합에 대한 모든 정보를 한 곳으로 수집하려는 경우에 유용합니다. 아카이브 / 패킹 된 파일이나 원래 참조를 다시 컴파일 / 업데이트하지 않고 항목을 이동할 수 있도록하는 간접적 인 정보 일 필요는 없습니다. 실제로 후자는 해결하는 것보다 더 많은 문제를 일으킬 수 있으므로 특정 요구를 해결 한 경우에만 그렇게 할 수 있습니다.
매니페스트의 가장 큰 장점은 하나의 컴팩트 한 장소에서 많은 양의 데이터에 대한 인덱스 역할을한다는 것입니다. 따라서 여러 객체를 반복해야하는 경우에 특히 디스크에서 전체 매니페스트를로드하여 메모리에 보관할 수 있기 때문에 성능이 향상 되지만 해당 객체가 무엇인지 미리 알 수 없습니다 . 객체가 디스크에있는 경우, 특히 여러 곳에있는 경우 파일을 반복 할 때마다 파일 시스템을 터치해야합니다. 디스크 기반 파일 시스템의 경우 파일 시스템을 다루는 데 시간이 많이 걸리므로 디렉토리의 파일을 반복하는 데 많은 비용이 듭니다. 빌드 타임 (NB : 컴파일 타임 아님)에 파일 매니페스트를 사전 빌드하면 해당 비용을 메모리 사용량과 교환 할 수 있습니다.
아카이브의 목차는 본질적으로 매니페스트이므로 아카이브 파일에는 매니페스트를 사용해야하므로 무료로 동작을 얻을 수 있습니다. 한 위치에서 자산에 매니페스트를 사용해야하는 경우 모든 자산이 매니페스트를 통해 참조되도록 주장하는 것이 더 깨끗할 수 있습니다. 코드에서 자산에 대한 참조에서 자산의 실제 저장 위치 / 메커니즘을 추상화 할 수 있습니다. 이렇게하면 코드에 단일 자산 참조 유형을 가질 수 있으며 파일 경로, 아카이브 파일 경로 + 오프셋 또는 하위 자산을 구분할 필요가 없습니다.
매니페스트 파일은 리소스 이름과 위치 사이에 간접 계층을 제공합니다. 간접적 인 추가 계층은 종종 디자인 오버의 표시입니다. 그러나 때로는 그 여분의 계층이 우아하고 효율적인 솔루션을 구축하는 데 필요한 것입니다.
다음은 리소스 이름 / 위치 분리가 도움이 된 간단한 구체적인 예입니다. 개발 과정에서 내 아트 자산은 소스 코드로 개정 관리됩니다. 매우 편리하며 빠르게 반복 할 수 있습니다. 일반적으로 리소스 이름은 해당 위치를 나타냅니다. 개발 매니페스트는 매우 간단합니다.
자산이 흩어져있는 게임을 배포하고 싶지 않습니다. 따라서 배포 할 준비가되면 자산을 리소스 파일에 쉽게 압축하여 새 매니페스트를 만들 수 있습니다.
또한 텍스처 아틀라스는 그래픽 시스템에서 약간 더 많은 성능을 발휘할 수있는 좋은 방법입니다. 지도 책은 빠르지 만 아트가 아직 개발중인 동안 작업하기가 어렵다. 내 솔루션은 게임을 최적화 할 때 마지막에 아틀라스 만 작성하는 것입니다. 매니페스트를 사용하고 있기 때문에 아틀라스 위치를 가리 키도록 매니페스트를 업데이트하기 만하면 게임이 이제 직선 파일 대신 아틀라스를 사용하고 있습니다.