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

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 ?
• Pourquoi avoir fait ce jeu ?
• Greycess Knight RPG : un jeu vidéo basique
  • Quel moteur technique ?
  • Quelques détails techniques
  • Quelques déconvenues techniques
• Une suite ?
• Pourquoi ce nom de jeu ?
• Remerciements
• Télécharger le jeu
  • Quelques clients BitTorrent libres
  • Pourquoi partager le jeu exclusivement via BitTorrent ?
• Comment compiler le jeu ?
• Et au fait comment on parle au programme ?
• Captures d’écran
  • Captures d’écran de menus
  • Captures d'écran de cartes
  • Captures d’écran de combats

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

• OpenGameArt, pour ses nombreuses ressources graphiques libres
• Kenney, qui a fourni sous licence libre Creative Commons 0 une grande partie des ressources graphiques
• le projet GNU, pour GCC et ses licences
• Clang, pour ses messages complémentaires à GCC
• les gens ayant fait la SDL2
• Trisquel GNU/Linux et Debian GNU/Linux, les deux systèmes d’exploitation utilisés
• GDB et valgrind, pour avoir bien aidé à déboguer des problèmes de mémoire
• GNU make et CMake, pour l’orchestration de la compilation et des tests
• check, pour des tests automatiques d’exécution
• Cppcheck et KWStyle, pour des tests statiques complémentaires aux compilateurs
• tou·te·s celleux que j’ai oublié (moyen facile de demi-esquive !)

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 :

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

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

Captures d'écran de cartes

Captures d’écran de combats

Aller plus loin

• Lien magnet du code source et des binaires (soyez patients et repartagez) (73 clics)
• Code source seulement (temporaire ; si pas de pairs depuis longtemps) (58 clics)