8

Unreal Engine and other engines support making games for multiple platforms like iOS, Android, Windows, MacOS and Linux. The games are distributed as pre-compiled executables and they all need specific builds targeted to a particular OS.

With the number of different Linux distributions, do there need to be different builds for Ubuntu, Arch etc?

How can developers ensure that as many Linux distributions as possible are supported?

Improve this question
2
  • 1
    In Linux distributions, you mainly have the GNU C Library and the Kernel as the OS. Other than that, you have the general software library dependencies, and that's all. Now some distros use the musl C Library (Alpine, Void Linux musl Edition, Gentoo musl Edition, etc.) - and they won't run binaries linked to the GNU C Library. Because of that, it is best for you to ship in a Sandbox format like Flatpak that would support all distros. Prefer Flatpaks to AppImages because they won't package the C Library, and to Snap, because it is a centralized solution that only works on distros with systemd. Commented Apr 22 at 21:25
  • systemd is the "Init System", and it's a hard dependency for the Snapcraft package system. AppImages are like the standalone executables, while Flatpaks (and Snaps) are the equivalent of the App Store or Microsoft Store on GNU/Linux distributions. Commented Apr 22 at 21:27

2 Answers 2

Reset to default
16

Your best option is to either:

  1. compile your games so that all libraries used (or as many as possible/practical) are statically linked - this will make the games mostly-independent of the library versions of the particular distro it is being run on (although other factors like desktop environment or X vs Wayland may still be a source of problems).

  2. compile your games to run in a specific environment. Mostly, this means steam and steamos. The steam linux runtime provides a known environment with known versions of libraries. IIRC, steam runtime is Ubuntu-based but I am not 100% sure about that - so check the developer documentation. The steamdeck is, IIRC, Arch-based. Of course, this is only really useful if you intend to distribute your game via steam.

BTW, library versions are one of the reasons why linux-native games can be short-lived unless the developer/publisher re-compiles them every so often to keep up with changes. Most of the big publishers don't bother, so many linux-native games end up breaking after a few years and players settle for running the windows version in proton or some other version of wine.

Improve this answer
4
  • 3
    Another issue is an everchanging mess in desktop environments, with no corporate funded backward compatibility, which can screw up anything done in "desktop". For example: XCOM EW/EU has native Linux port, but silly little change in Gnome default layout few years ago caused it to crash when displaying splashscreen (something about window position calculations). Commented Apr 20 at 21:23
  • 1
    the issue was caused by Ubuntu/Gnome (so the most popular combo) adding Mac-style status bar on top of desktop, which broke decade old code assuming accessible screen space starts at Y=0. Players "solved" it by deleting splashscreen image, but being stubborn bastard I found config flag which "fixed" it steamcommunity.com/app/200510/discussions/0/3112543466384647896 So its no wonder it works under more traditional desktops. As long as it gets into (exclusive?) fullscreen it will do fine. Commented Apr 21 at 16:14
  • 2
    An alternative to statically linking libraries is using the AppImage format, which allows packing shared libraries (and also data, which means it's just a single file for your users to download and run) with your executable. It is already used in the wild for game distribution, e.g. by World of Goo 2's standalone release. Commented Apr 21 at 16:30
  • 1
    @val-disappointedinSE AppImages don't help games run on musl distros. Flatpaks are better in that case. Commented Apr 22 at 21:28
8

What you are asking is an issue of packaging specifically. There are, broadly speaking, four approaches you can use:

  • Build for Windows but do proper testing under Proton/Wine. This is often the ‘easy’ solution for multiple reasons and it’s how most games that claim Steam deck support actually do it, but it provides the poorest integration and it’s only realistic for games (normal Linux users are not willing to deal with this for most other things for multiple reasons).
  • Build for a distribution (in the sense of distributing software, not the sense of a collection of software) platform like Steam or Flatpak. This is generally the best option in terms of being truly native but actually portable, but it requires you actively deciding on a development environment ahead of time (because retrofitting a game like to work like this is not exactly easy).
  • Take a Windows or macOS style approach, and ship all or most of your dependencies with the game itself. Linux, like other UNIX-like platforms, provides plenty of options for this, with the two easy ones being static linking or using custom library search paths. However, this makes the game itself much bigger, because you’re shipping a large amount of extra code with it.
  • If the game isn’t commercial, just make it FOSS and work with the distros to package it natively. Once you get working packages into Debian, Fedora, and Arch a majority of other distros will usually pick things up without you have to do much else, and this offloads most (but not all) of the distro-specific packaging overhead so you don’t have to deal with it. This requires a lot of up-front time investment though, as well as obviously not working for commercial games.

There is also, obviously, the option of doing per-distro builds (for the record, covering Debian, Fedora, and Arch will get you usability for a majority of desktop Linux users, because a vast majority of all desktop Linux usage is either via one of those three distros or via a derivative of one of those three distros). It’s a major time investment though, and also needs to be a recurring commitment to keep the game playable as time marches on.

Improve this answer
3
  • 1
    I'd suggest trying to install under Steam(Linux) and Heroic launcher and maybe Lutris(which I've always found a pain) is probably the most important bit as this is how most Linux users will approach installing a game and running a game like this, and it's the bit that causes the most frustration in my experience. Commented Apr 20 at 22:35
  • How does Cura do it? file says that the binary is UltiMaker-Cura-5.9.0-linux-X64.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=30e06184968532b6a9aa36f44ada39e4af0bda56, for GNU/Linux 2.6.32, stripped which looks like one (large) binary file but its dynamically linked Commented Apr 21 at 20:55
  • 3
    @Criggie They use an AppImage. It’s a SquashFS filesystem image containing the application and (some of) it’s dependencies, with an executable loader appended to the front kind of like how a self-extracting archive works. Running it runs the loader, which mounts the filesystem image and then runs the actual application inside it. Conceptually, this is a case of option 3 in the list in my answer. Commented Apr 21 at 21:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.