Recherche de fichiers de ressources dans les jeux Linux

Quelle est la méthode habituelle de stockage des modèles 3D, des textures, des sons et des scripts (par exemple les fichiers Lua) pendant le développement et dans une version? Je développe un jeu avec mes amis principalement en C ++; dans la phase de prototypage, nous n'avions qu'une seule texture qui a été enregistrée en tant qu'en-tête C avec le GIMP, mais bien sûr, cette approche ne s'adapte pas bien et augmente considérablement les temps de compilation.

Sous Windows, la pratique habituelle consiste simplement à les vider dans le %PROGRAMFILES%sous - répertoire où réside l'exécutable du jeu, en les disposant peut-être dans une arborescence appropriée. Cependant, sous Linux, l'image semble beaucoup plus compliquée. L'exécutable réside généralement dans /usr/bin, tandis que les applications stockent leurs autres fichiers /usr/share, et je pense que ce serait une très mauvaise pratique de mettre des non-exécutables /usr/bin. Cependant, la structure du répertoire pendant le développement est totalement différente.

Je pourrais proposer deux solutions différentes:

• Laissez l'exécutable trouver les fichiers de ressources par rapport à lui-même et installez le jeu sur /opt. Placez ensuite les liens symboliques vers /usr/bin. Pendant le développement, le chemin relatif des actifs vers les fichiers binaires est le même que lors du déploiement.
• Accédez aux fichiers avec un chemin absolu défini comme symbole de préprocesseur. Laissez le processus de construction (dans notre cas, les Makefiles premières ) prendre soin de le définir comme il convient.

Les deux approches me semblent quelque peu inélégantes sous un aspect ou un autre. Y a-t-il une pratique courante dans l'industrie du développement de jeux à ce sujet?

Les seules questions pertinentes que j'ai pu trouver étaient la détermination de l'emplacement des ressources de jeu installées / sur disque et des chemins de répertoire pour les ressources et les ressources , mais celles-ci n'ont pas résolu le problème de l'exécution "à partir de l'arborescence source".

../lib/programnameou ../share/programname/, par rapport à dirname(3)of argv[0], selon que les actifs dépendent ou non de l'architecture.

Il s'agit du même standard que tous les autres programmes Linux (et la plupart des programmes Unix non Mac).

Si vous souhaitez exécuter à partir de "l'arborescence source",

1. Vous devriez obtenir un vrai système de build et faire un build, car vous ne "courez jamais depuis l'arborescence source", vous exécutez un exécutable construit, que votre système de build crache quelque part, et il peut copier ou lier des actifs en place tout aussi facilement.
2. Si votre système de construction est trop merdique, vérifiez également .ou ./assets, etc., puis examinez un nouveau système de construction plus tard dans le développement.

Contrairement à happy_emi, vous devez certainement fournir un moyen de remplacer cela par des variables d'environnement. C'est exactement ce à quoi ils sont destinés.