Après une longue interruption, voici enfin la suite du making-of des Monstres d’Amphitrite. Il me sera d’ailleurs plus facile d’en parler maintenant que le projet est sorti (si vous ne l’avez pas encore vu, c’est là!) sans craindre de trop en dévoiler. Dans ce billet, il sera question de l’écriture et du storyboard et, au-delà de ça, des différents phases que je traverse lors de la gestation d’un projet de ce type.

D’abord, il est important pour comprendre la suite de dire que la gestation du projet a démarré quelques mois en amont : dès l’automne 2015, j’ai testé des outils, en particulier la librairie jCanvas, excellent outil que j’ai finalement abandonné mais auquel je reviendrai très certainement. Et dès l’automne, j’ai commencé à réfléchir au projet, tranquillement, sans rien poser sur le papier. Durant cette phase, un problème a émergé peu à peu…

Avant de commencer, il faut aussi rappeler que j’ai prédéterminé en amont une interface bien particulière, que j’ai présenté dans le deuxième billet de ce making-of. En ce qui concerne les raisons de ce choix (improvisation, gestion du temps, parcours multiples possibles), je renvoie au même billet. Au final, je me trouve confronté à une contrainte forte : l’histoire, quelle qu’elle soit, devra s’inscrire dans ce dispositif particulier que j’appelle « planche évolutive ».

L’idée était de me laisser aller à l’improvisation à l’intérieur de ce cadre. Une première phase a donc consisté, sans véritablement savoir où j’allais, à storyboarder directement des séquences, encore non reliées entre elles. C’est une mise en scène très directe, très rapide, à grands coups de crayon, d’intuitions diverses. En voici quatre exemples au format gif animés :

Dès les tous premiers instants de cette phase de recherche, le problème qui me travaillait dès le début de ma réflexion quelques mois plus tôt s’est fait plus insistant. Initialement, le projet devait consister en une adaptation de la légende du Lion de Terre et du Lion de Mer, qui donne une origine mythologique aux deux îlots du même nom au large de Saint Raphaël. Mais face à mon rapport douloureux à l’actualité et face à une déconfiture dans ma vie personnelle, cette idée me paraissait de plus en plus vaine : j’avais autre chose à raconter qu’une énième fiction. Dès lors, pour la première fois, le projet allait devenir en partie autobiographique, tout en conservant la trame originelle de la légende. J’avais envie de savoir, expérimentalement, ce qui allait se produire quand les événements précités entreraient en collision avec le scénario antique. C’est à partir de cette décision radicale que le projet démarre vraiment.

Parallèlement aux premiers storyboards, je peaufinais le code et faisais plusieurs bouts d’essai (je renvoie à nouveau au billet n°2 pour un exemple au format gif animé). Ce qui ressortait de toutes ces recherches ne me convenait pas mais je ne savais pas encore pourquoi. C’est là qu’intervient ce que j’appelle l’inspiration ou je ne sais quel genre de déclics. En l’occurrence, il en a fallu trois. Le premier concerne la forme : cette grille de 3×3 cases me posait problème. Elle complexifiait beaucoup l’écriture alors que j’avais peu de temps, et elle rendait la mise en forme du propos très mécanique. Le déclic soudain a consisté à resserrer à une grille de 2×2 cases : outre le gain d’efficacité, j’ai pu entrer pleinement dans des jeux visuels beaucoup plus poétiques. Le second déclic découle directement du premier : j’ai accepté douloureusemment de renoncer à « superposer » l’histoire à une carte du golfe de Fréjus, levant ainsi une énorme contrainte formelle. A noter que je m’étais fixé cette contrainte pour jouer avec la légende, qui explique que la naissance des deux îlots est due à Poséidon, qui aurait figé là les deux monstres. Le troisième déclic concerne l’histoire : tous les premiers jets disparates et les diverses idées restant encore à l’état de vue de l’esprit se sont soudainement assemblées de manière claire :

A partir de là, tout ne coule pas de source, mais le projet prend un rythme beaucoup plus soutenu. Je commence la réalisation des premières séquences dans leur forme définitive tout en continuant parallèlement le storyboard des séquences suivantes. Je bosse environ 12 heures par jour et boucle tout le projet en un peu moins de trois semaines (alors que la phase de gestation et les premières recherches décrites ci-dessus se font par micro-bonds disséminés sur environ six mois). J’inaugure un nouvel outil pour le storyboard : rien de tel que des post-it pour improviser librement ! Ils me permettent de jouer avec les jeux visuels et l’agencement des cases tout en facilitant grandement les repentirs.

Je crois que les images sont assez claires. Les changements de couleurs de post-it trahissent les innombrables repentirs. Les post-it fluos sont issus de versions anciennes de certaines séquences et ont été recyclés dans les séquences définitives (c’est particulièrement net dans le passage du monstre blanc). C’est ce que je voulais dire quand je disais que tout ne coulait pas de source : je n’ai pas pu compter le nombre de versions de chaque séquence tant il y en a eu. Pour preuve :

Voilà tout pour ce billet. La prochaine fois, on parlera de dessin vectoriel !

 

En attendant la sortie prochaine des Monstres d’Amphitrite et la suite du making-of, un strip qui en est extrait.

Quatrième billet de ce making-of et deuxième et dernière partie consacrée à la programmation de l’interface.

Pour rappel, je tente ici de répondre le plus simplement possible à une question que l’on m’a souvent posée : « comment ça marche tes trucs ? » et, collatéralement, « qu’est-ce que c’est, la programmation ? » Dans le dernier billet, j’ai répondu en disant : « c’est donner des ordres, des instructions à l’ordinateur ». Permettez-moi aujourd’hui de compléter : c’est donner des instructions à un ordinateur dans sa langue. Prenons un tout petit extrait du code utilisé dans Les Monstres d’Amphitrite :

Dans ce bout de code, je m’adresse directement à l’ordinateur pour lui demander certaines choses. Je le fais dans sa langue (ou plutôt l’une de ses langues : il en connait plusieurs). C’est exactement la même chose que parler une autre langue, que parler anglais ou espagnol. Je peux même m’amuser à traduire ce bout de code en français, ligne par ligne, phrase par phrase. Ca dit : « s’il-te-plaît adorable ordinateur, peux-tu faire en sorte que lorsque je passe la souris sur la case n°x (1), le pointeur de la souris prenne la forme d’une main-au-doigt-pointant (2); et que lorsque je clique dessus, cela déclenche les opérations permettant de passer à la case suivante (3)? » La langue utilisée ici est Javascript, dans une forme simplifiée grâce au framework jQuery. Hé bien on peut filer la métaphore de la langue encore plus loin. La différence entre Javascript et jQuery est analogue à la différence qui existe entre les différents niveaux de langage. Javascript est littéralement le niveau châtié de la langue, et jQuery le niveau courant ou familier : formes et tournures abrégées, grammaire et syntaxe simplifiées.

Quand je rédige un script, je fais un vrai exercice de traduction, du français (langue dans laquelle je rédige, au brouillon, les séries d’instructions indivisibles dont je parlais dans le précédent billet) vers le Javascript. La traduction est possible dans les deux sens. (Toute cette réflexion a fait l’objet de la performance Cache-cache, en 2013, dont vous pouvez voir la vidéo en ligne).

Revenons-en au script et en particulier aux « fioritures » de l’interface. Et ça commence par une erreur de conception majeure. La partie principale du script, celle qui fait avancer l’histoire, était destinée à être la plus souple possible. Je voulais qu’elle puisse fonctionner quel que soit le nombre de case, quelless que soient leur position et leurs dimensions, de manière à ce que cela puisse resservir pour d’autres histoires, mais aussi pour d’autres personnes (servez-vous ! Vous pouvez utiliser librement ce code!). Je voulais également me réserver la possibilité de créer des parcours à choix multiples à l’intérieur de mon récit. Hé bien ça, j’aurais dû y penser en amont, dès le départ, car la logique de mon script s’est avérée totalement incompatible avec les parcours multiples. N’ayant eu aucune envie de tout reprendre à zéro, j’ai bricolé un truc qui fonctionne pour Les Monstres d’Amphitrite, mais qui n’a aucune souplesse. Le script qui suit est donc prévu pour un unique cas : en fin de chapitre, un certain nombre de choix de parcours peuvent être proposés (le maximum possible étant défini par le nombre de cases à l’écran); mais chaque parcours ne dure que le temps d’un chapitre, tous les parcours se rejoignent au chapitre suivant et il faut repasser par ce nœud commun avant de proposer à nouveau plusieurs choix. Comme vous le voyez, c’est vraiment pour un cas de figure unique…

Ce bricolage a d’abord nécessité de revoir toute la hiérarchie du stockage des images en créant, dans chaque dossier d’images (un par chapitre, nommés ci-dessus « SEQ0 », « SEQ1 », etc.), un sous-dossier pour chaque branche possible dans le chapitre concerné (nommés « 0 », « 1  », « 2 », etc.).

Lors de l’initialisation, on indique quels chapitres offrent plusieurs choix à la fin de leur lecture, et combien de choix ils offrent (1). Par exemple dans cette version, on a 3 choix à la fin du chapitre 1. (Pour paramétrer plusieurs chapitres, on aurait pu utiliser une structure switch…case à la place de la structure if.) Ce sont les x derniers emplacements de la liste qui seront cliquables simultanément. Par exemple ici, pour 3 choix de parcours en fin de chapitre 1, ce sont les emplacements B2, C2, et A3 qui seront cliquables et clignoteront de manière simultanée (2).

Dans le dernier billet, on avait vu ce qui se passait au moment du clic dans le cas où il n’y avait pas de changement de chapitre et dans le cas où il y avait un changement de chapitre sans choix de parcours. On avait laissé de côté le dernier cas de figure : ce qui se passe lors du clic si on est arrivé à la fin d’un chapitre (1) qui offre plusieurs choix de parcours (2). Dans ce cas :
(3) On indique que l’on change de chapitre.
(4) Pour chaque choix de parcours, on applique à chaque emplacement correspondant le traitement suivant :
(5) On définit un lien vers le bon chapitre.
(6) On transforme l’emplacement correspondant en lien tel que défini en (5) et on le rend cliquable.
(7) Ce compteur permet d’interrompre la procédure une fois que tous les emplacements nécessaires ont été traités.
(8) et (9) On fait clignoter les emplacements.

Il reste deux fioritures à voir. Je les commenterai rapidement mais sans les détailler cette fois. D’abord, une partie du script permet de redimensionner l’ensemble des images de manière à s’adapter à la taille du navigateur de chaque utilisateur :

Ce sont de simples calculs de proportionnalité (vous savez, le tableau en croix ou règle de trois). Remarquez que je rentre en « dur » les dimensions des images dans le code, car je les connais d’avance et qu’elles font toutes la même taille (là encore, ça ne vaut donc que pour ce projet-là). Cela évite de devoir demander au programme de détecter automatiquement les dimensions des images, avec les problèmes que ça ne manque jamais de poser en terme de détection de la fin du chargement de chaque image.

Enfin, pour finir, voici la fonction qui fait clignoter le contours des emplacements quand ils sont cliquables :

C’est une simple animation qui se répète en boucle un certain nombre de fois (En l’état actuel du projet, 100 fois au début du premier chapitre et quand il y a choix de parcours, 2 fois dans les autres cas).