Un choix compte quand l’histoire s’en souvient. Ce projet pour débutants suit deux collaborateurs adultes qui décident comment ouvrir un studio, avec un petit graphe de passages, une décision enregistrée et deux fins. Il nécessite très peu d’illustrations. Votre première tâche consiste à faire en sorte que chaque choix mène au résultat prévu, puis que ce résultat soit conservé après une sauvegarde et un rechargement.
Le téléchargement contient le code source Twee pour SugarCube. Compilez-le en HTML jouable avec Tweego et un format d’histoire SugarCube installé, ou recréez les passages de l’histoire à la main dans Twine. L’exemple n’a pas été exécuté ici dans un environnement Twine : effectuez donc les tests ci-dessous avant de le publier.
Choisissez d’abord le format
Créez une histoire dans Twine, sélectionnez SugarCube 2 comme format d’histoire et notez la version utilisée. Gardez sa documentation officielle à portée de main pour les macros, les variables et les sauvegardes. Les exemples Harlowe utilisent une syntaxe différente ; les copier directement dans SugarCube est un moyen rapide de transformer une scène simple en séance de débogage.
Dans le code source téléchargé, les lignes commençant par :: introduisent des passages. StoryTitle et StoryData contiennent les informations de configuration. Dans l’éditeur de Twine, définissez le titre de l’histoire et le format SugarCube, puis créez StoryInit et les six passages de l’histoire en respectant exactement leurs noms. Copiez le contenu de chacun sans son en-tête :: et sélectionnez Start comme passage de départ. Un fichier .twee est un code source modifiable ; publiez du HTML pour les joueurs.
Construisez le graphe des passages
L’exemple initialise $sharedPlan à false. Start propose deux réponses : SharedPlan lui attribue la valeur true, tandis que SeparatePlan lui attribue la valeur false. Les deux mènent à Discussion, qui vérifie la valeur et affiche le lien vers SharedEnding ou IndependentEnding. Voilà tout le graphe : une décision avec une conséquence visible.
Donnez aux passages des noms stables et distinctifs, puis vérifiez chaque destination dans le graphe visuel comme dans la version publiée. Un joli libellé de lien ne peut pas compenser une faute dans le nom de la destination. Séparez le nom interne du passage du texte que vous pourriez réécrire ou traduire, afin qu’un changement de formulation ne casse pas le parcours.
Rendez les changements d’état prévisibles
Utilisez une variable nommée pour une décision précise. Ici, $sharedPlan enregistre si le joueur a choisi un projet commun ; elle n’a pas à représenter tous les sentiments entre les personnages. Définissez-la au moment du choix et lisez-la là où la conséquence apparaît. Rendre ce lien évident facilite l’extension d’une petite histoire.
Vérifiez ce qui se passe lorsqu’un joueur revient sur un passage. Si son affichage ajoute un point, une nouvelle visite peut involontairement en attribuer un autre. Dans les projets plus importants, donnez aux événements uniques leurs propres règles et décidez si revenir en arrière dans l’historique de l’histoire doit annuler leurs effets. Testez aussi les rechargements, sans supposer qu’ils se comportent comme une première visite.
Concevez une page lisible
Commencez avec l’interface par défaut du format d’histoire. Donnez au texte une largeur de lecture confortable, utilisez une police lisible et rendez bien visible le focus clavier sur les liens. Vérifiez les paragraphes et les choix sur un écran étroit. Une surcouche décorative n’est pas d’un grand secours si le joueur ne trouve pas la ligne suivante ; n’ajoutez des arrière-plans élaborés qu’une fois la lecture fluide.
Faites en sorte que les paramètres et les commandes de redémarrage et de sauvegarde soient faciles à trouver. Ne vous fiez pas uniquement à la couleur pour signaler les liens disponibles ou un état important, afin que la page reste compréhensible si un indice coloré passe inaperçu. Si vous ajoutez du son ou du mouvement, prévoyez des commandes et commencez discrètement. Laissez les joueurs choisir quand la bande-son ou l’animation entre en scène.
Publiez et testez la persistance
Publiez avec Twine, ou compilez le code source en HTML avec le format SugarCube sélectionné, puis servez ce fichier depuis l’hébergement prévu. Testez-le dans le navigateur et à l’origine du site que les joueurs utiliseront. Le stockage du navigateur dépend de son contexte : une sauvegarde locale réussie ne suffit donc pas à établir le comportement de la version hébergée.
Sauvegardez avant la décision, puis après. Fermez la page, rouvrez-la et chargez chaque sauvegarde en vérifiant que le choix mémorisé et la fin disponible sont corrects. Répétez le test dans un nouveau profil de navigateur, en y créant de nouvelles sauvegardes. Vérifiez séparément la navigation privée, l’effacement du stockage et la diffusion intégrée dans une autre page. Décrivez les limites constatées ; les paramètres du navigateur et le comportement de l’hébergement peuvent empêcher les sauvegardes de persister.
Préparez les futures mises à jour
Conservez le code source modifiable sous contrôle de version et archivez chaque version HTML publiée. Consignez la version de SugarCube et les modifications des passages, et conservez des fichiers de sauvegarde représentatifs afin de pouvoir comparer une mise à jour à la version précédente. Décidez si les mises à jour prendront en charge les sauvegardes existantes. Si les joueurs doivent recommencer, expliquez cette obligation avant qu’ils ne chargent la nouvelle version.
Jouez chaque fin depuis un nouveau départ et vérifiez tous les liens au clavier et, si nécessaire, avec des commandes tactiles. Utilisez la matrice de test des parcours pour consigner les résultats attendus et réels. Vous pouvez passer à la suite lorsque l’histoire se lit clairement, que son état se comporte de façon prévisible et que vous pouvez reproduire le processus de publication. Consultez le guide des parcours et des états avant de construire un vaste réseau de branches.
Décisions clés
- Sélectionnez SugarCube 2 avant d’écrire des macros SugarCube.
- Conservez le code source Twee ; publiez du HTML jouable.
- Testez les visites répétées, les sauvegardes et les rechargements sur l’hébergement prévu.
- Gardez des noms de passages stables et archivez les versions publiées.
Fichiers du guide
Exemple Twee pour SugarCube ↓Matrice de test des parcours ↓Les communautés externes consacrées aux modèles et les sites de publication externes peuvent contenir du contenu explicite. Les liens vers les sources s’ouvrent dans un nouvel onglet ; ce guide ne charge pas leurs aperçus.
Sources et lectures complémentaires +
Dernière vérification 5 octobre 2026.