Changement de priorités

Ca faisait longtemps que je n’avais pas pris un café avec Claire, c’est chose faite car on a réussi à se croiser non loin de là où je vis. Une discussion fort intéressante qui m’a permis de faire le point sur où j’en suis de mon travail de création, à quel niveau je procrastine, etc.

Il en ressort que c’était une bonne idée de remettre en service mon "ancien site" en tant que porte d’entrée principale, et j’ai évoqué une nouvelle fois mon désir de mettre en place une aventure interactive sur celui-ci. Comme il s’agit d’un sujet sur lequel je reviens souvent, je pense que ma priorité la plus haute devrait être d’avancer sur ce projet.

Voilà qui nous ramène à DiaVN. Mon idée initiale était de faire en priorité le traducteur Dia -> RenPY, mais avec le recul, il me semble à présent qu’il faut que je mette le paquet sur un outil pour effectuer une traduction Dia -> HTML.

L’idée serait de générer, à partir d’un diagramme Dia, un ensemble de pages web liées entre elles, formant une histoire interactive. Et qu’il y ait un ou des points d’accès dans le site actuel.

Le point de départ de l’histoire pourrait être un type qui regarde par sa fenêtre tout en télétravaillant, et le joueur pourrait sélectionner des "embranchements" qui lui permettent d’aller observer plus en détail tel ou tel élément de la scène. L’interactivité proviendrait du choix des embranchements (parcours en "arbre" classique) mais aussi de la possibilité pour le joueur de proposer lui-même une continuation à l’histoire lorsqu’il arriverait à un point terminal - en somme les pages de fin contiendraient un petit "formulaire" permettant de suggérer une piste. Cette suggestion arriverait sur mon terminal et je pourrais l’intégrer dans l’histoire. Lorsque la nouvelle section de l’histoire serait ajoutée, le joueur serait prévenu (par mail je suppose, à moins d’intégrer une connexion Fédivers ?) et pourrait revenir dans l’histoire au point où il s’était arrêté précédemment. La "sauvegarde" du joueur consisterait essentiellement à mettre un marque-page sur le point de l’histoire où il s’était arrêté.

Dans ce contexte, DiaVN serait utilisé en tant que générateur de HTML pour faire un arbre statique, sans base de données. Ayant fait des premiers tests et une analyse préliminaire, des challenges différents de ceux du générateur RenPY se posent :

• pas de possibilité d’utiliser les variables (on est alors dans un pur arbre, non conditionnel)
• pas de possibilité de compter le nombre de passages dans une boucle (donc pas d’utilisation possible des modes d’affichage des dialogues variant en fonction de la boucle)
• ne pas utiliser les procédures (car impossibilité de stocker en interne l’information sur la page appelante)
• utilisation de Javascript pour afficher progressivement les dialogues sur une page donnée / sélectionner le dialogue à afficher (dans le cas d’un choix aléatoire)
• gestion de template (changer la couleur de fond du texte, des dialogues... ?)
• et le plus important : DiaVN doit être capable de générer la même arborescence de fichiers web, afin que l’utilisateur puisse enregistrer sa progression (via un marque-page).

L’obstacle principal réside dans la façon que Dia a d’attribuer automatiquement des identifiants aux éléments de diagramme. Les identifiants sont notés de O0 à Oxxx, et dans le cas où un élément est supprimé, le prochain élément créé reprendra un identifiant précédemment utilisé. C’est à dire que, entre deux versions d’un même diagramme, deux éléments différents peuvent avoir le même identifiant. Or, à l’heure actuelle, DiaVN utilise les identifiants comme marqueurs uniques pour référencer les éléments. Par conséquent, si je génère les noms de fichiers en fonction des identifiants (approche naïve), l’arborescence risque de changer entre deux itérations du jeu - détruisant par le même coup le système de sauvegarde "marque-pages".

Comment faire en sorte que DiaVN génère, pour un diagramme modifié, la même arborescence que précédemment sur les parties qui n’ont pas changé, et comment s’assurer que les points terminaux sont toujours les mêmes d’une fois sur l’autre ?

• le risque principal vient de la situation où un élément serait supprimé puis recréé —> il sera donc "interdit" de supprimer des éléménts (ou tout au moins l’utilisateur devra être conscient que supprimer des éléments existants peut "casser" le système de sauvegarde)
• gestion des "fins temporaires" : peut-être qu’on mettra à profit le fait qu’il est possible d’utiliser des éléments terminaux officieux en les utilisant comme "fins temporaires". A contrario un "game over" (élément End) enverra vers une page prédéfinie où plus rien ne peut se produire.

Voilà. Ca implique que fatalement il y aura des différences entre les jeux RenPY et les jeux HTML. Mais je vais essayer de faire en sorte que le jeu HTML soit un subset du jeu RenPY (afin de pouvoir passer de l’un à l’autre quand le générateur RenPY sera actif).

Allez au boulot !

Màj

C’est encore pire que ce que je pensais : supprimer un élément d’un diagramme Dia change les identifiants de tous les éléments qui le suivent. Argh