This feels like a pretty silly issue to be having :s I wrote a Tetris clone in C++ with SDL, which uses a few .png and .ogg files, but it seems that these won't load unless I run the program from that directory -- i.e. if I make a symlink the current working directory is not that pointed to by the symlink but rather wherever I'm running the symlink from (my /home directory). I've managed to get around this by manually setting the current working directory in the code before the main loop starts with chdir(), but this seems like a really ugly way to go about it (By contrast, if I build the game on Windows in its own folder and create a shortcut to it on the desktop, everything works fine)

A symlink is not a shortcut! Windows does not have something that is equivalent to a symlink.

Shortcuts on Linux are .desktop files. See the Desktop Entry Specification. I don't know about MacOSX but they probably have something similar.

Okay, it seems I was dead wrong about symlinks :o
I've looked into .desktop files but it seems those are only used if I'm using GNOME or KDE -- I'm using xmonad
I suppose what I'm looking for is maybe something to put in my $PATH, that I may run the program from the commandline or from dmenu without having to navigate to the right directory

You should really look into the Filesystem Hierarchy Standard and into build systems like (auto)make. That is the technically correct way to solve your problem.

The build system will install all your files to the correct location and make sure all the paths in your source code are correct so that everything works. Basically you use path placeholders in your source code. So instead of load_image("image.png") you use something like load_image(IMAGE_DIR"image.png"). The build system will install your binary to /usr/bin, the graphics and sounds to /usr/share/yourgame and update the IMAGE_DIR and other path constants in the source code. This is what the "./configure" step in the canonical "configure && make && make install" does. It determines the proper paths and install locations and updates the source code.

This is what most Linux software uses and is the proper way to do it. It can even be made to work on Windows. But (auto)make can get pretty complicated. It also means that people will need to compile and install the game themselves.

An alternative way that some people use is very similar to what you are doing now. They put everything in the same directory and use chdir() to change the current working directory when the program starts. The only tricky thing is that you need to find what directory to change to. You don't want to hard-code a path in there :-) Have a look at this StackOverflow question. It tells you how to find the full path to the running executable from the inside (on Windows and Linux). Find that path, then use chdir() to change to that directory.

The advantage of the second method is that people can put the entire game anywhere they want, such as in /home/someone/thegame or in /opt/tetris-clone or whatever. The downside is that they will manually need to create a symlink from /usr/bin to the game or manually need to add the game directory to the PATH.

What method you choose is entirely up to you. My suggestion is that you use method #1 if you distribute the source of your game, i.e. it's open source. The (auto)make system has a very steep learning curve but it's worth it. Use method #2 if you only distribute the binary of your game.

If you are really adventurous you could even combine the two methods. Set it up in such a way that the executable will chdir() to the directory that contains the images and audio, where that directory is the same directory as the executable by default, but which can be overridden by the configure script. That way you can offer the source code for people to install and it will work like they expect (binaries in /usr/bin, the rest in /usr/share) but you can still create downloadable packages that people can simply unzip and run on their system.

Quote: Original post by Sander
This is what most Linux software uses and is the proper way to do it. It can even be made to work on Windows. But (auto)make can get pretty complicated. It also means that people will need to compile and install the game themselves.

That's an incredibly misleading statement. Whoever packages the game will have to compile it themself, but yer typical consumer just has to use the package manager provided with their OS to install a prebuilt binary package. That's the whole point of packaging. No modern Linux user needs to compile from source (but they can if they want to).

The method #1 that Sanders described is indeed how virtually everything works in Linux. Unfortunately, it is only sane to use this method for programs that are managed by the distribution's package manager.

I strongly recommend you use method #2 as primary means of working, because it'll make life easier for anybody who wants to develop the game (whether this is only yourself or not doesn't matter) and for anybody who wants to install the game simply by downloading a binary tarball (i.e. most normal users / customers unless your game is so damn popular that all distributions include it).

Then provide a reasonably simple way to override this decision so that distribution packagers can do what's right for their particular situation.

You might also want to look into PhysFS, in case you haven't heard of it yet.

Quote: Original post by Bregma
That's an incredibly misleading statement.

Not really. Getting the game into Linux distributions is another ballgame.

Quote: unless your game is so damn popular that all distributions include it

Popularity not required. If you built it, they will come. I wouldn't call my Hearts clone popular, yet you can find packages in Debian, Ubuntu, several other major distros and anything derived from it. All I did was build the Debian package myself (You don't have to be a Debian developer for that. You can get your package sponsored). Just contact the Debian/Ubuntu games team (it's one team packaging games for both distros).

Okay, thanks a lot, that's exactly what I needed :)
I think I'll wait until I write something a little less trivial than a Tetris clone before really getting into the first method, but I'll keep that in mind

Maybe this will help you. It basically reads /proc/self/exe or /proc/self/maps to find the program location, but might be of use nevertheless.