./play.it installe vos jeux sans prise de tête

[Ldfa]

Le projet ./play.it est dédié à un seul but : tordre le cou à la rumeur la plus persistante au sujet de GNU/Linux.
Il s’agit bien sûr de : « Ton linusque, là, c’est nul, il n’y a aucun jeu qui tourne dessus ! ».

Ce projet propose donc une collection de scripts, qui à partir d’installeurs pour Windows ou GNU/Linux de formats divers et variés construisent sans besoin d’intervention de votre part des paquets natifs prêts à être installés sur votre distribution favorite.

À date du 2 mars 2018 vous pouvez déjà installer 313 jeux via ./play.it, et la liste grandit chaque semaine… Peut‐être bientôt grâce à vous ?

Sommaire

Présentation du projet

./play.it est un projet né en réaction à la difficulté présumée de se constituer une bonne ludothèque sous GNU/Linux. Une collection de scripts shell est fournie, chacun permettant de construire des paquets .deb (pour Debian et dérivées) et .pkg.tar (Arch Linux et dérivées) à partir d’installateurs de jeux de formats variés. Ces paquets peuvent ensuite être installés via votre gestionnaire de paquets préféré.
Parmi ces jeux se trouvent, bien sûr, des jeux natifs pour GNU/Linux, mais aussi des jeux pour Windows et DOS tournant grâce à des logiciels comme WINE, DOSBox ou ScummVM.

La simplicité d’utilisation de ces scripts est une priorité depuis le début du développement, le public ciblé étant en priorité les nouveaux venus sous GNU/Linux qui ne veulent pas se prendre la tête pour installer leurs jeux.

Les utilisateurs avancés ne sont pas oubliés pour autant, les scripts acceptant quelques options pour affiner leur comportement (on peut par exemple choisir le chemin d’installation des jeux, ou la méthode de compression des paquets), mais le comportement par défaut est intégralement non interactif pour éviter de perdre les débutants.

Une seule limitation existe pour qu’un jeu soit géré par ce projet : qu’il en existe une version sans DRM. La raison en est à la fois technique (il est beaucoup plus difficile d’accéder au contenu de ces jeux, qui souvent ne fournissent même pas de méthode d’installation autre qu’un client privateur et obligatoire), légale (il est souvent interdit de passer outre les DRM intégrés à un jeu, y compris après un achat légitime), et éthique (aucun contributeur à ce projet n’apprécie ces méthodes, considérant par défaut l’utilisateur du programme comme coupable de contrefaçon). C’est pourquoi vous ne trouverez, par exemple, aucun jeu Steam dans la collection gérée par ./play.it.

Exemple d’utilisation

Pour mieux comprendre comment fonctionne ./play.it, voici un petit exemple d’utilisation utilisant comme base l’installateur pour Worms Armageddon, vendu sur GOG.com :

Installation de ./play.it

dave@HAL9000:/tmp$ git clone https://framagit.org/vv221/play.it.git
Clonage dans 'play.it'...
remote: Counting objects: 11569, done.
remote: Compressing objects: 100% (3252/3252), done.
remote: Total 11569 (delta 6919), reused 11509 (delta 6878)
Réception d'objets: 100% (11569/11569), 2.01 MiB | 4.91 MiB/s, fait.
Résolution des deltas: 100% (6919/6919), fait.
dave@HAL9000:/tmp$ cd play.it
dave@HAL9000:/tmp/play.it$ make install
mkdir -p ~/.local/share/play.it/
[ -e play.it-1 ] && cp -a play.it-1 ~/.local/share/play.it/ || true
[ -e play.it-2 ] && cp -a play.it-2 ~/.local/share/play.it/ || true
ln -fs play.it-2/lib/libplayit2.sh ~/.local/share/play.it/
mkdir -p ~/bin
cp -a play.it ~/bin

Construction des paquets

dave@HAL9000:~$ play.it ~/jeux/worms-armageddon/archives/gog/setup_worms_armageddon_2.0.0.2.exe
Utilisation de /home/dave/jeux/worms-armageddon/archives/gog/setup_worms_armageddon_2.0.0.2.exe
Extraction des données de setup_worms_armageddon_2.0.0.2.exe
Construction de worms-armageddon_3.7.2.1-gog2.0.0.2+20180224.1_i386.deb OK
Construction de worms-armageddon-data_3.7.2.1-gog2.0.0.2+20180224.1_all.deb     OK

Installez Worms Armageddon en lançant la série de commandes suivantes en root :
apt install /home/dave/worms-armageddon_3.7.2.1-gog2.0.0.2+20180224.1_i386.deb /home/dave/worms-armageddon-data_3.7.2.1-gog2.0.0.2+20180224.1_all.deb

Il ne reste plus qu’à installer les paquets générés avec la commande donnée (qui s’adapte bien sûr automatiquement au système cible) pour pouvoir jouer.

Historique

Adieu Windows !

Tout a commencé quand je (vv222, créateur de ./play.it) me suis rendu compte que mon double démarrage Debian / Windows n’avait plus vraiment de sens et que je me suis décidé à me débarrasser de Windows de manière définitive.

Ne voulant pas abandonner ma collection de jeux vidéo lors de cette transition, j’ai dû apprendre à me servir d’outils comme WINE pour pouvoir continuer à jouer à mes jeux favoris. Une des grandes forces de nos distributions GNU/Linux étant à mon avis leurs systèmes de paquets, je me suis dit que construire des paquets pour mes jeux pouvait être une bonne manière de ne pas devoir répéter les étapes de configuration de WINE (ou DOSBox, ou ScummVM, etc.) à chaque fois que je souhaite installer un jeu en particulier.

Des scripts sous licence libre

Plutôt satisfait du résultat, et ayant envie de contribuer au monde du logiciel libre depuis longtemps, s’est alors posé le problème de la distribution de ces paquets. S’agissant pour la plupart de jeux commerciaux, je ne pouvais bien sûr pas les distribuer sous forme de paquets (ou alors pas longtemps avant d’avoir de gros ennuis). C’est de là qu’est venue l’idée de publier les recettes de construction de ces paquets, à l’origine sous forme d’instructions à suivre, puis sous forme de scripts prêts à l’utilisation.

Le choix du Shell comme langage de script s’est très vite imposé, tout simplement parce que n’ayant aucune expérience préalable de la programmation, je me suis orienté vers le seul langage que je fréquentais déjà au quotidien : celui utilisé par mes terminaux. C’est donc armé de man dash et d’une quantité impressionnante de motivation et de café noir que l’aventure ./play.it s’est lancée sous sa forme définitive…

Évolutions et réécritures

Depuis les premiers scripts, illisibles pour qui que ce soit, beaucoup d’évolutions ont permis à ce projet de devenir accessible aux contributions. La première et probablement la plus importante, a été de réunir une collection de fonctions spécifiques aux besoins de ./play.it au sein d’une bibliothèque, et ainsi de simplifier l’écriture des scripts spécifiques à chaque jeu. La deuxième grosse évolution a été un énorme travail de réécriture de cette bibliothèque qui avait comme objectif principal de ne plus rien avoir de spécifique au format de paquet .deb (à ce moment le seul géré) codé en dur. La conséquence immédiate a été l’ajout de la possibilité de construire des paquets .pkg.tar(.xz/.gz) pour la famille Arch Linux.

Le travail tant sur la bibliothèque que sur la collection de scripts (visant chacun un jeu précis) ne s’est jamais arrêté depuis la naissance du projet, qui connaît un nombre croissant de contributions. Un tas d’améliorations est prévu et devrait nous occuper pendant encore longtemps, vous pourrez en lire un peu plus à ce sujet plus loin dans cette dépêche.

Keep It Simple, Stupid

Je pense qu’arrivés à ce point vous sentez peut‐être comme une odeur de NIH autour de ce projet ? Il y a plusieurs raisons pour lesquelles j’ai préféré lancer un nouveau projet plutôt que de participer au développement d’un logiciel existant, comme PlayOnLinux ou Lutris. Souvent ces projets sont soit trop limités (PlayOnLinux ne gère que des jeux tournant avec WINE, game-data-packager ne construit que des paquets pour Debian et à condition qu’un moteur libre soit disponible), soit fournissent trop de fonctionnalités pour l’adepte du KISS que je suis (Lutris gère les téléchargements des jeux et fournit un client pour les lancer). À ma connaissance ./play.it est le seul projet se concentrant sur la tâche de construire des paquets à destination de plusieurs familles de distributions pour des jeux commerciaux, sans poser aucune autre contrainte au niveau du choix de ces jeux que leur capacité à fonctionner sur GNU/Linux.

Fonctionnalités

Intégration

Le maître‐mot derrière le développement de ./play.it est « intégration ». Notre objectif est qu’un jeu installé via ./play.it soit indiscernable d’un jeu installé via les dépôts officiels de votre distribution favorite. Voici quelques points dans le fonctionnement de ./play.it qui nous aident à remplir cet objectif :

• installation des jeux via le système de paquets de la distribution, ce qui en simplifie les futures mises à jour, désinstallations et réinstallations ;
• pas de client intégré pour lancer les jeux, les paquets placent juste des fichiers .desktop dans les chemins standard du système qui permettent de les lancer via votre lanceur d’applications habituel ;
• les standards FHS et Freedesktop sont suivis, ce qui signifie que, si vous utilisez un client quelconque pour gérer vos jeux, il a de bonnes chances de repérer aussi ceux installés par ./play.it, sans aucune manipulation de votre part ;
• les jeux sont installés en lecture seule dans des arborescences système, et seuls les fichiers nécessitant des droits d’écriture pour l’utilisateur sont dupliqués dans le répertoire personnel de l’utilisateur (défini par $HOME). Dans le cas d’un système partagé, le jeu nécessite donc de n’être installé qu’une seule fois pour que tous les utilisateurs de la machine puissent en profiter, chaque utilisateur pouvant utiliser ses propres choix de configuration et sa propre collection de sauvegardes et de mods.

Simplicité

Les scripts ./play.it s’adressent avant tout à ceux qui veulent juste jouer, et pas passer des après‐midi à bidouiller avant que leur jeu ne fonctionne… Nous prenons ça en compte de différentes manières :

• les scripts sont totalement non interactifs, ce qui évite de perdre l’utilisateur avec des séries de questions auxquelles il ne saurait pas quoi répondre ;
• les paquets construits sur une machine peuvent être installés sur n’importe quel système utilisant ce format de paquets ; il suffit donc de construire les paquets une seule fois avant de pouvoir les installer sur autant de systèmes que vous le désirez ;
• passer par le système de paquets permet d’automatiser la gestion des dépendances, et dans le cas de dépendances obsolètes (versions plus fournies par les distributions actuelles) celles‐ci sont intégrées aux paquets construits.

Souplesse

Les utilisateurs avancés ne sont pas oubliés pour autant, et plusieurs options peuvent être passées aux scripts pour modifier en partie leur comportement. Voici la liste des propriétés configurables de cette manière (cette liste croît régulièrement en fonction des retours de nos utilisateurs et des nouvelles fonctionnalités développées) :

• le chemin d’installation est configurable (par défaut, /usr/local/share est utilisé) ;
• le type de paquets à construire est par défaut celui géré par le système courant, mais il est aussi possible de le spécifier explicitement (par exemple, pour profiter des machines du boulot pour construire des paquets à installer à la maison) ;
• par défaut les paquets sont construits sans compression, mais les méthodes de compression gzip et XZ peuvent être utilisées ;
• un test d’intégrité des archives données en entrée (installateurs des jeux) est effectué avant toute manipulation, mais peut être désactivé par une option.

Évolutions

De nombreuses évolutions sont au programme et nous sommes ouverts aux suggestions, aussi bien sur notre salon IRC (#play.it sur freenode) que via le système de tickets du dépôt sur Framagit. En voici quelques‐unes qui méritent d’être mises en avant :

• une API est depuis peu disponible sur http://api.dotslashplay.it/ pour permettre de facilement construire des applications se basant sur ./play.it ; cette API devrait aussi servir de base à une future refonte complète du site Web projet (dont la version actuelle se base sur DokuWiki) ;
• la rédaction de documentation, bête noire d’énormément de projets, qu’ils soient libres ou non, devrait bientôt débuter pour permettre de faciliter l’arrivée de nouveaux contributeurs au sein du projet ; pour l’instant, c’est le salon IRC qui sert à obtenir de l’aide sur le fonctionnement des scripts mais, sans documentation, la première approche n’est pas forcément évidente ; nous prévoyons que la première partie à écrire de la documentation explique comment ajouter la gestion de nouveaux jeux au sein du projet ;
• l’ajout de la gestion de nouveaux formats de paquets (en plus des .deb de la famille Debian et des .pkg.tar de la famille Arch Linux actuellement gérés) est une tâche qui reste à demeure dans notre TODO list, mais celle‐ci nécessite que l’on se fasse aider par des personnes connaissant ces formats de paquets ; d’ailleurs, un spécialiste du format RPM serait le bienvenu au sein de notre équipe !
• le système de gestion des sauvegardes et de la configuration des jeux nécessite encore d’être amélioré, à la fois pour empêcher les jeux de remplir nos répertoire personnels avec tout un tas de répertoires disgracieux, mais aussi pour faciliter la synchronisation des sauvegardes entre différentes machines ;
• la gestion des jeux sur support CD-ROM et DVD-ROM est prévue depuis le tout début du projet, mais s’avère bien plus complexe que la gestion des versions téléchargeables pour deux raisons principales : il est devenu difficile d’acheter ces versions aujourd’hui, et il existe pour un même jeu parfois une douzaine de versions différentes sur support physique ;
• dans le milieu du jeu vidéo dématérialisé, certaines structures de données se retrouvent quasiment à l’identique pour des dizaines ou des centaines de jeux. Des scripts génériques pouvant gérer un type de jeu (plutôt qu’un seul jeu) sont donc probablement envisageables ; par exemple, on pourrait imaginer un script unique gérant tous les jeux basés sur le moteur Unity3D, dont une version native GNU/Linux est vendue sur GOG ;
• un nouveau logo est en cours de réflexion et, plus généralement, une véritable charte graphique ; ce point devrait avancer en parallèle de la mise en place du nouveau site Web.

Contribuer

Pour les développeurs

Une des façons les plus efficaces pour contribuer consiste à écrire de nouveaux scripts gérant d’autres jeux. Nous sommes limités par nos ludothèques respectives et nous n’avons sous la main que des jeux de certains genres (ceux que nous aimons, bien sûr). Nous avons besoin de plus de contributeurs avec des goûts différents en jeux vidéo pour que la collection de jeux gérés se diversifie.

Sans rentrer dans les détails (la documentation sera bientôt là pour ça), l’idée est de se baser sur un script assez récent, décompresser l’installateur du jeu concerné, changer la valeur de quelques variables, et le tour est joué !

Bon, en rentrant un peu plus dans les détails : la simplicité des scripts est une priorité. Dans la plupart des cas, il n’y a pas beaucoup de choses à changer d’un script à l’autre. Les noms des variables sont les plus explicites possibles. Bref, tout est fait pour qu’un non‐codeur puisse s’y retrouver (mais, bon, ça reste du code). On se base donc sur un script récent, on farfouille notre installateur pour voir comment sont rangés les fichiers du jeu, on modifie le script (le nom du jeu, le nom des fichiers présents, où les trouver, le nom de l’exécutable…) et on teste. De même, nous essayons d’avoir des messages d’erreur faciles à comprendre. Quand un souci se présente, nous ne sommes jamais loin d’IRC ni de nos boîtes de courriel. Une fois que le script fonctionne, il faut l’envoyer par demande d’intégration Git (merge request), si vous connaissez Git, par pastebin ou par courriel, tous les moyens sont bons. Une relecture sera faite par vv222 et il l’intégrera dès que possible dans les dépôts.

Nous avons aussi grandement besoin de retour de contributeurs de scripts : les messages d’erreur sont‐ils compréhensibles ? En manque‐t‐il ? Qu’est‐ce qui pourrait faciliter vos contributions ?

Pour les autres

Mais contribuer peut aussi se faire de plein d’autres façons qu’en touchant directement aux scripts…
Par exemple, parler du projet autour de vous. :-) Et en invitant l’équipe à venir participer à divers événements (nous fréquentons déjà régulièrement les |JdLL](http://www.jdll.org/ "Les journées du logiciel libre"), Capitole du Libre et autres Ubuntu Parties parisiennes).
Offrir des jeux aux membres de l’équipe peut avoir une certaine utilité aussi, mais le résultat est très loin d’être garanti : si le jeu est vraiment bon, on risque de passer beaucoup de temps à y jouer, ce qui retardera la publication des prochains scripts.

Pour ceux qui souffrent d’un cruel manque de temps libre mais souhaitent tout de même aider le projet à avancer, nous acceptons les dons via Liberapay. Pour l’instant nous pouvons à peine nous acheter un café par an, mais si le volume de dons augmente il sera possible de dédier plus de notre temps au développement de ./play.it. Par exemple, vv222 (développeur principal du projet) a déjà décidé de passer en temps partiel dans son emploi pour pouvoir travailler plus souvent sur ./play.it, et d’autres contributeurs pourraient être intéressés si les dons pouvaient remplir au moins partiellement leur réfrigérateur. ;-)

Remerciements

Merci à tous ceux qui ont contribué à la rédaction de cette dépêche, y compris ceux qui ne sont pas passés par la tribune de rédaction de LinuxFr.org. Merci donc, en plus des participants listés, à Elzen, HS-157, Zatalyz, Mopi, kilobug et tous ceux qui ont aidé de près ou de loin à la première annonce de l’existence de ./play.it sur LinuxFr.org !

Afficher l’article complet