• DmitryMarakasov
• Games

Games on FreeBSD

Not long ago, number of ports under games/ category has passed over 1000. Thus, at least in terms of supported entertainment applications, FreeBSD goes on par with most popular Linux distros, and even overcomes some of them. Of course, there's still much room for improvement to which this page is dedicated.

Numbers

These are just numbers of items available under games/ category for different port/package systems.

Note, that these values may considerably differ from real quantity of games available due to many reasons (splitting data into separate package or not, availability of engines and various game-related libs under games/ or under other category, etc. For example, Debian has bunch of campaign packages for wesnoth, image packages for pysycache and language packages for gcompris, while FreeBSD has Perl/Python/PHP modules under games/ and various Quake 1/2/3 mods).

Numbers as of September 29, 2009

Problems

The most basic thing that we want to support are opensource games written for POSIX systems (Linux, that is, in most cases). Unfortunately, there are reasons why some of those games are not available for FreeBSD (yet):

Games using low-level Linux-only APIs

• ALSA

• Advanced Linux Sound Architecture (known by the acronym ALSA) is a Linux kernel component intended to replace the original Open Sound System (OSS) for providing device drivers for sound cards. Obviously, it's only available on Linux, so using it ties your product to this OS.

• Software affected: stormbaancoureur (runs without sound as of now).

• Linux generic input layer

• Linux has nice generic input layer (aka linux/input.h) that handles all input devices such as mice, keyboards and joysticks. It has large enough collection of drivers and supports many features including force feedback. Unfortunately, it's only available on Linux.
• Software affected: word war vi (since 0.19 or 0.20), OIS (doesn't support joysticks on FreeBSD for now).

Games using proprietary libraries free for non-commercial use

• FMOD Ex

• 'The FMOD Ex sound system is a revolutionary new audio engine for game developers, multimedia developers, sound designers, musicians and audio engineers. Based on the years of experience from Firelight Technologies’ previous products, FMOD Ex aims to push the capabilities of audio for games, whilst at the same time using minimal resources and remaining fully scalable.'
• FMOD Ex is available for Windows 32/64 bit, Linux 32/64 bit, Macintosh, Solaris ( ! ) and popular game consoles.
• Software affected: toycars (stuck at the last version which used OpenAL), TA3D

• Newton Game Dynamics

• 'Newton Game Dynamics is an integrated solution for real time simulation of physics environments. The API provides scene management, collision detection, dynamic behavior and yet it is small, fast, stable and easy to use.'
• Available for Win32, Linux and MAC.

• nVidia Cg Tookit

• This is usually required through Ogre3d cg_programmanager plugin, which is in turn unavailable on FreeBSD as it requires .so library from the toolkit, which is not available on FreeBSD.

• Software affected: rigs of rods (cannot use PagedGeometry to render vegetation), dungeon hack (same thing).

• Available for Win32, Linux, MAC and Solaris.

Those problems can be solved from both sides. Games written with portability in mind should not use OS-specific or non-portable APIs. Sometimes this can't be helped, as those APIs are really powerful and bring to much possibilities for programmers, so another way is to encourage commercial developers to port their software to FreeBSD and to implement Linux-compatible APIs for FreeBSD.

Games using copyrighted media

On August 20, 2008 the following ports were removed from FreeBSD ports collection: games/blobwars, games/blobandconquer, games/randomshooter, games/starfighter, games/viruskiller. Those are all games by Parallel Realities. The story is quite sad: not long after Blob Wars episode 2: Blob And Conquer version 1.0 was finally released it turned out that all the games by PR contain copyrighted material ripped from commercial games, so we had to remove ports to avoid potential legal issues (ports/packages were removed from popular Linux distros and other BSD systems as well).

To avoid such issues new ports (and existing ones) should be carefully checked. That's not an easy task.

Binary only Linux games

There are many closed source (both free and commercial) Linux games that will run well on FreeBSD with it's (recently improved to support Linux 2.6) Linux emulation layer, but some of those games require too many linux libraries not available in FreeBSD ports collection yet. That's huge task (for example, free Rigs of Rods game requires Ogre3D, DevIL and lua libs, Phun requires Boost and GLEW) and brings up thoughts of a need to automate process somehow. I can think of some ideas from Ports/ToDo, such as Abstract Ports.

Porting tips

data ports

See vegastrike-data for example (includes automatic plist generation).

/var/games stuff

Some games use shared directory to store e.g. highscores systemwide (TODO: add examples for Makefile/plist/pkg-install).

creating ~/.dotdir

Some games are not suited for systemwide installation, i.e. they tend to store highscores/savegames and other dynamically changed files in current dir. There's two ways to handle those.

• If the game creates files (default config, savehames, highscores) in the current directory, but doesn't require those files to exist on the first run, the following code may be used:

• +#include <unistd.h>
  +#include <err.h>
  +#include <sys/stat.h>
  
  ...
  
   int main(int argc, char **argv)
   {
  +       {
  +               if (chdir(getenv("HOME")) != 0)
  +                       err(1, "cannot cd to $HOME");
  +               if (mkdir(".nameofthegame", 0755) != 0 && errno != EEXIST)
  +                       err(1, "cannot mkdir $HOME/.nameofthegame");
  +               if (chdir(".nameofthegame") != 0)
  +                       err(1, "cannot cd to $HOME/.nameofthegame");
  +       }

• Thus, dotdir will be created and all game's files stored there. Sometimes easier thing is sufficient - for example changing config file name from 'std::string("config.txt")' to 'std::string(getenv(HOME)) + "/.nameofthegame.cfg"'

• Examples: biniax2, blackshadeselite (single config file), f1spirit-remake (also creating subdirs under dotdir), formido (simple one), freera (another simple one), meritous, reminiscence, solarconquest, stransball2 (as f1spirit-remake), untahris.

• If the game needs some files to exist in it's dotdir on the first run, you can create a wrapper script that does basically the same as the patch above + copying required files.
  • Create ~/.${PORTNAME} if it doesn't exist and chdir into it
  • Copy all required files from ${DATADIR}
  • exec real binary (usually installed as ${PREFIX}/bin/${PORTNAME}.bin or into ${PREFIX}/libexec)

• Examples: sauerbraten.

Misc stuff

• Ports/NewCategories

• TODO: assign a genre to each port under games/. That'll help to split it into multiple categories.