LibreGaming/libregaming-website
LibreGaming
/
libregaming-website
16
0
Fork 0
Code Issues 2 Pull Requests Projects 2 Releases Wiki Activity

update launcher with better formatted pad 

* collaborative anonymous editing, unknown contributors
* https://md.roflcopter.fr/launcher
This commit is contained in:
Phil Morrell 2021-08-12 23:49:26 +01:00
parent c049dcf330
commit 24e058eb4a
Signed by: emorrp1
GPG Key ID: DBCA65091F248E6C
1 changed files with 279 additions and 127 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

406
game-launcher-concept.md
View File

@ -1,41 +1,158 @@
<!-- SPDX-License-Identifier: CC0-1.0 -->
# Brainstorm about a libre-games launcher
# Libre launchers
## Media player UI (aka Steam big picture)
- Lots of projects focussing on that especially in the Emulation space
- Would be a nice feature to have
- KODI would be probably the best platform, but running it in Window-mode looks bad.
- KODI has a build in webserver a could be remote controlled via a web-interface / electron app
This document is a brainstorming around FLOSS games launchers. The rationale is:
## Types of possible packages / repositories (for Linux)
- 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
Maybe it would be useful to support several types of repositories?
# Table of Contents
- Appimage
- +: decentralized, PGP support, delta/differential upgrades
- -: no repositories yet, no windows support, updates rarely supported
- Flatpak
- +: decentralized, some sandboxing, delta updates, deduplication, repositories, appstream data
- -: some sandbox edge-cases make games suck with it (eg. to install mods), no windows support
- 0install.net
- +: truly cross-platform format for install/update, can interop with AppImages
- -: we haven't really tested it, also no delta upgrades
- Guix/Nix
- +: reproducibility, security, easy to ensure that upgrades build
- -: no integration for desktop files (menu entries) on foreign distro, no windows support (cross-compiling using mingw should be possible?)
- Packages for every different distro (too hard to maintain)
- tgz with statically linked binaries (AppImage is that, but better)
- Snap (centralized rapository) not seriously considered because it is too centralized
[ToC]
## Frontend - Backend seperation?
- Leverage existing CLI backend systems (which?)
- Utilize existing front-end launcher type projects
- Less integration and advanced features possible (why?)
# Ecosystem review
## Own repository?
## 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](https://gitlab.com/librebob/athenaeum) | ✅ <br>MacOS, GNU | ⚙️ | ❌ ⁽²⁾ <br>Flathub | ✅ <br>Qt | ❌ | ❌ | ✅ | ❌ ⁽²⁾ |
| [Lutris](https://github.com/lutris/lutris) | ❌ | ⚙️ | ✅ <br>GoG, Steam, Humble Bundle | ✅ <br>Qt | ❌ | ❌ | ✅ | ✅ |
| [GNOME Games](https://wiki.gnome.org/Apps/Games) | ❌ | ❌ | ✅ <br>Flatpak | ✅ <br>GTK | ✅ | ❌ | ✅ | ❌
| [Gameshub](https://github.com/tkashkin/GameHub) | ❌ | ❌ | ✅ <br>Steam, GoG, Itch Humble Bundle | ✅<br>GTK | ✅ | ❌ | ✅ | ✅ |
| [AppImagePool](https://github.com/prateekmedia/appimagepool) | ❌ | ❌ | ✅ AppImages | ~<br>Flutter | ❌ | ❌ | ❌ | ❌ |
| [Plei](https://github.com/sakshatshinde/Plei) | ? ⁽³⁾ | ❌ | ❌ ⁽⁴⁾ <br>Steam, uPlay, Origin, Epic | ✅ <br>Tkinter | ❌ | ❌ | ❌ | ✅ |
| [itch](https://github.com/itchio/itch) | ✅ <br>MacOS, GNU, Windows | ❌ | ❌ <br>Itch | ❌ <br>ElectronJS | ❌ | ❌ | ✅ | ❌ |
| [retroarch](https://www.retroarch.com/) | ✅ <br>MacOS, GNU, Windows | ❌ | ❌ | ✅ <br>Custom | ✅ | ✅ | ✅ | ❌ ⁽⁵⁾ |
| [Spring](https://github.com/springlobby/springlobby) | ✅ <br>MacOS, GNU, Windows | ✅ | ❌ ⁽⁶⁾ <br>SpringRTS | ✅ <br>wxwidgets | ✅ | ? | ✅ | ❌ ⁽⁶⁾ |
| [KODI](https://kodi.tv/) | ✅ <br>MacOS, GNU, Windows | ❌ | ? | ✅ <br>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](https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher) Epic Store client (ElectronJS)
- [RARE launcher](https://github.com/Dummerle/Rare) Epic store client (Qt5)
- [Desura](https://github.com/desura/desura-app) 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](https://book.veloren.net/players/airshipper.html) updater for [Veloren](https://veloren.net/) 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](http://identicalsoftware.com/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](https://github.com/matanui159/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](https://moonlight-stream.org/) 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](https://github.com/flightlessmango/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
@ -43,15 +160,26 @@ Should we provide a new repository for games, or reuse an existing one? There is
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
Downsides:
- really time consuming <-- really? should be a simple CI script
- server costs <-- is there that many games to package? a very small VPS should do it, as long as it has enough RAM (~4GB should be enough for most games), need a lot of disk space though
- cross compilation issues
- By making our own repository infrastructure fully FLOSS, we can make it easier for others to make new repositories (for example for abandonware)
### PROPOSAL 1: 0install repository
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](https://www.kimsufi.com/fr/serveurs.xml) 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/:
@ -82,7 +210,7 @@ On a high-level, the build system could operate like this:
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?
**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:
@ -90,109 +218,133 @@ In addition, a nightly cron job should run to publish nightly releases:
- 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
## 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)
- (negative) No good front-end integration yet?
- (negative) Appimages are Linux only
## Cross-platform?
### Windows support?
- Reality: even for libre games, most players are on Windows
- In Windows the need for a launcher is even higher as there are no good alternatives
- Windows sucks and we probably don't have any windows using developers
- Difficulties to cross-compile (MinGW etc.)
### Chromebook support?
- Really increasing market share (at least in the US)
- Lots of young players on school chromebooks, Minetest etc. probably popular
- Has Linux binary support in some way, but not that easy? <-- it's a system similar to wine, enabled by the user in system settings
- partial flatpak support https://flatpak.org/setup/Chrome%20OS/
### Android support?
- Completely different ecosystem, but some existing libre games have ports
- Could be just an curated f-droid repository <-- an F-Droid build server is considerably more difficult to setup than any other kind of repository
## Text chat support
- IRC:
- Easy to include, but basic.
- No good friend-lists like system.
- No account required
- No voice-chat
- XMPP:
- coverers all the needs and easy to host
- Good friend-list feature and custom status messages
- Good embeddable Javascript clients available (JSXC or maybe ConverseJS)
- Less good Discord like web-chat (But Movim might be an option)
- Built in p2p voice chat (possible server supported voice-chat in the near future)
- JSXC: Embeddable, has WebRTC voice & video chat + screensharing, e2ee, sidebar for friend-list
## PROPOSAL 3: Flatpak repository
- Matrix:
- No ready to embed client?
- Good friend-list feature
- Rich content
- More Discord like
- Resource intensive to host an instance, clients are also resource-intensive
- No (yet) built in voice-chat (I think 1 on 1 calls use their own protocol but not 100% sure about that <-- they use Jitsi integration for that)
- Mumble:
- Great audio-chat
- Text-chat very simple
- Mumble-web could be embedded
- No friend-list feature
**TODO:** Does someone want to make a detailed proposal based on that?
## Other ideas
### Screen overlay features?
- Is there a way to allow an easy to access screen-overlay like in Steam?
## Video streeming support
- Possible to include some sort of video recording /streaming support?
- Quick video replay feature?
- Screensharing via WebRTC might be easy to include
**NOTE:** This package format is not cross-platform, so the proposal needs to account for that.
## Front-end
### Native (qt or GTK etc.)
- Fast and low resource
- Need to build everything from scratch more or less
- Cross-platform more difficult
- Some existing Qt projects (Athenaeum, gamehub)
### Electron based
- Resource hogg
- Easy to include javascript based systems for chatting etc. (Mumble-web, JSXC)
- Nice existing game-launcher systems (Heroic launcher, itch.io)
### Tauri https://tauri.studio/en/
- Electron like, but more lightweight and with a Rust backend
- No WebRTC yet (planned), kind of deal breaker if we want to support WebRTC audio-chat/screensharing
- Possibly Mobile and WASM (PWA?) targets in the future
### Spring lobbies
- Not tied to spring games
- multiple implementations to choose from (chobby, ...)
- IRC-like chat, friends list
- Version matching
- No voice or rich content implemented
### CLIM
- Nerd points
- ???
- lisp lurker points
## PROPOSAL 4: GNU/guix repository
## Existing projects
- https://flathub.org/apps/details/com.gitlab.librebob.Athenaeum
- https://wiki.gnome.org/Apps/Games
- https://tkashkin.tk/projects/gamehub/
**TODO:** Does someone want to make a detailed proposal based on that?
## Relevant similar projects
- https://github.com/prateekmedia/appimagepool (Flutter based Appimage store)
- Spring lobby clients (SprintRTS engine specific)
- Lutris (Fronend for multiple stores, emulators and WINE)
- Airshipper (Game specific for Veloren. Updater and news feed reader)
- Unvanquish updater (Game specific, only updater)
- KODI (media station, mainly for fullscreen use. Games/Emulator support work in progress)
- EmulationStation / RetroArch (Fullscreen, very emulation focussed)
### Open-source store front-ends
- Heroic launcher https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher (electron)
- https://github.com/Dummerle/Rare (Native client, Python & qt)
- https://github.com/sakshatshinde/Plei (Python)
- itch.io app https://github.com/itchio/itch (browserbased)
- Desurium: https://github.com/desura/Desurium (browser based?)
### Other launcher concepts
- https://github.com/AykutSarac/epic-games-clone (seems more like a student project, react based)
**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](https://gitlab.com/librebob/athenaeum)
|GTK| ~ | ✅ | ❌ ⁽¹⁾ | ✅ | [gamehub](https://github.com/tkashkin/GameHub)
|ElectronJS| ✅ | ❌ | ✅ ⁽²⁾ | ❌ ⁽³⁾ | [heroic](https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher), [itch](https://github.com/itchio/itch)
|Flutter| ✅ | ~ | ~ ⁽⁴⁾ | ? | [AppImagePool](https://github.com/prateekmedia/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](https://tauri.studio/), a Rust toolkit which leverages system's web rendering engine
- [SciterJS](https://github.com/c-smile/sciter-js-sdk), 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](https://springrts.com/dl/LobbyProtocol/ProtocolDescription.html) | ❌ | ❌ | ✅ ⁽⁶⁾ | ❌ | ❌ | ❌ | ✅ ⁽⁶⁾ | ❌ | ❌
**⁽⁰⁾** 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](https://xmpp.org/extensions/xep-0118.html) 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](https://appimage.org/) | ❌ | ❌ | ❌ | ✅ | ❌ ⁽¹⁾ | ✅ | AppImagePool
| [Flatpak](https://flatpak.org/) | ❌ | ❌ | ❌ | ✅ ⁽³⁾ | ✅ | ✅ | athenaeum, GNOME Games
| [0install](https://0install.net/) | ✅ | ❌ | ❌ | ✅ | ✅ | ❌ |
| [nix](https://nixos.org/)/[guix](https://guix.gnu.org/) | ❌ ⁽²⁾ | ✅ | guix | ✅ | ✅ | ❌ |
**⁽¹⁾** AppImagePool uses a custom [upstream feed](https://appimage.github.io/feed.json), as well as a custom [featured applications feed](https://gist.githubusercontent.com/prateekmedia/44c1ea7f7a627d284b9e50d47aa7200f/raw/gistfile1.txt)
**⁽²⁾** 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](https://snapcraft.io/) 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