Je voudrais compléter le carry out standard du verbe « Prendre » par une règle complémentaire s’exécutant automatiquement juste après le carry out. Exemple, mais ce n’est qu’un exemple et la technique pourrait être démarquée pour d’autres verbes : vérifier immédiatement que le joueur n’a pas trop d’objets dans son sac à dos.
Autre question : dans une de mes tables, une colonne contient les noms de salles déjà définies normalement par ailleurs. Est-ce à dire que les objets ( au sens informatique ) correspondant aux tables sont dupliqués, ou bien la table ne contient-elle que de simples pointeurs vers ce qui existe déjà ? Question sans importance pour un jeu assez simple, mais qui peut avoir de l’influence sur un jeu plus complexe. Par exemple, le jeu que je suis en train de terminer compte 60 salles. Est-ce quelque chose de complexe ? Non, j’espère.
Dans l’exemple que tu donnes, celui de vérifier si le joueur a assez de place dans son sac, il existe une propriété qu’il te suffit d’utiliser : carrying capacity.
Utilisée sur un personnage, un conteneur ou un support, elle définie la taille de son inventaire. De base, elle est de 100.
Utilisée sur un objet qu’il est possible de prendre, elle définie la place qu’elle occupe. De base, il me semble qu’elle est de 1.
The carrying capacity of player is 10.
La potion is a kind of thing.
The carrying capacity of Potion is 2.
There are 10 Potion.
Dans ce cas, le joueur ne devrait pouvoir prendre que cinq potions. À la sixième, il y aura un message qui explique que le joueur a trop d’objets.
J’ai écris le code de tête, il est possible que je me sois gouré. Si tu veux consulter la documentation, ce sont les sections 3.19 et 10.5.
Pour ta question suivante, il ne s’agit que de pointeur vers les objets. Inform n’aime pas les déclaration d’objets en cours de processus. De nouveau objets ne sont créés que lorsque tu les définies, au départ.
La dague is a thing.
[Je viens de créer un objet.]
Table of Trésor
NomTrésor (thing)
With 10 blank rows
[Je viens de créer un tableau de 10 lignes et une colonne pouvant contenir des objets.]
When play begins :
Choose a blank row in table of Trésor ;
Now NomTrésor entry is Dague.
[Maintenant, la cellule de la première ligne pointe vers dague. Il n’y a pas deux dagues.]
Je regrette un peu de ne pas avoir de réponse à l’aspect général de ma première question, mais j’en déduis que la réponse est négative : non, ce n’est pas possible.
Dans mon tout premier projet, j’ai tenté de modifier des actions standards et je me suis heurté à pas mal de souci. Comme souvent, modifier s’avère selon moi plus difficile que de créer. Si tu désires vraiment t’éloigner du comportement standard d’Inform7, je te conseille donc de recoder intégralement les actions concernées.
Utilise par exemple une règle Instead pour réorienter une action classique vers une action de ta conception, une action dont tu pourras librement définir le Carry out sans te prendre la tête avec des effets de bord.
J’ai appliqué cette philosophie sur mes nouveaux projets et je n’ai pas eu à le regretter.
Il suffit juste d’écrire une nouvelle règle carry out, non ?
[code]Carry out taking (this is the blabla taking rule):
say « Nouvelle règle carry out ! ».
The blabla taking rule is listed after the standard taking rule in the carry out taking rulebook.[/code]
Ajouter un nom à la règle et indiquer son emplacement n’est pas utile pour l’action de prendre, car elle n’a qu’une seule règle carry out par défaut donc la nouvelle règle va directement se placer après la règle existante, mais je l’ai mis pour être complet. (Pour trouver le nom et l’ordre des règles, c’est dans l’index qu’il faut voir.) Voir le début du chapitre « Rulebooks » pour plus d’infos.
En revanche, si tu veux vérifier quelque chose et arrêter l’action en fonction de ça, c’est une règle check qu’il faut écrire (au carry out, l’action est considérée comme réussie).
Comme Corax l’a indiqué, des pointeurs seulement. D’une manière générale, ce sera toujours des pointeurs, sauf pour les booléens, les nombres, les valeurs énumérées, les heures et les unités.
Je pense que la dernière partie est fausse : le carrying capacity d’une chose ne définit que sa capacité et pas la place qu’elle occupe. Donc la spécifier pour des potions ne sert à rien. D’ailleurs, c’est logique car on aurait sinon le problème suivant : le carrying capacity d’un coffret qu’on peut porter définirait sa capacité ou la place qu’il prend ?
Du coup, le joueur pourra bien prendre 10 potions dans ton exemple.
Il doit y avoir des extensions qui permette d’avoir le comportement que tu décris, mais sinon ça ne doit pas être bien compliqué en remplaçant les règles qu’il faut dans l’action de prendre (il suffit de les copier des Standard Rules et de modifier la condition).
Et moi je te conseille de ne pas faire ça : l’action de prendre est très compliquée par exemple, car il faut effectuer de nombreuses vérifications (12 règles check rien que pour cette action !). Alors à la place de la recréer, il vaut mieux ajouter des règles comme dans mon exemple au début du message (on peut aussi en enlever, en remplacer ou les réordonner). Ce n’est pas très compliqué si on étudie bien le comportement de l’action grâce à l’index et en regardant dans les Standard Rules.
Après, tout dépend de ce que tu veux faire, et créer une autre action peut parfois être une solution.
Concernant Carrying capacity, en effet, ça doit être ça. J’avais écrit ma prime impression sur le sujet, mais je ne l’ai jamais utilisé.
Concernant le fait de créer des actions ou de les modifier, tout dépend à mon avis l’ampleur des modifications.
Pour le cas de la Tour d’Orastre, pour parler concrètement, je suis tellement éloigné du standard d’Inform que si j’avais voulu modifier toutes les règles, ça aurait été un chantier abominable. Du coup, je me suis codé en gros une surcouche qui fait appel à quelques fonctionnalités de base d’Inform et qui exclue le reste, le reste dont je n’ai plus à me soucier. Résultat, en me basant sur cette surcouche, je peux faire absolument tout ce que je veux, sans qu’Inform vienne me titiller avec des conflits.
Il faut cependant préciser que mes jeux ne se basent plus sur le prompt et que j’ai une formation de développeur, ce qui forcément influence ma manière de penser. Se mettre à créer intégralement des fonctionnalités exposent au fait de tout devoir gérer soi-même.
