Whaouh ! Deux ans et quatre mois depuis le dernier post. J'en ai mis du temps à développer la version 5.0 !
Mais ça y est, elle est là !La version bêta de FunLabyrinthe 5.0 est disponible en téléchargement (installateur) dans le premier post de ce thread.
Comme je l'avais dit, maintenant FunLabyrinthe repose complètement sur Sepi, mon projet de moteur de script orienté objet. Du coup, il est possible de concevoir de nouvelles cases à partir de cases existantes, par l'héritage, etc. Tout ça avec un langage simple, adapté spécialement à FunLabyrinthe (baptisé le FunDelphi, car il tient du Delphi pour un certain nombre de choses).
Comme il n'y a pas encore de fichier d'aide, je vais expliquer les grands points ici.
Ce qui change par rapport à la v4.x :
1. Plus d'éditeur d'actionsIl n'y a plus d'éditeur d'actions, car l'éditeur de labyrinthes prend toutes ses fonctions.
2. Les composants de caseChaque case est composée de 4 composants : terrain, effet, outil et obstacle. Le premier est obligatoire, les autres optionnels. Chaque composant a son utilité et son "sens" :
- Le terrain, c'est l'herbe, le mur, l'eau, etc. C'est ce qui détermine si on a le droit de marcher dessus ou non : herbe oui, mur non, eau seulement si on peut "aller sur l'eau" (GoOnWater, voir plus bas : les actions).
- L'effet, c'est ce qui détermine ce qui se passe quand on tombe sur la case. Un effet reste en place généralement (il ne disparaît pas). La flèche, par exemple, pousse dans une direction. Un trésor fait gagner le joueur.
- L'outil, c'est un objet que l'on ramasse quand on tombe dessus. Il disparaît donc, et le joueur dispose d'un nouvel objet. Exemple : l'outil Clef d'or disparaît et donne au joueur un objet Clef d'or (qu'il emporte avec soi).
- L'obstacle, c'est une chose qui se met par dessus tout et qui empêche le joueur de venir sur la case. Un obstacle peut en général être détruit si on peut effectuer la bonne action. Exemple : un Bloc en or peut être détruit si on peut "ouvrir un verrou doré" (OpenGoldenBlock, voir plus bas : les actions).
Cette distinction est en soi, je crois, la plus grande révolution dans FunLabyrinthe. Auparavant, les boutons persos prenaient tous ces concepts en charge dans le même code, ce qui était impossible à maintenir. Voyez par exemple le code du labyrinthe Murs et Murets, encore en ancien mode.
C'est en analysant la façon dont fonctionnaient les cases existant dans FunLabyrinthe 4.x que j'ai isolé ces quatre composantes, qui existent maintenant de façon naturelle dans FunLabyrinthe 5.0.
3. Les actionsPour faire certaines choses (aller sur l'eau, ouvrir un verrou), le joueur doit être capable de faire des
actions. Il existe des actions standard (GoOnWater, OpenSilverLock, etc.) mais on peut définir ses propres actions. Généralement, les terrains et les obstacles testent si un joueur est capable d'effectuer une action donnée.
Il y a deux choses qui permettent à un joueur d'effectuer une action : les objets qu'il possède, et les plug-in qui lui sont greffés. Je reparlerai des plug-in plus tard.
Le joueur dispose d'une liste d'objets, chacun avec son nombre d'exemplaires. Certains objets permettent, si on les possède (en nombre suffisant, parfois), d'effectuer une action. Par exemple, l'objet SilverKeys permet, si le joueur en possède au moins une, d'effectuer l'action OpenSilverLock. Ceci au prix de perdre une clef. L'objet Buoys (bouées) permet, sans la perdre, d'aller sur l'eau (GoOnWater). Les objets sont généralement obtenus en ramassant les outils qui correspondent.
4. Les plug-inOn peut greffer des plug-in au joueur. Les plug-in permettent de faire un bon nombre de choses, entre autres :
- Permettre au joueur d'effectuer des actions (le plug-in BuoyPlugin permet d'aller sur l'eau) ;
- Modifier l'affichage du joueur (le plug-in BuoyPlugin affiche une bouée autour du pion) ;
- Modifier la vue du joueur (le plug-in ViewRestriction restreint la vue du joueur - voir le labyrinthe Catacombes) ;
- Réagir à l'appui de l'une ou l'autre touche du clavier ;
- Etc.
Les plug-in sont très présents dans FunLabyrinthe 5.0. En effet, le joueur, en lui-même, ne possède aucun comportement. Il y a même un plug-in pour afficher les messages au joueur (en modifiant sa vue et en interceptant les appuis sur des touches du clavier).
5. Les attributsLe joueur peut avoir plusieurs attributs : une table de hashage chaîne -> entier. Les attributs permettent d'ajouter des "champs" non existant à la base à l'objet TPlayer. Exemple, l'attribut ViewRestrictionRadius définit le rayon du cercle dessiné par le plug-in ViewRestriction (à nouveau, voir Catacombes).
Le langage FunDelphiIci vient la seconde avancée majeure de FunLabyrinthe 5.0 (ou première, je ne suis pas très sûr).
Dans FunLabyrinthe 3.0 à 4.x, il y avait l'éditeur d'actions qui permettait de programmer des cases personnalisées avec de petits scripts du genre :
1 2
| Remplacer Case 4 3 4 ;
Message {Un trésor est apparu sur la case (4, 3, 4).} |
Avec l'avènement de FunLabyrinthe 4.0 et des cases personnalisables, les limites de ce langage primitif sont très vite apparues. Il a donc été nécessaire de revoir en profondeur le systèmes de scripts.
C'est alors que j'ai compris que j'avais besoin d'un moteur de scripts réel (pas le petit interpréteur codé sur le tas de la 4.x) qui devrait permettre carrément de
créer des classes, classes qui devraient s'interfacer de façon transparente avec le code natif du programme.
Évidemment, c'est impossible : il est impossible de créer des classes pendant l'exécution d'un programme. Et de fait, aucun moteur de script existant pour Delphi (TMS Scripter Studio, Pascal Script, etc.) ne le permettait. C'est comme ça que j'ai commencé le projet Sepi. Projet de moteur de script orienté objet pour Delphi.
Dans ce projet, je suis parvenu à faire l'impossible : créer des classes pendant l'exécution du programme, avec ses méthodes, virtuelles ou non, héritant de classes natives du programme, surchargeant éventuellement des méthodes virtuelles de ces classes natives, etc.
À présent, Sepi a été mis en oeuvre en environnement réel, avec FunLabyrinthe 5.0.
Il existe donc un nouveau langage dans FunLabyrinthe, le FunDelphi, qui est spécialisé pour FunLabyrinthe. Voici comment on peut définir un objet MasterKeys (passe-partout) qui permet d'ouvrir à la fois les verrous argentés (OpenSilverLock) et dorés (OpenGoldenLock) :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
| unit SpecialKeys;
uses
FLBCommon; // définit les attributs OpenSilverLock et OpenGoldenLock
components
// L'objet
MasterKeys: TMasterKeys;
// Et l'outil qui donne cet objet
MasterKey: TObjectTool(
ObjectDef: MasterKeys,
FindMessage: 'Tu as trouvé un passe-partout : tu peux ouvrir tous les blocs.'
);
// La classe TMasterKeys qui définit le comportement
object TMasterKeys
name 'Passe-partout'; // le nom du composant
image 'SpecialKey'; // le nom du fichier image
action OpenSilverLock, OpenGoldenLock then
Player discards 1 Self;
end;
end. |
Cette petite unité, ajoutée comme fichier source dans un labyrinthe, compilée, puis ajoutée comme Unité utilisée, ajoutera un outil MasterKey à la palette des composants de l'éditeur. Et vous pourrez constater qu'il donne un objet MasterKeys qui permet d'ouvrir aussi bien les blocs en argent que les blocs en or.
Des exemples plus complets sont disponibles dans les labyrinthes Catacombes et Ca-Glisse.
Ce langage est compilé et interprété par Sepi.
Bon je vais en rester là ce soir, je repasserai probablement donner d'autres explications demain, et peut-être déjà répondre à vos questions
0 |
0 |