Ok, so now you've built a game executable that can run on any distribution, and you've created an installer to deliver your game. How do you test it? What are some of the pitfalls and issues to watch out for?


Testing on Multiple Distributions
As we've already seen, there are literally hundreds of Linux distributions, and each distribution is different. They all use different versions of the Linux kernel, different desktop environments, different system configurations, different directory structures, and on and on it goes. So how do you test your game in such a diversified environment?

That's simple. You don't.

Let me explain. There are so many distributions that you can't possibly hope to test them all. Moreover, many distributions tend to release significant version upgrades 2-3 times per year. You can't keep up with them. So don't try.

Here's what someone recommended to me, and I've found great wisdom in it. Part of what makes Linux so great is the community of users. It is literally an army of collaborative volunteers that love their operating system. Use that to your advantage. Recruit some beta testers that use other distributions than you. Linux users are hungry for new games, so you probably won't have any trouble finding volunteers. Of course, part of the whole "community" concept is that you give something back in return. Opening your source code is one way to give back, but there are others. You can donate some time or resources to open source games, either by testing or helping improve their code. You can make monetary donations to those who maintain core game libraries like SDL. You can write articles like these to share what you learn and help other developers get started.

The best thing you, as the developer, can do is make sure your game doesn't depend on any distribution-specific stuff, try to conform to standards like the LSB, and make your program as compatible as possible. Then test the game yourself on a few of the more popular distributions, like Red Hat (Fedora), SUSE (OpenSUSE), Linspire (Freespire), Ubuntu, or Debian. At that point, let your beta testers take over and do the rest for you. If there's a problem, you'll find out about it quick enough, and then you can address it. This strategy worked for my friend who told me about it, and it seems to be working for me too.

Once you've released your first Linux game, you'll know what you need to do to ensure compatibility in your future games. And you probably won't encounter too many distribution-specific problems after that.

Here are a few issues that I encountered that you will want to watch out for.


Hardware Accelerated Video Drivers
For OpenGL-based Linux games, the end user will need to have a video card that supports OpenGL and have the 3D accelerated driver installed for it. Both NVidia and ATI provide accelerated drivers for Linux, and you can usually install them through the package manager of your Linux distribution.

One of the things I quickly discovered is that performance is not as good on a laptop as a desktop machine. You probably knew that already, but I didn't. My laptop happens to be quite a powerhouse, so I never noticed any performance issues with it. But a number of laptop users had problems with Dirk Dashing. The lesson I learned was that I should have provided a fallback mechanism to allow users on older laptops and slower machines to disable the OpenGL and use SDL rendering instead.

Another thing I discovered was that sometimes the default installation settings for the accelerated drivers will do weird things to your game performance. Different distributions use different default settings, so your game performance will vary depending on whether the system is set to sync with the vertical retrace, or whether anti-aliasing or other high-performance OpenGL settings are enabled by default.

In my case, I have a computer system with swappable hard drives. I set up one drive with SUSE 10, which I used to develop Dirk Dashing, and the game ran great. I then installed another distribution on a different hard drive, put the game on it, and the game performance was horrible. I couldn't figure out why - it was the exact same machine, just running a different Linux distribution on a different hard drive. After cruising Google for a while, I found a way to check the OpenGL settings of the graphics card, and I discovered that the default settings on the two distributions were different.

The problem is that the Control Panel and System Settings windows provided by most distributions do not provide you with a way to control these settings. You can usually control the resolution and the monitor refresh rate, but that's about it. Fortunately, both NVidia and ATI provide utilities to help.

NVidia provides a handy configuration utility called nvidia-settings, which is usually installed along with the driver. A few distributions give you a menu entry for this utility, but most do not, so it has to be started from the command line. It brings up a professional-looking window that lets you change all kinds of settings.

ATI provides a similar utility called aticonfig, which is also installed along with the driver. I've never used this tool, because all of my video cards are NVidia cards, but from what I've read, I believe aticonfig is a command-line tool only.

I'm not sure how many Linux users know about these utilities, so if performance seems to be an issue with your OpenGL game, the first thing you should do is point them to these utilities.


SELinux
Some of the newer distributions, particularly Fedora Core 5 and above, come with SELinux turned on by default. SELinux stands for Security Enhanced Linux, developed by the NSA, which provides a set of Linux Security Modules in the Linux kernel that controls programmatic access to the major subsystems in the kernel. The idea behind SELinux is to address and contain the damage that could be caused by malicious or flawed applications.

The problem with SELinux is that when it prevents a game from running, the error messages are usually misleading and give no clue as to the real cause or solution of the problem. For example, this is one of the more common errors that you might see:

./game: error while loading shared libraries: libgame.so: cannot restore segment prot after reloc: Permission denied The real problem here is that libgame.so has TEXTRELs, which means the dynamic linker manually relocates it. Apparently, this is not allowed in some SELinux policies. One workaround is to have your testers (and eventually your end users) run the following commands on their SELinux-enabled system after installing your game:

cd /path/to/game sudo chcon -t texrel_shlib_t libgame.so This changes the security permissions for libgame.so to allow TEXTRELs. Of course, this doesn't actually solve the TEXTREL problem itself, which typically requires quite an effort to track down the offending code and fix. This web site gives detailed instructions about how to find and fix TEXTRELs: http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml.
64-Bit Linux
Most developers will probably produce a 32-bit version of their game, and most of the installer builders listed in the previous article will produce a 32-bit installer. This is great for people using 32-bit Linux distributions.

But unless you produce a 64-bit version of your game, here is something you need to watch out for on 64-bit systems. The 64-bit versions of some Linux distributions like Ubuntu do not come with the 32-bit libraries installed by default, which are required in order to run 32-bit programs. If you or a tester is using a 64-bit Linux distribution and the installer and/or game will not run, then you should make sure the 32-bit libraries are installed. For Ubuntu, this means installing the ia32-libs package.


Summary
Hopefully, now you have a little better idea of how to conduct testing on Linux, and some of the potential problems to watch out for. These tips may also help you troubleshoot common problems that your Linux customers may experience.

In our last installment, we'll talk about how to market and distribute your commercial Linux game. Until next time!