Поиск файлов ресурсов в играх Linux

Каков обычный метод хранения 3D-моделей, текстур, звуков и сценариев (например, файлов Lua) во время разработки и в выпуске? Я занимаюсь разработкой игры с моими друзьями в основном на C ++; на этапе создания прототипа у нас была только одна текстура, которая была сохранена как заголовок C с GIMP, но, конечно, этот подход не масштабируется и значительно увеличивает время компиляции.

В Windows обычная практика - просто сбросить их в %PROGRAMFILES%подкаталог, в котором находится исполняемый файл игры, возможно, расположив их в соответствующей древовидной структуре. Однако в Linux картина выглядит намного сложнее. Исполняемый файл обычно находится внутри /usr/bin, тогда как приложения хранят свои другие файлы в нем /usr/share, и я думаю, что было бы крайне плохой практикой помещать неисполняемые файлы /usr/bin. Однако структура каталогов во время разработки совершенно другая.

Я мог бы предложить два разных возможных решения:

• Пусть исполняемый файл найдет файлы ресурсов относительно себя и установит игру в /opt. Затем разместите символические ссылки на /usr/bin. Во время разработки относительный путь активов к двоичным файлам такой же, как и при развертывании.
• Получите доступ к файлам с абсолютным путем, который определен как символ препроцессора. Пусть процесс сборки (в нашем случае raw Makefile) позаботится о том, чтобы определить его так, как он подходит.

Оба подхода кажутся мне несколько нелегкими в том или ином аспекте. Есть ли распространенная практика в индустрии разработки игр по этому поводу?

Единственные релевантные вопросы, которые я мог найти, были определение местоположения установленных / на диске игровых ресурсов и путей к каталогам для ресурсов и ресурсов , но они не решали проблему запуска «из дерева исходных текстов».

../lib/programnameили ../share/programname/, относительно dirname(3)of argv[0], в зависимости от того, являются ли активы зависимыми от архитектуры или нет.

Это тот же стандарт, что и для всех других программ для Linux (и большинства не-Mac Unix).

Если вы хотите запустить из "исходного дерева",

1. Вы должны получить реальную систему сборки и выполнить сборку, потому что вы никогда не «запускаете из дерева исходных текстов», вы запускаете встроенный исполняемый файл, который ваша система сборки где-то выплевывает, и он может так же легко копировать или связывать ресурсы.
2. Если ваша система сборки слишком дрянная, просто проверьте .или ./assetsи т. Д., А затем изучите новую систему сборки позже в процессе разработки.

В отличие от happy_emi, вы должны предоставить способ переопределить это переменными среды. Это именно то, для чего они предназначены.