(et au passage j’ai remarqué un problème avec le verrouillage de la porte si on refait la scène du musée - il faudrait faire dans la routine de ré-initialisation des variables, ou quelque chose dans ce goût-là - je te laisse t’en occuper )
En effet, j’avais oublié le verrouillage de la porte. Je m’occupe par ailleurs de donner à la porte du gardien un comportement de vraie porte (door lockable).
J’ai un petit problème avec cette scène, c’est au sujet des directions.
Les directions sont précisées ainsi « tout droit », « à gauche »… on pas précisées du tout, mais le déplacement se fait avec « aller à l’est » « aller au nord ». Le joueur non habitué va se perdre. Que préconises-tu ?
Concernant les directions, j’avoue que je n’en sais trop rien… Ca fait bizarre, de se déplacer dans un musée par rapport au nord, non ? En même temps, on n’a pas trop le choix… Il faudrait donc changer les directions en « nord », donc ?
Et pour les portes : si j’ai bien compris on ne peut pas aller plus de deux fois dans le bureau du gardien : deux fois par aventure (quand on lance le fichier lieuxcommuns.z8) ou par jeu (quand on rentre dans le musée par la boule de cristal) ? (si c’est la deuxième option - ce que je pense - peut-être trois, plutôt, non ? enfin, après tout, c’est pas très dur, ce qu’on demande au joueur dans cette pièce…)
A chaque fois qu’on recommence la scène, on a à nouveau 2 essais puis le joueur est renvoyé à la roulotte et peut recommencer la scène à zéro.
Deux essais me semblent suffisants, cela ajoute une petite difficulté vite surmontée.
A la troisième le gardien, qui n’est pas si bête, nous repère en train de casser le pot de fleurs volontairement et nous met dehors.
il doit être possible de modifier les bibliothèques pour accepter de nouvelles directions. Cela avait été fait pour donner dans un bateau le babord et le tribord. Par contre pour le coup du musée bien entendu cela ne fonctionnerait pas, puisque que l’on ne peut pas juste remplacer gauche par ouest et droite par est, puisque 2 fois à gauche par exemple fait faire demi tour… Mais il doit être possible de coder un nouveau verbe qui partant d’une référence précise, et en fonction de la dernière pièce visitée, puisse calculer si la gauche fait aller au nord ou à l’ouest par exemple…
Oui, tout cela est certainement possible (je me souviens d’avoir joué à « Rat in control » de Mike Roberts, un jeu en TADS 3 qui était une démo de ce système de déplacement), mais on ne va pas se lancer là-dedans maintenant.
Non seulement ce serait, il me semble, beaucoup trop long et compliqué à programmer, mais c’est aussi nettement plus difficile à jouer : on est plus facilement désorienté qu’avec le système standard des points cardinaux, il est plus difficile de « se faire une carte des lieux » dans sa tête…
Non, il vaut mieux utiliser les points cardinaux, même si ça peut paraître un peu bizarre a priori. En plus, c’est plus cohérent avec tout le reste du jeu.
Voilà, c’est modifié. En revanche aucun des 4 pieces de l’exposition ne mentionne l’emplacement des autres pieces. Faut-il le rajouter pour ne pas perdre le joueur debutant, ou est-ce qu’on laisse les joueurs se débrouiller ?
S’il n’est pas libre de droit, il faudrait le supprimer de subversion car il y a un accès web (en théorie il faudrait même le supprimer de toutes les révisions de subversion, mais il faut des droits admin sur subversion pour cela).
selon JB, il était mis comme un truc freeware en plus d’un jeu, aussi je doute que l’on puisse le réutiliser pour autre chose que l’écouter, cela dit cela ne doit peut être pas poser de pb pour le rediffuser sur un site web etc. Vu que je n’ai pas le titre, on ne peut pas vérifier.
De toute façon on retirera tout ce qui n’est pas nécessaire à la fin, et on purgera la base des parties multimédia qui ne servent pas (j’aurais bien été tenté de tout recréer mais cela ferait perdre l’historique des modifications de code, ce qui serait dommage). On demandera aux admins de « dumper » la base svn.
Pour pouvoir utiliser le fichier jouer_glulx.sh, n’oubliez pas de faire un chmod +x outils_linux/gargoyle2 et de placer le fichier lieuxcommuns.blb dans media/ (je suppose que tout le monde le sait mais bon ).
Au passage, quelle est la différence entrer utiliser ./jouer_glulx.sh et gargoyle lieuxcommuns.blb (si on a gargoyle installé) ?
pour le chmod, je crois que cela n’est pas possible de l’indiquer dans le svn (ou alors je ne connais pas la commande), quoi qu’il en soit, une fois que c’est fait même s’il y a une mise à jour du fichier je crois que cela garde les bons droits.
J’ai donc ajouté jouer_git.sh pour utiliser le moteur git et jouer_glulx.sh pour utiliser le moteur glulxe à la place (j’aurais dû renommer en jouer_glulxe.sh mais bon je ne voulais pas tout changer non plus).
./jouer_glulx.sh utilise la version de gargoyle présente dans le svn, et comme l’initialisation utilise le bon fichier de configuration présent dans le dossier media, cela affiche le jeu avec une taille de caractère légèrement plus grosse (plus lisible), et cela ouvre le jeu avec la taille optimale de fenêtre (un peu inférieure à 1024x768 comme cela cela ne dépasse pas les standards d’écran actuels)
le script est cela en fait :
cd media
../outils_linux/gargoyle2 lieuxcommuns.blb
De plus cela n’utilise pas le moteur git qui semble plus problématique que le moteur glulxe original (glulx est le format de la machine virtuelle, glulxe est l’interpréteur, git aussi)
Avec gargoyle lieuxcommuns.blb , cela utilisera git à la place, et cela oblige d’entrer dans le dossier media pour avoir le fichier de configuration (bien que l’on pourrait utiliser un lien symbolique…). Quand on passe son temps à compiler et tester, cela va plus vite. Et maintenant je teste plus volontiers avec la version glulx que la version zmachine, également pour essayer de trouver le bug « no opcode »
Sinon tu ne génères pas le fichier lieuxcommuns.blb à partir des sources à chaque fois ? De toute façon j’essaye de mettre une nouvelle version chaque jour dans informfr.tuxfamily.org/lieuxcommuns
je n’ai pas réussi à l’utiliser pour le moment. Par contre, il ne faudrait pas que les images d’agrandissent si la taille de fenêtre est trop grande, sinon cela fera moche…
Cela serait bien de pouvoir définir également les cadres de l’écran en fonction de la taille de la fenêtre, par exemple sous un pocket pc le jeu en glulx ne passe pas du tout car le cadre est déjà réservé pour l’image Mais cela me semble compliqué à implémenter, il faut changer la partie avec (winmethod_Left+winmethod_Fixed),500, )
Est-ce le problème dont parlait JB au début de ce projet ? Quel est l’objectif ? un dimensionnement plein écran en début de jeu ? le redimensionnement des images en cas de modification de la taille de la fenêtre ? l’utilisation de valeurs fixes pour les fenêtres en fonction de la machine ?