Greycess Knight RPG : sortie de la première version !

Posté par  . Édité par Ysabeau 🧶, palm123 et Benoît Sibaud. Modéré par Ysabeau 🧶. Licence CC By‑SA.
25
25
déc.
2021
Jeu

Greycess Knight RPG est un jeu de rôle ordinatique en tour par tour. Il est très basique, autant au niveau du moteur que graphiquement. Bien sûr, il est entièrement libre. Autant le code source que des binaires pour certaines plateformes sont disponibles via BitTorrent. Sur ce, bonne lecture pour celles et ceux souhaitant des détails.

Sommaire

Qu’est-ce que Greycess Knight RPG ?

Greycess Knight RPG est un jeu de rôle ordinatique en tour par tour (comme Golden Sun sur GameBoy Advance ou les plus connus jeux vidéos Pokémon « classiques »). RPG est un acronyme anglais pour « Role-Playing Game ». Son système de combat est pour le moment très très basique, comme le reste.

Pourquoi avoir fait ce jeu ?

Avec le premier confinement en 2020, je me suis remis à jouer, avec des jeux pour GameBoy Adavance. Je me suis dit que ces jeux étaient plutôt simples, de là m’est venue l’envie. Et j’ai plusieurs raisons qui m’ont motivé à me lancer dans l’aventure, dont :

  • le très faible nombre de jeux libres (je préfèrerais ne pas émuler des jeux privateurs et l’émulation consomme pas mal de ressources comparée à une exécution native ; pour le faible nombre, le méta-paquet games-rpg de Debian est assez illustratif, bien qu’il ne regroupe qu’une portion, comme le montre LibreGameWiki.org, probablement pour des raisons de droit d’auteur·e sur les ressources hors code ou juste par manque de forces pour faire les paquets),
  • m’amuser en programmant (chacun ses trucs…),
  • m’occuper autrement qu’habituellement (le travail contraint pour vivre et le militantisme),
  • faire de petites améliorations par rapport à certains jeux auxquels j’ai joué (mais pour le moment c’est globalement de très loin bien moins bien).

Greycess Knight RPG : un jeu vidéo basique

Il adopte la résolution graphique de la GameBoy Advance (240 de largeur et 160 de hauteur) et n’a plus généralement de grandes ambitions graphiques. En effet, c’est le moins que l’on puisse dire, puisque je suis très mauvais en réalisation graphique et que j’ai donc opté pour un jeu en nuance de gris avec 16 couleurs (dont 15 couleurs « vraies » et une couleur pour la transparence).

Cette simplicité, graphique mais pas que, s’explique pour plusieurs raisons. Il y a évidemment le peu de moyens : une seule personne, avec un travail salarié pour gagner sa croute, et des activités politiques non-politiciennes. Mais avec plus de temps, il aurait été possible de faire mieux, certes, mais il y a la volonté de sortir vite un truc pour ne pas se décourager et probablement finir avec un truc qui fait plein de choses mais qui n’est pas fini et risque d’en rester éternellement là (comme Tuxemon et OpMon).

Enfin, il y a une dernière raison : l’écologie. Un jeu vidéo n’a pas besoin d’avoir une machine puissante pour être agréable. Le « rétro-gaming » en est un exemple empirique et pas marginal. J’admets toutefois qu’en l’état il est loin d’être optimisé graphiquement, même si ce qu’il fait est très basique et pourrait donc être fait d’une manière ordinatiquement sobre. Ce ne serait d’ailleurs pas compliqué, mais ça demanderait un peu de temps, donc ce sera pour une potentielle prochaine version. Et on peut rajouter qu’il faudrait probablement en finir avec les ordinateurs pour faire une société écologique (condition nécessaire mais non suffisante), en tout cas c’est mon avis (là-dessus on peut par exemple lire « The Monster Footprint of Digital Technology » de Kris De Decker du low-tech magazine), donc j’admets que la sobriété n’est que vis-à-vis de l’ordinatique et que c’est en contradiction avec ma vision écologique, mais j’arrête là de vous ennuyer avec ça.

Quel moteur technique ?

Je voulais un moteur libre (au sens de la Free Software Foundation). Celui-ci devait pouvoir fonctionner ou être rendu fonctionnable sur n’importe quelle plateforme ou presque (GNU/Linux, *BSD, Web, Android, Nintendo DS, GameBoy Advance, Wine / ReactOS / Windows, macOS, etc.). À ma connaissance, ça n’existait pas, mais je n’ai pas non plus beaucoup cherché.

J’ai donc fait le mien, en démarrant au début de cette année 2021, donc fait en seulement un an environ (sur mon temps libre je le rappelle). Il est codé en langage C99, ce qui est géré partout (ou presque). Il utilise la bibliothèque C standard et la seule autre bibliothèque qu’il utilise est la SDL2 (du moins en ne considérant pas les tests automatiques, car check est utilisé dans ce cadre, ainsi que la transformation des images PNG en code C, qui utilise SDL2_image).

Ça permet de gérer GNU/Linux (sur-lequel je développe), *BSD, macOS et Windows (que je n’ai sur aucune de mes machines, et c’est des systèmes privateurs et payants, donc c’est théorique, mais il serait facile à quelqu’un de compiler dessus et de tester). Et il y a aussi le Web (avec WebAssembly et Emscripten) et Android (pour lequel il existe la distribution libre Replicant et le pseudo-magasin d’applications F-Droid).

Pour ce qui est de la gestion des consoles de jeu vidéo, ça devrait être possible au moins pour les consoles de Nintendo, celles portables de Sony et la PS2, mais cette possibilité n’est pour le moment pas exploitée (et ne le sera peut-être jamais). Pour les consoles de Nintendo ou du moins nombre d’entre elles (à l’exception notamment de la Nintendo 64), il y a devkitPro et des adaptations de la SDL1 pour de nombreuses machines de Nintendo, ainsi que tonc et d’autres bibliothèques pour la GBA (qui, au vu de ses faibles caractéristiques, nécessitera fort vraisemblablement de coder en natif, si tant est qu’il y ait un port fonctionnel de la SDL pour elle). Il serait aussi à priori possible de gérer 2 consoles portables de Sony : la PlayStation Portable ou PSP (qui a un kit de développement libre, un port SDL2 et un port SDL1, ainsi que 2 émulateurs libres : PPSSPP et JPCSP) ; et sa successeure, la Sony PlayStation Vita (pour qui il existe Vita SDK, un port de la SDL1 et un de la SDL2, ainsi que l’émulateur libre Vita3K). Enfin, la Sony PlayStation 2 (PS2) devrait aussi pouvoir être gérée (avec ps2toolchain pour la compilation, un port SDL, et l’émulateur PCSX2 pour tester rapidement et facilement), tandis que la Sony PlayStation 1 (PS1) n’a pas de quoi faire (il y a bien PSn00bSDK, mais il ne serait pas encore prêt, il ne semble pas y avoir de port de la SDL, si tant est que ça puisse avoir un intérêt au vu des faibles caractéristiques de la machine, donc il est invraisemblable que je me lance un jour dans l’aventure d’un port pour PS1).

Enfin, de par la dépendance à seulement la bibliothèque C standard (sans les ajouts POSIX) et la SDL2, ça ne devrait pas casser à l’avenir, ou alors très faiblement. En effet, l’API de la bibliothèque C standard ne va évidemment pas changer, mais celle de la SDL2 va peut-être, mais il est fort peu probable que ce soit significatif, donc ça devrait être simple et rapide d’adapter pour une nouvelle version qui casserait la rétro-compatibilité. De plus, la SDL2 est suffisamment légère et simple à compiler pour la lier statiquement, donc le jeu pourra continuer à fonctionner avec une veille construction ou même continuer d’être développé avec une version ancienne (même si ce n’est pas du tout souhaitable). C’est donc bien plus propice à la stabilité : le langage ne va pas casser, contrairement à Python avec le passage de la version 2 à la 3 (qui impacte par exemple Fall of Imiryn qui utilise le moteur Annchienta) ; C est plus simple que C++ par exemple, donc l’ABI (Application Binary Interface) est moins susceptible de changer ; pas de dépendance qui va disparaitre ou ne plus être maintenu (comme Hero of Allacrost qui utilise Qt4) ; pas de construction compliquée ; pas plusieurs langages à connaitre hors construction (comme Lua, utilisé par exemple par Valyria Tear, qui est un RPG libre 2D très poussé) ; pas besoin de service à l’exécution (comme CatchChallenger qui a un modèle client/serveur et besoin de PostgreSQL !) ; possibilité de tout mettre dans le binaire simplement (ce qui devient évidemment compliqué et lourd quand on utilise un langage de script, comme RogueBox Adventures) ; etc.

Quelques détails techniques

  • Pour pouvoir peut-être un jour gérer les consoles, tout est dans le binaire. Il n’est donc pas fait usage du système de fichiers. Les chaines de caractères et les images sont du coup convertis dans un format minimaliste et sont ensuite compilées.
  • Les chaines de caractères n’utilisent ni char ni wchar_t ni wint_t pour représenter un caractère. Cela permet de n’utiliser qu’un octet par caractère et de gérer un plus grand ensemble que l’ASCII (American Standard Code for Information Interchange). En effet, l’ASCII n’en utilise que 127, ne contient pas de caractère accentué (ce qui est quasi-indispensable pour le français) et a certains caractères qui ne nous serviraient à rien (et réduiraient donc, inutilement dans notre cas, le champ des possibles sur une même quantité de mémoire). J’ai donc fait ma propre table des caractères et chaque caractère tient sur un seul octet. C’est pourquoi les chaines de caractères sont converties et ce depuis des fichiers en texte brut éditables avec un éditeur banal (comme nano).

Quelques déconvenues techniques

Tout ne s’est pas passé exactement comme prévu. Certaines choses n’ont pas réussi à être faites comme prévu. De mémoire, il y a au moins :

  • incapacité de ma part à mettre du const à certains endroits, alors que ça devrait pourtant être possible, mais les compilateurs ne m’ont pas assez aidé
  • erreur de compilation pour la cible x86 32bits pour GNU/Linux (cf. make build-glinux-x86-32) et de même pour les cibles ARM
  • SDL_RenderSetLogicalSize n’est pas aussi satisfaisant qu’attendu (pas de centrage et hors vue logique pas mis en noir)
  • problème dans l’obtention de chaines de caractères formattées avec vswprintf dans le cadre du Web (qui utiliserait musl, une implémentation libre de la bibliothèque standard du langage C) malgré une tentative avec l’usage de setlocale, mais il faudrait de toute façon écrire une fonction similaire (car je n’utilise ni char ni wchar_t ni wint_t Pour représenter un caractère afin d’optimiser l’usage mémoire)
  • non-gestion de la SDL2 par WINE, donc je ne sais pas si les compilations Windows (faites avec MinGW) fonctionnent
  • problème avec ReactOS (un clone libre de Windows) sous GNOME Boxes, ce qui était ma seconde tentative pour tester les binaires Windows
  • incapacité à compiler pour la Nintendo Switch avec devkitPro, bien qu’il y ait un compilateur et un port de la SDL2

Une suite ?

L’état, vraiment très basique, invite à faire une suite, et j’ai plein d’idées en stock (ce n’est pas bien compliqué d’en trouver…). Parmi celles-ci, il y aurait entre autres :

  • une bonne gestion de la vue logique (centrage et bords noirs),
  • une police plus petite et potable (Spleen est une possibilité, mais aussi celles de Jeremy Oduber pour GB Studio et d’autres (dont au moins certaines non-libres) pour le logiciel éponyme, ainsi que celles de Kenney),
  • ajout et usage de sons et musiques (il y a une section pour chaque chez OpenGameArt.org, de même pour le RPG libre Valyria Tear, idem pour le Pokémon-like Tuxemon),
  • demander confirmation de fermeture de la fenêtre (par clic sur le bouton de celle-ci, Ctrl + Q ou Ctrl + W),
  • ajout d’un nom pour les cartes et l’afficher,
  • la gestion d’un état pour les combattant·e·s (empoisonné, enflammé, gelé, en train de saigner, confus, paralysé, endormi, etc.),
  • la séparation entre le physique et le spécial pour l’attaque et la défense (sur le modèle de Pokémon),
  • différentes classes avec des avantages et faiblesses entre elles, et ensuite pouvoir en régler l’importance ainsi qu’un mode pour inverser celles-ci,
  • la possibilité d’apprendre et d’oublier des capacités (au lieu d’une liste fixe par type de combattant·e),
  • implémenter des types de terrain (« normal », plaine, béton, forêt, grotte, sur l’eau, sous l’eau, montagneux, volcan, etc.) et des types de météo (« normal », ensoleillé, pluvieux, neigeux, venteux, tempête de sable, canicule, etc.) ayant une influence en combat,
  • des transitions (entre le passage de certains contextes à des autres, et durant les combats),
  • optimiser le temps de rendu graphique (déjà fait pour la carte et le « menu de commandes », mais ça pourrait être mieux, et surtout ça devrait être généralisé),
  • un mode KO punitif / game over,
  • option sur le droit ou pas à l’usage d’objet en combat,
  • un mode « végan » où il ne faut pas mettre KO mais affaiblir suffisamment mais pas trop,
  • ne plus avoir les types de combattant·e et les capacités en dur en C au profit de fichiers XML transformés avec XSLT (pour pouvoir à l’avenir plus facilement en changer la structure de données),
  • rendre les cartes plus grandes que la surface visualisable et gérer la caméra, puis avoir une structure de carte pour avoir des cartes de taille infinie ou presque (à la manière de Pokémon par exemple),
  • permettre de changer les éléments sur l’avant-plan d’une carte (pour entre autres rotationner les personnages quand on leur parle et les faire se déplacer lors de scènes),
  • donner une visibilité potentielle aux éléments de l’avant-plan et la capacité d’agir si quelque chose entre dans leur champ de vision (à la manière des dresseurs et dresseuses dans Pokémon qui peuvent bloquer le personnage et venir vers avant de déclencher un dialogue puis un combat),
  • implémenter un algorithme du plus court chemin,
  • un port Android (ce qui devrait être aisé avec la SDL2) et une manette virtuelle en impression écran (comme les émulateurs sur Android),
  • enregistrement de la sauvegarde à un endroit approprié (dans $HOME/.config/ sous GNU/Linux),
  • faire la sauvegarde dans un nouveau fichier et n’écraser l’actuelle que si l’écriture de la nouvelle sauvegarde a réussi jusqu’au bout,
  • implémenter une somme de contrôle pour la sauvegarde,
  • rapporter les messages d’erreur de la sauvegarde dans l’interface graphique et plus sur stderr,
  • plusieurs modes pour les entrées clavier (avec combinaison possible si compatible),
  • permettre de changer le nombre d’images par seconde,
  • la gestion de SDL1 en plus de SDL2 (pour gérer les systèmes sans implémentation de SDL2 mais avec une implémentation de SDL1, comme c’est le cas notamment pour de nombreuses consoles portables de Nintendo et pour lesquels devkitPro fournit des chaines de compilation),
  • un port NDS (idéalement, on a le droit de rêver, avec la SDL), puis un port GBA (car la NDS a de bien meilleures caractéristiques que la GBA, donc autant commencer par la NDS avant la GBA),
  • n’afficher que la vue pour la version web (et donc virer l’emballage d’Emscripten), puis idéalement tout mettre dans un seul fichier HTML (le HTML, le WebAssembly, et le JavaScript qui fait glu),
  • faire de quoi construire un paquet Debian, puis de même pour un paquet RPM et éventuellement d’autres procédures d’installation dans le genre (SliTaz, ArchLinux, GNU Guix, Flatpak, Ubuntu Snap, etc.),
  • améliorer l’exécutable WINE / ReactOS / Windows avec un meilleur fichier de ressources,
  • avoir un sprintf personnalisé adapté au format de chaîne de caractères (au lieu de faire une conversion en chaîne de wchar_t, puis passer le résultat à swprintf, et enfin reconvertir dans notre format),
  • avoir une implémentation de qsort avec laquelle la fonction de comparaison prend un argument arbitraire (pour éviter d’avoir besoin d’une variable globale, cf. battle_compare_speed_of_fighter_index_generic),
  • optimiser l’usage en mémoire avec un gros union globale dont chaque membre représenterait un contexte (voir les contrôleurs pour comprendre ce que j’appelle « contexte ») ou plutôt un méta-contexte (carte, combat, etc.),
  • mutualiser du code entre le type de menu pour des commandes et le type de menu pour des objets (notamment la gestion des menus longs qui ne peuvent totalement s’afficher à l’écran à un même moment),
  • organiser mieux le code source (avec plus de fichiers et de dossiers),
  • faire beaucoup plus de tests automatiques d’exécution,
  • implémenter un clavier virtuel,
  • permettre de parcourir les données du jeu en son sein,
  • permettre d’extraire les données du jeu en HTML et/ou LaTeX,
  • gérer FreeDOS et DOSBox (car pourquoi pas ?),
  • faire un éditeur graphique de cartes (comme Porymap pour les jeux Pokémon « classiques » de la troisième génération).

Tout cela est bien joli, mais ça demande du temps, de la motivation, etc., donc le futur est incertain. En tout cas, il l’est en ce qui me concerne. Mais, puisque le jeu est libre et peut être modifié en n’utilisant que des logiciels libres dans la totalité de sa chaine, vous pourriez très bien continuer le travail !

Pourquoi ce nom de jeu ?

  • grey : le jeu est en nuance de gris.
  • cess : le but est de sauver une princesse (original n’est-ce pas ?).
  • knight : le personnage incarné est un chevalier.

Je voulais un nom cours et unique. C’est pourquoi « princess » a perdu son début et que je l’ai concaténé avec « grey ».

Remerciements

Télécharger le jeu

Vous pouvez l’obtenir via BitTorrent. Le torrent contient le code source et des versions compilées. Certains clients BitTorrent permettent de ne télécharger que certains fichiers si vous le souhaitez. Mais ce serait cool que vous téléchargiez et partagiez le code source, même si vous n’en faites rien, pour qu’il ne se perde pas.

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 :

Pourquoi partager le jeu exclusivement via BitTorrent ?

L’intérêt principal que j’y vois est que c’est décentralisé en très grande partie et résilient. Une forge peut disparaitre et vraisemblablement quasiment personne ne lit l’historique des commits. Un site web pour le jeu nécessiterait du travail et de la gestion, même si ce serait minimal avec un site statique sur le serveur.

Ça permet aussi de partager le coût de l’infrastructure et de mettre en lumière le fait qu’elle n’est pas magique. Si personne ne partage (et je ne suis pas connecté 24h/24 et 7j/7), alors on ne pourra pas avoir le jeu, du moins par le moyen par lequel je l’ai partagé. Et si le partage est lent, alors il faut se résoudre à attendre ou laisser tomber.

De toute façon, puisque le jeu est libre, rien n’empêche des tiers de l’héberger ailleurs et autrement, ou de le partager par un autre médium (clé USB, CD, etc.). On peut mettre le code source dans une forge, il pourrait être distribué par des distributions GNU/Linux et *BSD, par F-Droid pour Android, etc.

Comment compiler le jeu ?

Si vous n’avez pas confiance dans une version compilée fournie ou qu’elle ne fonctionne pas (à cause d’une différence d’API et/ou d’ABI), vous pouvez obtenir le jeu sous forme exécutable depuis le code source. Hormis pour Wine / ReactOS / Windows, dont l’API et l’ABI sont stables (ce qui est chiant pour l’évolution mais pratique pour la compatibilité), vous aurez probablement à en passer par là, à moins que vous ayez la chance d’avoir votre distribution GNU/Linux ou système BSD qui fait le travail pour vous (et donc au moins une gentille qui a fait le travail nécessaire à cela) ou que vous en passiez par un méga-conteneur bien hideux et ultra-lourd (comme le permettent notamment Flatpak et Snap).

Dans le cas contraire, rassurez-vous. La compilation n’est pas compliquée et ne nécessite pas grand-chose. Sous les systèmes avec APT (Advanced Packaging Tool), dont Debian et Trisquel GNU/Linux, il vous suffit de faire ce qui suit dans un terminal textuel :

$ sudo apt install gcc make cmake libc-dev libsdl2-dev libsdl2-image-dev
$ cd greycess-knight-rpg-code/
$ make

L’installation de ce qui est nécessaire à la compilation (avec apt dans le cas de Debian et Trisquel GNU/Linux) peut être un peu longue, tout comme la compilation avec make (qui utilise cmake, ainsi que votre compilateur C par défaut, à savoir probablement GCC et potentiellement Clang). Une fois cela fini, l’exécutable du jeu est builds/default/bin/greycess-knight-rpg. Si vous le souhaitez, vous pouvez l’installer au niveau du système avec sudo make install. Toutefois il est plutôt recommandé de le faire avec sudo checkinstall --nodoc --pkgname='greycess-knight-rpg' --pkgversion='1.0.0' --pkgrelease='1' --pkglicense='AGPLv3' --install=yes (et si vous n’avez pas encore checkinstall, vous pouvez l’installer avec sudo apt install checkinstall), afin qu’il soit facilement désinstallable avec votre gestionnaire de paquets. Enfin, si vous êtes sur un système sans APT comme système de gestion de paquets (comme ArchLinux, Gentoo ou Fedora), vous n’aurez que la première ligne à adapter.

Et au fait comment on parle au programme ?

Aucun argument en ligne de commande n’est accepté, le jeu est purement graphique. On peut y jouer à la manette ou au clavier. La manette est recommandée, car là les touches sont triviales et que c’est plus confortable. Si votre manette n’est pas reconnue par le jeu ou que partiellement, vous pourriez y pallier avec un logiciel d’association de ses boutons à des touches du clavier. Pour ça, il existe entre autres QJoyPad, joy2key et rejoystick.

Le clavier n’est pour le moment pas configurable, donc l’association est imposée. Il y a les 4 flèches directionnelles qui font ce que l’on attend d’elle, autant dans les menus que sur la carte. La touche « entrée » correspond au bouton A, c’est-à-dire au bouton d’action positif. La touche « espace » correspond au bouton B, c’est-à-dire au bouton d’action négatif. La touche F10 correspond à start. Les touches F3 et F4 correspondent à select. Et voila, c’est tout !

À moins que vous n’ayez épousé le Malin… En effet, GNU Emacs est l’Éditeur !, le seul que les vrai·e·s utilisent. Mais evil-mode est là pour les égaré·e·s : k, haut ; j, bas ; h, gauche ; l, droite ; a, bouton A ; u, bouton B ; v, start ; point, select. Pour les brebis galeuses qui utiliseraient du privateur (de quoi rendre respectables les utilisateurs et utilisatrices de vi et ses dérivés !), ce sera à vous de vous adapter : ni Big Brother, ni propriétaire ! (pour celleux n’ayant pas capté la référence, c’est une tentative d’adaptation de la célèbre devise anarchiste « ni Dieu, ni maitre ».)

Enfin, faites attention avec Ctrl + Q et Ctrl + W, car ça ferme le jeu sans prévenir et sans sauvegarde. Il est prévu d’implémenter une confirmation avant, mais ce n’est pas encore fait.

Captures d’écran

Captures d’écran de menus

Jeu Greycess Knight RPG les menus

Captures d'écran de cartes

Jeu Greyscess Knight RGP cartes

Captures d’écran de combats

Jeu Greycess Knight RBG écrans combats

Aller plus loin

  • # SCM public ?

    Posté par  (site web personnel) . Évalué à 8.

    Une raison particulière de pas héberger le code sous un SCM public comme Mercurial ou git ?

    Je n'arrive pas à le compiler sous mac car il y a des erreurs dans le CMake, j'aurais bien voulu envoyer un patch mais du coup j'ai aucune idée comment faire. Je n'ai trouvé aucune adresse mail dans le dépôt.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: SCM public ?

      Posté par  . Évalué à 0.

      c'est indiqué dans la dépêche :

      L’intérêt principal que j’y vois est que c’est décentralisé en très grande partie et résilient. Une forge peut disparaitre

      Ça permet aussi de partager le coût de l’infrastructure

      effectivement les forges type github sont un gouffre énergétique et "c'est toi le produit". Mais après il faut rationnaliser quand même. J'ai joué le jeu, et j'ai essayé avec le torrent. Et très rapidement ça m'a rempli les fichiers de log avec du

      lun. déc. 27 09:19:07 2021: DHT: Got 1 potential peers for torrent greycess-knight-rpg_1-0-0
      lun. déc. 27 09:19:07 2021: Initiating connection to xxxxxxx via (TCP)
      lun. déc. 27 09:19:10 2021: Timeout occurred
      

      et le lendemain ça n'avait toujours rien téléchargé.

      J'ai donc utilisé la source, mais ça aurait été plus simple de mettre cela sur une forge.

      Le jeu a du potentiel, mais ne semble pas encore bien abouti. Ce que j'ai regretté également c'est que l'espace d'affichage de texte soit très réduit, et que le jeu au contraire soit très verbeux, ce qui rend la lecture un peu fastidieuse. La plupart des instructions de jeu auraient pu se retrouver dans le readme par exemple, et un rappel dans les options ou une aide.

      J'ai bien aimé les graphismes en tout cas.

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: SCM public ?

        Posté par  (site web personnel) . Évalué à 10.

        L’intérêt principal que j’y vois est que c’est décentralisé en très grande partie et résilient. Une forge peut disparaitre

        Ça permet aussi de partager le coût de l’infrastructure

        C'est mignon tout plein mais; c'est pas parce qu'une personne n'utilise pas GitHub ou tout autre forge qu'il va y avoir un impact écologique. Pour que le torrent marche, il faut que les gens laissent leur PC allumés et laissent le partage actif, est-ce réellement mieux ?

        Mis à part le côté partage, je souligne surtout le fait que développer quelque chose d'opensource sans la possibilité de contribuer facilement c'est légèrement contradictoire.

        Les projets mednafen et lua sont opensource mais avec un développement fermés et c'est bien dommage. Pour envoyer un patch, tu sais pas si tu es sur la dernière version ou non (en ayant téléchargé une version snapshot) donc si ça se trouve ton patch est plus obsolète.

        Il n'y pas que la convivialité de voir le code en ligne et de ne pas attendre un temps variable de torrent, il y a la faculté de pouvoir cloner, mettre à jour, voir l'historique, créer des patch Mercurial ou git, etc. Surtout pour un projet qui est encore en travaux.

        git is great because linus did it, mercurial is better because he didn't

        • [^] # Re: forge et contribution, bis

          Posté par  . Évalué à 1.

          C'est mignon tout plein, mais c'est pas parce qu'une personne n'utilise pas Microsoft GitHub ou tout autre forge qu'il va y avoir un impact écologique.

          La démarche est avant tout politique, en incitant notamment (au moins dans un premier temps) à réfléchir. De toute façon, mon jeu ne va en l'état être connu que par fort bien peu de monde (à part événement improbable), donc peu importe ma méthode de distribution pour l'impact écologique. Je m'en expliquerais un peu plus dans l'annonce de la version 1.0.1 (qui devrait être dans environ 1 mois et aussi sur LinuxFr, mais cette fois sur la forme de journal puisque ça a bien moins d'intérêt qu'une version qui apporte une chose significatives ou des choses du point de vue utilisateur·e).

          Pour que le torrent marche, il faut que les gens laissent leurs PCs allumés et laissent le partage actif, est-ce réellement mieux ?

          Les gens laissent de toute façon leurs PCs allumés pour faire d'autres choses. Avoir en même temps un client BitTorrent a un impact très faible, notamment si ce n'est pas pour télécharger et partager des trucs énormes.

          Mis à part le côté partage, je souligne surtout le fait que développer quelque chose d'opensource sans la possibilité de contribuer facilement c'est légèrement contradictoire.

          Je ne suis pas un partisan de l'open-source, mais du logiciel libre. Un logiciel libre confère des libertés, ce qui n'implique pas qu'il soit développé d'une manière communautaire. D'ailleurs, Richard Stallman et la Free Software Foundation ont commencé le projet GNU à une époque où Internet était inexistant ou quasi-inexistant. Du coup, avec la considération commune d'aujourd'hui de la facilité de contribution, ce serait probablement perçu comme difficile, et pourtant c'est le projet à l'iniative du mouvement et qui reste idéologiquement carré.

          Les projets mednafen et lua sont open-source mais avec un développement fermés et c'est bien dommage. Pour envoyer un patch, tu sais pas si tu es sur la dernière version ou non (en ayant téléchargé une version snapshot) donc si ça se trouve ton patch est plus obsolète. Il n'y pas que la convivialité de voir le code en ligne et de ne pas attendre un temps variable de torrent, il y a la faculté de pouvoir cloner, mettre à jour, voir l'historique, créer des patch Mercurial ou git, etc. Surtout pour un projet qui est encore en travaux.

          Gérer un projet communautaire peut vite demander du temps. Ce projet est un hobby et je n'ai nullement envie de m'embêter à la gestion d'une communauté autour de ça. Si une ou plusieurs autres personnes ont envie qu'il y en ait une, elles peuvent le faire, je n'y vois aucun inconvéniant, bien au contraire, mais il ne faudra pas compter sur moi pour l'initier et l'animer.

          Par ailleurs, avec la manière devenue commune d'aborder les relations via Internet, et tristement d'une manière plutôt générale maintenant qu'il a acquis une place centrale dans bien des sociétés contemporaines, ça serait par plein de micro-messages (à entendre là dans un sens très générique : discussion, patch, émoticonne, etc.), ce qui est à la fois épuisant à traiter et écologiquement très néfaste. Ou alors il faudrait brider la fréquence et le type des interactions, mais ce serait alors majoritairement perçu comme contraignant et ça en rebuterait fort probablement la majorité. Donc faire ça en distanciel pour un petit jeu qui est un hobby, je m'y refuse. Mais même quelques contributions en présentiel ou fortement filtré par une barrière allant contre les tendances de l'époque, je n'en ai pas envie pour un projet de ce type, même si ça me serait fort moins problématique, autant d'un point de vue anthropologique qu'écologique.

          On pourrait aussi alternativement se dire qu'en fait je le fais déjà. J'ai fait là une longue annonce et les éventuelles suivantes devraient être du même tonneau. De même pour les commentaires, longs et avec un délai non-négligeable (du moins selon la norme de normalité de l'époque, qui ne me va pas, autant anthropologiquement qu'écologiquement, que je refuse donc quand je le peux et quand c'est pour des petits enjeux, je suis par exemple bien moins strict dans mon militantisme collectivo-organisé qui m'est de loin bien plus important et touche autant au social d'une manière globale contrairement au librisme qu'à l'écologie).

          Enfin, mon projet n'est pas en travaux. Il est là dans un état « final ». Oui, il est très basique, plein de choses sont améliorables, mais c'est totalement assumé. Malgré que des améliorations y seront peut-être apportées (il y aura au moins une version 1.0.1 qui corrige des bogues très mineurs et améliore le code source mais aussi la taille des binaires) et que je prévois un futur jeu qui utilisera son moteur après des modifications significatives (mais qui continueront d'en faire un moteur très basique et énormément améliorable), c'est utilisable et reprenable, donc « fini » d'un certain point de vue.

          Pour conclure, c'est globalement ainsi et j'ai mes raisons. Et je suis tout à fait prêt à les exposer, comme je viens de le faire pour partie. Elles peuvent changer, je ne suis pas un fossile, mais mieux vaut ne pas trop espérer, et avoir des arguments dans ma logique ou la remettant en cause pour espérer que ça change de mon côté. Ça ne plait pas ? Tant pis, je n'en vis pas, et c'est cool de pouvoir faire des choses sans l'épée de Damoclès de la persévérance dans l'être. Si d'autres veulent reprendre ce que j'ai fait, qu'illes le fassent, je n'y vois aucun inconvéniant, tant qu'illes respectent l'attribution et surtout le gauche d'auteur·e, ainsi que de préférence l'esprit de ma création et les valeurs que j'y ai mises ou que j'ai voulu y mettre sans que ça ait été forcément un succès.

          • [^] # Re: forge et contribution, bis

            Posté par  (Mastodon) . Évalué à 3.

            Je m'en expliquerais un peu plus dans l'annonce de la version 1.0.1 (qui devrait être dans environ 1 mois et aussi sur LinuxFr, mais cette fois sur la forme de journal puisque ça a bien moins d'intérêt qu'une version qui apporte une chose significatives ou des choses du point de vue utilisateur·e).

            Les dépêches servent à publier de l’information sur les thèmes principaux de LinuxFr.org, à savoir Linux et les logiciels libres.

            Les journaux sont destinés aux discussions et aux informations qui n’auraient pas leur place en tant que dépêches.

            À mon humble avis, tant que cela ne se limite pas à un truc purement commerciales et publicitaires (voir l’ensemble des règles de modération) et qu'il y a un minimum de contenu, l'annonce de la version 1.0.1 aurait toute sa place sous forme de dépêche.

            Surtout, ne pas tout prendre au sérieux !

      • [^] # Re: écologie et basicité

        Posté par  . Évalué à 1.

        Les forges type GitHub sont un gouffre énergétique et "c'est toi le produit". Mais après il faut rationnaliser quand même. J'ai joué le jeu, et j'ai essayé avec le torrent. Et très rapidement ça m'a rempli les fichiers de log.

        • Il n'est néanmoins pas sûr que c'était pire que d'avoir mis le dépôt git en ligne. En effet, au moins le contenu du torrent ne contient pas l'ensemble des commits, mais uniquement l'état final. On peut toutefois arguer, et à raison, qu'il contient aussi des binaires (certes compressées).
        • Ton histoire de fichiers journaux pose pour moi interrogation, si je puis dire. En as-tu besoin ? ou qu'ils soient autant remplis ? Le problème n'est-il pas plutôt dans la manière dominante de concevoir des logiciels (et en l'occurrence ton client BitTorrent), dont un des aspects est de produire en masse de la donnée par défaut, alors qu'une très vaste majorité est inutile (ou potentiellement utile mais jamais consulté) dans 99% des cas ?
        • Je ne soutiens pas que ma méthode est nécessairement la plus écologique. D'ailleurs, rendre accessible la même chose par HTTP(S) via un serveur pas mal utilisé serait fort vraisemblablement écologiquement bien supérieur. Mais il n'y a pas que ça qui compte à mes yeux. Je m'en expliquerais dans l'annonce de la version 1.0.1, qui sera aussi sur LinuxFr et dans normallement environ 1 mois.
        • Je n'ai pas d'accès personnel à Internet. Mes moments « légitimes » pour partager par BitTorrent sont donc fort restreints. C'est pourquoi j'encourage particulièrement à continuer de partager (de préférence sans ratio) après l'avoir intégralement. Ça représente moins de 10 Mo, donc ça ne représent pas grand chose, même en le partageant beaucoup.

        Le jeu a du potentiel, mais ne semble pas encore bien abouti.

        Très clairement, il est pour le moment ultra-basique. Attendre d'avoir un truc bien meilleur pour commencer à en parler publiquement aurait fort probablement fini par me décourager. C'est aussi pourquoi il est si court (30-40 minutes pour finir l'aventure principale) : le jeu n'est pas super, mais le temps de jeu est suffisament court pour qu'on puisse avoir envie de le faire (ou du moins de finir la quête principale).

        J'en profite pour dire que ce jeu vidéo en particulier ne bougera à priori pas du point de vue utilisateur·e. En revanche, je compte ré-utiliser le moteur après modifications pour un autre jeu, qui sera néanmoins lui aussi très basique, mais tout de même un tout petit moins et avec un potentiel de re-jouabilité. Mais pour le moment, je n'en dis pas plus et j'espère annoncer la première version dans environ 4-5 mois (mais ce sera peut-être beaucoup plus ou jamais).

        Ce que j'ai regretté également c'est que l'espace d'affichage de texte soit très réduit, et que le jeu au contraire soit très verbeux, ce qui rend la lecture un peu fastidieuse. La plupart des instructions de jeu auraient pu se retrouver dans le readme par exemple, et un rappel dans les options ou une aide.

        • Le problème devrait être bien moindre une fois qu'une police avec des caractères plus petits soit utilisée. Ce n'est pour le moment pas une priorité, mais j'y ai pensé (comme l'atteste d'ailleurs le README.md des sources).
        • Bien que je ne me fasse pas d'illusion sur le public effectivement touchable en l'état, l'objectif est qu'il soit jouable par n'importe qui. C'est pourquoi j'explique longuement certaines choses (qui peuvent paraitre tout à fait évidentes), notamment au début du jeu. Mettre ça dans un fichier à côté n'aurait pas été avec ma perspective, car les gens (en particulier les joueurs et les joueuses) n'ont plus du tout l'habitude de lire un truc à côté avant de commencer un jeu, donc il fallait que l'information soit dans le jeu et qu'on ne puisse pas passer à côté.
        • En jeu, dans les paramètres (accessible par start), il est possible de changer la vitesse des dialogues. Elle peut être bien plus rapide que par défaut.

        J'ai bien aimé les graphismes en tout cas.

        Vraiment ? Si oui, tant mieux et ça me surprend. Je suis vraiment très mauvais pour ça et je me suis restreint à seulement 15 couleurs « vraies » (en réalité le jeu gère 16 couleurs, mais dont une qui est la transparence).

    • [^] # Re: forge public, macOS et contribution

      Posté par  . Évalué à 1.

      Une raison particulière de pas héberger le code sous un SCM public comme Mercurial ou git ?

      Comme l'a expliqué zurvan, je l'ai expliqué dans la dépêche.

      Je n'arrive pas à le compiler sous mac, car il y a des erreurs dans le CMake. J'aurais bien voulu envoyer un patch, mais du coup j'ai aucune idée comment faire. Je n'ai trouvé aucune adresse email dans le dépôt.

      • J'ai réussi à avoir accès à un mac avec macOS. Je n'ai pas eu de problème avec CMake. En revanche, j'ai eu un problème avec le compilateur fourni par Apple, j'imagine un Clang à leur sauce, puisque la compilation avec Clang sous Debian GNU/Linux 10 et Trisquel GNU/Linux 9 était fonctionnelle. J'ai fait un correctif pour la compilation avec le compilateur fourni par Apple pour macOS. Il sera inclus dans la version 1.0.1. Celle-ci devrait sortir dans environ 1 mois. J'y expliquerais à la fois le correctif et pourquoi cette espacement de temps pour cette version corrective. J'en profite pour dire que cette fois la distribution se fera exclusivement par BitTorrent et j'y expliquerais également pourquoi j'en fait si peu souvent la distribution (d'où l'incitation prononcée à ce que les autres le repartagent après l'avoir obtenu).
      • Il n'y a effectivement aucun moyen de me contacter avec les sources, ou alors c'est une erreur. Je m'en expliquerais dans l'annonce de la version 1.0.1, qui (au cas où vous n'ayez pas lu l'élément de liste précédent) devrait être faite dans environ 1 mois.
      • Tu aurais pu, et tu peux toujours (à fortiori si tu as un problème avec CMake et non la compilation C), exposer le problème en commentaire sur l'article LinuxFr ou y proposer un correctif avec explication. Ce projet est pour moi un hooby et je n'ai pas envie de gérer une communauté, donc il ne faudra pas compter sur moi pour mettre en place un moyen simple pour les contributions. Toutefois, si une ou plusieurs personnes montent quelque chose et font une version dérivée, je n'ai absolument rien contre, au contraire. Et, si je venais à en avoir connaissance, je suis tout à fait susceptible de prendre ce qui j'y trouve d'intéressant, tout en conservant l'attribution bien sûr.
  • # Nouvelle version, avec des petits correctifs

    Posté par  . Évalué à 2.

    La version 1.0.1 est maintenant disponible ! C'est une version corrective, du coup il n'y a aucune nouvelle chose du point de vue utilisateur. En revanche, je fournis des constructions pour plus de systèmes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.