Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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".

share|improve this question

2 Answers 2

up vote 4 down vote accepted

../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.

share|improve this answer

You should use MACROs.

With g++ you can use the -D option to give a macro a value. You can then use the DATADIR macro (for example) in your code to refer to a directory.

In the developing phase you can set DATADIR as "." because you have everything in one directory. At release time (i.e. while compiling the release version) you just set DATADIR as "/usr/share/mycoolgames" or whatever and you are done with it.

This is basically the same way used in a more standardized way by the GNU autotools (i.e. automake and autoconf). Actually the autotools generate a config.h file which contains the macro definitions (a file that you have to include in your own code) instead of passing a value to the g++ -D parameter but I think you got the picture now.

Try to resist the urge to use environment variables: they are just not very used for this purpose and also it's not a very elegant way to solve this problem.

share|improve this answer
    
-1, using such a scheme files cannot be moved even if the relative paths are maintained, for example on a system with several possible roots, or a mounted remote filesystem, or a detachable drive that mounts in different places on different systems. It also only works for languages with a macro system. –  user744 Aug 27 '11 at 22:25
    
Well yes, I assumed C++ which has a macro system because that's the language they are using. I'm not sure what do you mean by "files cannot be moved". They aren't supposed to be moved after the software is installed –  Emiliano Aug 27 '11 at 22:29
1  
Files get moved all the time on Unix without actually relinking them, like by using different mount points. Also, it's nice if people can move them, or stage them during building an rpm/deb, etc. Compile-time absolute paths are a terrible idea. –  user744 Aug 28 '11 at 14:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.