Branches de dialogue Ren'Py : relier choix, variables d'histoire et chemins de retour

Rendre explicite la suite de chaque choix

Un menu Ren'Py présente des choix dont le bloc d'instructions sélectionné est exécuté. Lorsque le bloc choisi se termine normalement, l'exécution se poursuit après le menu. Utilisez un bloc local pour une courte variation, et un label nommé lorsque la structure gagne à avoir une destination distincte. [1][2]

Notez à quel endroit chaque branche rejoint l'histoire. Un choix visible promet une conséquence, mais celle-ci peut être une réplique modifiée, une valeur de relation ou une option ultérieure, plutôt qu'un chapitre définitivement séparé.

Initialiser délibérément les variables d'histoire modifiables

Utilisez default pour les variables susceptibles de changer pendant la partie. Cette instruction fournit une valeur lorsque la variable n'est pas définie au démarrage du jeu ou lors d'un chargement. Les variables déclarées avec define sont traitées comme des constantes et ne doivent pas servir de compteurs de relation modifiables. [3]

Pour une scène de port originale, initialisez default trust = 0. Gardez cette déclaration séparée du déroulement ordinaire d'une conversation, afin que le fait de revenir à cette conversation ne réinitialise pas la relation de façon délibérée. Donnez à la variable un sens clair : la confiance gagnée en aidant le pilote du port, plutôt qu'un score inexpliqué réutilisé par des scènes sans rapport.

Relier un choix à une condition ultérieure

Proposez au joueur de réparer la lanterne du pilote ou de continuer sans l'aider. Dans la branche de réparation, utilisez $ trust += 1 ; l'autre branche laisse la valeur inchangée. Plus loin, une option permettant de consulter les notes de route du pilote peut utiliser if trust >= 1. Cet exemple définit la règle de relation ; Ren'Py ne la déduit pas du dialogue.

Une option de menu conditionnelle est normalement masquée lorsque sa condition est fausse. L'option de configuration config.menu_include_disabled permet à la place de l'afficher en grisé. Si aucun choix n'est disponible, le menu est ignoré et l'exécution se poursuit après lui. Prévoyez un repli volontaire, ou écrivez délibérément cette suite. [1]

Choisir entre call et jump selon le comportement de retour

call transfère le contrôle à un label et enregistre l'endroit où l'exécution doit reprendre. Le passage appelé peut utiliser return pour continuer après l'appel. jump transfère le contrôle sans ajouter son propre point de retour. Utilisez un appel pour un passage réutilisable de réparation de la lanterne, qui doit revenir vers différentes conversations ; utilisez un saut lorsque l'histoire doit se poursuivre à une autre destination. [2]

Un retour effectué avec une pile d'appels vide ramène au menu principal. Ne le considérez pas comme une instruction générique signifiant simplement que le paragraphe en cours est terminé. Gardez le comportement de retour visible dans la conception des branches.

Vérifier les conséquences et la reconvergence

Suivez les deux choix du port, puis examinez le menu ultérieur des notes de route. Vérifiez une nouvelle partie, une visite de retour et, s'il est possible de revenir à la conversation, une seconde tentative de réparation. Décidez si la récompense peut être obtenue de nouveau ; si elle doit être unique, suivez ce fait explicitement plutôt que de compter sur le fait que le joueur ne reviendra jamais.

Examinez ce qui se passe lorsque le choix facultatif des notes de route n'est pas disponible, et confirmez que tous les chemins prévus mènent à l'étape suivante de l'histoire. Il s'agit de parcours proposés, non de tests exécutés. Maintenez l'accord entre la formulation des dialogues et les mises à jour de l'état de l'histoire, afin que les conditions ultérieures reflètent ce que le joueur a réellement choisi.

Sources

1. In-Game Menus — Ren'Py documentation contributors.
2. Labels & Control Flow — Ren'Py documentation contributors.
3. Python Statements — Ren'Py documentation contributors.