Windows is a single platform, and there are at most three versions anyone has to worry about if they make a game for Windows. Most of the time the same code works on Windows 98SE, Windows 2000, and Windows XP. Or at least I would think. Mac OS X. One platform for all intents and purposes. Gnu/Linux: Debian, Red Hat, Gentoo, Slackware, and any number of distributions exist, and it isn't too uncommon for developers to complain that what works on Debian doesn't work on Red Hat, and vice versa. There are slight differences in file structures and configurations and who knows what else that cause game development to be a complicated affair. Essentially it is a problem with support: if you can't just tell someone the equivalent of "go download the latest DirectX", what can you do? So I would imagine that companies might give this reason for why they don't want to support Gnu/Linux game development. That all said, perhaps there should be a repository of common problems, fixes, and workarounds for game development on a platform that has multiple implementations? If such a thing were to become popular, a Wiki would be incredibly useful, but until then, we can post some issues here. For instance, I know that the old version of Kyra Sprite Engine didn't build from source and work without extra work and configuration on Debian Sarge, but it supposedly worked just fine on Red Hat.

The easiest way around this (for an non-open source) game/app is to do what most commercial games/apps have done: install everything into one directory, create some startup script/symlink into /usr/local/bin and include fallbacks for shared libraries like libSDL in your program's main directory.

The community is also very helpful in producing distro-specific packages and/or install scripts (ebuilds) if the licence permits this.

Many companies officially support only a handful (if any) of the most common distros. Usually these are Red Hat/Fedora, SUSE and Mandrake -- the ones that "newbies" frequently use. The majority of Linux users don't need official support if the program can be installed manually or via a script and doesn't rely on any hardcoded paths.

To sum it up: if you provide everything needed to run the program (save for maybe the C/C++ standard libraries) in a tar.gz package for as many CPU types as you can support then your program is automatically compatible with all distros.
Installers that make obscure assumptions about the underlying system can stay in the Windows world. Install scripts and GUI installers are fine as long as they are optional or at least easily reverse-engineerable.

An important point is that all Linux distros use the same linkage format (ELF) and also the same system call API (for whatever glue gets linked in). This means that the difference between the distros, to an application, comes down to file paths, rather than the binary execution environment. Thus, binary distribution of applications isn't all that much harder for Linux than it is for Windows. Do you support Windows 98? Do you require DirectX 9.0c? Sounds similar, doesn't it?

Quote: Original post by GBGames
For instance, I know that the old version of Kyra Sprite Engine didn't build from source and work without extra work and configuration on Debian Sarge, but it supposedly worked just fine on Red Hat.

Are you talking about cross-compiling or binary-distribution?
Try UT200x demo on both and see if it runs at once.

You can use the *-config programs to infer correct paths to many things. KDE's core API also includes classes that can tell you the correct paths to everything in KDE and handle loading of shared resources for you.

If the license allows, statically link with everything and you are fine :)
Of course, may licenses such as GPL and LGPL will not allow closed source programs to statically link with them.

The largest problem I see with open source game development for GNU/Linux, is when having users build the game for themselves. Linux-lore generally states that applications should use as many shared libraries as possible, and including source code (or object files) of external libraries with your game source tar-ball is generally seen as a very bad thing to do. The problem comes from the fact that the more shared libraries that are linked against, the more problems the users will have compiling.

An example from the game I'm working on:

In earlier versions of the game I included (among other) the source code for Lua5.0 and ODE in my tar-ball. It worked fine for everybody, but it almost got me lynched by a mad mob of Linux zealots :) Apparently that is very bad because important updates to these libraries wouldn't be integrated with my game. Fine, I changed the code to use the shared libraries instead. And now there's a lot more people having problems configuring and compiling: For instance Lua5.0 is called liblua50.so on Debian, but it's just called liblua.so on Gentoo. The header files are also placed at three different locations. The same goes for ODE.

The result: 95% of all bug reports for my game is about the build procedure, and I have to use a lot of time to create an increasingly complex configure script, instead of working on the actual game code. That's pretty annoying.

What I'm trying to say is, that it would be nice if the structure of these Linux distros was a bit more standardized - i.e. when it comes to the location and naming of libraries and such.

Quote: Original post by BBB
*nix needs some form of open super-api for stuff like this.
I have a few ideas but don't think anyone would listen.

...ok.

So if you happen to have good ideas, no one will know them. How is that any better?

kadaf: Thanks for that info. Basically, if you do it the "correct" way, you get a lot of people upset because it doesn't easily configure, but if you do it the convenient way, you need to break with tradition, which upsets a lot of people?

Has anyone tried using something like checkinstall to create RPMs and .debs and other packages? I found that when I installed the older version of the Kyra Sprite Engine using it instead of simply typing "make install" that it seemed to work out of the box. I guess the Debian package manager does extra things that a manual install wouldn't do.

Quote: Original post by owl

Quote: Original post by GBGames
For instance, I know that the old version of Kyra Sprite Engine didn't build from source and work without extra work and configuration on Debian Sarge, but it supposedly worked just fine on Red Hat.

Are you talking about cross-compiling or binary-distribution?
Try UT200x demo on both and see if it runs at once.

Well distribution would be the tougher part, I would think. It seems to be one of the bigger complaints people have when it comes to distributing games on the Gnu/Linux platform.