Jaka jest zwykle metoda przechowywania modeli 3D, tekstur, dźwięków i skryptów (np. Plików Lua) podczas programowania i wydania? Tworzę grę z przyjaciółmi głównie w C ++; w fazie prototypowania mieliśmy tylko jedną teksturę, która została zapisana jako nagłówek C w GIMP, ale oczywiście to podejście nie skaluje się dobrze i znacznie wydłuża czas kompilacji.
W systemie Windows zwykłą praktyką jest po prostu zrzucenie ich do %PROGRAMFILES%podkatalogu, w którym znajduje się plik wykonywalny gry, być może umieszczenie ich w odpowiedniej strukturze drzewa. Jednak w systemie Linux obraz wydaje się o wiele bardziej skomplikowany. Plik wykonywalny zwykle znajduje się w nim /usr/bin, podczas gdy aplikacje przechowują swoje inne pliki /usr/share, i myślę, że umieszczanie w nim plików wykonywalnych byłoby wyjątkowo złe /usr/bin. Jednak struktura katalogów podczas programowania jest zupełnie inna.
Mógłbym wymyślić dwa różne możliwe rozwiązania:
- Pozwól, aby plik wykonywalny znalazł pliki zasobów względem siebie i zainstalował grę
/opt. Następnie umieść dowiązania symboliczne do/usr/bin. Podczas programowania względna ścieżka zasobów do plików binarnych jest taka sama jak podczas wdrażania. - Uzyskaj dostęp do plików z bezwzględną ścieżką, która jest zdefiniowana jako symbol preprocesora. Pozwól procesowi kompilacji (w naszym przypadku surowym
Makefile) zająć się zdefiniowaniem go tak, jak jest odpowiedni.
Oba podejścia wydają mi się nieeleganckie w tym czy innym aspekcie. Czy istnieje w tej branży powszechna praktyka?
Jedyne istotne pytania, które mogłem znaleźć, to: Określenie lokalizacji zainstalowanych / na zasobach gier dyskowych i ścieżek katalogów dla zasobów i zasobów , ale te nie rozwiązały problemu uruchamiania „z drzewa źródeł”.