URL: https://linuxfr.org/news/greycess-knight-rpg-sortie-de-la-premiere-version Title: Greycess Knight RPG : sortie de la premiĂšre version ! Authors: GnouCat Ysabeau đŸ§¶, palm123 et BenoĂźt Sibaud Date: 2021ćčŽ12月19æ—„T15:16:00+01:00 License: CC By-SA Tags: rpg, debian, flatpak, postgresql, jeu_de_rĂŽle et jeu_vidĂ©o Score: 25 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. ---- [Lien magnet du code source et des binaires (soyez patients et repartagez)](magnet:?xt=urn:btih:8166dfe1f05edd6aabde6fdd1d45ce584b304faa&dn=greycess-knight-rpg%5F1-0-0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A6969%2Fannounce&tr=http%3A%2F%2Fbttracker.debian.org%3A6969%2Fannounce&tr=https%3A%2F%2Ftorrent.ubuntu.com%2Fannounce) [Code source seulement (temporaire ; si pas de pairs depuis longtemps)](https://drop.infini.fr/r/z0RXbAHvMk#evRS3+4syMMxRscrSnVPY1yJXbInraNEJPueTcyMFho=) ---- # Qu’est-ce que Greycess Knight RPG ? Greycess Knight RPG est un jeu de rĂŽle [ordinatique](https://fr.m.wiktionary.org/wiki/ordinatique) en tour par tour (comme [Golden Sun sur GameBoy Advance](https://fr.wikipedia.org/wiki/Golden_Sun_(jeu_vid%C3%A9o)) ou les plus connus [jeux vidĂ©os PokĂ©mon « classiques »](https://fr.wikipedia.org/wiki/Pok%C3%A9mon_(s%C3%A9rie_de_jeux_vid%C3%A9o)#S%C3%A9rie_principale)). 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](https://packages.debian.org/bullseye/games-rpg) est assez illustratif, bien qu’il ne regroupe qu’une portion, comme [le montre LibreGameWiki.org](https://libregamewiki.org/Role-playing_games), probablement pour des raisons de droit d’auteur·e sur les ressources hors code ou juste par [manque de forces pour faire les paquets](https://wiki.debian.org/Games/Suggested)), - 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](https://www.tuxemon.org/) et [OpMon](https://opmon-game.ga/)). 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](https://solar.lowtechmagazine.com/2009/06/embodied-energy-of-digital-technology.html)), 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)](https://www.gnu.org/philosophy/free-sw.fr.html). 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](https://en.wikipedia.org/wiki/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](https://www.libsdl.org/?lang=fr) (du moins en ne considĂ©rant pas les tests automatiques, car [check](https://libcheck.github.io/check/?lang=fr) est utilisĂ© dans ce cadre, ainsi que la transformation des images PNG en code C, qui utilise [SDL2_image](https://www.libsdl.org/projects/SDL_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](https://fr.wikipedia.org/wiki/WebAssembly) et [Emscripten](https://emscripten.org/)) et Android (pour lequel il existe [la distribution libre Replicant](https://replicant.us/) et [le pseudo-magasin d’applications F-Droid](https://replicant.us/)). 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](https://n64.dev/?lang=fr)), il y a [devkitPro](https://devkitpro.org/wiki/) et des adaptations de la SDL1 pour de nombreuses machines de Nintendo, ainsi que [tonc](https://www.coranac.com/tonc/text/) et [d’autres bibliothĂšques](https://github.com/gbdev/awesome-gbadev#user-content-libraries) 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](https://fr.wikipedia.org/wiki/PlayStation_Portable) (qui a [un kit de dĂ©veloppement libre](https://github.com/pspdev/pspsdk?lang=fr), [un port SDL2](https://github.com/joel16/SDL2?lang=fr) et [un port SDL1](https://github.com/pspdev/psp-ports/tree/master/SDL?lang=fr), ainsi que 2 Ă©mulateurs libres : [PPSSPP](https://www.ppsspp.org/?lang=fr) et [JPCSP](https://github.com/jpcsp/jpcsp?lang=fr)) ; et sa successeure, [la Sony PlayStation Vita](https://fr.wikipedia.org/wiki/PlayStation_Vita) (pour qui il existe [Vita SDK](https://vitasdk.org/?lang=fr), [un port de la SDL1 et un de la SDL2](https://github.com/rsn8887/SDL-Vita?lang=fr), ainsi que [l’émulateur libre Vita3K](https://vita3k.org/?lang=fr)). Enfin, [la Sony PlayStation 2 (PS2)](https://fr.wikipedia.org/wiki/PlayStation_2) devrait aussi pouvoir ĂȘtre gĂ©rĂ©e (avec [ps2toolchain](https://github.com/ps2dev/ps2toolchain?lang=fr) pour la compilation, [un port SDL](https://github.com/ps2dev/ps2sdk-ports?lang=fr), et [l’émulateur PCSX2](https://pcsx2.net/?lang=fr) pour tester rapidement et facilement), tandis que [la Sony PlayStation 1 (PS1)](https://fr.wikipedia.org/wiki/PlayStation) n’a pas de quoi faire (il y a bien [PSn00bSDK](https://github.com/Lameguy64/PSn00bSDK?lang=fr), 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](https://en.wikipedia.org/wiki/C_POSIX_library)) 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](http://annchienta.sourceforge.net/?page=fall_of_imiryn) qui utilise [le moteur Annchienta](http://annchienta.sourceforge.net/?page=home)) ; C est plus simple que C++ par exemple, donc [l’ABI (Application Binary Interface)](https://fr.wikipedia.org/wiki/Application_binary_interface) est moins susceptible de changer ; pas de dĂ©pendance qui va disparaitre ou ne plus ĂȘtre maintenu (comme [Hero of Allacrost](https://sourceforge.net/projects/allacrost/) qui utilise [Qt4](https://en.wikipedia.org/wiki/Qt_version_history#Qt_4)) ; pas de construction compliquĂ©e ; pas plusieurs langages Ă  connaitre hors construction (comme [Lua](https://fr.wikipedia.org/wiki/Lua), utilisĂ© par exemple par [Valyria Tear](https://valyriatear.blogspot.com/), qui est un RPG libre 2D trĂšs poussĂ©) ; pas besoin de service Ă  l’exĂ©cution (comme [CatchChallenger](https://github.com/alphaonex86/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](https://rogueboxadventures.tuxfamily.org/)) ; 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)](https://fr.wikipedia.org/wiki/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`](https://nano-editor.org/)). ## 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`](https://wiki.libsdl.org/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](https://www.musl-libc.org/), une implĂ©mentation libre de la bibliothĂšque standard du langage C) malgrĂ© une tentative avec l’usage de [`setlocale`](https://www.cplusplus.com/reference/clocale/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](https://www.winehq.org/), donc je ne sais pas si les compilations Windows (faites avec [MinGW](http://mingw-w64.org/)) fonctionnent - problĂšme avec [ReactOS](https://reactos.org/) (un clone libre de Windows) sous [GNOME Boxes](https://wiki.gnome.org/Apps/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](https://github.com/fcambus/spleen) est une possibilitĂ©, mais aussi [celles de Jeremy Oduber pour GB Studio](https://jeremyoduber.itch.io/fonts-for-gb-studio) et [d’autres (dont au moins certaines non-libres) pour le logiciel Ă©ponyme](https://github.com/DeerTears/GB-Studio-Community-Assets/tree/master/Fonts), ainsi que [celles de Kenney](https://kenney.nl/assets/kenney-fonts)), - ajout et usage de sons et musiques (il y a une section pour chaque chez [OpenGameArt.org](https://opengameart.org/), de mĂȘme pour le RPG libre [Valyria Tear](https://github.com/ValyriaTear/ValyriaTear/tree/master/data), idem pour le PokĂ©mon-like [Tuxemon](https://github.com/Tuxemon/Tuxemon/tree/development/mods/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](https://wiki.libsdl.org/Android)) 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](https://wiki.libsdl.org/MigrationGuide) (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](https://devkitpro.org/wiki/) 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](https://www.debian.org/doc/manuals/debian-faq/pkg-basics.fr.html), puis de mĂȘme pour un [paquet RPM](https://rpm.org/) et Ă©ventuellement d’autres procĂ©dures d’installation dans le genre ([SliTaz](https://doc.slitaz.org/fr:cookbook:start), [ArchLinux](https://wiki.archlinux.org/title/Creating_packages), [GNU Guix](https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/), [Flatpak](https://docs.flatpak.org/en/latest/first-build.html), [Ubuntu Snap](https://ubuntu.com/tutorials/create-your-first-snap), etc.), - amĂ©liorer l’exĂ©cutable WINE / ReactOS / Windows avec un meilleur [fichier de ressources](https://docs.microsoft.com/en-us/windows/win32/menurc/resources), - 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`](https://www.cplusplus.com/reference/cwchar/swprintf/), et enfin reconvertir dans notre format), - avoir une implĂ©mentation de [`qsort`](https://www.cplusplus.com/reference/cstdlib/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`](https://zestedesavoir.com/tutoriels/755/le-langage-c-1/notions-avancees/les-unions/) 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](https://www.freedos.org/?lang=fr) et [DOSBox](https://www.dosbox.com/?lang=fr) (car pourquoi pas ?), - faire un Ă©diteur graphique de cartes (comme [Porymap](https://github.com/huderlem/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](https://opengameart.org/art-search-advanced?field_art_tags_tid_op=and&field_art_tags_tid=16x16%2C+RPG&field_art_type_tid%5B%5D=9), pour ses nombreuses ressources graphiques libres - [Kenney](https://www.kenney.nl/), qui a fourni sous [licence libre Creative Commons 0](https://creativecommons.org/publicdomain/zero/1.0/deed.fr) une grande partie des ressources graphiques - [le projet GNU](https://www.gnu.org/home.fr.html), pour [GCC](https://gcc.gnu.org/) et [ses licences](https://www.gnu.org/licenses/licenses.fr.html) - [Clang](https://clang.llvm.org/), pour ses messages complĂ©mentaires Ă  GCC - les gens ayant fait [la SDL2](https://www.libsdl.org/) - [Trisquel GNU/Linux](https://trisquel.info/fr) et [Debian GNU/Linux](https://www.debian.org/index.fr.html), les deux systĂšmes d’exploitation utilisĂ©s - [GDB](https://www.gnu.org/software/gdb/) et [valgrind](https://valgrind.org/), pour avoir bien aidĂ© Ă  dĂ©boguer des problĂšmes de mĂ©moire - [GNU make](https://www.gnu.org/software/make/) et [CMake](https://cmake.org/), pour l’orchestration de la compilation et des tests - [check](https://libcheck.github.io/check/), pour des tests automatiques d’exĂ©cution - [Cppcheck](http://cppcheck.sourceforge.net/) et [KWStyle](https://kitware.github.io/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](magnet:?xt=urn:btih:8166dfe1f05edd6aabde6fdd1d45ce584b304faa&dn=greycess-knight-rpg%5F1-0-0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A6969%2Fannounce&tr=http%3A%2F%2Fbttracker.debian.org%3A6969%2Fannounce&tr=https%3A%2F%2Ftorrent.ubuntu.com%2Fannounce). 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](https://www.transmissionbt.com/?lang=fr) - [Deluge](https://deluge-torrent.org/?lang=fr) - [KTorrent](https://apps.kde.org/fr/ktorrent/?lang=fr) - [qBittorrent](https://www.qbittorrent.org/?lang=fr) - Android - [LibreTorrent](https://f-droid.org/fr/packages/org.proninyaroslav.libretorrent/) - [BiglyBT](https://www.biglybt.com/?lang=fr) ## 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](https://fsfe.org/contribute/spreadtheword.fr.html#nocloud). 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](https://fr.wikipedia.org/wiki/Flatpak) et [Snap](https://fr.wikipedia.org/wiki/Snap_(gestionnaire_de_paquet))). 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)](https://fr.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/Arch_Linux), [Gentoo](https://fr.wikipedia.org/wiki/Gentoo_Linux) ou [Fedora](https://fr.wikipedia.org/wiki/Fedora_Linux)), 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](https://github.com/panzi/qjoypad?lang=fr), [joy2key](https://packages.debian.org/bullseye/joy2key?lang=fr) et [rejoystick](https://sourceforge.net/projects/rejoystick/?lang=fr). 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](https://www.gnu.org/software/emacs/) est l’Éditeur !, [le seul que les vrai·e·s utilisent](https://stallman.org/saint.html). Mais [`evil-mode`](https://github.com/emacs-evil/evil/?lang=fr) 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 »](https://fr.wikipedia.org/wiki/Ni_Dieu_ni_ma%C3%AEtre_(devise)).) 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](https://i.ibb.co/dMPm6gG/greycess-knight-menus.png) ## Captures d'Ă©cran de cartes ![Jeu Greyscess Knight RGP cartes](https://i.ibb.co/GR6dGL6/greycess-knight-maps.png) ## Captures d’écran de combats ![Jeu Greycess Knight RBG Ă©crans combats](https://i.ibb.co/G71zWNY/greycess-knight-battles.png)

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /