Finding asset files in Linux games

Question

What is the usual method of storing 3D models, textures, sounds and scripts (e.g. Lua files) during development and in a release? I am developing a game with my friends in mainly C++; in the prototyping phase we only had a single texture that was saved as a C header with the GIMP, but of course, this approach does not scale well and increases compilation times greatly.

Under Windows, the usual practice is to just dump them to the %PROGRAMFILES% subdirectory in which the game executable resides, perhaps arranging them in an appropriate tree structure. However, on Linux the picture seems a lot more complicated. The executable usually resides in /usr/bin, whereas applications store their other files in /usr/share, and I think it would be an extremely bad practice to put non-executables in /usr/bin. However, the directory structure during development is totally different.

I could come up with two different possible solutions:

• Let the executable find the asset files relative to itself, and install the game to /opt. Then place symlinks to /usr/bin. During development, the relative path of the assets to the binaries is the same as during deployment.
• Access the files with an absolute path which is defined as a preprocessor symbol. Let the build process (in our case, raw Makefiles) take care of defining it as it is fit.

Both approaches seem somewhat inelegant to me in one aspect or another. Is there a common practice in the game development industry about this?

The only relevant questions I could find were Determining the location of installed/on disk game assets and Directory paths for resources and assets, but those did not address the problem of running "from the source tree".

Answer 1

../lib/programname or ../share/programname/, relative to the dirname(3) of argv[0], depending on if the assets are architecture-dependent or not.

This is the same standard as all other Linux (and most non-Mac Unix) programs.

If you want to run from "the source tree",

1. You should get a real build system and do a build, because you never "run from the source tree", you run a built executable, which your build system spit out somewhere, and it can copy or link assets into place just as easily.
2. If your build system is too crappy, just also check . or ./assets, etc., and then look into a new build system later in development.

Unlike happy_emi says, you should definitely provide a way to override this with environment variables. It is exactly what they are intended for.