Dlaczego warto korzystać z plików manifestu zasobów?

Czasami zobaczysz, że ludzie to zalecają, zamiast używać grafiki / plików dźwiękowych / itp. lubię to...

// Game code
Image myImage = new Image("path/to/image.png");

... zamiast tego powinieneś użyć pliku manifestu jako poziomu pośredniego:

// Manifest file
MY_IMAGE: path/to/image.png

// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");

Jakie mam powody takiego podejścia? Jeśli nie używam skompilowanego języka, czy istnieją jeszcze powody, aby to zrobić?

Przez większość czasu pliki manifestu są powiązane z jakimś formatem pliku archiwum. Na przykład plik JAR w Javie jest po prostu plikiem zip z plikiem manifestu, który zawiera listę zasobów w pliku zip i gdzie je znaleźć. W takim przypadku „ścieżka / do / image.png” nie jest prawdziwą ścieżką do systemu plików, ale jest informacją o tym, jak znaleźć obiekt w skompresowanym archiwum. Oprócz zalet kompresji miejsca na dysku, użycie archiwum plików może poprawić wydajność, ponieważ system Windows ma bardzo trudny czas z dziesiątkami tysięcy pojedynczych plików w niewielkiej liczbie katalogów.

Korzystając z tego rodzaju pliku manifestu, możesz całkowicie wyodrębnić, skąd pochodzi dany fragment danych. Być może Twój plik znajduje się na dysku DVD lub jest przesyłany strumieniowo z Internetu lub w pliku zip. Będziesz musiał napisać dodatkowy kod, aby poradzić sobie z tymi przypadkami, ale używając pliku manifestu, logika gry wcale nie musi dbać o to, skąd coś jest ładowane.

Teraz, jeśli używasz nieskompilowanego języka, ten plik manifestu może z pewnością być plikiem źródłowym w języku C #, ale dobrze jest, jeśli możesz łatwo zmodyfikować plik manifestu, którego używasz w czasie wykonywania klienta, na podstawie ustawień rejestru lub czegoś podobnego. Na przykład możesz sprawdzić podczas wykonywania, czy istnieje pamięć podręczna na dysku twardym lub czy dostępna jest tylko płyta DVD. Następnie możesz zmienić, który manifest ma być używany, w zależności od dostępnej konfiguracji.

Jeden powód: programowanie oparte na danych.

Twój kod może chcieć tylko wiedzieć, że potrzebuje tekstury „LightWood” i pozwolić menedżerowi zasobów użyć tego klucza, aby znaleźć właściwą ścieżkę do pliku. Co więcej, w skryptach ludzie nie chcą pamiętać ścieżek plików. Są nieuporządkowane, mogą się mylić. Pozwól manifestowi ustalić, gdzie jest plik, i pozwól człowiekowi ustalić, jakiego materiału potrzebuje na podstawie jego nazwy, a nie nazwy pliku.

<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>

Jako ogólny wzorzec projektu manifesty są przydatne, gdy chcesz zebrać wszystkie informacje o odmiennym zestawie obiektów w jednym miejscu. Nie musi to dotyczyć archiwizacji / spakowanych plików ani pośrednictwa, aby umożliwić przenoszenie rzeczy bez ponownej kompilacji / aktualizacji oryginalnych referencji. Rzeczywiście ten ostatni może wprowadzać więcej problemów niż rozwiązuje, więc zrobiłbyś to tylko wtedy, gdyby rozwiązał określoną potrzebę.

Dużą zaletą manifestów jest to, że działają one jako indeks dużej ilości danych w jednym kompaktowym miejscu. Jako takie poprawiają wydajność (ponieważ można po prostu załadować cały manifest z dysku i zachować go w pamięci), szczególnie w przypadku, gdy trzeba iterować wiele obiektów, ale nie wiesz z góry, jakie będą te obiekty . Jeśli obiekty znajdują się na dysku, zwłaszcza jeśli są w wielu miejscach, musisz dotknąć systemu plików za każdym razem, gdy chcesz iterować pliki. W przypadku systemów plików opartych na dyskach czas potrzebny na dotknięcie systemu plików jest wygórowany, więc iteracja plików w katalogu jest ogromnym kosztem. Wstępnie budując plik manifestu w czasie kompilacji (uwaga: nie kompiluj czasu), zamieniasz ten koszt na zużycie pamięci.

Pliki archiwów wymagają użycia manifestów, po prostu dlatego, że spis treści dla archiwum sam w sobie jest manifestem, więc zachowanie można uzyskać za darmo. A jeśli wymagane jest użycie manifestów dla zasobów w jednym miejscu, łatwiej jest nalegać, aby odwoływać się do wszystkich zasobów za pośrednictwem manifestów; pozwalając ci wyodrębnić faktyczną lokalizację / mechanizm przechowywania zasobów z odniesień do tych zasobów w kodzie. W ten sposób możesz mieć w kodzie pojedynczy typ odwołania do zasobu i nie musisz rozróżniać ścieżek plików, ścieżki pliku archiwum + przesunięcia lub pod-zasobów.

Oprócz innych odpowiedzi sprawia, że ​​kod jest nieco bardziej oddzielony od zasobów. Można na przykład zezwolić artyście na bezpośrednią pracę z plikami manifestu bez konieczności dokonywania zmian przez programistę i tworzenia nowej wersji. Wystarczy zmienić plik manifestu, aby wskazywał nowy obraz i po prostu ponownie uruchomić grę.

Pliki manifestu zapewniają warstwę pośrednią między nazwą zasobu a jego lokalizacją. Po dodatkowych warstwach pośrednich jest to tylko oznaka nadmiaru projektu. Czasami jednak ta dodatkowa warstwa jest potrzebna do zbudowania eleganckiego i wydajnego rozwiązania.

Oto prosty konkretny przykład, w którym pomogła mi separacja nazwy / lokalizacji zasobów. Podczas opracowywania moje zasoby graficzne są pod kontrolą wersji z kodem źródłowym. Jest to bardzo wygodne i pozwala mi szybko iterować. Zwykle nazwa zasobu odzwierciedla jego lokalizację. Manifestacja rozwoju jest bardzo prosta.

Nie chcę rozpowszechniać gry z rozproszonymi zasobami. Więc kiedy jestem gotowy do dystrybucji, mogę łatwo spakować swoje zasoby do pliku zasobów i zbudować nowy manifest.

Również atlasy tekstur są świetnym sposobem na obniżenie wydajności systemu graficznego. Atlasy są szybkie, ale praca z nimi jest trudna, dopóki sztuka jest wciąż rozwijana. Moim rozwiązaniem jest zbudowanie atlasu tylko na końcu, gdy optymalizuję grę. Ponieważ używam manifestów, wszystko co muszę zrobić, to zaktualizować manifest, aby wskazywał na lokalizację atlasu i voila, gra używa teraz atlasów zamiast prostych plików.