Harmonist: Dayoriah Clan Infiltration est un jeu libre (code sous ISC, CC By pour le reste) rogue‐like pause‐café d’infiltration. Le personnage, Syu, un petit singe gawalt, doit s’infiltrer dans le territoire du Clan Dayoriah pour libérer son amie Shaedra qui s’est fait capturer alors qu’elle essayait de récupérer un objet magique appartenant au grand Marévor Hélith.
Dans un premier temps, la dépêche introduit le jeu et ses particularités en tant que jeu d’infiltration au tour par tour. Ensuite, elle explique les algorithmes de génération procédurale de cartes utilisés par Harmonist.
Sommaire
Un aperçu du jeu
Lors de chaque partie, le joueur incarne Syu et doit explorer, au tour par tour, des cartes caverneuses parsemées de bâtiments appartenant au Clan Dayoriah. Syu peut essayer de passer inaperçu de maintes façons, en se cachant par exemple parmi les hautes herbes, ou sous une table ou encore à l’intérieur d’un tonneau. Les tonneaux sont les points « sûrs » du jeu, où le joueur peut se reposer et récupérer ses points de vie et de magie, mais ceci seulement s’il peut manger une banane avant, car pas de sommeil réparateur le ventre vide !
Voici quelques autres actions typiques que l’on retrouve dans toutes les parties : passer par un endroit alors qu’un garde regarde ailleurs, grimper à un arbre pour voir plus loin et se protéger de certains ennemis, passer à travers des trous dans les murs, regarder à travers des fenêtres ou activer des pierres magiques qui se trouvent sur la carte.
Dans chaque partie, Syu trouve aussi quelques objets magiques, appelés magaras et qu’il peut utiliser, au prix d’un point de magie, avec des effets divers suivant le type de magara : éloigner des monstres à l’aide de bruits magiques, les endormir ou les perturber avec des illusions et des sons, se téléporter ailleurs, etc.
En plus de l’histoire principale du jeu, le joueur peut trouver lors de ses explorations des messages courts divers donnant plus d’informations sur le Clan Dayoriah et le monde d’Haréka en général. Certains personnages et bon nombre d’éléments d’inspiration proviennent de la saga libre de fantasy Le Cycle de Shaedra.
Un jeu d’infiltration
Le jeu se focalise sur le positionnement tactique, les mécanismes de lumière et de bruit, en utilisant divers types de terrains et des cônes de vision pour les monstres. Ayant pour objectif d’offrir une expérience de jeu épuré et rejouable, le jeu évite la complexité dans la gestion d’inventaire et la construction du personnage, préférant utiliser des objets et l’adaptation du joueur pour faire évoluer le personnage.
Harmonist reprend beaucoup d’idées courantes dans les jeux d’infiltration. Deux particularités distinctives majeures sont :
- il s’agit d’un jeu au tour par tour dans la tradition des jeux roguelike, mais reprenant certaines idées plus souvent présentes dans les jeux de plate‐forme, comme des petits cœurs pour les points de vie et une interface simple ;
- le joueur ne peut (presque) jamais tuer ses ennemis, c’est juste un petit singe gawalt ; lorsque la situation devient difficile, le joueur a à sa disposition divers objets magiques qui peuvent l’aider à échapper aux ennemis ou les perturber temporairement de diverses façons. Un point important qui joue en faveur du joueur, c’est que les ennemis ont tendance à ne pas s’acharner très loin dans leurs poursuites : après tout, le joueur est un petit singe à l’air un peu suspect mais relativement inoffensif. :-)
Interface
L’interface est essentiellement un successeur amélioré de celle de Boohu, le jeu dont Harmonist est initialement une divergence (fork), même si le résultat est un jeu très différent.
Un point notable est que l’interface est plus simple : déplacements possibles avec uniquement les flèches (pas de déplacements diagonaux), une même touche sert à interagir avec tous les objets, ce qui réduit significativement le nombre de raccourcis. Enfin, les raccourcis essentiels sont visibles à tout moment dans l’interface.
Génération de cartes
Dans une dépêche précédente à propos du jeu Boohu, il était question de génération de cartes et différents algorithmes : marche aléatoire, automate cellulaire, génération de tunnels ou encore partition binaire de l’espace. Chacun, en modifiant divers paramètres et en apportant diverses touches finales ad hoc, pouvait produire des résultats très divers et avec des caractéristiques tactiques différentes.
Harmonist reprend certaines idées pour sa génération de cartes. Cependant, les retouches finales sont plus importantes, tout comme l’utilisation de pièces éditées à la main et placées ensuite aléatoirement dans la carte.
Un premier exemple de carte typique du jeu (capture d’écran en mode wizard, sans le personnage et les monstres) :
Génération de la caverne
Tout d’abord, un des algorithmes précédents est utilisé pour produire une première ébauche de carte caverneuse avec des murs et des espaces ouverts, tout en produisant une carte connexe : toutes les cases qui ne sont pas des murs sont connectées, il n’y a pas de cases non atteignables. Actuellement, automate cellulaire et marche aléatoire sont utilisés pour cette phase.
Un automate cellulaire est aussi utilisé pour rajouter ensuite des herbes sur la carte. Une recherche ad hoc pour placer une ou deux zones d’abîme ou un lac est aussi faite en cherchant un groupe de murs qui ressemble à un bon candidat.
Ajout de pièces créées à la main
L’algorithme choisit ensuite des pièces au hasard parmi quelques listes de pièces faites à la main et les place au hasard sur la carte (parfois avec certaines contraintes), en creusant et nettoyant au besoin, peu importe ce qu’il y avait avant à cet endroit. Avant de placer la pièce, des rotations et réflexions sont appliquées au hasard, rendant les pièces moins prévisibles. Les pièces sont décrites dans le code source de façon symbolique, par exemple, une pièce à forme vaguement triangulaire :
?????#?????
????#>#????
???#!.!#???
??#_..._#??
##!.#.#.!##
+..P...P..+
##_..P.._##
??###+###??
Les # vont devenir des murs, les . deviennent le sol de la pièce, les + potentiellement des portes ou des murs, les P sont des points possibles de patrouille, les !, _ et > des points où placer diverses catégories d’objets et, enfin, les ? représentent les parties du rectangle qui ne sont pas à proprement parler dans la pièce et qui peuvent être réutilisées par d’autres pièces ou tunnels.
En parlant de tunnels, justement : après placement initial des pièces, des tunnels sont créés entre les cases des pièces qui sont candidates pour devenir une porte, de sorte que toutes les pièces soient connectées. L’algorithme essaie de trouver une pièce proche, mais pas toujours la plus proche : il s’agit d’obtenir un résultat à la fois assez naturel, mais en même temps non prédictible et avec quelques boucles.
Afin de donner un style plus naturel au territoire du Clan Dayoriah, des constructions éparpillées dans une zone caverneuse souterraine, les tunnels créés entre portes deviennent des chemins pavés pour les distinguer des autres cases libres en dehors des tunnels et des pièces qui restent des zones caillouteuses ou herbeuses. Les chemins servent aussi à prédire le parcours probable de certains ennemis qui patrouillent.
Bien que toutes les pièces soient connectées grâce aux tunnels, certaines parties de la carte sont peut‐être maintenant isolées du fait de l’ajout des pièces et des murs qui les entourent : on calcule alors la partie connexe et puis on remet des murs dans les parties isolées. En pratique, cela donne des résultats plutôt satisfaisants avec les paramètres utilisés dans Harmonist.
Ajout des objets et créatures
La génération de carte place ensuite divers objets (tables, tonneaux, arbres, bananes, etc.) aléatoirement, mais avec certaines contraintes : les bananes apparaissent en général dans la nature, alors que les tables et les tonneaux vont apparaître à l’intérieur des pièces.
Notons que les pièces, ayant une forme donnée à la main, sont en revanche remplies aléatoirement, avec certaines contraintes quant aux emplacements possibles pour les objets. Une table ne peut pas apparaître juste devant une porte, et certains objets n’apparaissent pas dans tous les types de pièces.
Les créatures sont aussi placées aléatoirement avec des contraintes diverses : certaines patrouillent entre deux pièces, d’autres sont placées dehors dans les zones caverneuses, privilégiant plus ou moins les parties herbeuses (en général, des animaux), d’autres gardent une pièce en particulier sans bouger en regardant autour d’elles, etc.
Voici quelques autres exemples de cartes utilisant des algorithmes de base différents de l’exemple plus haut :
Aller plus loin
- Site du projet (254 clics)
- Jouer dans le navigateur (279 clics)
# Intéressant !
Posté par Maharon . Évalué à 2.
J'adore !
L'apparence en rebuterait plus d'un, mais je trouve ça original et intéressant
Ça me rappel Dwarf Fortress, qui d'ailleurs va sortir en version Steam avec un pack graphique et sonore
(ou Slaves to Armok: God of Blood Chapter II: Dwarf Fortress pour les fidèles)
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 2.
Merci !
En moins chargé, sans doute ;-) On m'a dit que le style des graphismes ressemblait à Caves of Qud aussi.
Ceci dit, graphismes de côté, Harmonist est un jeu à une beaucoup plus petite échelle, des objectifs/méchanismes de jeu plus ciblés et largement plus accessible :-)
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 2.
Je n'ai pas trouvé ou faire les bug-reports mais comme tu sembles être un des devs, voici quelques remarques après quelques parties:
[^] # Re: Intéressant !
Posté par BAud (site web personnel) . Évalué à 5.
ouaille dou you spik inegliche ?
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 9.
J'ai hésité à faire mes remarques en français mais, comme je m'adressais à un nombre indéterminé de développeurs potentiellement non-francophones, j'ai finalement choisis l'anglais. Après tout, la page du projet est en anglais. Aï kan translète iffe nidid.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 2.
Merci pour les retours ! Et ça me va ici pour le bug-report :-) Autrement, il y a un dépôt secondaire sur github, ou sinon un mail ça marche aussi, je suis le seul dev pour le moment.
Techniquement, en examinant avec
xon a une description différente, mais oui, ce serait bien d'avoir un retour visuel direct.Curieux, je vais voir ça (pas de soucis avec Iridium). Peut-être spécifique au mode plein écran dans Firefox ?
Je peux peut-être arrondir un peu la partie supérieure de la porte. Ou changer la couleur.
Oui, lorsqu'ils sont en dehors du champ de vision et ne dorment pas, j'utilise toujours la couleur pour “wandering/watching”, parce que c'est l'état par défaut le plus naturel à assumer par le joueur. Après, la couleur du fond est différente, donc en général je n'ai pas rencontré de problèmes avec ça personellement.
Oui, je pourrais modifier le F11 par défaut pour mettre que le canvas en fullscreen, comme le bouton.
Héhé, il n'y a pas de zombis au sens classique dans Haréka, donc ce serait bizarre :-)
Oui, mais c'est un peu inévitable si je veux que l'on puisse jouer aussi à la souris, à moins d'introduire une option clavier-uniquement, ou quelque chose comme ça ?
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 2. Dernière modification le 13 mai 2019 à 17:03.
Pour le mode plein écran, il est possible que cela soit causé par Sway (un clone de i3 pour Wayland).
F11 comme cela dans Dungeon Crawl. Cela serait parfait.
Le problème du mode 'explore' avec la souris est que cela peut arriver involontairement quand on joue sur un portable. Il suffit que la main effleure le touchpad. Je ne suis pas certain qu'une option clavier-uniquement soit souhaitable car l'inspection des tiles avec la souris est quelquefois utile. La version desktop de dungeon-crawl a un meilleur comportement: Il y a aussi un mode 'explore' activable par la touche x mais la souris permet d'obtenir une description des tiles sans pour autant activer ce mode.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 3.
J'ai effectué quelques commits suite à tes remarques : tuile différente pour les lumières éteintes, F11 devrait marcher maintenant, une tuile modifiée pour les portes avec des coins arrondis. J'ai testé avec une couleur différente pour les monstres qu'on voit plus, mais n'étant pas très satisfait du résultat j'ai laissé comme avant pour l'instant.
J'ai mis en ligne une page différente pour jouer à la version en développement.
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 1.
J'ai testé ta version de dev. Dans Firefox, F11 permet effectivement d'activer le fullscreen mais pas d'en sortir. Le jeux n'est plus centré verticalement ce qui n'est pas très agréable visuellement mais cela a le mérite de résoudre le problème avec les coordonnées de la souris.
Cela me fait d'ailleurs penser à un autre petit détail: La touche 'x' est utilisée pour fermer les menus alors qu'en général c'est plutôt ESC qui sert à cela. Pour ne rien arranger, le comportement par défaut de ESC dans Firefox est de sortir du mode fullscreen ce qui m'arrive au moins une dizaine de fois par partie.
Le comportement de Dungeon Crawl (encore lui) me semble plus intuitif: F11 pour activer/désactiver le fullscreen et ESC pour fermer les menus. Je suppose que Crawl gère le fullscreen différemment car contrairement à Harmonist, il n'affiche pas le popup "Exit Fullscreen (ESC)". Intuitivement, je dirais que Harmonist gère le fullscreen manuellement alors que Crawl se contente de laisser faire Firefox.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 1.
Esc et Espace font normalement la même chose que 'x', sauf que pas toujours suivant les navigateurs… La raison pour laquelle je mets 'x' en avant, c'est parce qu'avec Boohu j'ai déjà eu des retours dans lesquels soit esc soit espace ne marchait pas dans certains navigateurs/OS, du coup 'x' marche partout et est relativement mnémotechnique (ce n'est pas la première fois que je vois ce raccourci utilisé dans un roguelike).
Avec webengine on a ce comportement (active et désactiver), je n'ai aucune idée pourquoi c'est différent. J'ai beau trouver pratique la version web d'Harmonist, car facile à distribuer, parfois c'est un peu un cauchemar pour avoir une expérience homogène entre les différents navigateurs et OS :-)
Difficile à dire, a priori non, j'utilise un lib js (screenfull.js) recommandée pour faire le fullscreen de façon portable ;) Je pense qu'ils ont dû travaillé un peu plus dur dans DCSS.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 2.
Finalement, j'ai cherché un peu et il se trouve que c'est spécifique à Firefox : celui-ci ajoute automatiquement certaines règles css au plein écran d'un élément. Une solution est en fait de mettre le canvas à l'intérieur d'un div et faire plein écran du div à la place. Le comportement est le même dans le deux cas avec webkit/webengine, et avec firefox ça fait un plein écran fonctionnel mais peu élégant (le jeu n'est pas centré verticalement)… comme j'ai pas la patience de chercher une solution CSS qui centre verticalement le jeu sans rendre incorrecte la position de la souris, je vais me satisfaire de ça pour le moment :-)
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 2.
J'aime bien aussi. Je vais le garder dans ma liste des petits jeux pour m'occuper quand je voyage. Un peu frustrant par moments (du genre 4 monstres stationnés juste devant la sortie sans aucun moyens de les contourner) mais dans l'ensemble c'est assez prenant.
L'apparence est en effet un peu spartiate. Le bicolor cela fait très années 70. Il est peut être temps de rentrer dans les années 80 :-) Si les devs ne sont pas de bon graphistes, j'imagine qu'il ne devrait pas être difficile d'adapter quelques 'tiles' d'un autre projet open-source (Dungeon Crawl, Nethack, …) avec une licence compatible.
Du fait de sa simplicité ce jeux pourrait être une bonne introduction aux rogue-likes pour des enfants. Il est toutefois dommage que les textes soient en anglais et que rien ne semble prévu pour la localisation.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 2.
C'est le genre de situations où on n'a pas d'autre choix que d'utiliser les magaras et/ou sauter par dessus les monstres :-)
Harmonist utilise le jeu de couleurs pour donner des infos visuelles sur l'état des monstres, etc., là où des tuiles comme celles de Dungeon Crawl Stone Soup doivent utiliser des petites images à superposer pour cela. En plus, les tuiles polychromatiques, moins symboliques, sont en général plus grandes (sinon elles deviennent très peu lisibles) ce qui nécessite en pratique de passer en mode caméra centrée ou qui se déplace par à coups, plutôt que statique, car toute la carte ne loge plus sur l'écran, or ça fait partie des caractéristiques appréciés par certains joueurs.
Techniquement, la version native a un mode expérimental caméra-centrée (option
-c), mais le monochromatique aide aussi beaucoup à avoir une bijection simple entre version terminal et graphique, ce qui facilite la maintenance et utiliser un système différent juste pour ce mode serait un peu compliqué actuellement.Je suis le seul dev et c'est la première version, donc il n'y a pas vraiment encore la main d'œuvre suffisante pour cela, mais je suis ouvert aux contributions en ce sens :-)
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 1.
Je vais y penser. Je ne connais pas le Go mais implémenter la localisation serait un bon exercice d'apprentissage.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 1.
Le plus simple serait peut-être de définir une liste d'identifiants et donner un nom à tous les messages et utiliser les noms à la place des chaînes. Ensuite, il faudrait associer des chaînes à ces identifiants (un fichier par langue, par exemple). Idéalement tout est compilé dans le même binaire, c'est beaucoup plus facile à distribuer ensuite, mais ça empêche probablement d'utiliser des outils déjà existants pour ça (genre gettext). Sans doute plein d'ennuis auxquels je pense pas maintenant, genre qu'est-ce qui se passe quand une traduction n'est pas à jour, etc. :-)
[^] # Re: Intéressant !
Posté par roptat . Évalué à 1.
Ça serait pas mieux d'utiliser un truc existant que de réinventer ton format de données ? En cherchant un peu rapidement je trouve ça qui propose d'utiliser go-i18n qui a l'air pas trop mal.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 1.
Hé, sans doute, je n'ai pas creusé la question, du moment qu'à la fin j'ai pas de fichiers externes sur le produit final qui gênent la distribution, et que la bibliothèque n'a pas trop de dépendances, ça me va :-)
Après, autant je peux aider un peu si du monde est intéressé, je ne veux pas me charger moi-même de faire et maintenir ensuite les traductions, c'est pas trop ma tasse de thé. C'est pas pour rien que même des gros projets avec des milliers de joueurs et des dizaines de développeurs comme Dungeon Crawl Stone Soup ne sont qu'en anglais à ma connaissance, c'est beaucoup de travail, il faut aimer ; en tant que traducteur de Linux From Scratch, tu sais déjà ça ;-)
[^] # Re: Intéressant !
Posté par SChauveau . Évalué à 2.
J'ai aussi trouvé https://godoc.org/golang.org/x/text et en particulier https://godoc.org/golang.org/x/text/message/catalog qui montre comment écrire des règles de traduction tenant compte de diverses caractéristiques syntactiques (pluriels, féminin vs masculin, …).
Tout cela est probablement plus complexe que je ne pensais initialement mais c'est probablement faisable.
[^] # Re: Intéressant !
Posté par anaseto (site web personnel) . Évalué à 1.
Avec celui-ci on dirait que tout peut être fait dans des fichiers sources compilés et non chargés à l'exécution, donc a priori plus pratique, mais j'ai fait juste que survoler les deux.
# Déjà dans guix :)
Posté par roptat . Évalué à 2.
Hop, merci pour ce jeu aussi facile à empaqueter, il est maintenant dans guix dont on parlait il y a peu :)
Tu sais s'il y a moyen d'être prévenu lors de la publication de nouvelles versions, pour que je puisse faire la mise à jour dans guix au moment de leur sortie ?
[^] # Re: Déjà dans guix :)
Posté par anaseto (site web personnel) . Évalué à 1.
Super ! :-)
Eh bien, j'avoue ne jamais m'être posé ce genre de questions. Tu verrais ça comment, par exemple ?
Je sais que la personne qui empaquète Boohu pour Debian se débrouille de façon automatisée pour être au courant lorsque je fais une version (un espèce de tache périodique automatisée de style “watch file” pour les paquets dont il s'occupe), mais je n'en sais pas plus.
[^] # Re: Déjà dans guix :)
Posté par roptat . Évalué à 1.
Ça dépend du logiciel. Souvent en effet j'utilise
guix refreshpour être informé des mises à jour, mais tous les paquets ne sont pas pris en charge. Parfois ça se fait via les collègues, parfois je vais sur le site de temps en temps et pour le reste je suis abonné à une liste de diffusion nom-du-projet-announces.Tu ne dois pas être le seul projet sur tuxfamily, donc je vais voir si je peux écrire un petit gestionnaire de mise à jour.
[^] # Re: Déjà dans guix :)
Posté par anaseto (site web personnel) . Évalué à 1.
Je pourrais créer une liste d'annonces, tuxfamily propose de créer des listes de diffusion. Ça me rappelle que j'en ai déjà fait une pour le langage de balisage frundis, hum, sauf que je crois qu'on est encore que deux personnes et sans messages après plusieurs années…
En pratique, je m'occupe déjà d'actualiser à chaque version la page des jeux sur les wikis LibreGameWiki et Roguebasin, je vais finir par m'enmêler les pinceaux avec tant de trucs à faire à chaque release :-)
# Super projet !
Posté par bux (site web personnel, Mastodon) . Évalué à 2.
Bravo à toi, je trouve ce projet très aboutis et très bien réalisé !
Je suis particulièrement sensible à ce genre de design: Je développe moi-même un jeu avec un interface "Terminal". J'apprécierais beaucoup d'échanger avec toi à propos de la manière dont tu as géré la couche graphique:
Dans mon projet j'utilise une lib qui gère une interface à la ncurses. Je me limite donc à des caractères utf-8 et malgré l'abondance de caractères je n'y trouve pas toujours ce que je voudrais. Je me suis donc posé la question de proposer - un jour - une interface avec des "simili-caractères" comme le fait dwarf fortress avec ses "graphic sets".
Ce que ton projet propose c'est exactement ça et je suis curieux de savoir comment tu l'as implémenté !
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
[^] # Re: Super projet !
Posté par anaseto (site web personnel) . Évalué à 6.
Merci !
L'implémentation abstrait (plutôt concrètement) le cas typique du terminal : un tableau de cases où chaque case est caractérisée par un caractère utf-8, deux couleurs (devant et le fond) et si oui ou non elle est sur la carte (ce qui permet de gérer différemment les cases suivant si elles sont ou non sur la carte), c'est le type UICell dans ui.go.
Ensuite, chaque backend (terminal, Tk ou WebAssembly) associe à cette combination lettre-couleurs-carte quelque chose d'adapté à la situation. Dans le cas de Tk et WebAssembly, j'associe simplement une image monocolore à chaque type de case à dessiner (via un simple map) et je la colorie ensuite à la volée (puis garde en cache l'image coloriée), ça permet d'avoir des images/symboles à la place de caractères utf-8, ce qui donne parfois plus de liberté pour obtenir des trucs plus intuitifs que le caractère utf-8 d'origine (par exemple, pour Tk, les fichiers
tk.goettiles.gogèrent l'essentiel, c'est un bon endroit où commencer pour comprendre l'implémentation dans Harmonist). Note, par contre, que pour la partie purement terminal non tuiles, je me limite à des caractères utf-8 courants présents dans la plupart des polices, donc la version terminal de Harmonist est plus abstraite dans sa symbolique que la version graphique web.Dans le cas des backends graphiques, pour le dessin des tuiles dans la grille, le seul point vraiment subtil ensuite est l'optimisation des instructions de dessin comme le font ncurses et d'autres bibliothèques pour le terminal : s'assurer qu'on n'envoie pas au final des instructions de dessin redondantes à des cases qui n'ont pas changé : en pratique il faut utiliser deux buffers, un correspondant à l'état des cases après le dernier “flush” d'instructions de dessin, un autre où on modifie au fur et à mesure, puis ensuite la fonction “flush” doit faire la différence entre les deux pour calculer les instructions de dessins qui sont vraiment à exécuter.
Après, suivant le langage que tu utilises, il se peut qu'il y ait déjà une bibliothèque toute prête pour ce genre de cas (par exemple, libtcod, disponible pour divers langages, est couramment utilisé et, me semble-t-il, a des fonctionalités prévues pour abstraire tout cela). Si ton jeu ressemble à un roguelike, même vaguement, tu peux essayer de regarder la faq de roguelikedev pour voir s'il y a des choses qui peuvent t'aider, il y a plein de ressources pour les développeurs de jeux roguelike (et par extension, de jeux utilisant une grille avec des tuiles ou de l'ASCII) et l'ambiance est plutôt accueillante.
[^] # Re: Super projet !
Posté par bux (site web personnel, Mastodon) . Évalué à 1.
Super, merci pour ces informations. Je ne connaissais pas la faq de roguelikedev, ça à l'air d'être une mine d'or !
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
# Super projet (bis)
Posté par zurvan . Évalué à 2.
la version web est super, bravo, j'adore le monde de Shaedra (j'ai déjà lu quelques livres), et ce jeu s'inscrit bien dans cet univers.
J'ai essayé la version en go sur mon PC, mais j'ai des erreurs :
go get -u git.tuxfamily.org/harmonist/harmonist.git --tags tk.go
Password:
Et pas moyen d'aller plus loin.
J'ai tenté la version sur github :
go get -u github.com/anaseto/harmonist --tags tk.go
J'ai essayé aussi :
go tool compile tk.go (depuis les sources téléchargées)
mais ça m'indique :
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Super projet (bis)
Posté par anaseto (site web personnel) . Évalué à 2.
Oups, le
--tags tkest en effet mal placé dans l'exemple du README.md, j'ai corrigé :
go get -u --tags tk github.com/anaseto/harmonist
Pour git.tuxfamily.org, c'est normal, le serveur git est en panne depuis vendredi, ça devrait remarcher bientôt, je suppose.
[^] # Re: Super projet (bis)
Posté par zurvan . Évalué à 2.
super, merci, ça fonctionne, cette commande me génère le binaire dans mon dossier ~/go/
En version tk cependant, ça s'ouvre dans une fenêtre qui est plus large que mon écran (1280px).
Je viens de trouver pour compiler depuis les sources dans un dossier local, il faut taper :
go build
ou
go build --tags tk
pour la version graphique. Peut-être à rajouter dans le readme pour aider les néophytes en golang :)
Et j'ai modifié ça pour pouvoir changer la taille de la fenêtre :
wm resizable . 1 1
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Super projet (bis)
Posté par anaseto (site web personnel) . Évalué à 2.
Je sais plus très bien pourquoi j'ai mis à 0 le resizable, sans doute pour éviter de le faire sans faire exprès ou parce que j'automatisais le changement entre compact et non compact.
Pour les écrans petit, en pratique j'utilise le mode compact dans les options
Toggle normal/compact layout, un peu moins verbeux et sans menus et mémo des raccourcis, mais suffisant une fois qu'on connaît un peu le jeu.Tu peux aussi essayer l'option
harmonist -cpour le mode caméra-centrée, bien que c'est expérimental (pas trop testé et améliorable).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.