Oui, un tout petit peu, mais ce qui reste assez mystérieux pour moi ce sont les manières d'utiliser les unités FunDelphi… En effet dans l'exemple de l'unité “Money” je ne vois pas très bien l'intérêt de la poser dans GenericSquares puisque cette unité est quand même très spécifique : Un marchand vend une clé d'argent à 10€, je trouve + logique de l'intégrer dans le dossier du projet lui-même !.
Le top, j'imagine, serait de pondre une unité de base “Money” intégré au jeu (dans GenericSquares) et que l'on puisse faire varier les sommes et le matos vendu au sein de l'inspecteur d'objet (et/ou d'un autre .fnd), mais j'en suis pas là !!!
Autre(s) mystère(s) : La manière, l'ordre devrais-je dire, d'agencer les instructions dans un .fnd …
En vue de bâtir un labyrinthe assez conséquent j'envisage plutôt plein de petits .fnd (posés dans le repertoire du projet) plutôt qu'un seul de taille conséquente… Est-ce une bonne approche ?!.

DerF_44
Oui, un tout petit peu, mais ce qui reste assez mystérieux pour moi ce sont les manières d'utiliser les unités FunDelphi… En effet dans l'exemple de l'unité “Money” je ne vois pas très bien l'intérêt de la poser dans GenericSquares puisque cette unité est quand même très spécifique : Un marchand vend une clé d'argent à 10€, je trouve + logique de l'intégrer dans le dossier du projet lui-même !.
Le top, j'imagine, serait de pondre une unité de base “Money” intégré au jeu (dans GenericSquares) et que l'on puisse faire varier les sommes et le matos vendu au sein de l'inspecteur d'objet (et/ou d'un autre .fnd), mais j'en suis pas là !!!

Absolument, c'est comme ça qu'il faut faire, et seules des unités vraiment génériques comme tu le décris sont intégrées à la Library officielle.

D'ailleurs, souvent, les unités vraiment génériques sont plus courtes, et permettent plus de choses que les unités trop spécifiques. Mais par contre il est plus difficile de les écrire correctement si on n'a pas de connaissances en programmation en tant que telle.

DerF_44
Autre(s) mystère(s) : La manière, l'ordre devrais-je dire, d'agencer les instructions dans un .fnd …
En vue de bâtir un labyrinthe assez conséquent j'envisage plutôt plein de petits .fnd (posés dans le repertoire du projet) plutôt qu'un seul de taille conséquente… Est-ce une bonne approche ?!.

Oui c'est une bonne approche ! C'est même la bonne approche

Cool !..
Maintenant, après quelques réflexions je me sens assez intéressé par l'idée d'une unité Money “configurable”…
Le tip top serait de pouvoir choisir le matos et son prix depuis l'inspecteur d'objets, ainsi que de placer dans l'annonce du marchand le nom et le prix de l'objet à vendre !…
Cela donnerait : Choix de l'ID de l'objet = GoldenKeys et prix = 50€ dans l'inspecteur d'objet..
le .fnd en déduirait donc le name de l'objet qu'il insèrerait dans l'annonce ainsi que le tarif :
“Bonjour, veux-tu m'acheter une clé d'or pour 50€ ?…”
Comme cette déduction me semble un peu chaude à réaliser (ID=>Name), on peut contourner la difficulté en posant le réglage (manuel) dans l'inspecteur d'objet..
Reste plus qu'à savoir comment un .fnd va chercher les infos dans l'inspecteur d'objet !!!
Alors, commençons par le plus simple : Comment créer une interaction entre l'inspecteur d'objet et l'unité pour le tarif de l'objet à vendre !!?
Une idée d'unités dont je pourrais m'inspirer ?…

Oui tu peux t'inspirer de l'unité GenericSquares/Chests.fnd.

En gros, l'interaction consiste uniquement à avoir une ou plusieurs property. Tu peux très facilement vers la correspondance ID => Name simplement en faisant ObjectDef.Name si ObjectDef est la property qui correspond au type d'objet que vend le marchand.

Une base de travail :
Je te laisse t'amuser avec le reste du travail

Merci beaucoup !!.
Trop bien !.
Je vais bricoler tout ça dès ce soir !.. Enfin cette nuit !.

Super !!.. Non seulement ça fonctionne, mais en + cela m'a pris 4 minutes et 25 secondes !…
Se pourrait-il que je commence (à peine !) à comprendre quelques bases du FunDelphi !??..

Toujours dans un esprit d'initiation pour débutants, voici un micro-labyrinthe pourvu d'un marchand customizable qui peut vendre n'importe quel objet à n'importe quel prix via l'inspecteur d'objet..
(ObjectDef = objet à vendre, Price = prix de vente de l'objet.)

Dans mon exemple le marchand vends des pioches à 25 €.
Personnellement je compte bien virer les billets en € afin de les remplacer par quelques sous et autres pièces d'or plus appropriés (à mon goût) éthiquement et esthétiquement aux mondes de FunLabyrinthe !.

Prochaine étape : Limiter le stock du marchand !.. (via l'inspecteur d'objets, spécifier le nb. maxi d'objets à vendre même si le joueur est milliardaire !.)

Excellent !

Ce qui serait pas mal, aussi, ce serait d'avoir un seul TMoney générique (avec une propriété pour spécifier combien d'argent on reçoit).

Je patauge un peu là !…
J'ai réécris toute l'unité, en virant le bloc marchand et sa clé et les €…
Maintenant l'idée c'est que le joueur puisse trouver :
Soit 1 pièce d'or (no problemo)
soit quelques pièces d'or (avec quantité réglable via l'inspecteur d'objets)
soit une bourse contenant x pièces d'or (idem)
..Et pour les deux derniers je suis un peu perdu !. Dois-je faire un plug-in ???
Dans le cas contraire comment déclarer un Msgformat ?..
Que signifie exactement :
on AfterConstruction do
begin
inherited;

J'avance, j'avance….
En fait mon blèm est juste de pouvoir placer dans la phrase “Tu as trouvé x pièces d'or” le nb de pièces !!
Apparemment le reste fonctionne !..

MàJ message : Ok, ça marche !!.. Un tout bête petit %d et ça roule, qui l'eut cru !?..

Je m'attaque maintenant au stock du marchand, le nb. d'objets qu'il possède et qu'il peut vendre…..

re MàJ message : Eh zut !.. Et non ça marche pas : Si le joueur possède déjà 4 pièces d'or et qu'il trouve une bourse en contenant 5, on m'annonce que j'en ai trouvé 9 !… Je me disais aussi !…………..
Donc ma question : Mais d'où sort le %s de la phrase du marchand “Je vends des %s pour %d pièces d''or” ??

En fait dans
eh bien le ‘%s’ est remplacé par le contenu de la variable UnTexte (qui doit être un string) et ‘%d’ est remplacé par le contenu de la variable UnNombre (qui doit être un Integer). Le qui-remplace-quoi est déterminé par l'ordre d'apparition (donc le premier % correspond à la première variable entre les , etc.). La lettre après le % doit correspondre au type de la variable (s pour un string, d pour un Integer).

veut juste dire que lorsque le plugin/objet/effet/etc. sera créé, c-à-d dès qu'il commencera à “exister” quand le jeu va comencer, il faut exécuter ce qui est écrit à la place de “AutreChose;”. Le inherited dit qu'il faut faire tout ce qui est déjà prévu de faire dans la “classe parente”.