anaseto a écrit 2229 commentaires

Dans la plupart des langages interprétés

Je tente pas souvent ce genre de trucs, donc je saurais pas dire pour d'autres langages, mais en Perl et Tcl la vieille fonction utilise la nouvelle définition de nb-browser-to-url dans nb-open-bookmarks-in-tabs sans besoin de redéfinir cette dernière.

de compiler la fonction

Les langages de script ayant un eval (comme Perl, Tcl ou Javascript) peuvent faire ça aussi. En Perl ou Tcl la table des symboles est, par exemple, librement modifiable et, en fait, lors du chargement d'autres modules, c'est un eval particulier qui se cache et qui va compiler et rajouter à la table des symboles les nouvelles fonctions (compilées vers une sorte de byte-code interne à la volée).

Après, faut reconnaître que c'est amusant qu'un exécutable « hello world » statique avec rust prenne plus de place qu'avec Go qui lui inclut un GC dans le runtime (enfin, ça a l'air de dépendre de la plateforme aussi). Ceci dit, en dynamique ça donne juste 16K, oui.

Go est lent et primitif, Rust produit des exécutables de 4mo pour un Hello World

Hahaha :)

Très bon choix ;)

Héhé :)

je crois que de ce point de vue, pour boohu, c'est une réussite.

Merci !

J'imagine bien que ça peut être un peu frustrant au début :) C'est le soucis avec un jeu n'ayant qu'un seul niveau de difficulté. Peut-être qu'un jour je rajouterai une option pour paramétrer la difficulté, mais c'est le genre de trucs qui demande après pas mal d'efforts en plus après pour tester et équilibrer.

Je viens de faire le test : un hello world sans compression me donne 1.3M et, avec compression, ça me donne 290K, donc un peu mieux que quatre fois moins.

Le seul défaut que je vois — mais on en a un similaire pour la coloration syntaxique —, c'est pour les gros fichiers, où comme pour la coloration syntaxique dans plein d'éditeurs, j'imagine que l'idée serait de ne regarder, lors du calcul, qu'une fenêtre d'une certaine hauteur et ne pas analyser tout le fichier. Du coup, on pourrait, dans le cas d'une liste très longue, se retrouver à avoir des longueurs de ligne qui changent au fur et à mesure que l'on se déplace dans l'éditeur. Ceci dit, c'est sans doute moins gênant que la coloration syntaxique qui part en vrille.

Oui, sur ce point ça laisse à désirer pour les petits programmes. Encore que dans les serveurs qui font un gzip du fichier wasm (sans doute pas la plupart encore), c'est beaucoup plus raisonnable (le wasm se compresse très bien).

Je n'ai même plus envie d'écrire une seule ligne en Go tellement je le trouve ennuyeux.

Je suppose que c'est un point de vue courant. Je comprends que ça puisse ne pas être super excitant lorsque ce qui nous intéresse, c'est le code en soi et qu'on a envie de s'émerveiller sur la façon avec laquelle on a résolu un problème. Ceci dit, lorsque c'est le résultat et non le comment qui m'importe vraiment, je trouve Go très agréable et sans prises de tête.

Un dernier mot : Le support natif du Web Assembly. Je me prend à rêver que je vais pouvoir tout coder du backend au frontend, en passant par mes petits outils en ligne de commande, en Rust, sans une seule ligne de Javascript.

Pour le coup, la version 1.11 de Go aura ça, j'ai testé et c'est vraiment pratique : GOOS=js GOARCH=wasm go ...le reste comme d'habitude... et hop, le tour est joué :)

Donc, du combat, il y en aura, ça ne sera pas le cœur du gameplay.

Dans ce cas, un truc simple (voire même automatisé comme tu dis) conviendra. Tu pourrais même faire en sorte qu'il soit possible de jouer des parties purement pacifistes — c'est pas courant, mais il existe déjà des RPG dans lesquels c'est possible :)

Ceci dit, je n'oublie pas mon objectif de long terme qui s'appelle encore et toujours Akagoria ! Même si ce projet apparaît en pause, il ne l'est pas vraiment tant que ça. Je continue de réfléchir à plein de choses.

Des idées particulières concernant le gameplay, par exemple ? J'ai un peu regardé le readme le système de magie m'a par exemple l'air de tenir la route : limiter par temps de recharge et MP est une méthode ok pour éviter des abus à court et moyen terme. Ceci dit, c'est daté, de nouvelles idées depuis ?

Concernant le combat, temps-réel, le but est-il a priori de faire un système qui encourage de faire pause pour prévoir son prochain sort (style baldur's gate et compagnie, mais avec un seul personnage) ou bien style hack and slash et privilégiant l'action (à la diablo, flare, etc.) ?

Tu as raté une des dernières phrases de la dépêche : OpenBSD n'était pas au courant de l'embargo (ils ont demandé à en faire partie et cela leur a été refusé). Ils ont juste deviné la faille indépendamment : si eux l'ont deviné, c'est que d'autres moins bien intentionnés ont probablement pu le faire également, car maintenant que les esprits sont tournés vers ce type de faille, il n'est pas surprenant de les voir surgir plus facilement.

Pour KRACK, c'est bien connu qu'ils ont appliqué leur patch (sans commentaires) avec l'accord de la personne gérant l'embargo, dont ils ont respecté les délais initiaux — cela illustre juste que le secret dans ce genre de choses ne tient qu'à un fil, même si en l'occurrence c'est pas évident que quiconque ai fait un lien entre ce patch sans commentaires et en apparence spécifique et la faille qui a été publiée deux-trois mois plus tard ; en tous cas le web a été silencieux jusqu'à publication, contrairement au cas de Meltdown et Spectre où Linux a clairement révélé les choses avec ses patchs de Décembre — chose que je comprends parfaitement vu la longueur inouï de l'embargo, plus le fait qu'un article de blog plus ou moins décrivait innocemment la faille Meltdown (sans lui donner de nom) plusieurs mois avant : qui sait combien de monde était déjà au courant ?

Une réponse d'un des développeurs (trouvée au hasard). En gros, ça marche et ça a les fonctionnalités dont ils ont besoin pour leur cycle de développement sans branches, tout le monde commite et teste sur le même truc.

Oui, on dirait que la traduction a un peu de retard, mais visiblement c'est en cours.

Il y a aussi le fait que dans les campagnes on s'attache un peu à certaines unités et on ne veut pas les perdre, notamment quand on les a fait progresser dans les niveaux.

Pas faux :)

par exemple : the valley of death dans httt

Ah oui ! C'est la première campagne que j'ai joué et, du coup, je l'avais joué en difficulté facile et je me rapelle avoir recommencé pour pas perdre de vétérants sur ce scénario. Mais comme en dehors du niveau de difficulté facile, même en progressant, le perfectionnisme est frustrant — au fond je me demande si le perfectionnisme n'est pas un peu frustrant en toutes circonstances —, j'ai relativisé et maintenant je trouve qu'une partie sans petites tragédies épiques de temps en temps, c'est un peu fade ;)

D'une manière générale, quand les forces engagées dans une bataille sont équilibrées, la victoire dépend souvent d'un petit déséquilibre créé au cours des tous premiers combats.

Je suis d'accord, j'avais surtout en tête les scénarios de campagne où, par construction, un scénario bien équilibré n'équilibre pas totalement les forces :)

Et puis, le hasard ne joue pas toujours contre nous non plus. Lancer une charge de cavalerie est parfois la solution la plus efficace pour gagner une bataille en position défavorable; c'est le genre de stratégies qui peut s'avérer dévastatrice.

En effet, une absence d'une certaine dose de hasard aurait un coût important, puisqu'elle réduirait considérablement le nombre de tournures intéressantes que peut prendre une situation (en bien comme en mal).

Ça m'est arrivé plus d'une fois, assez pour me tuer une partie du plaisir (parce que je ne joue plus qu'avec les modes les plus difficiles, depuis le temps).

Oui, sauf que ça veut surtout dire que certains scénarios sont mal équilibrés en mode difficile. Après, honnêtement, je ne sais pas quel taux d'échec ont les meilleurs joueurs sur ces scénarios que j'aurais qualifié de mal équilibrés, mais sans doute assez faible.

J'avoue n'avoir testé que très rarement les scénarios avec de petites cartes. Tu as bien sûr raison que plus la carte est petite et moins il y a d'unités, plus la chance compte. Et en mode multi-joueur, si les deux joueurs sont bons (ou mauvais), la chance peut faire tourner la balance — auquel cas, il faut se dire en bon philosophe que de toutes façons on aurait possiblement gagné grâce à la chance (du style, coup de bol, l'autre joueur fait une faute d'inattention parce que le chat s'est assis sur le clavier).

Pour les campagnes, il m'arrive d'avoir cette impression de pile ou face en difficulté difficile dans certains scénarios, mais je joue peut-être juste trop vite et pas assez bien, ou bien c'était mal équilibré. Du coup, la plupart du temps je me contente de la difficulté normale et là, c'est vraiment rare d'avoir à refaire un scénario de campagne si on s'y prend raisonnablement bien : les fois où ça m'arrive, c'est presque toujours (sauf un scénario tous les vingt ou je sais pas) parce que j'ai mal évalué et que je m'y suis pris avec les pieds la première fois. Il faut juste pas essayer d'optimiser et risquer ses unités importantes juste parce que dans le cas où la chance (70%) est de ton côté ce serait préférable à une stratégie plus prudente. Parfois, ça veut dire passer à côté de certains objectifs bonus :)

on peut perdre en jouant bien et gagner en jouant mal

Je dirais que, concernant le ressenti vis à vis du hasard, la différence entre un jeu comme Wesnoth et un jeu de cartes style tarot ou belotte, c'est que si tu joues bien/mal à Wesnoth tu peux perdre/gagner un combat entre deux unités mais rarement une partie complète.

Perso, le RNG de Wesnoth ne m'a jamais spécialement gêné : l'issue d'une petite bataille en particulier n'est pas prévisible, mais celle de l'ensemble l'est en général assez bien du moment qu'on joue cela avec prudence (ou alors scénario mal équilibré, ça peut arriver). J'aime bien le côté gestion et évaluation du risque que ça développe, un élément de réalisme intéressant d'un point de vue stratégique (il y a toujours des petits imprévus dans la vie) et qui ne peut pas exister dans un jeu déterministe qui encourage plutôt à calculer une solution parfaite à un problème abstrait de type puzzle (genre un mat en trois coups aux échecs), aux dépends du développement des facultés d'adaptation du joueur dans un modèle de système plus chaotique. Après, les goûts et les couleurs… :)

Une semaine plus tard… toujours pas de tuiles, mais des animations ! :)

En lisant ton commentaire, mais aussi en regardant des vidéos, je me suis rendu compte qu'il manquait des retours visuels sur la carte pour les actions pour complémenter les messages, du coup je suis en train de faire une refonte de l'interface avec des animations et un meilleur affichages des menus qui ne cachent pas plus que nécessaire la carte désormais. Plus de 50 commits ces derniers jours ^^

Côté immersion, ça ne remplace peut-être pas des tuiles, mais ça rend les vidéos beaucoup plus intuitives : maintenant on voit quel potion/projectile/etc. on choisit (marqué en jaune brièvement), on voit le lancé de javeline, des animations par changement de couleurs divers du @ suivant les circonstances et des animations pour le combat (différents suivant si on tue ou non le monstre ou si on manque la cible), boule de feu, etc.

Côté immersion et ambiance

Ironiquement, parfois je me dis que les roguelikes ascii c'est un peu comme un jeu d'échecs ou de Go, mais avec un peu de réalisme (un peu d'hasard) et plus d'ambiance justement, du coup ça dépend de comment on approche la question :)

Tout d'abord: félicitations pour ton jeu!

Merci !

Est-il prévu de faire une version "tuile" de Boohu dans le futur?

Ce n'est pas vraiment prévu, mais peut-être un jour, ça ne devrait pas être trop difficile a priori, vu que même si je suis pas un artiste il y a moyen de récupérer des tuiles libres ici et là — si par miracle quelqu'un s'y colle à ma place, ce serait génial :)

Ceci dit, autant les tuiles ça devient vraiment plus intuitif quand un jeu devient complexe, par exemple dès qu'il y a plus de monstres que de lettres ou qu'il y a trop d'états différents — raison pour laquelle je joue à certains roguelikes comme DCSS et ToME4 en version avec tuiles —, autant dans un jeu simple et « pause-café » comme Boohu la version ascii est non ambigüe et donc on profite pleinement de deux avantages des versions ascii : plus de cases lisibles sur moins d'écran et l'œil humain analyse les symboles colorés connus plus rapidement que des dessins. Des roguelikes comme Brogue et Boohu, c'est un peu les conditions idéales pour découvrir l'ascii sans en rencontrer les limites.

Côté immersion et ambiance, je pensais un peu pareil à une époque, mais après coup je trouve que c'est surtout une question d'habitude et je n'y pense même plus : dans le monde des roguelikes il y en a même pas mal qui préfèrent justement l'ascii car, tout comme un livre, il leur permet de s'imaginer la scène à leur façon tout en les guidant un peu.

Oups :) J'ai oublié de mettre un lien vers la fiche récapitulative de l'épopée tragique !

Edit : et puis je sais pas pourquoi une des images s'affiche pas, mais bon.