Comprendre la complexité des embranchements dans un visual novel

Mars 2026 6 min de lecture Structure du projet

Ren'Py Embranchements Structure narrative Cartes visuelles

Tout développeur de visual novel arrive à un moment où il ne peut plus garder toute la structure de l'histoire dans sa tête. Le script continue de grossir, les choix de menu se multiplient, et la question « ce choix a-t-il vraiment de l'importance ? » cesse d'avoir une réponse évidente.

Ce n'est pas un problème d'écriture. C'est un problème de visibilité structurelle. Voici ce qui se passe mathématiquement et ce que vous pouvez faire à ce sujet.

Pourquoi les scripts simples deviennent difficiles à raisonner

Un script de visual novel est un graphe orienté. Les labels sont des nœuds, les sauts et appels sont des arêtes. Quand vous écrivez un menu: avec trois options, vous créez trois arêtes sortantes depuis un nœud — et ces trois chemins peuvent chacun se ramifier plus loin en aval.

À petite échelle, c'est facile à suivre mentalement. Trois labels, deux choix, un point de fusion. Vous pouvez le schématiser sur papier.

À moyenne échelle — 50 labels, 20 points de choix, 8 fins possibles — les schémas sur papier cessent de fonctionner. Vous maintenez un modèle mental implicite du graphe, et ce modèle se dégrade chaque fois que vous écrivez du nouveau contenu sans regarder l'ensemble de la structure.

L'explosion des choix : les chiffres

Le nombre maximum de chemins distincts dans un script croît de manière exponentielle avec le nombre de points de choix. Pour une structure à branchement binaire simple (chaque choix a exactement deux options, sans fusion) :

Points de choix	Nombre maximum de chemins distincts	Testable manuellement ?
5	32	Facilement
10	1 024	Avec effort
15	32 768	Non
20	1 048 576	Non

La plupart des visual novels fusionnent les branches fréquemment — réduisant le nombre réel de chemins bien en dessous du maximum théorique. Mais « fusion au prochain chapitre » n'est pas la même chose que « tous les choix sont équivalents ». Les chemins entre le choix et le point de fusion peuvent contenir des scènes différentes, des assets différents, des états de variables différents. Ces chemins intermédiaires doivent chacun fonctionner correctement.

La conséquence pour les tests Vous ne pouvez pas tester tous les chemins. C'est vrai pour quasiment tout visual novel commercial. Ce que vous pouvez faire, c'est vérifier la structure statiquement : confirmer quels labels existent, lesquels sont atteignables, et quels sauts pointent vers quelque chose qui n'existe pas.

À quoi ressemblent les scripts en grandissant

En début de projet, le flux est linéaire avec des branches occasionnelles :

start └─ intro_scene └─ [ choix 1 ] ├─ path_a → chapter_2 └─ path_b → chapter_2

À mesure que le projet avance, la structure s'accumule. De nouvelles scènes sont ajoutées entre les existantes. Les fins se multiplient. Les variables commencent à déterminer quelles branches sont atteignables :

start └─ prologue └─ [ choix précoce ] ├─ route_a │ ├─ route_a_ch2 │ └─ [ choix intermédiaire ] │ ├─ route_a_good → chapitre_3 │ └─ route_a_bad → chapitre_3 └─ route_b ├─ route_b_ch2 └─ [ choix intermédiaire ] ├─ route_b_good → chapitre_3 └─ route_b_bad → mauvaise_fin_1

Ajoutez maintenant deux chapitres de plus, trois nouvelles fins, des chemins conditionnés par des variables qui n'apparaissent que si une statistique dépasse un seuil, et une route cachée ajoutée à mi-développement — et vous avez un graphe qu'aucun développeur ne peut garder exact en mémoire.

Problèmes structurels qui n'apparaissent qu'à grande échelle

Labels morts

Labels vers lesquels rien ne saute. Ils ont été écrits, peut-être entièrement doublés et illustrés, mais retirés du fil actif de l'histoire quand la narration a changé. Ils existent toujours dans le fichier script. Ils consomment des assets. Ils sont invisibles dans un éditeur de texte.

Cibles de saut inexistantes

Un jump ending_secret_route ajouté avant que le label n'ait été créé — et ensuite la création du label a été oubliée. L'erreur n'apparaît que lorsqu'un joueur atteint ce point précis de l'histoire.

# Ajouté lors du refactor du chapitre 5
jump route_c_hidden_ending

# Le label n'a jamais été écrit
# Cette erreur attend celui qui atteindra ce chemin
    

État de variable orphelin

Une variable est définie dans une branche et lue dans une autre, mais le chemin qui la lit peut aussi être atteint sans jamais l'avoir définie. La variable a sa valeur par défaut — ce qui peut produire une ligne de dialogue grammaticalement incorrecte, une mauvaise expression de personnage, ou une erreur logique silencieuse qui s'accumule jusqu'à la fin du jeu.

Pourquoi les cartes visuelles changent ce que vous pouvez voir

Lire un fichier .rpy est une expérience linéaire. Vous voyez les labels dans l'ordre où ils sont écrits, pas dans l'ordre où un joueur les expérimente. Un jump au bas d'un label de la longueur d'un écran envoie l'exécution quelque part qui peut se trouver à des centaines de lignes de distance, dans plusieurs fichiers.

Une carte visuelle restitue la même information sous forme de graphe — des nœuds pour les labels, des arêtes pour les sauts et appels. Sur cette carte, vous pouvez voir d'un coup d'œil :

Quels labels n'ont pas d'arêtes entrantes (labels potentiellement morts, ou vrais points d'entrée)
Quels labels n'ont pas d'arêtes sortantes (fins, ou labels qui devraient avoir un saut mais n'en ont pas)
Où l'histoire converge à nouveau après les branches
Quels nœuds ont un nombre inhabituellement élevé d'arêtes entrantes (points de fusion par lesquels passent de nombreux chemins)
Si le graphe a des composantes connexes — des sous-graphes isolés inatteignables depuis le démarrage

Rien de tout cela n'est visible depuis un éditeur de texte. Tout cela est visible en quelques secondes sur un graphe.

Ce qui change au-delà de 100 labels En dessous d'environ 30 labels, la plupart des développeurs maintiennent un modèle mental exact de la structure de leur histoire. Au-delà de 100 labels, le modèle mental est presque toujours incomplet ou inexact sur au moins un point. Une carte visuelle ne remplace pas votre compréhension — elle corrige les parties que votre mémoire a silencieusement laissé tomber.

Comment BranchPy visualise la structure de l'histoire

Le visualiseur de flux de BranchPy lit chaque fichier .rpy de votre projet et génère un graphe de nœuds interactif. Chaque label devient un nœud. Chaque jump, call, et branche générée par un menu devient une arête. Le graphe est disposé automatiquement et est consultable par nom de label.

Cela ne nécessite aucune modification de vos scripts. Vous continuez à écrire en Ren'Py exactement comme vous l'avez toujours fait.

Résumé

La complexité des embranchements croît de manière exponentielle avec le nombre de points de choix.
Les tests manuels ne peuvent couvrir qu'une petite fraction de tous les chemins possibles dans un projet de taille moyenne.
Les problèmes structurels — labels morts, cibles de saut manquantes, chemins orphelins — sont invisibles dans un éditeur de texte à grande échelle.
Une carte visuelle du graphe de l'histoire rend ces problèmes immédiatement visibles sans exécuter le jeu.
Comprendre la structure est un prérequis pour la tester efficacement.

Visualisez la structure de votre projet BranchPy génère un graphe de flux interactif à partir de vos scripts Ren'Py — labels, sauts, branches, et tout le reste. Aucune configuration requise.

Voir ce que BranchPy analyse →

← Comment repérer les images manquantes Tous les guides →