libregaming-website/content/game-launcher-concept.md

+++ title = "Libre Launchers" +++

Libre launchers

This document is a brainstorming around FLOSS games launchers. The rationale is:

• The gaming world has switched to centralized, non-free gaming platforms with auto-updates and social features
• FLOSS games usually lack discoverability, updates, and social features
• Existing launchers are very resource-heavy

Table of Contents

[ToC]

Ecosystem review

Existing projects

There's already quite a few projects in this field, so let's try to make a comparison table:

Client	Multi-platform	Social	Multirepo ⁽⁰⁾	Native UI	Compiled	Overlay	Translations	Runners ⁽¹⁾
Athenaeum	✅ MacOS, GNU	⚙️	❌ ⁽²⁾ Flathub	✅ Qt	❌	❌	✅	❌ ⁽²⁾
Lutris	❌	⚙️	✅ GoG, Steam, Humble Bundle	✅ Qt	❌	❌	✅	✅
GNOME Games	❌	❌	✅ Flatpak	✅ GTK	✅	❌	✅	❌
Gameshub	❌	❌	✅ Steam, GoG, Itch Humble Bundle	✅ GTK	✅	❌	✅	✅
AppImagePool	❌	❌	✅ AppImages	~ Flutter	❌	❌	❌	❌
Plei	? ⁽³⁾	❌	❌ ⁽⁴⁾ Steam, uPlay, Origin, Epic	✅ Tkinter	❌	❌	❌	✅
itch	✅ MacOS, GNU, Windows	❌	❌ Itch	❌ ElectronJS	❌	❌	✅	❌
retroarch	✅ MacOS, GNU, Windows	❌	❌	✅ Custom	✅	✅	✅	❌ ⁽⁵⁾
Spring	✅ MacOS, GNU, Windows	✅	❌ ⁽⁶⁾ SpringRTS	✅ wxwidgets	✅	?	✅	❌ ⁽⁶⁾
KODI	✅ MacOS, GNU, Windows	❌	?	✅ Custom⁽⁷⁾	✅	?	✅	?

⚙️ means the feature is planned but has not been implemented. Ideally, we'd have links to issues describing plans/ideas about said feature.

⁽⁰⁾ Multirepo means the launcher can download games from multiple sources, potentially with different protocols. ⁽¹⁾ Runners are different programs to run the games (eg. emulators) on the same platform. Games obtained on the same repository can leverage different runners. ⁽²⁾ Athenaeum technically has different repositories and runners, but only one per platform (flathub.org on free systems, homebrew on MacOS) ⁽³⁾ Plei runs on Windows, not sure about other platforms ⁽⁴⁾ Plei supports multiple repositories, but only non-free centralized stores (Origin/UPlay/Steam..) ⁽⁵⁾ Retroarch supports multiple runners, but there is currently no runner for native games ⁽⁶⁾ SpringLobby only supports games from the SpringRTS engine. ⁽⁷⁾ OpenGL based fullscreen app (windowed mode possible)

The following clients were not included in the comparison because there's a simple frontend for a single store (eg. Epic Store), but could be forked:

• Heroic launcher Epic Store client (ElectronJS)
• RARE launcher Epic store client (Qt5)
• Desura Friv store client (GTK2)

The following clients were not included because they're a simple frontend for a single game, but show that there is a demand for such an updater/launcher even in FOSS games:

• AirShipper updater for Veloren FLOSS game
• Unvanquish updater (TODO: find a screenshot)

Feature wishlist

In this section, we make a detailed wishlist for features an ideal libre games launcher should have.

Games setup

• Managing game repositories
• Listing available/installed games, with a filtering system for repos/runners
• Installing & updating the games
• Launching the games, tweaking CLI options

Social features (optional)

• Accounts
  • Offer hosted accounts?
  • Make it possible to bring-your-own account
  • Pseudo-nymous access without account if possible?
  • Offline accounts for LAN etc.
• Contacts
  • Adding/removing friends
  • Adding/removing friends to specific groups
• Joining games/servers
  • Seeing/joining games friends are advertising
  • Advertising the games you join, unless you're in private mode; optionally, allow to advertise games only to certain groups of contacts
  • Invitations to join a game
• Chatting
  • Private chatting with friends
  • Public, pseudonymous chatting per game or server (eg. SuperTuxKart chatroom, and/or a STK server chatroom)
  • Groupchats for teams?
• Audio-chat
  • P2P for small groups (WebRTC? Jingle? Jami?), server-backed for larger groups (Mumble? WebRTC with SFU?)
  • Can be for contact groups, 1-on-1 chats, or per-game/server chats
  • Different server backends should be easy to configure (Mumble/Jingle) and/or there should be an easy-to-setup bridge server-side so people who don't use a compatible launcher can join using a standard 3rd-party client

Game library

• Personal game library
  • Advertising which games you play ("own")
  • Opt-in achievements system (like Gamerzilla) ; see anti-features section about the attention economy and addiction
  • Developer feedback and bug tracking link
  • Donation link?
  • Matchmaking
  • Mods setup ; for games who already have an addon server, we could extract metadata from there and distribute proper packages Mumble (eg. flatpak/0install)
  • Per server/team text and/or audio chatting
• Public game library
  • Game highlights/curation
  • Game news: RSS from game homepage, proxied via repositories?
  • Popularity tracking (opt-in)
  • Searchable index with (user provided?) tags
  • User provided game reviews
    • More relevant for an app-store (i.e. risk of feature creep)
    • Spam, offensive content, review bombing, moderation workload
    • Negative reviews very demotivating for volunteer developers

Video streaming support

• Cross-platform instant replay integration? see ReplaySorcery for free systems
• UI to publish those instant replays after reviewing (once the game has ended)
• Integration with OBS to automatically start certain scenes and/or trigger transitions?
• P2P screen-sharing to friends (popular on Discord also helpful for setup etc.)
• In-home streaming between devices? Something like Moonlight integration

Alternative user interface

It would make sense to develop a backend-first games launcher, on top of which different UI frontends can be prototyped. Some features could be:

• a "media player" UI (like Steam Big Picture mode)
• an ingame opt-in overlay, triggered with a common keybinding, for social interactions, like MangoHud or Mumble but for social networking (like Steam social overlay triggered with Ctrl+Tab)
• Remote control via a web-interface or mobile app for updates and launching games?

Games integration

In addition to providing features for games from the outside, some games could integrate with free launchers using a specified free protocol:

• each game may have its own URI format for designating servers, but maybe the protocol is common (eg game:)
• bi-directional communication between the game and the launcher take place on a local socket or equivalent depnding on the platform; this socket may be advertised via an environment variable, and both programs must have permissions to read/write
• all interactions need to be further defined using ActivityStreams 2.0 JSON, XMPP XML stanzas, or Matrix JSON stanzas
• from the launcher to the game:
  • a private chat message has been received
  • user has been connected to a game/server groupchat
  • someone is talking with voice in groupchat
  • an invitation to join a game/server has been received
  • user is requesting to join a specific game/server
  • a friend invitation has been received
• from the game to the launcher:
  • user invited someone to friend list
  • user invited someone to join their game/server
  • user sent a message
  • user has joined a game/server
  • user made an achievement
  • user achieved a certain score (usually at the end of game, to opt-in collect stats about played games)

With a such protocol, it becomes possible (in addition to switching windows and/or an overlay UI) to have games integrate social interactions directly within their UI. This means that:

• they don't have to if they don't want to work on that
• if they have sufficient resources to study their UX, they may provide well-integrated notifications and/or social interaction GUI
• games with existing social channels using the same underlying protocol (eg. XMPP/Matrix) would be easily integrated into the launcher (other protocols may be bridged/gatewayed)

Libre games repository

Should we provide a new repository for games, or reuse an existing one? There is already a number of games on Flathub/Snapstore, however:

• we're not sure these packages are maintained by upstream or by a benevolent team of volunteers (risk of malware)
• we're not sure these packages will receive updates (see above)
• there are no packages for nightly updates or beta/RC releases

So we consider whether to serve a repository of our own.

Upsides:

• Own repository would allow better curation and trust chain
• we can add games that are not packaged elsewhere, and ensure all games we want to support are available through the same channel (not Flathub for one game, snap for another, etc)
• More complete "service", not "just" another frontend
• By making our own repository infrastructure fully FLOSS, we can make it easier for others to make new repositories (for example for abandonware)

Downsides:

• can become a lot of work to fix builds, when there are a lot of packages
• cross compilation is hazardous
• server costs
  • server doesn't need to be too beefy, as long as we don't try to build several packages in parallel (2 threads and 4GB RAM should be enough for the build server)
  • need a lot of storage space so we can serve the last N releases
  • people/organizations could volunteer HTTP mirrors
  • we could also use a P2P content-addressed network like IPFS/IPNS to reduce network costs
  • budget could be 15-25€/month for a build server with 8 threads and 2-4TB storage; could it be the same machine that provides the repo, too?

PROPOSAL 1: 0install repository

Note: Maybe distributing AppImages on GNU/Linux and *BSD via 0install would be interesting, so that the games can be copied around when there is no network. On Windows and Mac, .exe and .app should do that already.

Since we aim to support multiple platforms, we need a cross-platform packaging format. The only candidate so far is https://0install.net/:

• releases for multiple architecture
• source release with automated compilation instructions
• PGP signatures for all package "feeds"
• there's already a GUI for everything
• non-stable releases (nightly, beta..)
• multiple package sources

In order to reduce server storage/network costs, we should serve files over IPFS or Bittorrent. IPFS has a clear advantage, in that IPNS enables us to have a stable "feed" address with a corresponding PGP key.

On a high-level, the build system could operate like this:

• Keep a local cache of upstream versions to package, so that we know when an upstream release is new
• Check for upstream updates (eg. via RSS), extract corresponding git tags
• If upstream repository is signed, verify PGP signatures on commits (eg. guix git authenticate)
• If an update was found, try to build for all platforms
  • If a platform does not build or run tests successfully
    • Publish the build log on the website
    • Inform admins via email, XMPP...
  • If a build was successful
    • Create the 0install manifest containing checksums for this new build
    • Add the new manifest to the application's feed
  • If one or more builds were successful
    • Sign the application's feed with the repository's PGP key
    • Publish the new feed and corresponding builds on HTTP and IPFS/IPNS

In case a release build has failed, it is expected that either our repository's build steps will be updated. In that case, all manifests for the current release should be unpublished, and the release process for that version starts anew. If the problem was upstream and they have to publish a new tag, a normal release process ensues and the previous version will only have the previously-successful builds published.

TODO: When updating our repository's build steps, should it rebuild all packages? Should we run a git diff to see which application's build steps have been altered, and trigger a rebuild for the last release for those? (probably the second option)

In addition, a nightly cron job should run to publish nightly releases:

• Check for upstream updates on main branch
• If upstream repository is signed, verify PGP signatures on commits
• If new commits have been published, publish a new "nightly" release following the algorithm explained above

PROPOSAL 2: AppImageUpdate repository

TODO: Does someone want to make a detailed proposal based on that?

NOTE: This package format is not cross-platform, so the proposal needs to account for that.

• https://github.com/AppImage/AppImageUpdate
• Decentralized and with delta-updates
• Hosting own repo is basically just putting appimage files on a server
• CDNs supported to lower traffic load on server (IPFS support feasible?)
• Already supported by Suse open-build service
• People can easily add their own 3rd party appimages (if those include the needed metadata)

PROPOSAL 3: Flatpak repository

TODO: Does someone want to make a detailed proposal based on that?

NOTE: This package format is not cross-platform, so the proposal needs to account for that.

PROPOSAL 4: GNU/guix repository

TODO: Does someone want to make a detailed proposal based on that?

NOTE: This package format is not cross-platform, so the proposal needs to account for that.

Additional considerations

GUI toolkit

What GUI toolkit to use determines how easy it will be to implement further features. Here's a comparison table:

Framework	Cross-plat.	Lightweight	Social	UI Overlay	Implementations
Qt	✅	✅	❌ ⁽¹⁾	✅	athenaeum
GTK	~	✅	❌ ⁽¹⁾	✅	gamehub
ElectronJS	✅	❌	✅ ⁽²⁾	❌ ⁽³⁾	heroic, itch
Flutter	✅	~	~ ⁽⁴⁾	?	AppImagePool

⁽¹⁾ Not impossible to implement, but harder than just embedded a 3rd party client ⁽²⁾ Via a web-based XMPP/matrix client + build in WebRTC for audio/video. ⁽³⁾ Until proven otherwise, it's assumed an electronJS application can't hijack focus from a running full-screen application ⁽⁴⁾ Flutter/Dart libraries for exist for XMPP and Matrix. Also see FluffyChat for Matrix.

Also worth mentioning, Electron functionality of desktop web applications could in fact be replaced by:

• Tauri, a Rust toolkit which leverages system's web rendering engine
• SciterJS, a C++ toolkit

Social protocol

In order to provide excellent social features, we need to ues a social networking protocol. Here's a comparison chart:

Protocol	Federation	Easy selfhosting	Text	Voice	Video	Friendslist	Extensible ⁽⁰⁾	Guest accounts ⁽⁵⁾	Spaces ⁽⁸⁾
IRC	❌ ⁽¹⁾	✅	✅	❌	❌	❌	~	✅	❌
XMPP	✅	✅	✅	✅ ⁽²⁾	✅ ⁽²⁾	✅	✅ ⁽⁷⁾	✅ ⁽⁴⁾	❌
Matrix	✅	❌	✅	❌ ⁽³⁾	❌ ⁽³⁾	✅	✅	❌	✅
Mumble	❌	✅	✅	✅	❌	❌	~	✅	❌
Spring	❌	❌	✅ ⁽⁶⁾	❌	❌	❌	✅ ⁽⁶⁾	❌	❌

⁽⁰⁾ Extensibility is needed to develop new features, such as matchmaking ⁽¹⁾ Federation in the context of IRC means something else, it's a closed federation to provide redundancy across servers, but does not enable users to communicate across networks ⁽²⁾ Audio/Video in XMPP ecosystem is provided by Jingle and/or multimedia bridges; Jitsi implementation is not standard, but some clients are working on interop (Conversations/JSXC/Gajim) ⁽³⁾ Audio/Video in Matrix is provided by third-party clients/protocols such as Jitsi ⁽⁴⁾ Guest accounts are provided via "anonymous login" ⁽⁵⁾ Guest accounts with limited privileges (can't send friend invites) could be useful to start a multiplayer game on a specific game without having to create an account first ⁽⁶⁾ Spring uses a customized IRC protocol with support for sharing current "matches" (servers) ⁽⁷⁾ XMPP supports basic presence information, but it's trivial to build advanced presence via the PubSub extension; see User tune for an example extension ⁽⁸⁾ Spaces are a sort of collective namespace, where permissions can be defined for the entire group/team, and some chatrooms can be affiliated to the space

Package/Repository standards

Maybe it would be useful to support several types of repositories? Or a single cross-platform format? Here's a comparison chart:

Format	Cross-platform	Reproducible	Bootstrappable	Signatures	Repositories	Delta upgrades	Implementations
AppImage	❌	❌	❌	✅	❌ ⁽¹⁾	✅	AppImagePool
Flatpak	❌	❌	❌	✅ ⁽³⁾	✅	✅	athenaeum, GNOME Games
0install	✅	❌	❌	✅	✅	❌
nix/guix	❌ ⁽²⁾	✅	guix	✅	✅	❌

⁽¹⁾ AppImagePool uses a custom upstream feed, as well as a custom featured applications feed ⁽²⁾ Technically, guix and nix can build Windows application, however there is currently no support for Windows as foreign distro ⁽³⁾ Flatpak repositories are signed

The following packaging systems were considered, but not added to the comparison table:

• Packages for every different distro and system: hard to implement because every distro uses different build systems/conventions
• tarball with statically linked binaries: need to define well-known paths for package metadata, therefore reinventing AppImage/0install
• Snap not seriously considered because it is centralized

Platforms/architectures to support

Below, we consider a list of platforms to support:

• GNU/Linux and *BSD: obvious choice
• More various POSIX (haiku/redox): could be nice, but that's a small userbase
• Windows: most gamers are on it, most FLOSS developers probably aren't though (cross-compilation and testing can be tough)
• Chromebook: already supported by ChromeOS Linux support
• Android: building a game/repository for Android is wildly different and more complex than for desktop; maybe advertising FLOSS games from F-Droid makes sense?

Below, we consider a list of architectures to support:

• x86_64: obviously
• i686: for older PCs?
• ARM architecture (eg RaspberryPi): as long as it builds and tests pass, all platforms should support ARM architectures (cross-compilation)

Anti-features (to avoid)

• Monetization of software itself (we can recommend indie stores and or donation platforms to support creators)
• Direct upload of binaries by 3rd party (malware risk)
• Gamification of UX and other attention-grabbing (addictive) patterns
• User-tracking and other privacy issues (opt-in ok)
• Online account requirement: social interactions should be optional, and/or it should be very straightforward to setup local accounts for LANs or have an account-less fallback mode.

Priorities

This document is not exatly a specification for a future client project. However, if it must be interpreted like that, some features should probably be prioritized over others:

• GNU/Linux, *BSD and Windows support (x86 & ARM)
• Focus on multiplayer games that need version syncronisation (auto-update)
• Social features incl. voice-chat (true libre alternative to Discord)
• Trustworthy repository with fast updates for games
• Some limited content curation (highlight of new games, popularity sorting etc.)

Some features described in the wishlist may appear to be less important to some people:

• User-reviews of games: could cause moderation issues, and/or negatively affect volunteers when harsh reviews are published