• Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter. Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running! Categories (See All) Like 0Likes Dislike Linux Game Development Part 3 By Troy Hepfner | Published Aug 10 2007 10:55 PM in Game Programming installer game install linux system bitrock menu loki setup  If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource Welcome back! So far, we’ve learned about the tools available for Linux development and how to build a binary executable that will run on any distribution. Now we need an installer for our game. The need for a distribution-independent installer on Linux is important. Last time, I discussed why I believe you should not use a distribution-specific package manager, but it is worth repeating here. Essentially, you would have to provide a distribution-dependent package like rpm or deb to deliver your game, and allow the distribution’s package manager to resolve the library dependencies for you. While this sounds good in theory, in practice this can be a nightmare for both the developer and the end user. From the end user’s standpoint, it can be a very frustrating experience trying to find and install all of the dependent packages that the package manager says it needs – some package managers do this for you automatically, but some don’t. And when it doesn’t work, some users (particularly those new to Linux) will not know how to solve this problem. This is not the first impression you want a potential customer to have with your game. From the developer standpoint, you would have to provide not only a package for every distribution that you want to support but also a package for every version of that distribution you want to support. New versions can be released several times a year. Plus there are so many distributions (and every one is different) that you can’t possibly support them all in this manner. It would be a full-time job. And if you choose to support only a handful of the more popular distributions, you will effectively shut out many potential customers who use other distributions. So delivering your game with a distribution-specific package manager is not an ideal commercial solution (unless you open your source code and let volunteers do the work for you). But there are a growing number of distribution-independent installers to choose from. Here is the current set of options (as of mid-2007): Loki Setup Loki Setup is a free installer program built primarily for games, and it runs on just about any UNIX-like platform. I’ve never used it, but I’ve been told it works fairly well for what it does, though it does require some fiddling to get it working. In the past, it has been the installer of choice for games on Linux. The problem is that it is rather outdated, and nobody is maintaining it anymore. For example, one of the issues with Loki Setup is the way it installs menu entries. When Loki original made Loki Setup, every Linux distribution had its own menu system. Loki Setup would put the menu entries in several places and then do some tweaking based on the specific desktop environment that was present. Obviously, this meant that Loki Setup would only work with a limited set of desktop environments, and users with less common environments would not have any menu entries. Nowadays, this method is obsolete because more and more distributions are becoming LSB-compliant. LSB stands for the Linux Standard Base, which defines a set of specifications for interoperability between distributions. The specifications dictate how and where menu entries should be installed on a compliant system. These specifications did not exist when Loki Setup was originally written, so on many LSB-compliant distributions it no longer works right. Loki Setup could be fixed, of course, if someone would start maintaining it. But nobody has stepped forward to do so, which makes it hard to recommend using Loki Setup as an installer anymore, despite some of the good features it had built into it. MojoSetup (Son of Loki Setup) Ryan Gordon and the folks at icculus.org investigated the possibility of upgrading Loki Setup, and decided instead that is was too outdated. So they began building a brand new installer from scratch to replace Loki Setup. The new installer is called MojoSetup. While it looks promising, it is not yet ready for prime-time use (at least not at the time of this writing). The user interface is very rough, there are bugs, and not all of the planned features are available yet. But it may become a viable option in the future. Illwinter Game Installer Illwinter Game Design made its own installer, the Illwinter Game Installer. This installer is free, but it is pretty basic. It doesn’t provide many options; it just installs the game. It does add menu entries, but since the installer was last updated in 2004, I suspect it probably uses the same outdated method that Loki Setup uses. Autopackage Autopackage is designed to be a replacement for rpm, deb, and other distribution-specific package systems. Autopackage builds a binary package that will run on any distribution and will automatically resolve dependencies. It looks great, but it has its own share of problems. First, it does not provide a way to display a README or EULA during install, nor does it provide any install options. Second, installing requires Internet access because the binary package files don’t actually contain the installer itself - they only contain a stub that downloads the installer if it’s not already on the system. Zero Install Like Autopackage, Zero Install was designed to be a replacement for rpm, deb, and other distribution-specific package systems. It has some of the same problems Autopackage has, like the inability to display a README or EULA during install. The other big drawback with Zero Install is that it provides no mechanism for installing as root, which means each user on the system has to install his or her own copy of the game. InstallJammer Formerly known as InstallBase, InstallJammer is a free, open source, multi-platform installer that currently supports Windows and most versions of UNIX. It claims to be highly configurable, with support for multiple themes. I know of two commercial games that use this installer: “Lunar Domination” by Valen Games, and “Runes of Avalon” by Anawiki. For a free installer, it does a pretty decent job. Both developers for these games told me they were quite satisfied with InstallJammer. I’m told there is excellent documentation for it, though it does require some tweaking to get it to work properly. Also it has a few bugs, like when you try to create a new directory to install the game in, you MUST press Enter when you’re done typing the directory name or it doesn’t actually create the directory. Hopefully these bugs will be fixed before long. Bitrock InstallBuilder If you want a professional installer for your commercial Linux applications, then Bitrock is the way to go. I used Bitrock as the installer for Dirk Dashing, and I’m very happy with it. I understand Garage Games also uses it. Bitrock is cross-platform, and it provides a nice, easy-to-use installer that looks the same on all platforms. This is a major benefit on Linux, especially for the growing number of Windows users who are migrating to Linux. The Bitrock installer provides a familiar install experience for them. Bitrock is highly configurable, though most of the more advanced options are not currently available through the user interface. On the positive side, the installer project file is an XML file, and the file format is well documented. The Bitrock customer support staff is also very friendly, and when I had to tweak the XML, they answered all of my questions and even provided some examples. I tweaked the XML, for instance, to auto-generate our game’s startup script using the install path provided by the user. The main downside of choosing Bitrock is the price, and I noticed they have raised the price since I originally purchased it. You can download a trial version of it for evaluation purposes, but if you decide to use it, you’ll have to pay for a commercial license. However, Bitrock is still much cheaper than our final option, which is… InstallAnywhere This is the top-of-the-line, professional multi-platform installer. It is powerful and has a lot of advanced features. It’s also insanely expensive. Plus, it is based on Java, so there is a lot of overhead associated with running it. That’s about it for installers. There are some Java-based multi-platform installers for Java applications, such as JInstaller and install4j, but they probably don’t support C/C++ programs. And there’s Klik, a non-installer that is actually a mechanism for downloading and running software without installing it. But Klik has some issues that make it undesirable for distributing commercial software. First, it is currently regarded as “usable alpha” quality (according to the Klik wiki), so I would be hesitant to trust it with my game distribution. Second, it is designed for use with live CD systems, for beta testing new versions of software without affecting your production software, and for other cases where installation is not desired or doesn’t make sense (also according to the Klik wiki – look under the FAQs). Third, users first have to install the Klik client itself (if they don’t already have it) before they can install your game – I personally don’t like to make potential customers jump through extra hoops to install a program. Fourth, Klik delivers applications as a single compressed .cmg file, which must be decompressed each time the program is run – for games (especially those with lots of assets), this can mean slow start-up times. And fifth, like Zero Install, Klik doesn’t appear to provide any mechanism for installing as root, which means each user on the system has to install his or her own copy of the game. For these reasons, I did not list Klik with the other installers because I do not consider it a viable option for distributing commercial games. Additional Hints Depending on which installer you choose, it may or may not provide all of the features that you need. So here are some miscellaneous tidbits to help make up for any deficiencies in the installer system you choose. Where to Install Some of the installers are LSB-compliant, but others are not. You should ensure that your game is installed into the correct place according to the LSB. The LSB directory standards for installation can be found here. Startup Script Remember the script for launching your game that I presented in the last article? The paths in that example script were hard-coded for my specific development environment. As a result, that script would probably not work on anyone else’s computer. When you choose an installer, you’ll want to pick one that will allow you to auto-generate a startup script for your game. You want the script to point to the install path provided by the user. With Bitrock, you can do this via the “addTextToFile” tag in the XML project file, and by using the${installdir} variable. I
know InstallJammer provides a way to do this too, but I am not familiar with the specifics.

At the time this article was written, Bitrock did not provide a way to add menu entries to the system menu. I worked with their engineers to figure out a way to do it, and they are currently
adding this functionality to Bitrock. However, for the benefit of those who might choose other installers lacking this functionality, you need to use the XdgUtils tools. You can find these tools
here. The specific tool you are interested in is xdg-desktop-menu, which allows you to install submenus and menu entries into the system
menu of any LSB-compliant distribution. With Bitrock, I included the xdg-desktop-menu tool and the menu entry files in my installer, and I tweaked the XML to auto-generate a postinstall script that
would invoke xdg-desktop-menu to install my menu entry files on the user’s system. This same solution works for InstallJammer, and will probably work for other installers as well.

Command Line Access

Some Linux users prefer to use the command line, rather than desktop or menu shortcuts. Other users have Fluxbox or another window manager that is not LSB-compliant, which means they will not get
any desktop or menu shortcuts, so they will be forced to run your game from the command line. Therefore, it’s a good idea to put a symbolic link somewhere in the PATH. That way, people can
launch the game by typing its name (or more appropriately the name of the script that launches your game) without having to first cd to the game’s install directory. Bitrock provides an easy
way to do this via the “addDirectoryToPath” tag in the XML project file.

I’ve noticed that on some distributions, for whatever reason, the system will look for dynamic libraries that end in .so, and on others it looks for the specific version of the dynamic
library, like .so.0.8. I have no idea why this is, but when you include your custom libraries in your installer (which we talked about last time), you need to make sure the end user’s system
can find them, regardless of how you named them. To do that, your installer should create symbolic links to each of your custom libraries for all of the possible names that the system might use to
try and find them. If you look for the version of the library that comes with your distribution, and you go to the directory where it is installed (.e.g, /usr/lib), you can usually see the symbolic
links it created for the library. Then you just need to configure your installer to create similar links to your custom library in your install directory. Bitrock provides an easy way to do this via
the “createSymLink” tag in the XML project file. I believe InstallJammer can also do this, based on what I’ve seen with the two aforementioned commercial games that use it.

Miscellaneous Installation Topics

Where to write game data files

On a Linux system, you should write saved game files, configuration files, high score lists, etc. to the player’s home directory. You can determine the player’s home directory in your
C/C++ program by reading the HOME environment variable, like this:


char* home_dir = getenv(“HOME”);

if (home_dir != NULL)

{

// build the path to your game files

}



Your game or your installer can then create a subdirectory to contain all your data files. If you prepend a period on the front of your subdirectory name, you’ll make it a hidden directory
(e.g., /home/troy/.dirkdashing). I recommend doing this, so that you don’t clutter up the player’s home directory.

Install Instructions

Be sure to include instructions for installing and running your game on your web site’s download page. You’ll need to cover all of the different ways of running your program (via
desktop shortcut, system menu entries, command-line, etc), so that no matter what distribution your customers are using, they will find at least one way to run it. It’s a good idea to also
include these instructions in a README file that you install with your game, especially for command-line users who will need to know what to type to start the game. If you need an example, take a

Digital Rights Management (DRM) Solutions

There really aren’t any DRM solutions like ActiveMARK or Software Passport for Linux. There has not yet been a sufficient demand by commercial developers for a DRM system on Linux, so nobody
has developed one. Besides, even if a DRM system existed, I’m not sure how well the Linux community would receive it anyway. The concept of DRM really isn’t compatible with an operating
system that strives to be open so that users can do whatever they want with their system. On the other hand, Linux users tend to be much more respectful of software licenses than Windows users, so
DRM isn’t as big an issue, though that might change as the Linux user base continues to grow. The common practice for distributing commercial games on Linux is to distribute separate demo and
full versions.

Summary

Creating a Linux installer for your application will require a bit more work than you’re used to, particularly if you don’t use one of the professional installers. On the other hand,
not every shareware developer can afford a professional installer like InstallAnywhere or even Bitrock.

Regardless of which installer you choose, your goal is the same: to provide a professional, easy-to-use install experience for your end user. This is especially important for the growing number of
Windows users who are migrating to Linux. They are used to the plug-and-play install system on Windows, so you need to make the installation process as painless as possible, something that has not
been easy to provide on Linux until recently. Also, if you want your game to be available to everyone, then your installer needs to run on any distribution, so again I recommend you avoid using
distribution-dependent packages like rpm or deb to deliver your game.

For those that can afford it, I highly recommend Bitrock. It provides installers for Linux that look like Windows installers and are easy to use, and I have found it to be very configurable.
We’ve received a lot of compliments for our Dirk Dashing Linux installer, and I think that says a lot for Bitrock’s quality. Also, Garage Games is starting to use it (check out the
Kachinko demo). As I said earlier, it is very well supported and does a great job.

For those who can’t afford a professional installer, I recommend InstallJammer. I’ve never used it, but I know two developers who have used it and were satisfied with it. Like Bitrock,
it creates installers that look similar to Windows installers and the feature list is fairly comprehensive. The installer itself is easy to use and works fairly well, despite a few minor bugs.

Next time, we’ll talk about testing your Linux game and some of the issues you will encounter in the
diverse environments that Linux users have. See you then!