Bonjour YAZ,
Pour commencer, je propose de nous tutoyer, si ça ne dérange pas (ou au moins me tutoyer moi :P). C'est la première fois qu'on me vouvoie sur un forum, je suis un peu déstabilisé
Avant de commencer ma longue explication, je vous propose de télécharger et d'essayer les scènes d'exemple que j'utilise pour mes tests pendant le développement d'Escoria. Ce n'est pas réellement un jeu, il n'y a pas d'histoire, c'est une succession de rooms sans lien spécifique. C'est en anglais pour le moment car je n'ai pas encore travaillé sur la traduction. C'est moche parce que je ne suis pas artiste
mais j'utilise des assets libres de droit (leurs auteurs sont cités dans le readme du projet).
https://cloud.murgia.fr/s/XpfcdK6bt2Domkm
YAZ a écrit : ↑29 mars 2021, 09:58
Je n'ai pas encore créé de jeu Point & Clic à proprement parler, mais j'aime assurément les puzzles (c'est mon point fort), et j'attends d'un point & clic qu'il ait des dialogues à choix multiple (et une réelle conséquence à ces choix), une gestion d'inventaire (objets à récolter, objets à observer de plus près, objets à combiner, objets à utiliser sur le décors, ...), ... et pourquoi pas une carte générale sur laquelle activer des lieux à pouvoir visiter, ainsi qu'un arbre de choix-conséquences comme dans Detroit (oui, je sais que ce n'est pas un point & clic ^^) pour résumer les actions faites par le joueur et l'embranchement de celles-ci dans le scénario.
Beaucoup de desideratas ici ! Parfait !
En ce qui concerne les puzzles, nous pourrions en discuter très, très longuement, même si j'ai lu quelques articles tentant de définir une classification des puzzles que l'on peut rencontrer dans un jeu d'aventure. Ils vont du plus simple (utiliser poulet en caoutchouc avec une poulie au milieu sur corde) jusqu'aux puzzles que j'appelle "complexes" et qui n'utilisent pas forcément les objets du jeu pour être résolus : je pense par exemple aux puzzles de Deponia, ou de certains qu'on peut voir dans The Dig.
Pour les premiers, c'est facile : Escoria permet simplement de scripter chaque action avec le langage de script fourni, pour chaque objet utilisé. Prenons par exemple une lampe torche sans les piles. Je peux lui affecter le bout de script suivant:
Code : Tout sélectionner
:ready
# Au départ, l'objet n'a pas de piles
set_global lampe_torche_piles_ok false
:utiliser piles
inventory_remove piles
set_global lampe_torche_piles_ok true
say player "J'ai mis les piles dans la lampe torche. Elle devrait fonctionner maintenant !"
:utiliser
> [!lampe_torche_piles_ok]
say player "Il n'y a pas de piles! Elle ne fonctionnera pas."
stop
> [lampe_torche_piles_ok]
say player "La lampe torche est allumée."
stop
Dans le script ci-dessus, j'ai défini une variable globale (connue d'Escoria, à tout moment) permettant de savoir si les piles ont été mises dans la lampe. Au départ elles n'y sont pas. Puis je définis une action "utiliser" avec un paramètre "piles", qui va supprimer les piles de l'inventaire (normal puisqu'elles sont dans la lampe) et passer la variable globale à "true". Enfin, je définis une action "utiliser" sans aucun paramètre, qui contient un embranchement selon la valeur de la variable globale.
Pour les puzzles plus complexes, le langage de script donné en exemple ci-dessus ne suffira pas. Cependant, c'est là toute la force de Godot : s'agissant d'un moteur généraliste, il est possible de créer n'importe quel puzzle avec Godot à l'aide de son propre langage de script GDScript (utilisé par Escoria en coulisses). Il suffit alors d'appeler certaines fonctions fournies par Escoria pour indiquer le puzzle a été résolu, généralement en définissant une variable globale, comme ci-dessus. De cette façon, Escoria sait que le puzzle est résolu et il peut donc enchaîner les actions correspondantes.
Pour les dialogues à choix multiples, le langage de script fourni avec Escoria le permet. Pour et une réelle conséquence à ces choix, cela dépend de l'écriture et des scripts... Escoria ne peut pas le faire à la place de l'auteur
Mais là encore, tout se passe avec des variables globales. Prenons un dialogue simple:
Code : Tout sélectionner
say vilain "Donne moi tout ton or !"
?
- Pas question !
say player "Pas question ! Tu devras le prendre à mon corps froid."
set_global refuse_donner_or true
# Et on continue la branche...
- D'accord, prends-le.
say player "D'accord, je ne veux pas me battre."
remove_inventory argent
set_global refuse_donner_or false
Comme on peut le voir, la variable "refuse_donner_or" permet au jeu de se "souvenir" que le joueur a donné son or, ou pas. Il est alors possible de tester cette même variable beaucoup plus tard dans l'aventure, et d'activer des actions spécifiques selon le cas.
Pour ce qui est de la gestion d'inventaire, tout ce que vous avez listé est possible aussi :
- objets à récolter : oui
- objets à combiner : oui
- objets à utiliser sur le décors : oui
- objets à observer de plus près : je pense que cela s'apparente un peu à ce que j'appelais un "puzzle complexe" ci-dessus. Je ne l'ai cependant pas encore illustré moi-même, mais c'est tout à fait possible.
Idem pour la carte générale sur laquelle activer des lieux à pouvoir visiter : c'est un classique des jeux d'aventure, on le trouve sous différentes formes (dans Monkey Island 1, 2 et 3, Guybrush se déplace physiquement d'un point à l'autre, alors que dans The Longest Journey le jeu change simplement la scène dès que le joueur a cliqué sur la destination). Je n'ai pas encore illustré cela avec un exemple, mais les 2 sont parfaitement possibles : Escoria intègre simplement une fonction qui permet de changer de scène. Une scène peut être une "room" (au sens du jeu d'aventure, c'est une pièce avec un unique point de vue) ou une scène spéciale affichant carte permettant le choix de la destination.
Enfin:
arbre de choix-conséquences comme dans Detroit (oui, je sais que ce n'est pas un point & clic ^^) pour résumer les actions faites par le joueur et l'embranchement de celles-ci dans le scénario
Je n'ai pas joué à Detroit donc je ne sais pas exactement à quoi cet arbre ressemble. Mais là encore, l'arbre des possibilités n'intègre logiquement que des possibilités prévues par le game designer, qui sont autant de variables globales à gérer dans les scripts. Ce qui manquerait, c'est une façon d'afficher au joueur cette succession de choix ayant activé ou non ces variables. A mon avis, dès l'instant où j'offre au concepteur de jeu la possibilité de garder en mémoire des informations incluant les choix du joueur, il n'est pas trop compliqué de concevoir une scène pour les lui afficher sous une forme ou une autre (comme un journal, ou un graphe), mais cela nécessitera certainement d'utiliser GDScript pour obtenir le résultat voulu, car le langage de script ESC fourni par Escoria est une surcouche, dédiée uniquement à manipuler les éléments du jeu d'aventure.
YAZ a écrit : ↑29 mars 2021, 09:58
Si vous avez des images (la présentation du post est un peu "sobre" sans images ^^) afin de montrer comment ça fonctionne, s'il faut écrire des lignes de code ou utiliser une interface WYSIWYG, si les exemples et autres aides seront écrites en français (j'avoue qu'en plus, si tout est en anglais en commentaires/explications, ça peut bloquer quelques dev indés/amateurs francophones) et quelques exemples visuels de résultat (captures d'écran depuis Escoria dans Gogot), ce serait top ! Peut-être que votre outil me donnera l'envie de me lancer dans Godot, qui sait ? ^_^ En revanche, j'ai cliqué sur votre lien github, et je me retrouve à ne pas savoir quoi faire de tout ce qui est à l'écran (j'ai toujours trouvé qu'un tel pack de fichiers est effrayant lorsqu'on ne s'y connaît pas). Décidément, si on ne me tient pas la main, je me perds d'un rien, d'où l'importance d'un travail comme le vôtre ^^ Merci à vous.
Pas de problème !
Vous l'aurez compris en lisant mes explications ci-dessus: Escoria est un mélange de WYSIWYG et de lignes de code. Pour ce qui est du scripting propre à Escoria, le langage se veut relativement simple, même s'il est selon moi nécessaire de comprendre un minimum de concepts de Godot pour l'utilise (notamment les animations, par exemple). C'est bon à savoir pour moi, car quand je commencerai à m'occuper de la documentation il faudra que je le prenne en compte.
Bon alors évidemment je suis un peu obligé de travailler en anglais parce qu'Escoria était développé en anglais à l'origine... La documentation sera donc en anglais au départ, mais il me semble important de traduire cette documentation en français.
Quelques images (dont une issue de la démo à télécharger ci dessus):
escoria_room.png
Vous ne pouvez pas consulter les pièces jointes insérées à ce message.