Encontrar archivos de activos en juegos de Linux

¿Cuál es el método habitual para almacenar modelos 3D, texturas, sonidos y secuencias de comandos (por ejemplo, archivos Lua) durante el desarrollo y en una versión? Estoy desarrollando un juego con mis amigos principalmente en C ++; En la fase de creación de prototipos, solo teníamos una única textura que se guardaba como un encabezado C con el GIMP, pero, por supuesto, este enfoque no escala bien y aumenta los tiempos de compilación en gran medida.

En Windows, la práctica habitual es simplemente volcarlos en el %PROGRAMFILES%subdirectorio en el que reside el ejecutable del juego, quizás organizándolos en una estructura de árbol adecuada. Sin embargo, en Linux la imagen parece mucho más complicada. El ejecutable generalmente reside en /usr/bin, mientras que las aplicaciones almacenan sus otros archivos /usr/share, y creo que sería una práctica extremadamente mala colocar no ejecutables /usr/bin. Sin embargo, la estructura del directorio durante el desarrollo es totalmente diferente.

Podría proponer dos posibles soluciones diferentes:

• Deje que el ejecutable encuentre los archivos de activos relativos a sí mismo e instale el juego /opt. Luego coloca enlaces simbólicos a /usr/bin. Durante el desarrollo, la ruta relativa de los activos a los binarios es la misma que durante la implementación.
• Acceda a los archivos con una ruta absoluta que se define como un símbolo de preprocesador. Deje que el proceso de compilación (en nuestro caso, raw Makefiles) se encargue de definirlo como sea adecuado.

Ambos enfoques me parecen poco elegantes en un aspecto u otro. ¿Existe una práctica común en la industria del desarrollo de juegos sobre esto?

Las únicas preguntas relevantes que pude encontrar fueron Determinar la ubicación de los recursos del juego instalados / en el disco y las rutas del Directorio para los recursos y los activos , pero no resolvieron el problema de ejecutar "desde el árbol de origen".

../lib/programnameo ../share/programname/, en relación con el dirname(3)de argv[0], dependiendo de si los activos dependen de la arquitectura o no.

Este es el mismo estándar que todos los demás programas Linux (y la mayoría de los programas que no son Mac Unix).

Si desea ejecutar desde "el árbol de origen",

1. Debe obtener un sistema de compilación real y hacer una compilación, porque nunca "ejecuta desde el árbol de origen", ejecuta un ejecutable compilado, que su sistema de compilación escupe en algún lugar, y puede copiar o vincular activos en su lugar con la misma facilidad.
2. Si su sistema de compilación es demasiado malo, simplemente verifique .o ./assets, etc., y luego busque un nuevo sistema de compilación más adelante en el desarrollo.

A diferencia de lo que dice happy_emi, definitivamente debe proporcionar una forma de anular esto con variables de entorno. Es exactamente para lo que están destinados.