gnoucat2 a écrit 8 commentaires

Salut. Le fait qu'on ne partage qu'une archive des sources ne signifie pas qu'on n'utilise pas un gestionnaire de versions comme git. En l'occurrence, on utilise ce dernier, mais le dépôt reste privée. En effet, l'intérêt de le partager nous semble fort limité (l'intérêt de l'historique est faible et il est au moins pour le moment peu probable que ça intéresse quelqu'un) et exposerait les méta-données des commits (qui peuvent certes être truquées).

• On distribue nous-même le jeu via BitTorrent. Mais on n'a pas d'accès à Internet personnel et on n'a pas envie de prendre le risque (fut t'il à priori très léger) de le partager via l'accès Internet de l'employeur. Ça fait effectivement qu'on le distribue de fait peu. Cependant, le torrent fait un peu moins de 20 Mo (avec les sources, des binaires, de la documentation auto-générée, etc.), donc il est facile que d'autres contribuent au partage.
• Les contributions qu'on recherche sont en terme de sprites. Or, il n'y a pas besoin d'un accès au dépôt des sources pour ça. Les spécifications (la résolution et le spectre des couleurs) et des exemples suffisent pour ça, ce qui est implicitement donné par un binaire du jeu. Pour ce qui est de la découverte des créations, le plus simple est de les mettre sur le wiki du projet d'origine, mais il est aussi efficace de les héberger ailleurs avec pour étiquettage « tuxemon » ou « libre fakemon ».
• On préfère passer du temps à réaliser des choses qu'à faire de la communication. On préfère miser sur l'intérêt pour la chose elle-même que sur une campagne de brouhaha. Donc on a fait ce second petit jeu vidéo libre et on a longuement expliqué pourquoi et comment, et on préfère utiliser notre temps libre pour faire de la qualité plutôt que de la quantité.

Pour revenir sur ce qu'on aimerait avoir comme contributions, la version longue de l'annonce (télécharger le torrent, puis voir sources.tar.xz, et enfin à l'intérieur news/fr/version-1-0-0_annonce.md) a une partie dédiée et son découpage est assez éclairant (on y parle d'abord des sprites, puis un peu de traduction, mais pas du tout de code) :

## Détails pour contribuer
### Les sprites de créatures et de dresseur·e·s
#### La couleur des sprites de créatures et de dresseur·e·s
#### Les tailles pour les sprites de créatures et de dresseur·e·s
#### Le droit d'auteur·e pour les sprites de créatures et de dresseur·e·s
#### Les pokéballs, c'est non !
### Traduire dans une nouvelle langue

Et c'est pas la seule fois où on a écrit franchement les choses (voir news/fr/version-1-0-0_annonce.md dans sources.tar.xz fourni par le torrent). Exemples :

• « ce serait comme chercher de la gauche au sein de la droite et par exemple se tourner vers le bien bourgeois et pseudo-vert Yannick Jadot d'EELV »
• « les logiciels quasi-ininstallable sans être foutu dans un conteneur (tellement c'est du grand n'importe quoi, car c'est tristement la raison, moins belle il est vrai que l'efficacité productiviste à tout prix et la bien étrange sécurité basée sur un gros fourre-tout et un empilement de couches d'abstractions, entre autres joyeusetés justificatrices de la nécessité de notamment Docker et Flatpak, qui sont de l'ordre de la machine à steaks hachés pour McDo et l'inverse même du “génie logiciel”) »

Il est vrai que ce qu'on donne à voir n'est pas nécessairement représentatif de la manière dont on a fait le jeu. Toutefois c'est déjà ça. De plus, de par la manière dont on l'a fait (C99, limite de 80 caractères par ligne, cmake et pas un fichier d'un environnement de développement intégré pour compiler, toutes les dépendances sont stables et disponibles dans les distributions Linux hors Android et chez les *BSD, SDL2 et pas un gros moteur comme Godot, etc.), on peut le continuer d'une manière sobre (au sein de l'ordinatique), même si ça avait été fait jusque là d'une manière lourde (au sein de l'ordinatique). Mais pour les curieux et curieuses, on l'a fait avec GNU Emacs (avec peu de personnalisation et légère quand on en a fait) sous Debian GNU/Linux et Trisquel GNU/Linux avec Xfce 4 (certes LXDE ou LXQt seraient par exemple mieux, sans parler de faire sans interface graphique), mais il est vrai malheureusement des processeurs Intel et pas qui soient économes (Atom et compagnie) sans pour autant que ce soit des machines de guerre avec les standards actuels (mais si ça l'aurait été, ça n'aurait rien dit de la consommation à l'usage, car les processeurs Intel et AMD peuvent heureusement adapter leurs fréquences en fonction de l'intensité du travail qu'on leur demande). Enfin, il aurait certes été mieux d'utiliser par exemple de l'ARM ou du MIPS, mais il faut néanmoins garder à l'esprit que le plus gros du coût écologique n'est généralement pas dans l'usage mais dans le reste du cycle de vie (extraction, assemblage, transport, post-usage), donc utiliser des composants ordinatiques déjà produits est souvent mieux que d'en acheter des neufs plus économes à l'usage (mais on peut nous rétorquer qu'on aurait pu acheter par exemple un Chromebook ARM d'occasion sur lequel on pouvait installer Trisquel GNU/Linux ou le cas échéant une autre des distributions GNU/Linux recommandées par la FSF ou Debian GNU/Linux malgré ses quelques problèmes).

1. git est décentralisé, mais aussi très verbeux. On n'a pas envie d'exposer quand et comment on travaille les commits, ce qui représente en plus de l'information que probablement pas grand monde ou personne ne consulterait.
2. On pourrait certes diffuser via le Web une simple archive des sources, voire également les binaires et la documentation auto-générée, comme on le fait via le torrent. Mais l'option avec binaires encouragerait l'écrasante majorité à omettre les sources (et donc ça nuirait à l'accessibilité et à la conservation de celles-ci). Pour ce qui est de l'option sans binaire, ça encouragerait inutilement à l'hétéro-gestion, puisqu'on peut faire autrement et facilement via BitTorrent, à fortiori du fait que tout compris (dont sources et binaires) ça fait un peu moins de 20 Mo.
3. Les sources sont libres. Donc, si pour une raison pratique, comme faire un paquet pour une distribution, quelqu'un veut les rendre disponible par HTTP ou FTP ou autre, c'est tout à fait possible en toute légalité, ce que quelqu'un a d'ailleurs fait pour la dernière version de notre précédent petit jeu vidéo. Enfin, il y a une vérification d'intégrité avec BitTorrent, donc l'archive des sources d'origine est facile à vérifier (mais si besoin voila le résultat qu'en donne sha1sum : 50a19b485a233d10765c4fc408d57088b67fb9e1), tout différentiel par rapport à l'origine est en revanche de la responsabilité de la personne (individuelle ou morale) qui fait une version dérivée (pour altérer le jeu, en faire un paquet, ou autre chose).
4. Pour ce qui est de la pénalisation des utilisateurs et utilisatrices, ta remarque nous semble exagérée. Il faut être lucide sur le public potentiel du présent jeu. C'est un jeu en niveau de gris et inférieur aux premiers jeux Pokémon en terme mécanique et de durée de vie. Son public potentiel est donc particulièrement de niche. Ça peut intéresser des libristes, des décroissantistes, des créatifs et peut-être des curieux·euses. Ce petit public potentiel n'est pas lambda et une bonne partie devrait pouvoir faire le petit effort de télécharger par BitTorrent (il est tout de même facile de télécharger et installer un client BitTorrent puis le laisser tourner). Pour ce qui est des empaquetteur·euse·s (qui ont le problème que l'ensemble des sprites en 16×16 n'est pas individuellement crédité, mais ceux là sont toujours sous la licence Creative Commons 0 en version 1.0.0 et faits par Kenney ou nous, et pour les autres se référer à include/specific/data/licensing/sprite/16/all.h), télécharger le torrent devrait être tout à fait dans leurs capacités et également d'héberger les sources par HTTP ou FTP ou autre.

---

Dans sources.tar.xz, puis news/fr/version-1-0-0_annonce.md :

Pourquoi ne partager le jeu (code source et binaires) que par BitTorrent ?

Nous ne souhaitons pas héberger le jeu sur une forge. En effet, nous ne souhaitons pas animer une communauté pour un jeu vidéo, nous ne jugeons pas utile de faire connaitre les commits au fur et à mesure et de toute façon personne ou presque ne les lirait, et cela révélerait des informations temporelles (quand nous faisons des commits) ou nécessiterait de ré-écrire exprès l'historique. Un site web (même basique et statique) nécessiterait lui un peu de travail de mise en place et de la maintenance, ainsi que d'avoir accès à un serveur.

D'ailleurs, à ce propos, pourquoi devrions-nous gérer le coût de l'infrastructure ? ou pourquoi devriez-vous vous rendre quelque part qui le fait sur votre dos (il faut que les plateformes aient d'une manière ou d'une autre de l'argent et c'est rarement le cas via exclusivement des dons et/ou subventions) ou sur le nôtre en pillant notre code (comme Microsoft avec GitHub Copilot) ou vous habitue à dépendre d'autres (modèle freemium) ? Avec BitTorrent, tout le monde partage le coût, hormis certes celui du ou des traqueurs, et c'est donc collectivement qu'on assure la disponibilité (il ne faudra pas compter que sur nous si vous souhaitez ne pas attendre beaucoup avec les attentes devenues normales, car nous partageons via BitTorrent en moyenne moins d'une fois par semaine).

De plus, BitTorrent est résilient, en théorie du moins, puisqu'il faut quelques personnes qui partagent et utiliser plusieurs traqueurs pour qu'il le soit effectivement. À contrario, un site web géré par une seule personne ou une forge qui a un coût non-négligeable a bien plus de risque de disparaitre qu'une gestion collective (si effectivement elle advient et se maintient sur le long-terme).

Mais si cela ne vous convient pas, le jeu est libre. Rien ne vous empêche donc de l'héberger (autant les sources que les binaires) ailleurs et autrement (mais pitié par sur cette infamie privatrice et ultra-centralisée qu'est M$ GitHub, qui au surplus pille maintenant le code et va jusqu'à vendre ce « service » !) ou de le partager par un autre médium (clé USB, CD, etc.). On peut mettre le code source dans une forge (et nous ne pouvons à ce propos que vous recommander de tenir compte des critères éthiques de GNU), il pourrait être distribué par des distributions GNU/Linux et *BSD, par F-Droid pour Android, etc.

Dans l'ensemble, tu as bien résumé. En revanche, le « plaisir coupable » est de consacrer du temps à un petit jeu vidéo de niche (on sait bien en l'état qu'il est improbable que ça aille plus loin, même si on faisait beaucoup de communication) plutôt qu'à une activité militante plus importante (en l'occurrence du syndicalisme de classe et plus précisément du syndicalisme à vocation révolutionnaire dans une perspective matérialiste, qui se marrie bien avec l'écologie en criant besoin de rapport de force, auquel on pourrait ajouter la lutte véganiste / anti-espècisme) et on n'a quasiment pas fait de sprite (aucun en 64×64, hormis ceux de « floctain » / « poulpagicien » mais qui ne sont qu'une fusion manuelle de ceux de la pré-évolution « flocty » / « poulpation » et « snykic » / « psython » pour le halo, et ceux en 16×16 qu'on a fait sont pour l'essentiel des dérivés de ceux de Kenney et pas forcément les plus réussis).

Merci pour les amendements. On a encore des petites remarques :

• Le lien pour les images est vers un hébergeur qu'on a pris « aléatoirement » (en fait au plus rapide) avec du JavaScript obligatoire et de la publicité. Ce serait mieux que les liens pointent vers les images du proxy de LinuxFr.
• Dans « Aller plus loin », « le wiki de Tuxemon (le projet sur lequel s'est initialement basé Tuxemon Tower) » : Ça devrait être « Tuxemon Tower 0 ». Le numéro ne correpond en effet pas au numéro de version. Il y aura peut-être, dans quelques années, un autre jeu Tuxemon sous la forme d'une tour pour l'espace explorable. On a donc mis « 0 » à la fin du nom du présent jeu, ainsi l'éventuel prochain jeu similaire sera plus facile à distinguer (que s'il y avait « Tuxemon Tower » et peut-être futurement « Tuxemon Tower 2 » ou plutôt « Tuxemon Tower 1 » puisqu'on a commencé à itérer à 0 comme il est d'usage en ordinatique).

• Nous n'avions pas mis « le wiki » dans « Aller plus loin » (voir la fin de l'article, pas d'ancre HTML). En effet, on s'est basé sur le projet Tuxemon d'origine, mais c'est tout. Hormis qu'on a ré-utilisé plein de tuxemons, le système par défaut des types et le nom « Tuxemon », le lien avec le projet Tuxemon d'origine / historique s'arrête là (à peut-être un ou quelques trucs oubliés). En soi, pas de problème de faire la publicité au projet source, au contraire même, mais c'est potentiellement source de confusion là : car le présent projet (Tuxemon Tower 0) n'en est pas issu officiellement, c'est un dérivé officieux (mais on cite méticuleusement ce qu'on a repris, tout en créditant et mentionnant les licences pour les sprites). Par conséquent, il nous paraitrait approprié de donner un titre plus explicite à ça ou de tout simplement enlever de cet endroit une référence au wiki du projet d'origine.
• Pour les données du jeu en images, on n'avait pas pensé qu'elles seraient en tout petit. Il serait donc souhaitable d'ajouter un lien pour avoir la taille réelle, puisque là les gens doivent penser à ouvrir dans un nouvel onglet ou enregistrer puis ouvrir avec un outil externe.

Hormis ça (qui n'est pas bien grave) et le différent de vision éditoriale (voir « En plus long ? » ; mais c'est normal que les gestionnaires du site web puissent imposer un cadre aux contributions potentielles), on en profite pour remercier pour la publication.