Journal Greycess Knight RPG : de la 1.0.0 à la 1.0.1

Sommaire

• C'est quoi Greycess Knight RPG ?
• Changements de la 1.0.1 par rapport à la 1.0.0
  • Correction d'un bogue au chargement de la partie
  • Correctifs pour les chaines de caractères
  • Arrêt du gros tableau unique de chaines de caractères pour absolument tout et n'importe quoi
  • Initialisation des variables extern avec des valeurs bidon pour Apple macOS
  • Création de fichiers textes vides sans echo -n
  • Ajout d'informations sur la licence des divers éléments
  • Ré-organisation du code source
  • Ajout de la cible build-static pour make
  • Ajout de la version sur l'écran d'acceuil
  • Fortification et amélioration de la lisibilité du fichier pour make
  • Ajout de cibles pour la construction pour GNU/Linux
  • D'autres changements insignifiants ou oubliés
• Télécharger la version 1.0.1
  • Quelques clients BitTorrent libres
• Foire aux questions
  • N'es-tu pas écologiquement incohérent ?
  • Pourquoi pas une forge publique ?
  • BitTorrent est écologique ?
  • Quel avis sur la distribution du jeu par des distributions ?
  • Comment contribuer ?
  • Pourquoi avoir fait ton propre moteur ?
  • Pourquoi autant de texte sur si peu de place ?
  • Pourquoi cet énorme bloc de texte au début ?
  • Et la version web ?
  • Pourquoi utiliser l'identité « GnouCat » ?
  • Pourquoi utiliser C et pas un autre langage de programmation ?
  • Pourquoi proposer un paquet Debian pour Ubuntu ?

C'est quoi Greycess Knight RPG ?

Greycess Knight RPG est un jeu vidéo. Il consiste pour l'essentiel en un jeu de rôle en tour par tour. Entre les combats et pour l'histoire, on se meut sur une carte et on a accès à un menu pour divers trucs (voir l'état de son personnage, changer son équipement, sauvegarder, changer des paramètes, etc.).

Autant sur son moteur que graphiquement, ainsi que sur son scénario et sa durée de vie, il est très très basique. C'est pour partie volontaire, puisque je suis un écologiste décroissant (qui va jusqu'à penser qu'il faudrait entre autres mettre fin aux ordinateurs ! et sans pour autant être contre une certaine forme de luxe !) et parce qu'il est bien plus sûr (autant pour le développement technique que psycologiquement) de faire itérativement un truc fonctionnel que vouloir sortir quelque chose que quand ça atteint un stade avancé.

Pour ce qui est du code source, c'est essentiellement du C99 (les intérêts principaux par rapport à C90 sont dans mon cas : pouvoir déclarer des variables n'importe où, la possible de faire des fonctions inline, pouvoir définir des valeurs de struct d'une manière nommée et indiquer l'indice pour un tableau, vswprintf). La bibliothèque SDL2 est utilisé dans le jeu, tandis que la bibliothèque SDL2_image est utilisée pour convertir des images PNG en code C (pour en faciliter l'usage et ne pas dépendre d'une bibliothèque pour les images à l'exécuation) et check pour des tests automatiques d'exécution (qui ne sont pas tous très unitaires, en particulier ceux sur le combat, cf. check_battle).

Pour ce qui est des licences, tout est libre. Le code source (de moi) est principalement sous licence GNU AGPLv3.0+. Les images sont sous la license Creative Commons 0 v1.0 (donc dans le domaine public), dont une partie a été faite par Kenney d'OpenGameArt et le reste par moi-même. La bibliothèque SDL2 et sa copine pour les images sont sous la licence zlib, tandis que check est sous la GNU LGPL 2.1+. Enfin, pour la compilation, make est un standard POSIX avec une implémentation GNU et CMake est sous diverses licences libres.

Cette présentation « courte » est déjà bien longue. Si vous voulez en savoir plus, lisez donc l'annonce de la toute première version.

Changements de la 1.0.1 par rapport à la 1.0.0

Correction d'un bogue au chargement de la partie

S'il y avait bien un endroit où je voulais ne pas avoir de bogue, c'était dans le système de sauvegarde. La raison en est simple : personne n'a envie de perdre sa partie, même dans un jeu aussi court que Greycess Knight RPG. Pourtant ça semblait très bien fonctionner. Peut-être d'ailleurs que personne n'a rencontré le bogue !

Mais si c'est un bogue, il est forcément rencontrable, non ? Et bien pas forcément. Un bogue logique peut se retrouver ne pas en être en pratique, par une chance-malchance due au compilateur. Au moins dans la construction que j'ai utilisé sur mon poste, le bogue n'était en pratique pas présent ou alors je ne l'ai pas eu en pleine face par malchance.

Mais c'était quoi ce bogue alors ? Au moment de la sauvegarde d'une partie, est sauvegardé entre autres la santé du personnage joué et son niveau. Évidemment les mêmes données sont récupérées au moment de la sauvegarde d'une partie. Jusque là rien que de plus normal.

Quand une sauvegarde est faite, j'ai confiance dans les données qu'a l'application, donc aucune vérification n'est faite dessus, à part dans la construction de débogage (avec mon bien aimé assert de la bibliothèque C standard). En revanche, au chargement, la personne joueuse a pu modifier sa sauvegarde d'une manière tierce et l'avoir mise dans un état incohérent, donc des vérifications sont faites (mais il n'y a pas encore de somme de contrôle).

J'ai commencé un autre jeu vidéo similaire. Du coup, il a logiquement pour base le moteur de Greycess Knight RPG (et c'est d'ailleurs ce jeu vidéo en préparation qui m'a poussé à tant améliorer les arcanes de Greycess Knight RPG jusqu'à cette version 1.0.1). Mais il s'en écarte pour certaines choses. Une des conséquences est qu'il y a plus de données sur la sauvegarde, notamment parce qu'on pourra avoir plusieurs combattants. Le compilateur a alors dû définir et/ou arranger les données d'une autre façon. Cela a conduit à m'apercevoir du bogue logique, qui s'était matérialisé concrétement (du moins dans la construction avec les options par défaut et pas dans celle avec les options de débogage !)

J'enregistrais une partie. Ensuite, quand je la chargeais, le jeu me disais dans le terminal (l'interface graphique se contente pour le moment du minimum et indique donc juste qu'il y a eu un problème au chargement de la sauvegarde) que la santé actuelle d'un combattant était supérieure à sa santé maximale potentielle. Pourquoi une telle hérésie ? La santé maximale dépend de 2 paramètres (cf. FIGHTABLE_FIGHTER_COMPUTE_STAT dans le code C) : la classe de combattant et le niveau. Pour calculer correctement la santé maximale, il faut donc préalablement avoir la classe et le niveau. Dans Greycess Knight RPG, le personnage joué ne peut avoir qu'une seule classe, donc elle n'est pas stockée (ce qui changera avec le jeu en préparation). En revanche, le niveau peut lui varier et est donc enregistré. Pour celleux qui ne l'auraient pas vu venir, le problème venait de l'ordre de chargement : la santé était chargée avant le niveau ! La correction du bogue était donc simple (mais pas la recherche de sa cause, bien qu'elle soit toute bête) : il suffisait de changer l'ordre.

Correctifs pour les chaines de caractères

• Au début du jeu, j'ai fait en sorte qu'une information de localisation soit adéquatement définie. Cela permet ensuite que les fonctions pour les caractères étendues agissent comme attendu. J'ai fait ça via setlocale. Plus précisément, setlocale(LC_ALL, "C.UTF-8") fait l'affaire au moins pour GNU/Linux.
  • isblank(L'…') était vrai, donc le caractère pour les points de suspension était converti en espace. Il fallait utiliser iswblank de cwctype.h. C'était tout bête et ça corrige en fait probablement pour d'autres caractères au-delà des 127 la table ASCII. J'en ai profité pour commencer à ajouter des tests automatiques d'exécution à ce propos (avec check_character_symbol).
  • toupper de cctype.h était utilisé sur des caractères étendues. Il renvoyait tel quel ceux non-ASCII ou au moins une partie d'entre eux (en tout cas au moins le « é » de « éléphant »). Il fallait utiliser towupper de cwctype.h.
• Le caractère pour la multiplication (« × ») n'était pas bien géré suite à un bête oubli. C'est maintenant corrigé. Pour Greycess Knight RPG, du point de la personne joueuse, ça n'a aucun intérêt, puisque ce caractère n'est pas utilisé, mais j'ai commencé un nouveau projet à partir de Greycess Knight RPG et lui fera usage de ce caractère.
• Il y avait une confusion entre « ï » et « î », ce qui est maintenant corrigé.

Arrêt du gros tableau unique de chaines de caractères pour absolument tout et n'importe quoi

Vis-à-vis des chaines de caractères, mon jeu a plusieurs grandes « particularités » :

1. Il n'utilise ni ASCII, ni unicode, ni aucune table de caractères standards. J'ai fait la mienne. Le but de cela est de mettre tous les caractères dont j'ai besoin sur 8 bits chacun et donc optimiser l'usage mémoire. ASCII n'inclut entre autres aucun caractère accentué, d'où sa non-utilisation. Évidemment je n'écris pas à la main dans ma table de caractères. À la place de cette possibilité fort fastidieuse et décourageante pour à peu près tout le monde, j'écris dans des fichiers en texte brute encodés en UTF-8, puis un petit programme fait la transformation pour moi.
2. Les chaines ne sont pas mises là où il y en a besoin. Elles sont, ou plutôt étaient, dans un unique grand tableau (cf. strings_all dans la 1.0.0). On y accède donc depuis un indice et il y a dans le code une liste exhaustive des indices avec un nombe symbolique sous la forme de variables pour le pré-processeur C.
3. Je n'utilise aucun système « standard » (comme GNU gettext) pour l'intertionalisation. Mon ex-unique grand tableau était composé d'autant de sous-tableaux qu'il y a de langues gérées (en l'occurrence 2 pour le moment, le français et l'anglais).

Certaines choses (les classes de combattant·e·s et les capacités de combat, mais aussi les objets) ont déjà un indice et elles ont aussi chacune un nom. Il fallait donc faire le lien, ce qui se fasait avec un attribut (de type string_index_t). Ça prenait inutilement de la place, donc maintenant l'indice d'une chose avec un nom est aussi l'indice pour son nom dans un tableau spécifique. Le système est quasiment le même qu'avant, il y a juste plusieurs tableaux maintenant.

Une des conséquences est que ça a baissé significativement la valeur maximale pour string_index_t utilisé pour le reste des chaines. Il était à 300 et a perdu environ 100. Il est donc passé en-dessous de 255 (un indice est réservé pour la chaine de caractères nulle), ce qui a eu pour conséquence qu'il n'a plus eu besoin de 16 bits en pratique (en théorie, avec moins de 512, il n'avait besoin que de 9 bits, mais le découpage se fait par octect, c'est-à-dire par 8 bits, donc il fallait 16 bits en pratique, à moins qu'il soit possible et souhaité d'optimiser l'espace au détriment de la perfomance avec les plusieurs attributs d'un même type entier).

Ça a aussi permis de détecter une erreur de copier-coller. BATTLE_ABILITY_INDEX_SIMPLE_BITE avait STRING_INDEX_BATTLE_ABILITY_DEATH_BITE pour name. L'utilisateur/utilisatrice était donc trompé par le texte dans la boite de dialogue quand son personnage se faisait attaquer pour une morsure simple. Toutefois, ça ne changeait rien en pratique, car la seule différence réside dans state_changer, dont l'usage n'est pour le moment pas implémenté (et qui a d'ailleurs été commenté avec cette version 1.0.1 pour rendre les binaires un peu plus petits). Néanmoins, ça a démontré un avantage inhérent et durable du nouveau système.

Après tout ça, je dois néanmoins admettre que je n'ai pas compris quelque chose. De par le fait qu'il n'y ait plus besoin d'indiquer un indice de chaines de caractères, je m'attendais à un léger gain au niveau du binaire. Le fait de passer de 16 bits à 8 bits pour là où un indice était toujours nécessaire faisait un petit plus (à condition que ce soit effectivement enregistré précédemment sur 16 bits avant et 8 bits maintenant, et non un mot). Il y avait environ 150 chaines dans ce cas là et avec la correspondance faite à un seul endroit. Même en considérant que c'était sur un mot (donc 32 bits ou 64 bits, soit respectivement 4 octects ou 8 octects), je pensais que ça n'aurait fait économiser au plus (hypothèse haute) que 200 × 8 = 1600 octects, soit un peu moins de 2ko. Ça c'était pour la liaison, mais il faut aussi compter les tableaux d'indices de chaines de caractères utilisés pour les contextes de dialogues. Toutefois, ils ne font bien souvent qu'une taille de 2 (un indice « réel » puis l'indice nul) et il n'y en pas non plus des tonnes. En supposant une taille moyenne de 4 et qu'il y en aurait 150 (encore une fois, hypothèse haute), ça ne semble à priori faire qu'une pauvre économie de 600 octects. Mais cela a fait économiser plusieurs centaines de kilo-octects (et je précise que ce n'est pas la seule chose qui a fait réduire la taille du binaire, mais c'est ce qui a eu l'impact le plus signicatif et de loin). Pourquoi ? Je n'en sais rien, mais je serais bien curieux de savoir.

Initialisation des variables extern avec des valeurs bidon pour Apple macOS

La compilation avec le compilateur « officiel » d'Apple macOS a été corrigée. Il voulait que les variables extern soient initialisées avec une valeur (cf. __APPLE__ dans le code source).

Sous GNU/Linux, GCC et Clang n'exigeaient pas ça. MinGW pour GNU/Linux (c'est une adaptation de GCC ciblant Windows, mais aussi WINE et ReactOS qui cherchent à être compatible avec lui) était lui aussi sympa. Emscripten (pour compiler en WebAssembly) avait nécessité d'utiliser extern pour les variables globales (aucun intérêt de faire des tâches simultanément et ça a permit de rendre certaines choses plus simples), mais il ne nécessitait pas pour autant qu'elles soient initialisées avec une valeur.

Du coup, j'ai mis des valeurs bidons, puisqu'il est normal qu'elles ne soient pas initialisées dès le début. En effet, la majeure partie est initialisée quand on démarre une partie (par chargement d'une sauvegarde ou en commencant une nouvelle partie). Pour ce qui est de l'initialisation de la langue, ça utilise celle de l'éventuelle sauvegarde (et ce dès le lancement du jeu, sans que l'utilisateur·e ait encore pu décidé de charger son éventuel sauvegarde ou de faire autre chose) ou ça ouvre un menu spécifique (qui est alors le premier contexte, donc la première vue graphique).

Création de fichiers textes vides sans echo -n

Dans le fichier pour make, pour créer des fichiers textes vides, j'utilisais echo -n '' > 'mon-fichier.txt'. Mais -n n'est pas une option standard de echo, mais un ajout des versions récentes de bash. Du coup, ça ne fonctionnait pas sur Apple macOS. Tant mieux, ça m'a fait découvrir une méthode plus simple : > 'mon-fichier.txt' suffit ! Et ça a peut-être aussi profité aux systèmes BSD quasi-libres.

Ajout d'informations sur la licence des divers éléments

Avec la version 1.0.0, il n'y avait qu'au milieu de son annonce (en tant que « Remerciements ») et en jeu dans un menu pseudo-caché (dans le menu permettant de démarrer une nouvelle partie ou éventuellement d'en charger une déjà existante, appuyer sur l'équivalent de start) que l'on pouvait avoir des informations sur les licences des divers éléments du jeu (code source, bibliothèque SDL2, ressources graphiques, etc.). À la racine des sources, il y a maintenant un fichier LICENSE.md, ce qui permet de plus facilement avoir l'information.

Néanmoins, en ce qui concerne les images, rien n'est dit sur l'auteur de chacune d'entre elles. La seule chose indiquée est que c'est moi-même (GnouCat) ou Kenney d'OpenGameArt. Cependant, ce n'est pas bien grave, puisqu'elles sont toutes sous la license Creative Commons 0 v1.0 (donc dans le domaine public).

Ré-organisation du code source

Comme prévu, je me suis lancé dans un nouveau jeu. Il démarre depuis le code de Greycess Knight RPG. Il gardera grosso-modo les données (les cartes, le scénario, les quêtes annexes cachées, etc.) et ce sera toujours un jeu de rôle en tour par tour très frugal, mais les adversaires et la mécanique des combats vont légérement changer. Ne quasiment rien changer hormis ça me permettra d'obtenir assez rapidement un résultat, de par la relativement petite itération, et les grandes ressemblances ne seront pas bien graves (car, pour le moment, le public est celui des libristes et des développeur·e·s, et Greycess Knight RPG va passer à peu près inaperçu, donc le côté quasi-doublon sera pour bien peu de monde). Mais fermons la parenthèse sur les détails de ce nouveau projet à l'état embryonnaire.

Techniquement il m'incite à améliorer et ré-organiser une partie du code source. Du coup, je le fais d'abord pour Greycess Knight RPG et ensuite je fusionne dans le nouveau projet. Je fais évidemment ça avec un gestionnaire de versions, bien que je ne publie le code source que des versions numérotées (et avec un délai d'au moins 1 mois entre chaque version, y compris quand il s'agit juste d'une ou plusieurs corrections, et ce pour avoir une temporalité qui m'incite à bien tester avant et qui rompe avec la temporalité ultra-rapide que les moyens de communication contemporains et le capitalo-productivisme ont fortement contribué à installer).

Ajout de la cible build-static pour make

Pour faire une construction native avec la SDL2 liée statiquement (qui n'aura alors donc pas besoin d'être installée sous forme partagée au sein des systèmes des utilisateur·e·s), a été ajouté la cible build-static pour make. Pour certaines plateformes, il y avait déjà des règles spécifiques, qui sont supposées fonctionner aussi pour de la compilation croisée (mais en pratique toutes ne fonctionnent pas). Toutefois, ce n'était pas le cas pour toutes et c'est plus pratique de ne pas à avoir à connaitre le nom de la cible spécifique à sa plateforme, d'où l'ajout de build-static.

Ajout de la version sur l'écran d'acceuil

Puisqu'il y a maintenant plusieurs versions, j'ai ajouté le numéro de version sur l'écran d'acceuil. Ainsi on peut très rapidement et simplement savoir si on a la dernière ou si on l'est bien resté sur une ancienne pour je ne sais quelle raison. L'information était déjà accessible via « Informations » du menu hors jeu, accessible avec start depuis le menu d'acceuil, mais c'était pseudo-caché, d'où la visibilisation sur l'écran d'acceuil.

Fortification et amélioration de la lisibilité du fichier pour make

• make éxécute les commandes les unes après les autres pour une cible. Si l'une foire au milieu, il s'arrête bêtement. Si vous créiez votre cible en plusieurs étapes et que les étapes se font avec le nom de la cible, alors vous vous retrouvez avec la cible créée et à jour même si ça a foiré au milieu. En effet, make n'annule pas ce qui a été fait si ça foire au milieu, comme c'est le cas avec une transaction (par exemple avec un système de gestion de base de données). Pour éviter le problème, on peut créer un fichier temporaire (avec mktemp en shell et `(shell mktemp))comme instruction pour une cible dans un fichier pourmake), faire les divers étapes dessus, et seulement à la fin en faire le fichier avec le nom de la cible (avec un simplemv`). De plus, ça peut aussi éviter des problèmes de constructions parallèles. Ce n'est pas grand chose, mais ça peut éviter des pépins et de l'incompréhension dans la recherche de la source.
• C'est relativement peu connu, mais le standard POSIX recommande que -- permette de dire qu'après il n'y a plus d'option. export DIR_TO_RM='--no-preserve-root /' && rm $DIR_TO_RM ne fait par exemple pas ce qu'on pourrait naivement attendre de lui : il prend --no-preserve-root comme une option et c'est le drame avec '/' derrière. Avec -- avant (donc rm -- $DIR_TO_RM), le problème ne se pose pas. Malheureusement -- n'est pas géré par tout le monde, cppcheck et KWStyle sont par exemple de vilains petits canards, toutefois ils ne devraient normalement pas être dangereux.
• export DIR_TO_RM='--no-preserve-root /' && rm $DIR_TO_RM ne donne pas à rm 1 argument mais 2. Pour empêcher cette possibilité, il suffit de lui dire que $DIR_TO_RM doit être traité comme une chaine de caractères représentant 1 seul argument : rm "$DIR_TO_RM". C'est tout bête, mais ça peut éviter des problèmes.
• Dire explicitement avec des guillemets que c'est une chaine de caractères peut être pertinent pour la sécurité (et devrait selon moi être fait systématiquement, même dans les cas où ça ne devrait servir à rien, pour que ce soit une habitude / un pli qui ne nous fait pas omettre la chose quand il le faudrait), mais ce n'est pas le seul avantage. En effet, des éditeurs avec coloration syntaxique (comme mon cher GNU Emacs) mettent les chaines de caractères d'une couleur différente, ce qui facilite l'identification et la différentiation des divers éléments des commandes pour sh.

Ajout de cibles pour la construction pour GNU/Linux

Vous voulez pouvoir construire un paquet Debian vite fait (mais mal fait) pour pouvoir facilement désinstaller ou le partager ? checkinstall est votre ami. Au cas où vous ayez oubliez la commande, il y a maintenant une règle deb dans le fichier pour make.

La nouveauté bien plus intéressante, mais plus crade encore que checkinstall, est la règle appimage pour make. Comme son nom l'indique, elle permet de créer un fichier AppImage. Et c'est quoi l'intérêt de ce truc me demanderez-vous ? Créer un fichier exécutable pour GNU/Linux qui fonctionne en théorie partout sans pré-requis (contrairement à Flatpak). Évidemment pour faire ça, j'ai lié statiquement la SDL2, mais surtout le logiciel de création d'AppImage ajoute de la glu par rapport à une installation standard (avec make install ou le système de gestion de paquets de votre distribution favorite).

La glu pose 2 incovéniants : il faut avoir confiance dans le fait qu'elle ne fait que ce qu'on attend d'elle ; elle alourdit, car forcément elle ne pèse pas rien et elle est exécutée. Je ne recommande donc pas d'utiliser ce genre de système. Mieux vaut obtenir ce qu'on veut depuis sa distribution (mais il faut qu'elle en fasse la distibution) ou le cas échéant compiler soi-même. Mais mon jeu ne sera pas de suite distribué par les principales distributions (si tant est qu'il le soit un jour) et la compilation est rebutante pour les utilisateur·e·s lambdas.

Pour Greycess Knight RPG 1.0.1, je fournis bien un paquet pour Trisquel 9 (car c'est une distribution entièrement libre), Debian 10 et 11 (car c'est presque libristiquement propre), ainsi qu'Ubuntu 20.04 LTS (car c'est très populaire, qu'il n'y a qu'une version de long-terme tous les 2 ans, et que c'est de très loin moins pire que Microsoft Windows pour lesquels je fournis aussi des binaires). Mais ces distributions vont avoir de nouvelles versions, qui vont casser la compatibilité, et évidemment il n'y a pas que celles-ci. C'est pourquoi je fournis maintenant aussi du AppImage.

Ça ne règle cependant pas tout pour la compatibilité. En effet, il reste le problème de l'architecture. Mais je ne connais pas de solution relativement légère à ça. C'est qu'il y a bien une solution, mais elle est affreusement lourde (mais pas forcément plus, selon le point de vue adopté, que de la containairisation à la Docker ou similaire) : l'émulation (par exemple de la Nintendo DS ou mieux de la GameBoy Advance).

Mais pour le moment, je n'ai aucune construction pour une console de jeu vidéo relativement peu puissante et avec au moins un émulateur libre ou un ensemble d'émulateurs libres présents sur les systèmes courants de l'époque (GNU/Linux bien sûr, les *BSD même si là on repassera pour le nombre d'utilisateur·e·s graphiques, Android, Microsoft Windows et Apple macOs). C'est toutefois quelque chose que j'aimerais faire, pour l'intérêt pratique de la compatibilité sur à peu près toutes les plateformes puissantes, mais aussi pour « l'accomplissement technique » (qui n'aurait certes rien d'incroyable). Mais ce n'est pour le moment pas une priorité pour moi (mais, bien sûr, libre à quelqu'un d'autre ou à un collectif de le faire avant que je m'y mette potentiellement).

D'autres changements insignifiants ou oubliés

Je n'ai pas là fait une liste exhaustive. Je me suis contenté de citer les changements importants, ou du moins ceux que je n'ai pas oublié. Il y a aussi des petites améliorations dans le code, dont des vérifications supplémentaires, que je n'ai pas pris le temps d'énoncer.

Télécharger la version 1.0.1

Comme pour la version 1.0.0, je promeuts le téléchargement et le partage par BitTorrent. En effet, ça oblige tout le monde à en supporter le coût, ce n'est pas dans la logique du service avec une disponibilité à toute épreuve (si personne ne partage à un moment, il faut attendre, ou s'en détourner au profit d'autres choses en phase avec la temporalité dominante à l'heure actuelle), et c'est décentralisé donc résilient. À travers ce lien magnet, vous devriez pouvoir un jour obtenir le code source et des constructions pour certaines plateformes. Ce serait sympa de le partager pendant son obtention et après que ce soit fait.

Quelques clients BitTorrent libres

Au cas où vous n'auriez pas de client BitTorrent (ou un qui soit propriétaire), en voici quelques uns qui sont libres :

• GNU/Linux, *BSD, Windows et/ou macOS
  • Transmission
  • Deluge
  • KTorrent
  • qBittorrent
• Android
  • LibreTorrent
  • BiglyBT

Foire aux questions

N'es-tu pas écologiquement incohérent ?

Tu dis vouloir la fin des ordinateurs par écologisme décroissant, mais tu fais un jeu vidéo : ça ne te semble pas être une putain de contradiction ? Très clairement c'en est une. Cela avoué, qu'est-ce que je ferais si je ne faisais pas ça ? Faire un petit jeu en C avec GNU Emacs, ce n'est pas ce qu'il y a de plus consommateur. Il se pourrait bien que je fasse des choses écologiquement pires si je ne faisais pas ça. Malgré mes efforts pratiques (végétalisme, alimentation dite « biologique » et quasi-zéro emballage chez moi, couches de vêtements plutôt que chauffer une pièce entière, pas de climatisation, non-usage de congélateur et réfrigérateur, pas d'accès à Internet et de téléphonie chez moi, évidemment pas non plus de télévision, refus de l'aviation que j'admets avoir pas mal utilisé par le passé, pas d'aspirateur, etc.), je sais bien que cet échellon individuel est bien insuffisant, pour des raisons structurelles « dures » (quasi-obligation de certaines choses et difficulté de changer individuellement des choses quand ce n'est pas impossible) et « molles » (être alternatif peut ne pas être facile pour diverses raisons), ainsi que par inertie/habitude.

On pourrait néanmoins tenter d'arguer que c'est un moyen de diffusion d'idées et d'affectation pour contribuer à engendrer une puissance matérielle pour que les choses changent. Dans cette perspective, le public touché via le biais de jeux vidéos pourrait être en partie différent que d'autres que je touche déjà (par des actions militantes hors ordinatique, des textes, etc.) ou receptif d'une manière différente. Du coup, le coût écologique du jeu pourrait potentiellement (et avec beaucoup d'optimisme) sur le long terme être compensé par certains de ses effets.

Il est aussi possible de tenter une autre argumentation. Celle-ci me parait bien moins bancale. Elle est la suivante : les gens auraient en moyenne fait des choses écologiquement moins biens que de jouer à mon jeu si celui-ci n'avait pas existé. J'ai de l'imagination pour mettre du platre sur mon incohérence !

Pourquoi pas une forge publique ?

Pourquoi ne pas utiliser publiquement une forge et y mettre tous les commits de ton gestionnaire de versions ? Une forge peut disparaitre et vraisemblablement quasiment personne ne lit l'historique des commits. De plus, c'est centralisé, et il me parait bien difficile de faire autrement pour les commits (car répliqué sur chaque instance serait bien trop lourd, ou alors il faudrait un système d'entente pour ne répliquer les choses que sur X instances et pouvoir paramétrer au niveau de l'instance à quel point on veut bien qu'elle soit une source de copies).

BitTorrent est écologique ?

N'est-ce pas écologiquement bien moins bien d'utiliser BitTorrent ? Comparativement à une forge avec tous les commits, ce n'est pas sûr. En effet, avec BitTorrent, je ne partage que les versions finalisées, donc ça représente moins de données au niveau du code source, mais je mets aussi des binaires. En revanche, il est certain que mutualiser la récupération de ressources sur un serveur qui a de l'activité et lui faire donner les dites ressources via HTTP(S) est plus efficace que BitTorrent à données équivalentes. Clairement ne partager que les versions numérotées par HTTP(S) via un serveur avec une bonne activité serait écologiquement meilleur. Cependant c'est moins résilient et ce serait donner du poids à une entité centralisatrice, alors qu'on peut faire autrement. Mon côté autonomie relative et fédéralisme existe aussi.

Quel avis sur la distribution du jeu par des distributions ?

Serais-tu contre que des distributions fassent la distribution de ton jeu ? Bien au contraire, j'aimerais beaucoup. Et elles font déjà de la distribution d'une manière décentralisée avec des mirroirs, et elles pourraient le faire avec BitTorrent ou une technologie similaire pour celles dont les versions ont une durée de vie conséquentes (comme Debian et Trisquel GNU/Linux, ou le pas totalement libre Ubuntu LTS). Toutefois je n'aimerais pas qu'il se retrouve sur Steam de Valve ou Origin d'Electronic Arts ou d'autres plateformes privatrices et/ou ultra-centralisées du même genre. De plus, pour ne rien arranger, il ne m'étonnerait pas qu'elles intègrent des menottes numériques (dites DRM).

Comment contribuer ?

Si je veux contribuer, comment je fais ? Je n'ai pas envie de gérer une potentielle communauté, ou alors une toute petite par frein avec des outils jugés « austères » et/ou « pour radicaux ». Par exemple, ça pourrait typiquement être une forge qui marche intégralement sans JavaScript et gérée par une petite entité, comme Savannah que le projet GNU recommande.

Mais rien n'empêche d'autres de mettre le code où illes veulent et de former une communauté sans moi. Si j'en ai connaissance, je viendrais peut-être y récupérer des choses, avec évidemment attribution de celles-ci. Et pour mon projet en cours, après sa première version (si un jour j'en sors une), je serais particulièrement friand de nouvelles ressources graphiques bien faites et de sons, que je suis incapable de produire.

Je fais ce jeu en bonne partie pour m'amuser. Mon but n'est pas d'y consacrer trop de temps. Dans le cas contraire, une organisation collective du projet aurait effectivement été pertinente avec moi dedans, mais là je laisse d'autres potentiellement initier et porter quelque chose si ça en motive.

Pourquoi avoir fait ton propre moteur ?

Pourquoi ne pas utiliser un moteur déjà existant ? Je n'en connais pas qui puisse potentiellement permettre de gérer GNU/Linux, *BSD, Android, le Web, la Nintendo DS (j'en ai une et je rêverais de jouer dessus à un jeu libre que j'ai moi-même fait, ce qui est possible avec une carte non-officielle dans laquelle on peut une carte microSD avec des exécutables dessus) et la GameBoy Advance (par défi technique, car elle a peu de ressources, et parce que ça s'émule à peu près partout et d'une manière « légère » comparativement aux consoles plus récentes).

Pourquoi autant de texte sur si peu de place ?

Pourquoi dérouler autant de texte et l'afficher sur si peu de place ? Par simplicité technique et parce que ce n'est pas juste un jeu de baston, il y a parfois pas mal de texte, en particulier quand on commence le début du jeu où il fait expliquer les interactions. Ça pourrait parfois être fait d'une manière graphique, avec des vues spécifiques, mais ça aurait nécessité du travail en plus et je préférais sortir quelque chose relativement vite que peaufiner chaque petit détail et sortir quelque chose bien plus tard (si je ne finissais pas par me décourager). Pour ce qui est de l'espace alloué au texte, il pourrait être optimisé avec une police plus petite, ce qui éviterait de cacher plus de choses avec 3 lignes au lieu de 2, ou de faire un contexte pour une boite de dialogue avec 2 lignes et une autre avec 3 lignes.

Pourquoi cet énorme bloc de texte au début ?

Pourquoi imposer au début d'une partie un énorme bloc de texte pour expliquer les interactions au lieu d'une autre solution ? Tout le monde conviendra qu'il faut expliquer comment intéragir, puisqu'il n'y a pas une limitation de par le terminal, comme c'est le cas avec les consoles de jeu. J'avais 2 grandes possibilités : miser sur la lecture d'une explication en-dehors du jeu avant qu'il ne soit lancé, ou une explication au début d'une nouvelle partie (qui pourrait ne pas être forcée avec une question préalable qui demande si on la veut, mais il n'y a pour le moment une telle chose implémentée, donc ça aurait demandé du travail en plus et en conséquence ça aurait retardé la sortie d'une première version, voire aurait avec d'autres choses fini par me décourager à force de ne rien sortir pour peaufiner plein de choses).

La première, une explication hors-jeu, me parait bien trop optimiste. De nos jours, les gens ont pris le pli que les manuels ne serviraient à rien, ou juste dans d'obscurs cas. J'ai donc préféré intégré l'explication au jeu et dès son début. Pour éviter un énorme bloc de texte, j'aurais pu préalablement demander si on voulait l'explication (pour épargner celleux qui ont eu l'explication d'une façon externe ou qui font une nouvelle partie) ou la faire d'une manière graphique (comme c'est par exemple le cas avec Pokémon Rouge Feu et Vert Feuille pour GameBoy Advance, utilisé comme base de nombreuses hack-ROM). Mais cela aurait demandé plus de travail, donc ça aurait retardé la sortie, hors sortir relativement régulièrement des choses est plus encourageant et pousse à se focaliser à avoir quelque chose dans un état globalement convenable et fonctionnel au lieu de s'éparpiller à peaufiner d'abord plein de détails et au final ne pas avoir quelque chose de globalement fonctionnel dans un état acceptable du point de vue de l'utilisateur·e (je pense là par exemple à Tuxemon et OpMon, mais aussi à Libervia contrairement à Movim, ainsi qu'évidemment à GNU Hurd qui n'a pas eu le temps d'avoir sa chance face au monolithique Linux, mais ce ne sont là que des exemples parmi bien d'autres de sur-peaufinement de certaines choses avant d'avoir quelque chose de globalement fonctionnel et d'éparpillement par bien trop de fonctionnalités au lieu de se concentrer d'abord sur en avoir quelques unes qui soient dans un état acceptable pour une certaine proportion d'utilisateur·e·s ou une trop forte focalisation sur l'innovation au détriment de l'essentiel).

Et la version web ?

Dans l'annonce de la version 1.0.0, tu indiquais que tu arrivais à faire une construction web (avec Emscripten), mais qu'elle ne fonctionnait pas bien, est-ce maintenant de l'histoire ancienne ? En effet, avec la version 1.0.0, il y avait un problème lors de l'usage d'une fonction de formattage de chaines de caractères larges (en l'occurrence vswprintf). Avec les correctifs relatifs à ça, que j'ai mentionné ci-avant, je me suis dit que j'avais alors peut-être corrigé sans faire exprès la version web.

Mais j'ai bien cru que finalement je n'en saurais rien ! En effet, je n'arrivais plus à compiler la SDL2, à cause de la variable was_error de SDL_Delay, qui n'est pas déclaré avant la première instruction, ce qui provoque une erreur de respect du standard C (du moins dans ses versions inférieures à C99). En utilisant une version plus récente de la SDL2 (j'étais pourtant avant sur la dernière stable, la 2.0.20), le problème n'existe plus. J'ai ensuite eu une autre mésaventure, cette fois avec __stack_chk_guard qui n'était pas défini. Mais avec -fno-stack-protector -D_FORTIFY_SOURCE=0 (et effectivement ce genre de protection semble particulièrement inutile pour une construction web), il était calmé.

Las, ça ne fonctionne toujours pas comment attendu. Des chaines de caractères sautent purement et simplement ! J'ai eu la flemme de re-tenter d'investiguer. C'est pourquoi je ne propose toujours pas une construction web, malgré que ça compile et fonctionne très bien hormis pour ça (mais le problème me semble trop embêtant du point de vue utilisateur).

Pourquoi utiliser l'identité « GnouCat » ?

Pourquoi utiliser l'identité « GnouCat » et pas celle officiellement reconnue par l'État ? Il n'aura échappé à personne qu'à travers cette identité j'exprime des opinions politiques qui ne sont pas vraiment en phase avec l'idéologie dominante. Et je compte continuer de le faire. Mais ça ne pourrait pas plaire à des personnes individuelles ou morales (États, patrons, fascistes, etc.), donc pourquoi m'exposer ? Pour ce qui est de la valorisation de la partie technique de ce travail auprès d'un potentiel employeur, j'ai de toute façon pour le moment déjà un emploi.

Mais n'est-ce pas problématique vis-à-vis du droit d'auteur·e ? Comme faire respecter le gauche d'auteur·e ? Pour le moment, le problème ne se pose pas et je doute qu'il se pose un jour ou au moins pas avant pas mal de temps. Si un jour il venait à se poser, j'ai un dépôt avec mon gestionnaire de versions, donc je pourrais le publier en mon nom reconnu officiellement par les États pour attaquer en justice afin de faire respecter de force la réciprocité. Je pourrais aussi donner mon droit d'auteur·e à une entité externe qui le voudrait bien (on pourrait par exemple imaginer que ce soit la Free Software Foundation) pour que ce soit elle qui s'expose et ainsi que je puisse continuer de rester dans l'ombre vis-à-vis de cette activité.

Pourquoi utiliser C et pas un autre langage de programmation ?

• Pourquoi pas Go ? L'implémentation de Google est libre et il y a le moins connu gccgo, tous deux avec des paquets fournis par les distributions, donc je n'y vois pas de problème du point de vue du librisme, même si c'est fait par Google que je n'aprécie pour le moins pas. La première raison est simple : je n'ai jamais utilisé ce langage. La seconde l'est aussi : quel en aurait été l'intérêt ? Il n'y a pas de gros traitement et il n'y a pas vocation à ce qu'il y en ait dans le futur, donc la concurrence m'est inutile et à fortiori le système apparemment simple qu'offirait Go là-dessus. La troisième est logique vis-à-vis de ma frugalité : pourquoi s'encombrer de choses lourdes ? Il n'y aurait notamment pas d'accès direct à la mémoire et un ramasse-miettes serait imposé, mais je peux gérer la mémoire comme un grand et ce n'est pas comme si j'avais besoin d'en allouer dynamiquement (si ce n'est pas pour la SDL2). Enfin, la quatrième est vis-à-vis d'un petit rêve : il n'y a à ma connaissance pas de gestion des veilles consoles de jeu vidéo, comme il y a en C notamment avec devkitPro pour les consoles Nintendo, donc ça m'empêcherait de peut-être un jour faire ça, ce qui serait dommage.
• Pourquoi pas Rust ? Encore une fois, et ce n'est pas dans l'absolu une bonne raison, je n'ai jamais utilisé ce langage. Comparé à Go, il permettrait une gestion mémoire directe. Son système de type pourrait permettre plus de détection d'erreurs avant l'exécution, ce qui serait cool, mais avec GCC et Clang avec pas mal d'options (dont -Wall et -Wextra évidemment, mais pas que) pour vérifier plein de choses, plus cppcheck et KWStyle, c'est déjà bien scruté avant les tests automatiques d'exécution (avec la bibliothèque check et CTest intégré à CMake). Pour ce qui est de la sécurité, malgré que le code du binaire soit intégralement du C, il y a à priori bien peu de risque, puisque les seules entrées sont les touches du clavier et/ou d'une manette et le fichier de sauvegarde qui lit octect par octect et des petites séries d'octects avec généralement vérification des valeurs lues, sans compter que le code est compilé de sorte que l'exécutable soit position-indépendant (via set(CMAKE_POSITION_INDEPENDENT_CODE ON) avec CMake qui s'occupe de donner la bonne option au compilateur) et avec au cas où de la fortification (via les options -fstack-protector-strong et -D_FORTIFY_SOURCE=2, qui sont probablement inutiles dans le cadre de mon jeu, mais qui ne sont pas bien lourdes et pas appliquées à quelque chose de lourd, et qu'il faudrait désactiver pour les éventuelles futures constructions où il n'y aurait par construction pas de risque de sécurité puisque le programme est seul dans son petit monde). Enfin, on peut faire un binaire pour la NDS et la GBA avec Rust, ce qui est un bon point inattendu au vue de la relative jeunesse du langage et du faible intérêt à gérer ces veilles machines délaissées.
• Pourquoi pas C++ ? Ça j'en ai fait, pas énormément, mais pas non plus juste quelques heures. Mais c'est un langague hyper-compliqué, avec plein de concepts, à tel point que Bjarne Stroustrup (rien de moins que le créateur de C++ ! et encore bien actif sur C++) ne connaitrait que « seulement 60 % du standard » ! De plus, ça fait des trucs magiques, dont certains sont dangereux (je pense notamment au constructeur par copie et à l'opérateur d'affectation pour une classe, car par défaut il en sont automatiquement créés et ceux-ci font une bête copie des membres de l'instance de la classe, ce qui est trèmauvais s'il y a un pointer vers une ressource allouée dynamiquement, car ça engendre des tentatives de désallocation qui n'ont pas lieu d'être, donc ce qui se veut être une aide peut créer des comportements non-souhaités si on ne pense pas systématiquement à y faire attention). Certes, au moins, c'est bien géré pour faire des binaires sur de veilles machines. Mais dans mon cas, qu'est-ce que ça apporterait par rapport à du rustique C (je ne suis pas pour autant anti-C++) ? Hormis de la complexité et de la lourdeur dans le binaire, je ne vois pas trop.
• Pourquoi pas en assembleur ? Malgré mon amour du C, donc d'un langage relativement bas niveau, je suis une grosse bouse en assembleur et je n'en ai fait que quelques heures. Mais il y a une raison bien plus importante et radicalement éliminatoire : ce n'est pas portable.
• Pourquoi pas Java ? Ça va peut-être vous étonner, mais j'aime bien ce langage. Une implémentation libre bien sûr, du typage obligatoire (dommage toutefois qu'il ne soit pas possible d'indiquer la nécessité de la non-nullité sans une annotation), une seule classe publique par fichier (mais ce serait mieux que ce soit juste une classe tout court), obligation d'indiquer dans la signature la ou les éventuelles exceptions qui peuvent arriver (ce qui oblige à les gérer ou au moins à visibiliser qu'on s'en torche), historiquement pas de fonctions anonymes (ce qui force à nommer les choses et est bien pour faire des tests unitaires, mais à mon regret ça a changé avec Java 8), pas d'héritage multiple (mais encore une fois Java 8 n'a pas été mon pote), des outils libres pour la qualité (JUnit pour les tests automatiques, checkstyle pour des vérifications statiques, et même Eclipse qui n'est malheureusement plus distribué par les versions récentes de Debian), entre autres choses. Toutefois on repassera pour la légerté à l'exécution, le minimalisme pour l'exécution du binaire (avoir besoin d'une machine virtuelle Java, du moins depuis la mort de GNU Compiler for Java), et évidemment pour la gestion large des vieux systèmes.
• Pourquoi pas Python ? Je trouve que c'est très bien pour les scripts, mais au-delà je préfère largement un langage comme Java (que, révélation !, je préfère à C++, de par le fait qu'il est plus strict).
• Pourquoi pas JavaScript ? Comme langage pas sûr, il a un certain niveau. Évidemment pour les systèmes embarqués (comme la Nintendo GameBoy Advance), il ne faut pas compter sur lui. Bref, non. Et c'est sans avoir parlé des multiples ré-inventions faits dans ce langage et des multiples bonheurs de npm, mais avouons que ce n'est pas le langage lui-même et qu'on peut donc faire avec lui sans ce merdier, et qu'on peut saluer l'existance de TypeScript pour amoindrir les défauts (du moins pour autre chose que des petits scripts, où là JavaScript me va très bien pour programmer, mais pas pour recevoir du code arbitraire dans le navigateur web et souvent devoir quitter le site web par refus de le faire exécuter ou par usage de Dillo ou Emacs Web Wowser).
• Pourquoi pas Ada, D, GDScript, Vala ou Objective-C ? Je ne vais pas m'attarder sur tous les langages, j'en ai déjà fait beaucoup.

Pourquoi proposer un paquet Debian pour Ubuntu ?

N'est-ce pas incohérent avec ton librisme de proposer un paquet Debian pour Ubuntu ? Il est vrai que la Free Software Foundation ne recommande pas Ubuntu et pour des raisons que j'approuve. Cependant, est-ce une raison pour ne pas rendre la vie facile à la distribution GNU/Linux de loin la plus utilisée par les particuliers ? Je ne le prense pas. Je propose d'ailleurs aussi des paquets pour Debian GNU/Linux, qui pose lui aussi problème, même si c'est dans une bien moindre mesure qu'Ubuntu. Mais surtout j'en propose pour Windows, car c'est tristement un gros vivier d'utilisateur·e·s et parce que j'arrive à compiler pour lui avec des outils libres fournis par ma distribution GNU/Linux (contraiement à Apple macOS).

Si en même temps je proposais des binaires pour Windows et que je me refusais idéologiquement à le faire pour Ubuntu (qui est de très loin bien moins problématique que Microsoft Windows), ce serait désaventager GNU/Linux par rapport à un système d'exploitation privateur et très lourd (pas sûr toutefois que l'environnement de bureau GNOME par défaut dans la distribution « officielle » et Kubuntu soient significativement plus légers que Windows, mais il y a aussi Lubuntu et Xubuntu). On pourrait alors me faire remarquer que je devrais faire des paquets pour bien plus de distributions GNU/Linux et pour des BSD, ce qui est idéalement vrai, mais je ne le fais pas pour des raisons pratiques (il faut installer le système, puis y installer ce qu'il faut, ensuite compiler, et enfin récupérer le binaire packagé ou pas, ce qui prend du temps et de l'énergie, autant biologique que non-biologique d'ailleurs, avec de plus un coût non-négligeable en espace disque).