Fiction-interactive.fr

Fiches de lecture

Liste des articles :

Notes de lecture : mémoire de Caroline Brun – Hugo Labrande

Notes de lecture : « Make IF Fast » - Hugo Labrande

Notes sur Création de récits pour les fictions interactives – Nathanaël Marion

Notes de visionnage : la conception narrative de Virtue’s Last Reward – Nighten Dushi

Fiche de visionnage : expérience utilisateur et jeux textuels – Filiaa

Fiche de visionnage : Construisez des histoires riches avec une story grid – Nighten Dushi

Notes de lecture : deep learning et parser (2015) – Hugo Labrande

Notes de lecture : Textworld (2018) – Hugo Labrande

Notes de lecture : la plateforme LIGHT – Hugo Labrande

Inform 7 bientôt open source – Hugo Labrande

L’avenir de Ren’Py, le moteur de visual novel de référence – Nighten Dushi

Sélection de conférences de la Visual;Conference 2020 ! - Nighten Dushi

Des nouvelles d’Inform 7 lors de Narrascope II – Nathanaël Marion

Cet ebook compile des articles parus sur le site http://www.fiction-interactive.fr ; ce sont tous les « fiches de lecture », des résumés et comptes-rendus de mémoires, conférences, etc.

Nous publions un article sur la fiction interactive, et plus largement les narrations non-linéaires, tous les vendredis de septembre à juin.

Si ces articles vous ont plu, n’hésitez pas à :

parler de http://www.fiction-interactive.fr autour de vous ;

nous rejoindre sur notre serveur Discord ;

faire un don à notre compte paypal (paypal@fiction-interactive.fr), qui servira à couvrir nos frais d’hébergement et à proposer des prix pour notre concours annuel.

Notes de lecture : mémoire de Caroline Brun

Hugo Labrande

Aujourd’hui, nous inaugurons un autre type d’article sur notre site : les notes de lecture ! Le concept : nous avons lu un article, un mémoire, une thèse (ou vu une conférence) qui porte sur la fiction interactive, et nous extrayons la substantifique moelle pour vous, ce qui peut nous aider ou nous inspirer en tant qu’amateurs ou créateurs de fiction interactive !

Aujourd’hui, un mémoire écrit en 2016 par Caroline Brun pour l’obtention de son diplôme supérieur d’arts appliqués (bac +5) mention design graphique, et qui s’intitule « Jeux textuels, archaïsme et design graphique ». C’est un mémoire assez intéressant, qui a l’avantage de rappeler en français pas mal de choses de sources anglophones, et de soulever de chouettes problématiques (même si je ne suis pas d’accord avec tout ce qu’elle écrit). La problématique du mémoire, c’est en gros : « regardez, y’a des genres littéraires sur internet qui sont restés au niveau 0 du design, et les possibilités sont énormes pour peu qu’on connaisse un peu de JavaSript/CSS, alors pourquoi les designers n’investiraient pas ce champ? ». Ce à quoi je réponds « OUI ! OUI ! OUI ! Venez les designers, on a des outils super et on sait pas les manipuler aussi bien que vous ! ». Attention par contre, ce mémoire ne donne pas de solutions, hein ; l’impression que j’en ai tiré, c’est que le design est un métier, et qu’améliorer le design graphique de nos jeux suppose de lire des livres de design ou d’ ou au moins d’avoir un minimum sur les bases et une petite connaissance des outils…

Le mémoire a une forme qui peut paraître bizarre pour le non-initié : il y a une synthèse (un long texte académique sur le sujet, la grosse partie du mémoire), mais aussi une fiche de lecture, un rapport de stage, une étude de cas, une étude technique et un entretien. C’est peut-être standard pour ce genre de diplômes mais, en tout cas il y a beaucoup de choses différentes ; je vais essayer de les détailler (en espérant faire un résumé plus court que le texte lui-même…). Allez, hop, on commence — et n’hésitez pas à faire des remarques sur cet article (format, etc.) pour savoir si nous continuons comme ça dans cette catégorie !

Synthèse : « Le design au service du jeu : littéractions et fictions interactives »

Intro

Définition d’un jeu, les jeux vidéo s’inspirèrent de la littérature à l’heure ou le livre-jeu explosait. Pourquoi un designer graphique s’intéresserait-ils aux jeux avec texte ? Questions intéressantes : place du texte dans le jeu, rendre intelligible le rapport texte/image dans le jeu, et la relation entre écran et papier.

I — Texte et jeu

Historique du livre-jeu avec Queneau et tout (classique, cf. le bouquin de Monfort pour plus de précisions, mais là ça a l’avantage d’être fait en français !). Fiction interactive : à parser ou à hypertexte. (Elle appelle le parser « interpréteur » au lieu d’« analyseur syntaxique », et l’image qui accompagne est un mix de cartes et de flowcharts de puzzles, c’est un peu bizarre. Mais y’a notre traduction de la carte postale de Zarf !). Composantes d’une FI : le courage (décisions prises par le joueur), la chance (le hasard), la destinée (branches écrites par l’auteur) : je trouve ça joli et rigolo !

Aspects du livre-jeu et de la FI :

L’identification : le joueur s’imagine dedans (elle dit « simulacre », c’est aussi roleplay, escapism, etc.), c’est une composante essentielle en FI surtout à la deuxième personne. (Là on pleure parce que son exemple est une capture d’écran d’Adventure qu’elle a trouvée… sur Littéraction.fr — bouhou on est nuls en référencement.) Intéressant : identification aidée par l’acte même de lecture, qui consiste à rassembler des fragments pour s’imaginer le truc, ca va bien avec l’exploration typique des FI.

le choix : essentiel. Livre-jeu : chaque choix fait avancer ; parser : chaque choix fait avancer ou nourrit la profondeur de la narration (examiner, etc.).

Une aventure est-elle irréversible ? Je vois pas trop le rapport avec ce qui précède mais c’est intéressant quand même. Craft of Adventure dit qu’il vaut mieux donner des indices sur les actions irréversibles ; elle dit que c’est depuis ce texte que c’est classique, mais bof : pour moi c’est Monkey Island des années avant (et la Cruelty Scale d’Andrew Plotkin un peu après). En tout cas, c’est vrai que c’est 100 % moderne, et aux antipodes des jeux des années 80 genre Sierra. Et si on bloque vraiment ? Undo, restore ou restart (et toute cette partie est vraie pour les FI ou les livres-jeu papier, hein !).

Elle imagine ensuite ce que ça voudrait dire un livre-jeu irréversible (permadeath quoi) : par ex avec de l’encre thermosensible pour un livre, en disant que les joueurs devraient alors collaborer pour aller plus loin que ceux qui sont morts (et ouais carrément, vous imaginez le nombre de gens qui iraient sur reddit). (Mais l’inconvénient, c’est qu’un livre est en random access, rien n’empêche de lire les autres paragraphes une fois mort ou de prendre en photo… Un programme auto-destructeur avec un DRM/une base de données de joueurs qui y ont déjà joué me semble bien mieux. Genre la disquette de Agrippa de William Gibson mais pour 2017 quoi.]

Usages actuels et communautés

La FI et le livre-jeu subsistent grâce aux amateurs car 0 marché commercial après un gros boom dans les années 80. La communauté du livre-jeu tourne essentiellement autour des collectionneurs. La FI survit mieux en terme de créations / pratiques nouvelles : elle attribue notamment le succès d’interfaces comme Twine ou Adrift qui permettent de créer des jeux visuellement sans code.

C’est très discutable pour Adrift: le nombre de jeux est très petit, la communauté se meurt dans des débats pour savoir si c’est mieux Adrift 4 ou 5 (qui a changé des choses et ajouté des formulations qui font plus langage de programmation, ce qui déroute les historiques). Pour Twine, par contre, c’est indéniable !

Elle souligne que y’a des FI indies (et cite Emily is Away — si vous avez envie que j’écrive un article pour râler sur ce jeu dites-le moi). Et que globalement la FI ça permet aux auteurs une grande liberté dans l’expérimentation, très d’accord.

S’inscrire dans un type de jeux archaïques

Ça part fort : « un des seuls milieux du numérique où la construction visuelle n’a pas évolué au même rythme que les autres ». BIM, headshot (et elle a raison hein, un screenshot de Brume sur Gargoyle et on se dit « où est l’évolution visuelle »). Elle dit que ça vient de comment c’était quand c’était en vogue : les fichiers de jeu se lisaient sur des émulateurs donc il fallait que ça marche sur toutes les machines donc pas d’aspect graphique ; mais du coup dès que les graphismes sont arrivés bye bye.

Elle a raison en fait : c’était la stratégie d’Infocom (et juste eux quoi) et Frotz et Gargoyle en sont les descendants directs, et même maintenant la portabilité de la Z-machine est glorifiée par certains (« j’ai une configuration très précise » ou « je veux pouvoir y jouer sur mon iPod Touch » donc c’est de ma faute, j’aurais pas dû compter sur une largeur d’écran d’au moins 80 colonnes pour Life on Mars gnagnagna) : faites un jeu super beau en Inform customisé qui tourne que dans un navigateur et y’aura toujours un plouc pour venir faire « où est mon fichier .ulx ».

On pourra dire en même temps que la FI des années 80 c’est pas qu’Infocom, y’a qu’à voir en France ou en Espagne, où les illustrations étaient systématiques et où il n’y avait pas de portabilité comme avec Infocom. Mais le fait est que c’est Inform qui a gagné de nos jours, et Inform est basé sur « du texte et c’est tout », avec zéro contrôle sur la mise en page (l’aspect archaïque de « que du texte » est banalisé par le langage comme elle dit) justement au nom de cette portabilité. Bref je suis d’accord avec elle même si le paragraphe est parfois limite (elle mélange parfois des trucs qui étaient vrais dans les 80s à des trucs actuels, je trouve).

En exemple de jeu plus actuels et adaptés à notre monde elle parle de Lifeline (et ses notifications et la gestion de l’attente), Versu (qui pour le coup est discutable dans un chapitre sur l’archaïsme visuel : je sais pas quel était le design graphique, mais elle cite « la gestion des affects par une IA » ce qui semble un peu hors-sujet — et bon, citer un projet mort comme exemple actuel…), et Twine (mais du coup sans parler du CSS et des macros et tout ce qui rend Twine intéressant niveau graphique…). Bref, OK pour le concept du paragraphe et le diagnostic mais pas convaincu par les exemples…

II — L’intervention du designer : travail du texte

Passage sur la mission du designer graphique, qui n’est pas qu’un illustrateur. Dans tout texte, il y a le texte et son agencement, et ce dernier conditionne la lecture ; on peut jouer avec l’agencement (genre les calligrammes d’Apollinaire) pour ajouter une couche de plus. (Mon passage préféré d’un livre, c’est la séquence kinesthésie dans Terminus les étoiles de Bester.)

L’édition numérique : de nos jours, des apps de lecture invoquent clairement le livre (pages qui tournent, bibli en bois…), alors qu’entre le scrolling et les hyperliens on a des trucs plus intéressants. Mais la lecture est toujours indissociable du support, des contraintes de la plateforme technologique, et faut aussi savoir déchiffrer/utiliser ces codes. (Si j’ai bien compris, là c’est un peu abscons…) Et pourtant, on assiste à des expériences de lecture numérique façonnées essentiellement par des ingénieurs (mouais, Apple, Kobo et tout ont plein de designers…), et les designers se tournent vers l’édition de beaux livres luxueux alors qu’il y a du boulot pour le livre numérique ! (récemment par contre, quand on voit par exemple Adrénalivre et Via Fabula et consorts, y’a clairement un designer derrière et c’est très chouette ! Ça change peut-être donc ?)

L’écran est un support distinct, avec ses usages propres, qu’il faut investir. Pas besoin de recréer le livre : Realistic Books par Ian Witten prétend que représenter un livre en vue isométrique c’est mieux pour la lecture que le scrolling, ce qu’elle réfute ; « iPad and Mimesis » dit qu’à trop vouloir mimer un livre on oublie qu’un livre peut se corner et se surligner, on restreint les usages. L’hypertexte et la lecture non-linéaire « en tache d’huile » plutôt qu’en profondeur est une innovation majeure ; c’est cool de savoir un peu de tout et de fureter plutôt que d’essayer d’avaler un texte ; mais du coup, rédiger un hypertexte est pas facile, et construire un contexte à partir d’une lecture non-linéaire ,c’est pas facile.

C’est le genre de trucs que Twine nous permet d’aborder : est-ce qu’on fait une présentation thématique de l’histoire (clic sur un mot = un souvenir, un approfondissement), est-ce qu’on se focalise sur l’exploration d’un espace physique ; est-ce qu’on s’attend à ce que les lecteurs lisent absolument tout et parcourent toute l’arborescence ou est-ce qu’on a une trame linéaire et des liens fournissant clarification, approfondissement ou backstory optionnelle? Est-ce qu’il y en a entre les deux ? Comment écrire une non-fiction interactive, genre un reportage ou un cours, avec des hyperliens, quelles sont les attentes et comment présenter le contenu en conséquence ? Comment est-ce que les gens lisent Wikipédia ? En tout cas, je trouve ce questionnement sur « que change l’hypertexte sur les modes de présentation de textes » très intéressant !

III — La rencontre entre écran et papier dans les JV narratifs

Très franchement, je pige pas la problématique de cette partie… L’idée serait que faire en sorte que le joueur mêle papier et JV serait désirable, et voir comment on peut inviter à ça ? (Pour « dépasser l’opposition ».) Le point qui revient, c’est que le joueur prend des notes en jouant ou dessine une carte : je sais pas vous mais moi je déteste le faire, et c’est pas réaliste à l’heure du mobile de penser que le joueur le fera… Bref j’ai pas compris l’intérêt de la problématique… :/

Une partie sur le fait que web et papier peuvent se rencontrer :

avec un peu de programmation (CSS) on peut faire des pages jolies et qui s’impriment bien (mise en page, nombre d’images réduites, disparition de certains éléments, etc.). Mais a priori, je vois pas le rapport parce qu’on n’imprime pas des FI…

Elle a aussi un autre argument sur « l’écran c’est différent, y’a pas la même notion de page, de haut de page et de pied de page comme en typographie » : c’est dommage ici de pas parler des Twine, qui (en plus de porter une grande attention au design, pour le coup) optent parfois pour un découpage du texte en écrans (un écran de texte à la fois, pas de mur de texte, et on clique sur un lien qui revient essentiellement à tourner la page : c’est pour le rythme de la narration, mais aussi pour éviter de faire défiler) ; ou les Choice of Games, qui disent dans leurs conseils aux auteurs de ne pas laisser passer trop de temps entre deux choix pour ne pas que le lecteur s’ennuie, ce qui revient à morceler le texte. Bref, on a tendance à découper le texte en pages sur un écran pour le confort de lecture (mais est-ce ce genre de choses auxquelles elle pense quand elle parle de ce que le designer peut faire, par exemple ?).

Puis : le designer peut faire ressortir la structure de l’expérience non-linéaire pour que le joueur en prenne conscience et puisse jouer avec (undo, tricher, etc). Un joueur qui découvre le format aura envie de l’explorer et de voir ce qui est possible. Pour ça le designer ne doit pas écrire un long texte sur comment on arpente le texte mais travailler sur la forme pour que le lecteur le comprenne de lui-même.

Intéressant mais, du coup, elle ne donne aucun exemple, comme si les jeux avec automaps ça avait jamais été tenté ; tout au plus elle dit que si tu fais bien le boulot, le joueur est enclin a prendre un papier et un crayon et dessiner sa carte.

En fait je suis pas sûr d’interpréter ça bien mais j’ai l’impression qu’elle dit qu’un designer doit mieux faire qu’un simple manuel « comment jouer à une FI » : tout à fait d’accord et malheureusement on se contente souvent de ça. Les sections tutorielles ou autres expositions progressives aux mécanismes sont très peu faites (Juhana avait un thread sur intfiction qui avait l’air cool), avec le risque de faire des jeux pour les experts et c’est tout. Mais je sais pas si je vais trop loin dans l’interprétation.

Elle a l’air de dire que c’est intéressant d’amener le joueur à prendre des notes. Je sais pas si c’est une fin en soi, en tout cas je sais que les notes de David Welbourn sont intéressantes.

Conclusion : en parlant d’échanges entre le jeu et le papier, quid de l’échange entre le jeu et le monde ; en fait on pourrait imaginer des jeux qui font intervenir la réalité, te forcent à te déplacer, à coopérer avec d’autres, etc. pour faire avancer l’histoire. Bref, un Pokémon Go pour la FI, et pourquoi pas ? (« >nord / Vous allez au nord. Ben allez, allez-y quoi ! Je décris la scène quand vous aurez marché 1 km ») Il me semble que Zombies Run était un peu dans ce genre. Et perso c’est In Memoriam qui me reste en tête, quel concept de ouf !

Conclusion

Conclusion du mémoire : les FI c’est cool et y’a peu de designers qui s’y intéressent alors que y’a plein de trucs à faire pour fabriquer un texte qui fait envie. OUI OUI OUI VENEZ LES DESIGNERS !

Fiche de lecture : Craft of Adventure

Bon je vais pas faire une fiche de lecture d’une fiche de lecture, si ?! Elle fait une bonne contextualisation, puis elle résume le texte ; peu de contresens ou d’erreurs il me semble, bref c’est un très bon résumé si on veut savoir de quoi parle Graham Nelson, le premier en français si je me trompe pas.

Rapport de stage (chez Apicoove)

La problématique qui sous-tend le (court) rapport de stage est : pourquoi notre société crée-t-elle tant de jeux, pourquoi la gamification et comment un designer peut-il s’insérer dans ça ? Honnêtement, vous pouvez sans doute sauter cette partie (pas vraiment applicable à la FI et à ses auteurs) ; pour ceux qui veulent j’en dis deux mots.

Premièrement, pourquoi tant de jeux. L’analyse proposée a l’air de reprendre d’autres analyses et d’y mêler quelques réflexions, mais personnellement, je n’ai pas trop aimé. En fait l’analyse m’a l’air un peu éculée (allez, je trolle, presque réac), à base de « la modernité chamboule tout et aseptise tout et les gens sont perdus ou désenchantés ». Aucun mot sur le capitalisme, les médias de masse, l’étude psychologique du jeu et sa réhabilitation en tant qu’outil pédagogique ou son utilisation parfois sordide pour produire de l’engagement… M’enfin, passons.

La deuxième partie traite du rôle du designer en essayant d’analyser le rôle de l’image dans un JV, ce qui est plutôt intéressant en soi : comme la caractéristique première d’un jeu vidéo est l’interactivité, on peut voir l’image comme une interface entre le système et les règles du jeu et le modèle mental du joueur ; le joueur doit pouvoir lire et décoder l’image pour comprendre les conséquences de ces actions, et du coup on peut lire l’image dans le jeu vidéo comme étant fonctionnelle, comme un truc de design industriel. L’image doit être lisible (ex. : analyse de choix de saturation dans Diablo 3), et peut utiliser l’affordance, concept d’ergonomie et de design industriel qui suggère la capacité d’un objet à suggérer son usage de lui-même (en gros, si vous voyez un truc avec des piques sur la carapace, vous savez que c’est un ennemi ; si vous voyez un monstre avec un œil énorme et jaune vous savez qu’il faut taper là ; si les personnages sont designés différemment vous les reconnaissez rapidement, et vous savez que le gros est fort et résistant et le petit est agile).

Étude de cas : Le Songe de Poliphile, Francesco Colonna

Ce livre a l’air rigolo : c’est un des premiers à utiliser la forme du texte en complémentarité avec le fond ; c’est pas juste un texte, y’a des passages en calligrammes et d’autres avec des hiéroglyphes, c’est cool. Le lien avec le reste du mémoire, et là où ça peut nous intéresser, c’est que c’est souvent considéré comme un livre d’architecture (on trouve des modèles d’architecture ou d’art des jardins). Pourquoi c’est intéressant pour nous ? Tout le livre 1 est constitué quasi-uniquement de descriptions d’objets (architecture, costumes, etc.). Comme dans une FI à parser, dont une grande partie du texte consiste en des descriptions de lieux (et même mieux : la joueuse se base sur les descriptions pour en déduire ce qu’elle peut faire et quels choix s’offrent à elle). Ça peut être intéressant de regarder comment c’est écrit et fait (et peut-être que ça nous donnerait des idées, genre un jeu où toutes les descriptions sont prises de ce livre et on fait « lisez la description page 35 »).

Dispositifs techniques

Partie très court, c’est peut-être une contrainte formelle de ce genre de mémoire ? En tout cas ce sont des liens vers deux tutoriels qu’elle a écrits sur le site du labo de design de Marseille, un en Inform 7 et un en Twine.

Entretien

Un entretien avec Annabel Roux, qui travaille autour des chatbots comme support à des FI et qui en développe une d’ailleurs. Elle met narration et interaction sur un pied d’égalité, dit qu’un problème est la nouveauté mais surtout l’absence de public (« 90 % des gens ne savent pas ce que c’est », euh, 99 % même… 🙁 et, comme elle le dit, on sait pas trop comment les faire entrer dans la sphère d’attention du public). Les mécanismes de jeu est une façon d’impliquer le lecteur et de maintenir son intérêt. Prédiction : on voit qu’elles sont de plus en plus avalées (comm, marketing, journalisme, JV) mais de moins en moins investies par les financeurs comme une forme en soi ; pour cela il faudrait favoriser les pratiques amateures (créer un public — et même plus, aller le chercher et montrer que tout le monde peut écrire des FI, sachant qu’elle est membre de Storycode Provence) et qu’on montre une vraie réflexion sur le lien entre histoire et expérience dans des titres de qualité (ex. : Her Story). Bref, un mix de démocratisation des outils et de productions connues qui donnent envie de réfléchir dessus.

Après la publication de l’article, Caroline Brun nous a laissé un commentaire :

Merci de s’être attardé sur mon mémoire 🙂

Le format est vraiment sympa, j’ai hâte de lire d’autres notes de lecture sur le sujet !

Concernant le contexte et la forme, effectivement, c’est un format particulier qui concerne exclusivement le DSAA Design Graphique de Marseille : étant donné que les étudiants abordent des thèmes aussi variés que la fiction interactive, le journalisme, l’artisanat 2.0 ou même la narration textile et le design olfactif, demander à chaque étudiant de composer un ensemble de livrets thématiques permet de synthétiser plus largement nos points d’études plutôt que théoriser sans fin dans une synthèse.
Les livrets comprenaient donc effectivement :
— un rapport de stage (le premier livret rendu, dû à nos dates de stage : cela explique mon rapport assez général et moins approfondi, c’était une petite observation avant d’attaquer nos sujets — d’ailleurs pour beaucoup, notre sujet n’était pas encore définitivement choisi au moment de la composition de ce livret et effectivement, j’aurais aimé le reprendre complètement pour l’ajuster)
— une étude technique qui permet aux lecteurs de comprendre la composante concrète de notre sujet, une fiche de lecture qui proposait une analyse (pour ma part, j’ai plutôt décidé d’interpréter en français Craft of Adventure, le document était déjà très clair et j’ai trouvé plus intéressant de proposer une lecture française pour faire ressortir cet écrit, plutôt qu’analyser quelque chose de déjà très clair en soit)
— une étude en rapport avec l’histoire de l’art qui nous forçait à chercher une/plusieurs œuvres sans rapport direct avec le sujet mais dont nous pourrions tirer des enseignements
— une synthèse de nos études précédentes et de nos recherches en rapport avec une problématique précise, l’écrit central du mémoire
— évidemment une liste de nos ressources, lectures, et un glossaire

Effectivement ce n’est donc pas une approche « standard » de l’écriture d’un mémoire, qui est du coup plus court mais plus diversifié : le design (graphique et autre) interagit avec énormément de champs d’études, techniques/artistiques/sociologiques/sociaux/etc, il semblait donc réducteur de vouloir se contenter d’une étude théorique très longue et nous avons préféré toucher du doigt beaucoup plus de domaines 🙂

En tout cas, les ressources que vous partagez pour compléter/corriger mon propos sont vraiment intéressantes ! J’ai sûrement commis des erreurs et des approximations parce que, soyons honnêtes, je connaissais très peu le sujet avant de commencer à travailler dessus (j’avais juste « joué » quelques livres dans ma jeunesse et testé quelques IF en étant trop jeune pour comprendre quelle magie opérait derrière).
J’ai décidé de travailler sur ce thème au mois de décembre 2015 (après beaucoup de recherches pour affiner mon sujet de « je veux travailler sur le jeu vidéo » vers « travailler sur les IF », et les détours ont été multiples hahaha), et le mémoire a du être rendu en avril 2016 (donc terminé au niveau de son écriture presque un mois avant).

En 4 mois, il a été intense d’agréger autant que possible autour d’un thème et d’une technologie développés quand j’étais trop jeune pour le connaître, et sans connaître personne sensible à ce domaine, mais c’était passionnant ! Je prends donc bien note que dans ma précipitation, j’ai jugé très vite certaines références par souci de temps, et qu’il aurait été bénéfique que je me tourne beaucoup plus que je ne l’ai fait vers des communautés comme la vôtre pour préciser au mieux mon propos 🙂

Dernière petite précision : en addition à notre mémoire, nous devions créer un projet concret en lien avec notre thème, un objet créatif, quelque chose qui propose une réponse à une question abordée dans le mémoire.
Concrètement, j’ai fabriqué une boîte de jeu permettant de ranger des cartes, équipée d’un dispositif Arduino et d’un lecteur de puces RFID ; les cartes sont principalement textuelles et « inactives ». On lit le petit texte dessus, si rien n’est indiqué on pose la carte suivante à sa droite, jusqu’à arriver à une carte proposant des choix (en haut, bas ou droite de la carte) ; on bifurque alors dans la direction souhaitée, et au fur et à mesure des cartes déposées cela dessine une sorte de « carte » de nos choix narratifs. Certaines cartes sont illustrées : cela indique que ces cartes sont équipées d’une puce RFID et que l’on peut les scanner sur le lecteur contenu dans la boîte de jeu. On accède alors, et c’est la partie pour laquelle j’ai manqué de temps pour faire des recherches, à des « extra » numériques qui s’affichent sur l’écran : au choix, cela pourrait être de simples informations contextuelles (« Vous entendez résonner une chanson de Billie Holiday au fond du couloir » + la carte est illustrée du visage de Billie Holiday = on scanne la carte, un lien youtube est ouvert vers un extrait de cette chanteuse de jazz, par exemple), des énigmes à résoudre, des mini-jeux en rapport avec l’intrigue, les possibilités sont très larges et mériteraient encore de la prospection.

Il s’agit d’un prototype initial, et on pourrait encore faire beaucoup de choses dessus, il reste dans un coin de ma tête pour le moment où j’aurais à nouveau du temps à y consacrer 🙂
Pour un petit aperçu visuel, on peut voir ça sur mon folio : http://carolinebrun.fr/?page_id=17
Il faut scroller jusqu’au 3ème projet, « Telling stories » !

Au plaisir de continuer à apprendre auprès de vous !

Notes de lecture : « Make IF Fast »

Hugo Labrande

Voici un deuxième opus dans la série des notes de lecture ! Aujourd’hui, on parle d’un article un peu particulier, qui raconte la genèse de jeux, mais surtout donne des techniques intéressantes de création.

En 2000, J. Robinson Wheeler a écrit « Make IF Fast », un texte sur son site dont nous allons parler aujourd’hui. Wheeler est l’auteur de quelques jeux qui ont eu un certain succès, comme First Things First ou Being Andrew Plotkin (comme Dans la peau de John Malkovitch, mais pour la fiction interactive anglophone, avec les blagues et private jokes qui vont avec) : ces deux jeux ont remportés des XYZZY Awards, les Oscars de la fiction interactive anglophone. Dans ce texte, Wheeler explique comment il est parvenu à créer des jeux en Inform en un temps relativement court : 20 jours pour Being Andrew Plotkin, 10 jours pour Centipede, 5 jours pour The Tale of the Kissing Bandit. Je vais tenter de désosser ce texte et de faire ressortir les principes que j’ai trouvé intéressants, et que j’applique moi-même pour l’écriture de mes jeux.

Écrivez rapidement

Le premier conseil est d’être capable d’écrire rapidement. Il prend l’exemple d’une éponge qui peut être mouillée ou sèche dans un jeu à parser, et dit que des objets basiques comme ça doivent vous prendre une minute, pas plus. Et pour cela, il recommande de faire des Speed-IF pour s’entraîner. Les Speed-IF, appelées il fut un temps en français « Rapid’Fictions », sont des sortes de jams (pour reprendre le vocabulaire contemporain, comme sur itch.io) où le temps est limité. TRÈS limité : en général, vous avez 2 heures ! En 2 heures, vous n’avez pas le temps d’hésiter, et vous apprenez à coder des objets basiques très rapidement ; c’est un très bon entraînement si vous commencez à savoir pas mal programmer, ça vous permet de consolider ce que vous savez et de pouvoir laisser de la place et du cerveau pour des parties plus compliquées. (Je ne recommande pas faire une Speed-IF en Inform si vous commencez, ça risque d’être frustrant !)

Si vous ne faites pas d’Inform, je pense qu’une généralisation de ce concept est de vous entraîner à écrire vite, sans hésiter, et en tapant rapidement, sans trop vous laisser ralentir par la relecture ou des hésitations. C’est une des raisons notamment pour laquelle le NaNoWriMo a autant de succès : forcez-vous à écrire un roman en un mois, il n’y a pas mieux pour vous apprendre à foncer et à écrire vos idées sans trop réfléchir ou vous critiquer !

Personnellement c’est un peu ce que j’ai essayé de faire avec « Les Aventures d’Un Soir », mon concept où je crée avec les spectateurs un jeu d’aventure sur Twitch en une soirée. Vu la quantité de choses à faire et à écrire, il faut aller très vite, tant au niveau du code que du texte ; pas de place pour l’hésitation ! Les jeux finaux sont relativement bien, en tout cas j’en suis plutôt content ; ça n’est pas de la grande littérature, mais ça montre qu’on peut créer un jeu vidéo en quelques heures, et c’est excellent pour rester affûté et continuer à se poser des défis !

On a déjà organisé des Speed-IF en français, et c’était très cool ! On a même une page spéciale sur le site à ce sujet. Cependant, on a perdu l’habitude d’en organiser… malgré l’enthousiasme des gens pour le format, d’ailleurs ! Manifestez-vous, parlez-en sur le forum ou sur le Discord, et on ne sait jamais, ça pourrait revenir…

Recyclez

Un deuxième conseil, qui apparaît au détour d’une phrase, est de vous servir dans le code de vos jeux précédents pour aller plus vite. Vous avez sans doute implanté des verbes chouettes, ou un objet avec un comportement intéressant, ou un script avec une fonctionnalité nouvelle, ou un effet que vous voulez réutiliser : allez vous servir ! Avec un peu d’habitude, vous identifierez les parties intéressantes de votre code rapidement, et elles deviendront plus automatiques : ça peut vous permettre de progresser, tout en vous construisant un petit répertoire, des petites habitudes, une petite « patte personnelle » qui sera partagée par tous vos jeux. Et vous pouvez aussi vous servir dans le code des autres ! Je sais que j’ai personnellement eu des idées intéressantes en regardant les jeux de JB (dont le code source est tout le temps disponible) ; mes codes sources sont également disponibles en ligne, pour la même raison : si ça peut servir à quelqu’un ou donner des idées… Les forums (comme le nôtre !) et autres sites de questions sont aussi des mines à scripts et codes intéressants, alors n’hésitez pas à aller vous y promener !

Une fois que vous avez identifié un bout de code utile, que vous avez tendance à réutiliser souvent, et sur lequel vous avez travaillé pour qu’il soit plus puissant ou plus flexible et s’applique à plus de jeux… C’est peut-être l’heure d’en faire profiter la communauté ! La communauté des fictions interactives est historiquement basée sur le partage ; beaucoup de gens partagent leur travail gratuitement avec le reste de la communauté, et tout le monde est content de profiter de ce travail. Alors, si vous pensez avoir un truc cool, faites-en une extension, un script, un tutoriel, une vidéo, n’importe — vous aiderez sans doute quelqu’un !

Écrivez la solution avant le jeu

Un troisième conseil, un des plus importants et que j’utilise systématiquement : faites une fausse transcription ! Une transcription est un fichier texte avec tout le texte qui s’est affiché à l’écran pendant votre partie ; une fausse transcription, ça veut simplement dire écrire ce à quoi une partie pourrait ressembler : vous écrivez la transcription avant le jeu ! J. Robinson Wheeler recommande de se focaliser sur une transcription minimale, c’est-à-dire de se concentrer sur une ligne droite du début à la fin de son jeu, sans passer par les solutions intermédiaires ou autres. L’idée derrière est celle du minimum viable product, c’est-à-dire : « mieux vaut avoir une version préliminaire, un premier jet, que l’on peut améliorer et polir, plutôt que démarrer en passant énormément de temps à faire les premières scènes parfaitement puis baisser les bras devant l’ampleur de la tâche à accomplir. »

Plutôt que de passer plein de temps à faire une belle carrosserie et se rendre compte qu’on ne sait pas fabriquer un moteur, commencez par faire un truc qui roule, et voyez après.

Personnellement j’ai tendance à écrire aussi toutes les descriptions d’objet et les réponses particulières (c’est-à-dire celles qui ne sont pas juste celles de la bibliothèque Inform), et à faire une liste de noms se rapportant à l’objet dont je suis en train de parler, pour ne pas oublier de rajouter des synonymes. Voici par exemple le genre de trucs que j’ai écrit pour Le Kébab hanté :

>x bayram / x gérant / x patron / x gérant/patron du kebab / x gérant/patron du grec / x gérant/patron du restaurant / x gérant/patron de l'egee / x victime / x turc / x grec

Bayram est le patron de "L'Égée", le restaurant grec / kebab devant lequel vous vous trouvez. Il porte un blouson, visiblement de marque, et peut-être pas assez chaud, car il s'agite et tremble de temps à autre, malgré son écharpe. Il semble avoir une trentaine d'années, mais sa moustache semble déjà avoir les premiers cheveux blancs - peut-être à cause de [ce qui se passe] dans son restaurant... En tout cas, vous a-t-il dit au téléphone, il veut que le problème soit réglé au plus vite, pour qu'il puisse ouvrir ce soir de [réveillon].

>x restaurant / x devanture / x panneau / x vitre / x kebab / x restau / x restau grec

"L'Égée", proclame le grand panneau aux couleurs vives au-dessus de l'entrée du restaurant. Le nom est flanqué de deux photos de kebabs, des gros pains pita remplis de viande, de salade et de tomate, vision sans doute idéalisée du produit fini que l'on vend ici. Mais n'allez pas faire comme si vous n'en mangiez jamais ; au contraire, comme tant d'autres de votre promo, la tentation d'un gros sandwich avec des frites, qui cale bien pour pas cher, vous tire de votre appartement à peu près une fois par semaine. Cela étant, "L'Égée" est un peu excentrée, et vous ne saviez même pas qu'il y avait un kebab dans cette partie de la ville. Les commentaires que vous avez vues sur votre minitel de poche [pub http://kebab-frites.com/ ici ?] disent que les sauces sont industrielles mais les quantités généreuses.

La fausse transcription a plusieurs avantages :

Elle vous permet d’avoir une bonne idée de ce à quoi va ressembler votre jeu (et vous fait vous poser des questions de game design relativement tôt).

Elle vous permet de gagner du temps pendant la phase de code (vu qu’il suffit de faire un copier-coller pour les textes).

Et surtout, elle sépare la phase de code et la phase d’écriture. Comme le dit Wheeler dans son texte (dans la section sur Being Andrew Plotkin), pendant que vous écrivez la fausse transcription, vous êtes en mode « écriture » et vous pensez comme un écrivain, et votre prose est ainsi plus fluide, plus cohérente, et vous pouvez y consacrer plus d’efforts ; pendant la phase de code, vous pensez comme un programmeur, et vous vous attardez sur les mécanismes du jeu. L’alternative (que l’on fait très souvent quand même) est de faire les deux en même temps, d’alterner en permanence entre le code et l’écriture, ce qui casse le flow pour les deux tâches.

Make IF Fast!

Le reste de l’article de Wheeler est relativement intéressant, mais quelque peu technique. Il alterne entre des phases où il raconte dans quel ordre il a implanté les différentes idées, et comment il a eu ses idées, et des passages un peu techniques sur la façon dont ses jeux fonctionnent. Le texte se lit globalement bien, et je l’ai déjà lu des dizaines de fois ; mais pour moi, ce sont ces trois grandes idées qui ont été les plus utiles dans mon parcours d’auteur de fictions interactives. J’espère qu’elles vous feront réfléchir et vous stimuleront ! N’hésitez pas à en discuter dans les commentaires, ou parler de vos propres méthodes pour créer un jeu rapidement !

Notes sur Création de récits pour les fictions interactives

Nathanaël Marion

Aujourd’hui, je vais parler de ma lecture de l’ouvrage mentionné dans le titre de l’article, Création de récits pour les fictions interactives, simulation et réalisation, de Nicolas Szilas et Jean-Hugues Réty.

Je suis tombé dessus à la bibliothèque, où il s’agissait du seul livre parlant de FI. Je ne savais pas du tout ce sur quoi j’allais tomber, ni si cette lecture serait pertinente (après tout, le terme « fiction interactive » est très vaste). C’était finalement modérément intéressant, mais quand même pertinent.

À noter aussi qu’il s’agit de la première fois que je me livre à ce genre d’exercice, alors j’espère que le compte-rendu sera utile ; en tout cas, j’essaierai d’en tirer ce qui était intéressant. Il sera en revanche assez long.

Présentation générale

Ce livre est constitué de plusieurs chapitres écrit par des auteurs différents. En fait, ce sont moins des chapitres et plus des articles académiques. Du coup, la lecture devient un peu décousue puisqu’on peut passer d’un sujet à un autre suffisamment différent. Le livre est néanmoins divisé en deux parties : la première traite de l’aspect théorique (comment formaliser une FI) et la seconde, de la façon de mettre en œuvre cette théorie.

Par son style très académique et formel, je ne pense pas que le livre soit destiné au grand public, et il m’a fallu plusieurs mois pour le lire. Cependant, comme il est relativement vieux (2006), il est intéressant de voir si les auteurs avaient vu juste quand à la fiction interactive aujourd’hui. Et c’est toujours sympa que ce genre de recherche s’est faite en France.

Comme chaque chapitre est indépendant, je crois que le mieux est de les traiter de manière indépendante. Je vais donc en sélectionner quelques-uns et en parler.

Quelques remarques générales

Le terme « fiction interactive » n’est jamais vraiment bien défini dans le livre ; de ce que j’ai compris, il ne s’agit pas ici du sens qui était plutôt communément admis (jeux textuels, avec analyseur syntaxique ou bien hypertextes) ; il n’y a d’ailleurs aucun mention dans le livre d’incontournables comme Infocom. Le terme désignerait le concept un peu flou situé entre le jeu et la narration, ou spectateur et acteur se brouillent et se confondent. Le terme est donc plus général, et certains auteurs utilisent également souvent « drame interactif », ce qui peut permettre de mieux cerner le sens.

Un exemple qui revient très souvent dans le livre est Façade, et je pense que la personne la plus citée est Chris Crawford. Je ne m’étenderai pas sur ce dernier parce qu’il y aurait beaucoup de choses à dire, mais selon le livre, il aurait travaillé sur un système de rumeurs pendant plus de 10 ans et n’aurais jamais réussi (je ne sais pas si c’est censé être un compliment ou pas…).

D’autres références qui reviennent souvent sont la Poétique d’Aristote (aussi étonnant que ça puisse paraître !) et la Morphologie du conte de Vladimir Propp.

Bref, passons au plus important, mes réflexions sur certains des chapitres.

Première partie

La cyberlittérature entre jeu littéraire et jeu vidéo (Jean Clément)

L’auteur essaie ici de faire des liens entre littérature, littérature numérique et jeux. Il utilise pour cela la typologie des jeux de Robert Caillois, qui donne au jeu plusieurs catégories : l’Agon (compétition), l’Alea (hasard), la Mimicry (imitation, comme le théâtre) et l’Ilinx (vertige, adrénaline).

Après avoir montré que la lecture peut être considéré comme un jeu, même quand il s’agit de littérature « standard », il s’attaque plus à la littérature numérique. C’est là que ça devient assez bien. Il utilise les termes du paragraphes précédents ainsi que des exemples (mais dont les pages sur internet n’existent malheureusement plus pour la plupart) pour établir ce qui la rend intéressante pour le lecteur/acteur. Il utilise pour ça les exemples de la littérature hypertexte et la génération procédurale de texte.

La conclusion de cet auteur est que les fictions hypertextes ont tendance à trop ressembler aux jeux vidéo (on s’identifie au personnage et on tente de lui faire atteindre ses buts, plutôt que de vouloir simplement atteindre la fin de l’histoire) et que la poésie expérimentale, par exemple générée procéduralement, est plus intéressante, comme le sont les effets « spéciaux » tels que l’apparition ou la disparition de texte.

C’est assez ironique par rapport à la production actuelle, car il existe maintenant beaucoup d’œuvres hypertextes comme celles créées avec Twine, et beaucoup ne sont pas de simples jeux. Quant aux effets spéciaux, c’est assez utilisé avec Twine également (il est facile de modifier du texte au survol de la souris par exemple). Le procédural, bien qu’encore étudié aujourd’hui, ne fait pas l’unanimité je pense. C’est donc un chapitre intéressant qui propose une analyse assez pertinente, mais avec une conclusion qui finalement ne correspond pas tout à fait à la réalité actuelle.

Écrire dans l’espace : un modèle formel du level design d’un jeu vidéo d’aventure (Stefan Grünvogel)

Ce chapitre propose une description mathématique d’un système de quêtes ou d’étapes dans un jeu (on ne peut accéder à tel endroit que si l’on a effectué telle action par exemple), et ce à l’aide de réseaux de Petri et d’hypergraphes. Vous ne savez sûrement pas ce que c’est, et à dire vrai, moi non plus. Autant je comprends que l’on puisse vouloir formaliser ce genre de choses, autant ce chapitre est assez inutile pour une personne lambda. En effet, il rend compliquée des choses assez intuitives.

Il reste que c’est intéressant si l’on aime ce genre de choses, et ça peut être utile si on veut décrire précisément un jeu, mais je ne m’étendrai pas plus. 🙂

Ontologie de la fiction interactive dans les jeux vidéo (Stéphane Bura)

Ici, l’auteur décortique les problèmes inhérents que présentent l’intégration dans le jeu vidéo d’un cadre narratif avec lequel le joueur peut interagir. On commence par une remarque intéressante : ce cadre narratif n’est en général qu’un raccourci pour ne pas avoir à expliquer les règles du jeu. L’exemple pris est celui d’un jeu se passant lors de la seconde guerre mondiale : le cadre permet instantanément de savoir qui sont les « méchants », comment fonctionnent les armes, le but… Le scénario ne serait au final qu’un prétexte.

L’auteur prétend donc que la plupart des jeux vidéo sont plus portés sur l’interaction et non sur la fiction. Je pense que je peux dire sans trop me tromper que les jeux narratifs ont le vent en poupe ces temps-ci, et que ce n’est plus très vrai de nos jours.

L’auteur décrit ensuite le cycle d’un jeu (le jeu écoute le joueur, pense, parle, puis le joueur écoute ce que le jeu dit, pense et parle au jeu, et ainsi de suite) et détaille pour chacune de ces étapes les problèmes qu’elle pose en terme de fiction interactive.

Ce qui ressort, c’est qu’il faut d’abord s’affranchir du réalisme, qui semble pourtant être la tendance dans le milieu AAA : plus un jeu est réaliste, plus les règles qui le régissent sont floues. Si l’humain que je vois à l’écran est photo-réaliste, je m’attendrais à ce qu’il réagisse comme un véritable humain, ce qui n’est bien sûr pas le cas ; j’aurais donc du mal à savoir ce qu’il est possible de faire ou de ne pas faire.

L’auteur souligne que cela vaut également pour les FI à parser (dans une note de bas de page, certes). Elles peuvent être considérées comme réalistes car une infinité d’actions sont potentiellement possibles (comme dans la vraie vie), mais c’est ça qui bloque souvent le joueur, qui ne peut pas savoir quelles actions le jeu est susceptible de comprendre. L’auteur pense qu’il vaut mieux utiliser un langage limité (ou du moins explicite) pour communiquer avec le jeu. Cela permet au joueur de mieux exprimer ses intentions, et au jeu de mieux réagir et d’adapter son histoire. Cette tendance peut se voir dans les FI comme Eat me ou The Wizard Sniffer, qui ont un parser dit « limité », ce qui ne les a pas empêché de gagner des XYZZY Awards cette année. (Bien sûr, le parser « infini » aura toujours une place dans mon cœur, alors j’aurais plein de critiques à faire, mais je ne le ferai pas sinon on n’aura jamais terminé !)

Enfin, l’auteur pense qu’il faut exploiter la capacité d’un être humain à s’imaginer des histoires ou des motivations. Il prend l’exemple de Tetris, où il est difficile de ne pas s’imaginer que le jeu fait exprès de retarder l’arrivée de la barre (que celui qui n’a jamais blâmé Tetris pour cela lève la main !). On peut alors provoquer volontairement ce genre de situation : dans X-COM, la dernière balle d’un chargeur fait plus de dégâts, ce qui favorise l’émergence de moments héroïques ; mais bien évidemment, ceci n’est pas dit au joueur. Je trouve ce dernier point très intéressant. Assez vicieux par rapport au joueur, mais c’est tellement bien pensé !

Un chapitre qui pose des réflexions intéressantes, donc, même si certains points sont contestables.

Deuxième partie

La modélisation simulation du récit (Nicolas Szilas)

Le chapitre commence par une analogie spatiale du temps. Dans une histoire linéaire, la lecture s’apparente à un fleuve : on ne peut que regarder le paysage défiler. Une FI hypertexte verrait l’apparition d’affluents (quand l’histoire se subdivise) et de confluents (quand deux scénarios se rejoignent) ; à cela peuvent s’ajouter des écluses, qui ne s’ouvrent que sous certaines conditions. Il peut y avoir des lacs, ou carrément des océans, quand il n’y a plus de direction précise (on se rapproche d’un monde ouvert ou d’une FI à parser).

J’aime bien cette analogie car, même si elle a des limites, elle permet de comprendre de quoi on parle assez facilement. Cependant, l’auteur trouve que cette métaphore a des limites quand on l’utilise pour de la création. Selon lui, dans les océan, on gagne en interactivité ce que l’on perd en narrativité (car il est plus difficile de créer une histoire qui a du toujours du sens si le joueur peut effectuer des actions dans le désordre, il n’y a plus de « causalité narrative »). Autant je suis d’accord sur la justification, autant je ne pense pas que ça puisse empêcher de raconter des histoires. Si la structure du scénario est bien faite, c’est faisable (ou alors il faut penser à des façons différentes de raconter, comme de l’environmental storytelling, ce qui peut représenter un défi intéressant).

Toujours est-il que l’auteur pense que pour réaliser un bond en drame interactif, il ne faut plus utiliser cette métaphore et ne plus représenter le temps. Pour lui, pour faire de bonnes fictions interactives, il faudrait écrire des mini-séquences de façon abstraite. Par exemple, « X frappe Y avec Z ». Puis on peut lier ces séquences par un système de cause-conséquence, par exemple : « Si Y est frappé par X, alors Y crie ». Ensuite, c’est le programme qui remplit les trous. Pour que cela fonctionne bien, il faut que le programme sélectionne les séquences en fonction de certains critères, pour que ce soit intéressant du point de vue de l’histoire, et pas simplement une suite d’événements fade.

Et donc, encore une fois, on pense que le futur de la narration interactive réside dans la génération procédurale. Je suis d’accord que des façons différentes de penser la narration interactive sont bonnes à créer de nouvelles œuvres ; d’ailleurs, ce système de mini-séquences correspond assez bien au système de règles d’Inform 7, et est pratique pour coder le comportement des personnages sans avoir à les préscripter. Je ne suis en revanche pas certain que le procédural soit la clef absolue. Je pense, et je ne doit pas être le seul, qu’une histoire bien construite peut avoir plus d’impact que mille histoires bâties sur le même schéma.

De l’écriture à la réalisation d’une fiction interactive : simplification de la chaîne allant de la création à l’adaptation (Stéphane Donikian)

Le début du chapitre s’étend longuement sur la structure narrative d’une œuvre linéaire, en utilisant plusieurs formalismes (Propp, Todorov…). C’est très long et, même si ça peut être utile pour qui s’y intéresse, il reste qu’il s’agit de beaucoup de formalisme avec des symboles et des schémas assez lourds.

La deuxième partie de ce chapitre est plus intéressante. Elle détaille la création d’un outil de création de fiction interactive nommé DraMachina, permettant d’appliquer ce qui a été dit avant et qui permettrait de à un auteur de créer des fictions interactives sans forcément plonger dans la partie technique. Le programmeur en moi a apprécié ce passage. Il décrivait les technologies utilisées, l’interface, les choix qui ont dû être faits. Ce système repose sur les composantes telles que les lieux, les personnages, les rôles, les relations entre personnages ou les actions.

Je pense avoir trouvé ce chapitre en anglais en PDF, mais le logiciel en lui-même est apparemment resté à l’état de prototype et est introuvable, ce qui est malheureux.

Enfin, je trouve dommage que le système n’ai pas été comparé à ceux qui existaient déjà comme Inform (Twine n’avait pas encore été créé à cette époque).

Conclusion

Je ne recommanderai pas spécialement ce livre dans le sens qu’il est très universitaire et pas vraiment pédagogique. Cependant, je ne regrette pas de l’avoir lu car certains points restent utiles et c’est toujours bien de savoir que des Français ont fait ce genre de recherche.

Il est intéressant de voir le point de vue de cette époque. Je pense que l’idée principale qui s’en dégage est que le futur de la narration interactive est dans le procédural. Je ne pense pas être d’accord, même si cette façon de faire n’a jamais eu autant de potentiel. Et vous, qu’en pensez-vous ?

Je suis par contre étonné du peu de diversité dans les références (toujours Façade, et Chris Crawford qui est littéralement partout…) et du fait que la fiction interactive « traditionnelle » (genre Inform) n’ait pas du tout été mentionnée (alors que Galatea aurait sûrement été un bon exemple). Une autre chose est qu’en effectuant un rapide recherche, je n’ai pas trouvé beaucoup de traces récentes des auteurs, donc je ne sais pas vraiment ce qu’ils sont devenus ; j’aurais bien aimé savoir, pourtant !

Notes de visionnage : La conception narrative de Virtue’s Last Reward

Nighten Dushi

La Game Developers Conference (GDC) est un événement annuel à destination des professionnels du jeu vidéo et se déroulant à Los Angeles. Elle est surtout connue pour ses conférences, dont certaines sont ensuite diffusées gratuitement sur Youtube ; si vous vous intéressez à quelque domaine que ce soit de cette industrie (visuel, écriture, marketing, technique) c’est une vraie mine d’or !

Il y a quelques mois, une conférence enregistrée en 2013 a particulièrement attiré mon attention : Visual Novels: Narrative Design in Virtue’s Last Reward ou en français : « Roman Visuel : Conception narrative de Virtue’s Last Reward ». Virtue’s Last Reward, abrégé VLR par commodité, est donc un visual novel japonais sorti sur 3DS et PSVita en 2012 ; il est la suite du jeu 999, Nine Hour, Nine Persons, Nine Doors, qui représente un vrai classique du genre ; les deux ont par la suite été rendus disponibles sur Steam. Je n’ai encore pu joué à aucun des deux, mais un ami à moi vous les recommande chaudement si vous aimez les thrillers psychologiques et bien écrits, et que vous lisez l’anglais accessoirement.

Pour ceux qui ne serait pas familier avec le terme, « visual novel » fait référence à un genre de fiction interactive japonaise, et par extension aux FI qui s’inspire de celles-ci. La majeur différence entre les FI occidentales est l’usage dominant de l’hypertexte ainsi que la place plus importante des illustrations. Mis à part pour des passages spécifiques, j’utiliserai les terme « visual novel » (VN) et « fiction interactive » (FI) de manière indifférenciée.

Après cette introduction, voici maintenant le résumé des points que j’ai trouvé pertinents dans cette conférence tenue par Kotaro Uchikoshi, réalisateur et écrivain de VLR !

Est-ce qu’une FI est un jeu vidéo?

Monsieur Kotaro tente en premier lieu de définir ce qu’est un visual novel, ce qui a déjà été fait de manière différente dans cet article ; article que je ne vous ferai pas l’affront de répéter.

Après avoir établi sa définition, il pose la question : Est-ce que les VN sont des jeux vidéo ?

Le débat ne fait pas rage dans la communauté francophone, c’est le moins qu’on puisse dire. Néanmoins, la question mérite d’être posée : certaines personnes sont convaincues que la réponse est négative, et auraient pu contester la présence du conférencier à la Game Developers Conference ; de même qu’il est fréquent de voir critiquer l’arrivée de visual novels, de FI ou de kinetic novels sur des plates-formes de distribution de jeux vidéo (comme Steam), ou une participation à des compétitions qui n’ont pas l’habitude de ce genre.

Au passage, en ce qui concerne la distribution de votre FI sur Steam ou itch.io, sachez que ces deux plateformes sont et se présentent comme des distributeurs de logiciels et de contenus numériques. Des bandes dessinées et des assets sont vendues sur itch.io, des documentaires et des logiciels, sur Steam. Il est totalement légitime de distribuer vos FI sur ces plates-formes, ne vous mettez pas de barrières !

Faisons un parallèle avec les sports. Que ce soit l’athlétisme, le foot ou la brasse, peu de gens hésiteraient à les définir comme des sports. Mais qu’en est-il des fléchettes, des courses de voiture, du golf et de la pêche ? Eh bien ils sont considérés comme sports également, car leur dénominateur commun est le fait de demander une bonne condition physique, pas l’intensité à laquelle elle est demandée. Ce sont donc des sports, bien qu’un peu à part.

Au même titre, les FI et VN sont une sorte de jeu un peu à part. Le dénominateur commun selon le conférencier est la sélectivité : que les actions (inputs) du joueur aient une influence sur les réponses (output) du jeu, sans qu’il y ait de minimum requis.

Utiliser le cerveau du joueur comme carte mémoire

Le thème du concours de fiction interactives de l’année dernière était « mémoire », et beaucoup d’idées très créatives en sont sorties ; notamment sur la manière dont le jeu gère sa mémoire, ses sauvegardes. Le jeu que je vais vous présenter ci-dessous aurait parfaitement eu sa place parmi ceux-là !

Dans un visual novel, où un jeu en hypertexte de manière générale, certaines variables (comprendre « données que retient le jeu ») sont utilisées pour se souvenir des choix du joueur sans pour autant que les répercussions soient immédiates : est-ce que l’explorateur a pris une lampe torche ou un sandwich avant de partir ? Est-ce que j’ai pensé à éteindre le gaz ? Ces variables, souvent binaire (Oui/Non), s’appellent communément des « flags ».

Si vous souhaitez en apprendre plus sur les variables dans les fictions interactives, notre cher Hugo a écrit un très bon article sur la question il y a quelques semaines, dans lequel il vous explique comment ces variables sont utilisées de manière très pratique.

Kamaitachi No Yoru (littéralement « La nuit de la faucille-belette », un titre bien japonais en somme) est un visual novel sorti uniquement au Japon en 1994 sur Super Nintendo, et il possède une particularité bien à lui : les flags qu’il utilise sont intégrés dans la tête du joueur !

Avant de vraiment expliquer ce que je veux dire par là, revenons au début.

Au début de chaque partie, le joueur arrive très vite après une introduction face à un choix : il doit deviner le nom du coupable d’un meurtre. Au début, il n’a clairement pas assez d’éléments pour choisir avec discernement, mais il doit choisir. Il donne donc un nom et, en fonction de celui-ci, il est emmené vers une certaine branche de l’histoire. Si le joueur a faux, il arrive sur une « route », une suite d’événements qui le mènera vers une mauvaise fin, avec plus de drames et de meurtres. Pourtant, le joueur récolte des indices durant ces mauvaises fins, indices qui lui permettent, au fur et à mesure qu’il se trompe, de reconstituer le puzzle et de trouver le nom correct, d’obtenir la bonne fin !

À chaque fois que le joueur recommence le jeu et doit deviner qui est le meurtrier, il a en sa possession plus d’informations que le personnage principal qu’il incarne ! Il aurait pu deviner dès le premier essai qui est le véritable coupable, sur un coup de chance ; mais c’est ça qui rend la démarche si intéressante.

Pour résumer, dans Kamaitachi No Yoru, la mémoire du jeu est dans celle du joueur.

La plupart des jeux d’aventures d’antan utilisaient la même méthode, les anciens vous diraient. Par exemple dans les jeux comme Zork, il était nécessaire de prendre des notes, et en particulier de tracer des cartes, afin de progressivement trouver le chemin à prendre vers la fin du jeu, ce qui soulageait la mémoire logicielle, qui était limitée. Mais au fur et à mesure que les ordinateurs et consoles ont gagné en capacité, la machine a pris le relais pour stocker les informations, ce qui a rendu le jeu d’aventure plus fun et accessibles pour beaucoup de gens.

Un autre point intéressant à retenir en tant que créateur : inspirez-vous de vos contraintes techniques ! Ici, c’était une taille mémoire limitée, mais ce peut être une résolution mobile peu familière, de maigres compétences graphiques, un manque de temps… Corax parle justement de son expérience en la matière, de comment il a utilisé ses contraintes lors de sa participation (gagnante !) du concours de FI de l’année dernière.

La plupart des visual novels utilisent ainsi des flags pour suivre et s’adapter à la progression du joueur. Dans un VN moderne, tel que Fate/stay night par exemple, le joueur doit passer par chacune des fins tragiques pour les valider auprès du jeu via des flags. Une fois cela fait, il débloque la vraie fin, la bonne en l’occurrence. Ce n’est pas une mauvaise chose en soi bien entendu, simplement que dans ce contexte Kamaitachi No Yoru paraît différent et frais dans son approche.

Et dans Virtue’s Last Reward ?

« On Ko Chi Shin » est un adage japonais qui signifie « étudier le passé pour découvrir de nouvelles choses ». C’est ce qu’a fait Kotaro Uchikoshi lors de la conception de Virtue’s Last Reward en étudiant Kamitachi No Yoru !

Dans VLR, le joueur se voit ainsi demander occasionnellement des mots de passe, pour accéder à un ordinateur ou désactiver une bombe. Ces mots de passe peuvent être récupérés par le joueur dans d’autres « routes », et lui permettent de continuer plus loin son aventure. Et le jeu n’utilise pas de flags lors de ces points : il vérifie juste que le mot de passe est bon, sans savoir comment le joueur l’a obtenu. Le joueur peut aussi aller voir sur des forums ou dans des guides stratégiques quel mot de passe il doit entrer ; cela pourrait être gênant, mais monsieur Kotaro trouve justement cela intéressant.

D’autres jeux auraient par exemple généré un mot de passe aléatoirement pour chaque joueur, pour éviter la triche, ou auraient simplement retiré la possibilité au joueur de taper un mot de passe, ne donnant accès à certaines informations et zones qu’une fois un flag validé.

Petite digression, et pour sortir de nos FI, on peut noter qu’Eidos avait une approche similaire avec la série Deus Ex ! Dans Deus Ex, ou dans Deus Ex: Human Revolution, les mots de passe sont toujours les mêmes, et sont découverts par le joueur au fur et à mesure de l’aventure via des documents et des dialogues. Mais rien ne l’empêche de hacker le système avec une compétence élevée, d’aller récupérer ces codes sur Internet ou d’utiliser les codes de vos parties précédentes, et ainsi d’accéder à des zones ou des informations plus tôt que ce que les développeurs avait prévu pour la plupart des joueurs.

Conclusage

Voici ce qui conclut ce résumé de conférence, et mon tout premier article sur Fiction-Interactive.fr !

Si vous souhaitez approfondir certains point et écouter l’intégralité de la source, voici la vidéo originale en anglais (et avec un son pas terrible).

C’est une conférence vraiment intéressante, bien que trop en surface ou vague sur certains points. Je vous recommande de l’écouter en entier si vous avez un peu moins d’une heure à lui accorder !

Tant que je vous tiens, n’oubliez pas que le concours de fiction interactive 2019 est en cours à l’heure où j’écris ces lignes ! Retrouvez toutes les informations sur cet évènement important de la communauté dans cet article !

Fiche de visionnage — Expérience utilisateur et jeux textuels

Filiaa

Designing text UX for effortless reading est le titre donné à une conférence de la Game Design Convention (GDC), présentée par Joseph Humphrey, cofondateur de la société inkle. Fort de son expérience sur des jeux tels que 80 Days ou Sorcery!, il nous explique comment faire lire de grandes quantités de texte aux joueurs sans qu’ils s’en rendent compte. La façon dont le texte est présenté peut en effet faire toute la différence entre une expérience ludique agréable et l’impression d’être confronté à un interminable mur de texte.

Focus

Le premier des deux concepts primordiaux évoqués dans la conférence, le focus, c’est la mise en valeur du texte de façon à concentrer toute l’attention du joueur sur sa lecture, sans même qu’il s’en rende compte.

Éviter les distractions

La première des choses à faire pour que le joueur se concentre sur le texte, c’est de supprimer le plus possible les distractions à l’écran : un texte seul, au centre d’un écran uni, attirera bien plus l’attention que s’il est relégué à un petit encadré en marge d’une fenêtre chargée en éléments graphiques.

Ici, un écran tiré de l’inventaire de The Witcher, pris en exemple dans la conférence. Bien que plaisant esthétiquement, il ne met pas en valeur son texte : les nombreuses images en arrière plan détournent le regard du joueur, le texte apparaît comme peu important, presque accessoire. De plus, le texte, assez long, présente un aspect « pavé » qui peut le faire paraître pénible à lire, indépendamment de son contenu. De nombreux joueurs fermeront alors la fenêtre sans accorder au texte l’attention qu’il mérite.

Ne pas négliger l’espace blanc

L’espace blanc (ou white space pour nos amis anglo-saxons) correspond tout simplement aux parties de la composition qui sont laissées vierges, autour du texte et des images. Dans le cadre de l’imprimerie, cet espace restait de la couleur du papier, généralement blanc.

Ces espaces — marges, interlignes et interlettrages — sont nécessaires pour éviter l’effet mur de texte et peuvent améliorer la clarté du texte. Des lettres suffisamment espacées sont plus faciles à identifier, tandis que des interlignes conséquents évitent que l’œil ne se perde sur la ligne précédant ou suivant celle que l’on est en train de lire.

Adapter la quantité de texte

Pour cela, une règle simple : moins il y a de texte à l’écran à un instant donné, plus celui-ci paraît important, et mieux il est retenu.

Quand il est nécessaire de présenter au joueur des blocs plus longs, il peut être utile de les scinder en plus petits paragraphes qui apparaîtront successivement. L’attention du joueur est ainsi à un instant donné entièrement sur la phrase en cours, sans se disperser sur les passages précédents ou suivants. Dans 80 Days, les dernières lignes apparues sont en surbrillance par rapport au reste du texte, elles attirent donc naturellement l’attention du joueur, qui peut tout de même se référer aux phrases précédentes en cas de besoin.

Ajouter une option, discrète, permettant de passer rapidement le texte peut toutefois éviter des frustrations aux lecteurs rapides ou ayant déjà lu cette partie du texte.

Faire les bons choix typographiques

La règle est simple : clarté et lisibilité avant tout ! Les fontes un peu fantaisistes ou extravagantes sont à proscrire pour le corps de texte. Bien qu’elles puissent contribuer à l’immersion, elles deviennent très vite fatigantes à lire. De plus, leur caractère esthétique attire l’attention, et la détourne donc du contenu du texte : la page risque d’être considérée comme une œuvre d’art, à contempler plutôt qu’à lire.

Il faut donc se tourner vers des fontes plus classiques : plus la forme des lettres nous est familière, plus leur lecture est aisée et rapide. La lisibilité est le premier facteur à prendre en compte lors du choix d’une police d’écriture : le déchiffrement des caractères doit être instantané et sans effort.

La page droite de ce livre est tirée directement de The Elder Scrolls IV: Oblivion ; sur la page de gauche, Joseph Humphrey propose une présentation plus lisible du même texte. Le changement le plus évident est celui de la police d’écriture : la calligraphie médiévale est remplacée par du Caslon, une fonte plus adaptée aux textes longs, mais qui garde une connotation de texte ancien. Les marges et les interlignes ont été augmentés, et des alinéas ont été ajoutés pour rendre la lecture plus fluide. Il n’est cependant plus possible d’afficher tout le texte sur la première page.

La taille du texte est un autre facteur à prendre en compte et dépend du médium de destination. Un texte lisible sur ordinateur risque d’apparaître trop petit sur un écran de téléphone ou sur la télévision d’un joueur console. Pour ceux qui souhaitent développer sur plusieurs plateformes, le plus simple est de commencer par les écrans les plus contraignants (smartphones et/ou console), puis de s’adapter aux plus permissifs.

Il est aussi conseillé de limiter le nombre de caractères ou de mots par ligne pour ne pas perdre le regard du lecteur. Joseph Humphrey conseille entre 5 et 15 mots par ligne en anglais, sachant que les mots français ont tendance à être légèrement plus longs. Coïncidence ou pas, on retrouvera la même fourchette en écrivant à la main dans la largeur d’une feuille A4.

Pacing

Le pacing, c’est la gestion du rythme du jeu. Dans un jeu purement textuel, cela consiste donc à définir quand, comment et à quelle vitesse révéler le texte au lecteur afin de maintenir son attention jusqu’au bout.

Découper les paragraphes

Une des premières tâches à effectuer consiste à découper le texte en paragraphes qui seront affichés l’un après l’autre. S’ils doivent rester relativement courts pour éviter l’effet « mur de texte », on peut jouer sur leur longueur pour accélérer ou ralentir la révélation du texte.

Ainsi, en préparant les combats de leur jeu Sorcery!, les designers de la société inkle ont voulu enchaîner des phrases très brèves, séparées par des choix. Leur but était de dynamiser les combats et d’y impliquer le joueur. Lors des phases de test, ils se sont rendus compte que cette stratégie ne marchait pas : chaque choix interrompt la lecture, et donc la ralentit. De plus, comme on l’a établi dans la première partie, plus les paragraphes sont courts, plus le joueur y accorde d’attention. Les combats étaient alors plus lents que les phases descriptives, ce qui était à l’opposé de l’intention de l’équipe.

Un écran de combat dans Sorcery! : les phrases très courtes prévues au départ pour les phases de combat ont été remplacées par des paragraphes de quelques lignes. Le récit paraît ainsi moins haché, le joueur ne se sent pas sans cesse interrompu dans sa lecture.

On aboutit donc à un résultat qui peut paraître contre-intuitif, puisqu’il va à l’opposé de ce qui se pratique dans un récit non interactif : des paragraphes trop courts ralentissent le rythme par rapport à des paragraphes plus longs.

Toutefois, si on peut utiliser cette règle pour faire les premières estimations, seul des tests répétés permettront de vraiment maîtriser le rythme de la narration. Faire lire le texte brut de son jeu ne suffit donc pas : il faut compiler le jeu au fur et à mesure pour pouvoir évaluer conjointement la présentation, qui peut grandement influer sur l’impression globale.

Tromper l’ennui et la fatigue

Lire demande un certain degré d’attention, et après un certain temps, cela peut causer une certaine forme de fatigue, qu’il faut prendre en compte pour éviter que le joueur ne se lasse ou ne délaisse le jeu.

Pour cela, le plus simple est d’alterner les phases très fournies en lectures avec d’autres, plus légères, ou tout simplement différentes. Elles seront une pause bienvenue, requérant un peu moins de concentration, et renouvelant l’attention du joueur avant la prochaine phase de lecture. Si le changement d’activité est à l’initiative du joueur, c’est encore mieux, car cela augmente sa sensation de contrôler le cours de l’histoire, cela agit comme une forme de récompense.

Marquer la progression du joueur en indiquant, d’une manière ou d’une autre, où il se situe dans l’histoire peut aussi lui permettre de ne pas décrocher. Comme la numérotation des pages d’un livre ou des diapos d’un PowerPoint, cela peut rappeler que le jeu a bien un but, et que le joueur s’en approche peu à peu. Il faut faire attention aux effets pervers : un joueur qui voit qu’il approche de la fin peut être tenté de lire les derniers passages en diagonale pour terminer plus vite.

Animer son texte

Si ajouter des animations à son texte n’est pas nécessaire, elles sont un moyen relativement simple et rapide de lui donner un aspect professionnel. Elles attirent immédiatement l’attention du joueur et, dans le cas d’un jeu commercial, donnent l’impression d’un jeu aux finitions impeccables, digne de son intérêt et de son argent.

Au-delà de leur intérêt esthétique, utilisées avec finesse, les animations peuvent aussi fluidifier la lecture et attirer l’attention du lecteur précisément là où on veut. Ainsi, animer uniquement le dernier paragraphe attire l’attention dessus sans que l’on soit obligé de masquer le précédent, qui peut être utile au contexte. Il faut bien évidemment faire attention à ne pas trop en faire, sans quoi les animations détourneront l’attention du texte lui-même, et risquent de ralentir la progression des lecteurs les plus rapides.

Dans 80 Days, tandis que les paragraphes de narration apparaissent immédiatement lors du clic sur un choix, les choix suivants, eux, sont retardés d’une demi seconde. Pendant cette demi-seconde, un joueur pressé n’a donc d’autre choix que de commencer à lire le paragraphe, plutôt que de cliquer sur un lien au pif pour faire avancer l’histoire. La pause doit toutefois rester très brève pour éviter qu’un lecteur rapide ne soit frustré de devoir attendre à chaque tour. Les choix apparaissent par ailleurs dans un fondu discret et assez lent pour ne pas distraire ceux qui n’auraient pas fini la lecture du paragraphe.

Ici, un exemple tiré de 80 Days : en gris clair, on peut lire le texte apparu précédemment, tandis que le texte le plus récent est en blanc et vient d’être animé, il attire plus l’attention. En dessous, on discerne à peine les trois choix menant à la suite de l’histoire, qui sont en cours d’apparition. Pour mieux visualiser le fonctionnement des animations, vous pouvez vous rendre à 21:50 de la vidéo.

Une fois encore, le choix des animations est un domaine qui laisse peu de place aux règles absolues : tester, retester et tester encore est la seule manière d’atteindre un équilibre qui convienne au plus grand nombre.

Cette conférence nous éclaire donc sur certains des choix de design des jeux inkle. De nombreux efforts ont été faits pour mettre en valeur le texte, fluidifier sa lecture et conserver l’attention du joueur tout au long du jeu. Vous êtes maintenant libres de vous inspirer de ces techniques pour peaufiner la présentation de vos propres FI.

Fiche de visionnage — Construisez des histoires riches avec une story grid

Nighten Dushi

Le travail d’un auteur de fiction interactive, autre que de faire des trucs cool avec Vorple, c’est bien d’écrire des histoires ! Aujourd’hui, je vous résume une conférence qui nous parle d’un outil diablement efficace pour écrire des histoires : les story grids !

La Visual;Conference est un séminaire annuel en ligne, ou webinaire, dont la dernière édition s’est déroulée le 12 janvier 2019 (c’est vraiment très récent !). Il a pour thèmes les visual novel, et donc plus globalement les fictions interactives ! De nombreux acteurs du milieu, professionnels et amateurs, y donnent des conférences sur des thèmes très variés, allant de la phase créative à la gestion d’équipe en passant par le marketing. Si vous comprenez l’anglais, je vous invite chaudement à apprécier les près de soixante conférences gratuitement disponibles sur leur chaîne YouTube !

Celle que je vous résume aujourd’hui a été donnée par Katy133, une animatrice canadienne qui développe des visual novel sur son temps libre. Avant de commencer, gardez en tête que j’ai pris des libertés sur son discours, ajoutant ce qui me semblait pertinent et retirant ce qui l’était moins. Bonne lecture !

Construire son histoire avec une story grid

On imagine la plupart du temps nos histoires de manière linéaire. Pas dans le sens « non interactives », mais « scène après scène » ; une suite d’événements qui, lorsqu’on arrive à sa conclusion, donne un tout cohérent. L’outil que je vous présente aujourd’hui propose une approche différente, puisqu’on vas utiliser un tableau, une grid, pour découper notre histoire en Séries.

Qu’est-ce qu’une Série ?

Rien à voir avec ce que vous pouvez regarder sur Netflix. Ici, une Série est un élément narratif (un personnage, un objet, un lieu, une phrase ou un thème) qui apparaît à plusieurs reprise dans le récit le long duquel il va évoluer. Je l’écrirai avec une majuscule pour que vous gardiez cette distinction en tête.

Une Série peut se nommer en fonction du nombre d’itérations :

1 itération, c’est un Deus Ex Machina. Littéralement un élément sorti de nulle part. Vous chercherez en général à l’éviter pour cette raison.

2 itérations, c’est un Fusil de Tchekhov. Ce terme fait référence une phrase très célèbre du dramaturge russe :

Si, dans le premier acte, vous indiquez qu’un fusil est accroché au mur, alors il doit absolument être utilisé quelque part dans le deuxième ou le troisième acte. Si personne n’est destiné à s’en servir, il n’a aucune raison d’être placé là.

Anton Tchekhov

On le résume de nos jour comme un objet insignifiant qui se révèle important par la suite, mais cette structure en deux temps peut être utilisé différemment, par exemple pour faire une blague : Une situation initiale (« Que fait Platon quand ça le démange ? ») et une chute inattendue (« Il Socrate »).

3 itérations, c’est un arc narratif. Vous avez sûrement déjà été confronté à la structure en trois temps : début, milieu et fin. C’est une structure tellement primaire qu’on la retrouve partout, y compris dans cet article.

4 itérations et plus, c’est une série de rappels. Elle permet de découper plus précisément votre scénario et de développer des intrigues plus complexes.

A chaque itérations, il est important que l’élément de la Série change ; Ainsi le joueur sentira l’histoire évoluer et vivre sous ses yeux (bien sûr, faites l’inverse si vos intentions sont contraires).

À quoi ressemble une story grid ?

Vous pouvez construire votre story grid avec un tableur (comme Excel ou Calc), sur papier ou avec n’importe quel logiciel qui vous convienne ; Pour ma part, j’utiliserai un tableau pour pouvoir facilement le partager avec vous.

L’illustration ci dessus est plutôt claire, mais je vais vous détailler ce tableau.

Dans la première colonne se trouve, dans l’ordre chronologique, les noms ou numéros de vos scènes.

La deuxième contiendra l’histoire en elle même, une description de ce qu’il se passe dans la scène et une « fusion » de toutes les Séries qui y sont incluses.

Dans les colonnes suivantes, vous placerez justement vos Séries et, pour chaque scènes où elles font une apparition, vous rédigerez une petite description.

Besoin d’un exemple ? Il se trouve que j’ai récemment réalisé un jeu très court en utilisant cet outil. Bien sûr, je n’ai aucune prétention au sujet de sa qualité d’écriture ; j’utilise cette histoire car elle m’est de facto familière. Il n’est pas nécessaire de l’avoir lu pour comprendre, puisque je vais vous décrire étape par étape sa structure.

Sentiments Enneigés est un visual novel réalisé en un weekend à l’occasion d’une game jam organisée par la communauté de Game Dev alliance. Le thème était « Passion Hivernale ».

On y suit Déborah, une ado solitaire et mal dans sa peau qui est obligée d’accompagner sa petite sœur Susie pour une promenade dans la neige. Elles croiseront Théo, le garçon populaire de la classe et que Déborah n’a jamais osé approcher.

Une fois cette première idée trouvée, je l’ai découpé en trois Séries différentes :

L’état d’esprit de Déborah, sa relation avec elle-même.

Sa relation avec sa sœur Susie.

Sa relation avec Théo, que j’ai un peu élargie à la relation de Déborah avec ses camarades.

Voilà trois axes pour démarrer ! J’ai ensuite ajouté deux fusils de Tchekhov, le bonhomme de neige et la bataille de boules de neige.

Dans la fatigue de la jam, je n’ai pas sauvegardé la story grid originale ; mais en voici une reconstitution a posteriori. Je l’ai légèrement modifiée en omettant la deuxième colonne, fusion de toutes les séries, car je voulais éviter d’être redondant.

1

Déborah ne veux pas sortir, est de mauvaise humeur.

Susie oblige Déborah à sortir.

Susie veut faire un bonhomme de neige.

2

Déborah sort et regrette déjà d’être sortie.

Susie semble préparer quelque chose pour embêter sa sœur.

Susie tasse une boule dans ses moufles, Déborah lui interdit de la lancer.

3

Introspection, plainte à propos de sa situation.

Déborah pense au fait qu’elle n’est pas populaire en classe.

4

Susie brave l’interdiction de Déborah.

Susie jette une boule de neige sur sa sœur.

5

Déborah est très mal à l’aise et ne peut rien dire.

Théo arrive au moment où Déborah se relève. Il les salue avant de repartir.

6

Déborah culpabilise d’avoir réagit comme ça et s’enfuit dans les bois.

Susie poursuit et cherche sa sœur dans les bois. Elle est inquiète.

7

Introspection: Déborah veut changer et ne plus être la bizarre de la classe…

Susie la retrouve et essaie sincèrement de la consoler, s’excusant pour la boule de neige. Déborah envie l’innocence de Susie.

Susie s’excuse d’avoir lancé une boule de neige.

8

Calmée, Déborah propose à Susie de faire un bonhomme de neige dans les bois.

Les sœurs font ce pour quoi elles étaient sorties : Un bonhomme de neige !

Fin 1/2

On peut facilement voir, grâce au tableau, que le principal point de l’histoire est Déborah et la relation avec sa sœur, alors que celle avec Théo est carrément secondaire. Cela m’a indiqué qu’il fallait plus la développer dans la fin alternative.

Cet outil vous permet de voir facilement les problèmes dans le rythme de votre jeu : si par exemple vous n’avez pas laissé assez d’indices avant une grande révélation, si une intrigue secondaire disparaît pendant trop longtemps, si une scène se répète ou n’apporte pas grand-chose à l’histoire et aux personnages.

Si vous avez une scène qui n’implique aucune des Séries de votre tableau, demandez vous si elle est vraiment nécessaire ou si elle implique une Série que vous n’avez pas notée en colonne ; elle mériterait peut-être d’être développée et de revenir à d’autres moments du récit.

A contrario, il est normal de ne pas impliquer toutes les Séries à chaque scène ; Votre histoire en deviendrait indigeste.

Quel usage dans le cadre de la fiction interactive ?

Les story grids ont été imaginées pour structurer des histoires non interactives, néanmoins je suis convaincu de sa pertinence dans notre contexte.

Dans un premier temps, cet outil conviendra aux jeux où le joueur a peu d’influence sur le cours des événements ou avec de nombreux passages obligatoires, comme c’est le cas de VN commerciaux et de certaines FI à parser.

Pour les jeux à embranchements, deux utilisations sont possibles :

Commencer par une histoire linéaire finie pour ensuite imaginer un ou des scénarios alternatifs, comme ce que j’ai fait avec Sentiments Enneigés. D’expérience, je garantis que synthétiser une histoire fait beaucoup travailler l’imagination ; Penser à noter toutes vos idées dans un coin au fur et à mesure !

Utiliser plusieurs tableaux pour chaque grands choix, ou routes, du jeu : Un tableau pour l’introduction, un autre pour la voie A et ses différentes fins, un autre pour la voie B… Cela demandera une bonne organisation, et sera très difficile à adapter si vos embranchements sont très complexes ou nombreux ;

À ce sujet, j’ai d’ailleurs contacté la conférencière, qui m’a gentiment conseillé Twine (auquel vous êtes habitués à présent !) pour structurer un projet plus complexe lorsqu’une story grid n’est plus efficace.

Pour aller plus loin…

Dans un premier temps, je vous recommande chaudement de visionner à votre tour la conférence de Katy133, très courte mais vraiment dense !

Vous pouvez également la retrouver sur Twitter et essayer ses créations sur sa page itch.io !

Elle recommande également le livre Book Architecture de Stuart Horwitz, où elle a découvert le concept de story grid pour la première fois. Si vous n’avez pas la possibilité d’obtenir ce livre, cet article en résume un des chapitres et inclut une story grid utilisée par J. K. Rowling pour Harry Potter et l’Ordre du Phénix ; Eh oui, elle aussi a utilisé cette méthode !

Enfin vous pouvez utiliser les story grid comme outil d’analyse de vos œuvres préférées ; vous pourrez ainsi mieux comprendre leur rythme et pourquoi telle révélation vous a tant affecté.

Je découvre encore les nombreuses possibilités qu’offre cet outil si neuf pour moi. Si vous souhaitez en discuter, n’hésitez pas à commenter, à me contacter ou à nous retrouver sur le forum et sur Discord !

Notes de lecture : deep learning et parser (2015)

Hugo Labrande

Aujourd’hui, c’est notes de lecture ! L’article d’aujourd’hui est dans la droite lignée de ce dont on parlait la dernière fois, sur le fait d’apprendre à une intelligence artificielle comment jouer à une fiction interactive à analyseur syntaxique. J’ai lu un article de recherche récent portant sur ce sujet, et je vous en fais la synthèse, pour qu’on puisse voir les difficultés et l’avancée de la recherche dans le domaine !

Dans tout l’article, on parlera d’« intelligence artificielle qui joue à une fiction interactive ». C’est long ! Donc je lui donne un petit nom : l’IAFI.

L’article est « Language Understanding for Text-based Games using Deep Reinforcement Learning », de Narasimhan et al., paru en 2015.

Le but de ce papier est de construire une IA qui soit capable de lire la description donnée et d’en inférer l’état du jeu et les actions souhaitables. Ils utilisent comme support des MUD, et plus précisément le framework Evennia, qui apparemment fonctionne en donnant les lieux, les objets et les actions. (Un peu comme les expériences en JSON d’Astrofra ?) Je ne connais pas du tout Evennia, et il y a peut-être des subtilités qui font que tout ceci n’est pas immédiatement transférable aux jeux Inform ; mais on peut penser qu’un jeu simple en Inform sans trop de complications (verbes simples, pas de conversations, etc.) devrait convenir.

En général, quand on veut construire un système qui analyse du texte, il y a l’approche primitive du « sac de mots » (on compte les occurrences de chaque mot — mais on perd de l’information) ou l’approche par annotations, où l’humain annote plein de textes avec des catégories et des choses pour aider l’ordinateur à faire des abstractions. L’approche utilisée ici est de faire un apprentissage par renforcement par réseaux neuronaux, c’est-à-dire une approche où on donne un score à la performance de l’ordinateur, pour qu’il puisse voir si c’est bien ou pas et ajuster ses neurones en fonction.

L’article commence par une petite formalisation du problème, où l’on apprend qu’ils se limitent aux jeux à parser avec des commandes « verbe + nom ». Leur but est de calculer la valeur d’une action étant donné un état ; mais vu le nombre d’états possibles, leur but est en fait d’avoir un réseau neuronal capable, étant donné un état, de prédire quelle action serait la meilleure, ce qui est plus simple. Ils ont deux composants : un qui essaie de se représenter l’état en lisant la description, implanté avec un réseau de neurones de type LSTM (qui a fait ses preuves en traduction et en analyse de sentiments) ; l’autre qui essaie de deviner le score qu’obtiendra une commande (et donc quelle est la meilleure) avec un autre réseau de neurones.

Une subtilité : ils ont un système qui devine la meilleure action, et un système qui devine le meilleur objet, et ils prennent le couple « action-objet » qui a la moyenne la plus haute. Ceci est plus efficace (seulement 200 évaluations avec 100 actions et 100 objets, alors qu’il y a 10000 couples possibles), mais c’est assez étrange : en gros, leur IAFI lit la description du lieu, a un bout de neurones qui lui dit « mmh ouh là je sens qu’il va falloir prendre quelque chose » et un autre qui dit « mmmh cette pelle m’a l’air cool », donc elle essaie « prendre pelle » !

Une fois l’évaluation des commandes possibles faites, l’IAFI va vouloir jouer ce qu’elle pense être la meilleure action. Mais en fait, on va la faire dévier de ce choix avec une certaine probabilité : par exemple, l’ordinateur peut suivre son instinct avec probabilité 50 %, ou faire complètement autre chose avec probabilité 50 %. Pourquoi ? Parce que c’est une bonne façon d’introduire plus de diversité et d’améliorer l’apprentissage, en tombant au hasard sur les bonnes actions et en s’en souvenant pour la prochaine fois. Et de façon intéressante, ils font baisser le pourcentage de ne pas suivre l’instinct à mesure que l’ordinateur apprend : plus l’IA joue, plus elle apprend, et plus elle a dû trouver des actions chouettes, ils font donc en sorte qu’elle devienne plus sûre d’elle au fil du temps. (Ça rappelle un algorithme de recuit simulé, où on commence avec des perturbations aléatoires mais on devient sérieux à mesure qu’on s’approche de la fin.)

Le jeu est ensuite testé avec deux mondes différents. Le premier est simple : 4 pièces toutes interconnectées, 4 quêtes possibles (mais formulées de façon potentiellement complexe). On lâche l’IAFI dans une pièce au hasard, on lui dit par exemple « mange une pomme mais ne dort pas », et on la laisse jouer ; puis on recommence, sachant que le score obtenu lui permet de modifier ses prises de décision futures. Le deuxième monde est un peu plus complexe ; créé par les développeurs d’Evennia, il a plus de descriptions de salles et d’actions possibles. Cependant (et c’est un peu décevant), les auteurs disent 3 pages plus loin « en fait on ne va s’intéresser qu’à la quête de traverser le pont, où à chaque tour on a 5 % de chance de tomber du pont » ; je ne sais pas comment le jeu est fichu, mais quand ils disent que c’est plus complexe, ne vous attendez pas à des miracles. Ils font des dizaines d’essais, en laissant tourner l’IA pendant des dizaines de tours…

Et alors ? Ça marche ?

Hé ben plutôt pas mal !! Prenons l’exemple du premier monde simple : si on a une IAFI qui choisit l’action et l’objet au hasard, ça tourne en rond et ça ne marche vraiment pas bien. Si on a une approche « sac de mots », ça commence à être pas mal : l’ordinateur ne perd plus son temps à essayer « manger pomme » s’il n’y a pas de pomme dans la salle. Par contre, cette approche a du mal avec les quêtes qu’ils ont créées (« mange la pomme mais ne dort pas »), parce que comme on ne compte que les occurrences des mots (et pas leur ordre ou le sens de la phrase), le système ne sait pas s’il faut dormir ou manger (il a vu les deux, donc il pense aux deux, donc il peut très bien aller dormir). Par contre, leur système avec un LSTM ne se trompe pas et, au bout d’un moment, comprend tout parfaitement, et ne se trompe jamais dans la résolution des quêtes !

Alors OK, on pourrait dire que c’est artificiel : après tout, il n’y a pas tant de quêtes, donc c’est facile à mémoriser. Surtout, ils ont fait exprès de faire des quêtes avec des « ne pas » en sachant que l’approche « sac de mots » n’arriverait pas à comprendre ; si la quête était « mange une pomme », les deux systèmes auraient 100 % de réussite. Donc bon, certes, leur système apprend à résoudre leur genre précis de quêtes.

Ensuite, ils appliquent la même procédure au monde de fantasy (avec le pont). Le système qui choisit au hasard est nul, bon, normal. Le système « sac de mots » est pas mal, et on peut aller plus loin si on compte les occurrences de couples de mots, mais dans les deux cas ils ne sont pas très efficaces et tombent du pont pas mal de fois, et sont perturbés par les descriptions changeantes. Encore une fois, l’IAFI est la meilleure, et traverse le pont en moins d’étapes et sans se laisser dérouter par les descriptions changeantes.

Enfin, ils ont obtenu deux résultats supplémentaires assez encourageants :

Si on regarde les représentations internes d’un système entraîné sur le
jeu simple dans la maison, les mots « pizza », « kitchen » et « hungry »
sont rapprochés, et idem pour les 3 autres salles, ce qui laisse penser que
l’ordinateur a appris des associations de concept.

Si on entraîne un système sur le premier jeu et qu’on le lâche dans une
variante où les salles ne sont plus à la même place, le système parvient à
apprendre à résoudre la variante bien plus rapidement que s’il n’avait
jamais vu le premier monde — ce qui implique un certain degré de transfert
et de réutilisation des connaissances !

En conclusion, les auteurs ont donc construit un système qui a l’air de comprendre ce qu’on attend de lui en lisant les descriptions beaucoup mieux qu’avec d’autres approches. Certes, les jeux et les quêtes sont très simples, et même avec cela il y a énormément de possibilités, et les auteurs ont dû procéder à des simplifications. Mais tout de même, on a un système qui apprend à résoudre des problèmes simples, et qui peut transférer un peu de son savoir sur des situations similaires mais différentes ; c’est intéressant, et prometteur !

Notes de lecture : Textworld (2018)

Hugo Labrande

Allez hop, encore une note de lecture sur l’IA et la FI ! Je vous ai déjà parlé (en deux parties) du fait qu’apprendre à une IA à jouer à une FI à analyseur syntaxique était un problème difficile, et que le résoudre serait un grand pas vers les IA avec un peu de bon sens. Mon article suivant était une note de lecture d’un article de recherche de 2015, qui construisait une IA capable de se représenter une description et d’en déduire une commande intéressante, et surtout de raffiner son fonctionnement à partir de l’expérience.

Aujourd’hui, on parle de TextWorld.

TextWorld c’est quoi ?

On parle de TextWorld dans 2 articles de recherche différents, parus en 2018. Le premier est « Counting to Explore and Generalize in Text-based Games » (par Yuan, Côté et al.), dans lequel les auteurs créent une intelligence artificielle suivant la même structure que dans l’article précédent : un réseau neuronal pour traduire le texte vu en une représentation interne, et un autre (avec une structure différente) pour trouver une commande qui devrait être intéressante. Une différence par rapport à l’article précédent est qu’ils ajoutent dans le scoreur d’actions une information qui dépend de l’état précédent, en plus de la représentation interne.

Pourquoi font-ils cela ? Parce qu’ils veulent que le système puisse résoudre un problème très particulier, restreint et qui paraît du coup un peu artificiel, mais qui a été utilisé dans d’autres articles sur les IA : celle-ci doit parcourir une succession de lieux consécutifs, en partant du début et en arrivant à la fin (la « chain experiment »). Pour augmenter la difficulté, chaque salle peut avoir quelques salles supplémentaires connectées ; ces dernières ne servent à rien et sont des impasses, et l’IA doit le reconnaître, revenir sur ses pas, et repartir vers la fin de la chaîne (et donc se souvenir de toutes ces choses !). C’est un labyrinthe, en fait — même si c’est particulièrement simple car les impasses sont immédiates, soyons gentils avec notre IA et encourageons-la.

Ce qui est intéressant, c’est que leur IA améliorée arrive à résoudre le problème au bout d’un moment, et apprend même une stratégie intéressante : celle qui consiste (pour les humains) à garder la main sur le mur de droite et à avancer. Les autres IA y arrivent aussi, mais plus lentement (il faut qu’elles recommencent plus de fois avant d’obtenir un très bon score). Et encore mieux : après avoir entraîné une IA à résoudre un labyrinthe, ils la lâchent dans un labyrinthe différent et plus difficile (avec plus d’impasses), et elle y arrive quand même, en appliquant la stratégie qu’elle a apprise !

Bon, mais c’est quoi TextWorld ??

TextWorld est l’outil qu’ils ont créé dans ce cadre-là, et qu’ils présentent (en tout cas, il y a 3 auteurs principaux en commun) plus en détail dans un second article : « TextWorld: A Learning Environment for Text-based Games ».

Une première fonctionnalité de TextWorld est de pouvoir interfacer les fictions interactives Inform avec des intelligences artificielles. Un script Python permet d’exécuter le jeu Inform, ainsi que de lancer l’IA dans le même environnement, et l’entraîner par renforcement en jouant au même jeu encore et encore. Bien sûr, le fait que l’IA y arrive reste théorique pour ce qui est des « vrais » jeux, pour les raisons que j’avais détaillées dans mon premier article, voire d’autres, données dans l’article dont on parle (comme le fait que 2 commandes différentes peuvent donner le même résultat). L’article donne d’ailleurs une liste de fictions interactives (un poil datée, si vous voulez mon avis) classiques mais avec des contraintes et des profils variés, résumés en annexe. Choisir des profils différents vous permettrait de développer certaines capacités chez votre IA au dépens d’autres ; vous avez des jeux où il faut se nourrir tout le temps, d’autres où les énigmes se basent sur des références à la culture populaire, d’autres où certaines énigmes doivent être résolues en un temps imparti, d’autres où il y a des combats, etc. C’est assez intéressant de les voir classés comme cela, en fonction des difficultés que peut rencontrer une IA — même si une telle liste paraît ambitieuse voire prématurée dans l’état actuel des choses.

La deuxième partie de TextWorld est la génération de quêtes et de jeux pour entraîner votre IA, et là on touche à quelque chose de très marrant. TextWorld a une sorte de moteur de jeu qui modélise quelques actions de base (entrer, prendre, manger, etc.). Puis, à partir de ces actions, TextWorld permet de générer des quêtes, c’est-à-dire des suites d’action qui permettent de gagner ; on peut les générer en spécifiant les actions dans l’ordre, ou en partant de la fin. TextWorld permet également de générer une carte au hasard, avec certains paramètres comme le nombre de connections ou la présence de cycles. Enfin, TextWorld peut générer les noms d’objets (au hasard ou avec des qualificateurs génériques si votre IA a peu de vocabulaire), ainsi que les descriptions des objets et des salles et les instructions de quêtes.

Et le résultat est écrit par TextWorld en un code Inform 7, prêt à être compilé ! Ainsi, en utilisant TextWorld, vous pouvez générer une infinité de jeux correspondant à un schéma que vous avez spécifié, avec des caractéristiques immuables permettant de focaliser votre IA sur un type de FI précis, et ainsi sur des capacités bien identifiées. Vous pouvez ainsi générer 10000 jeux où il y a une porte et une clé, et les utiliser pour que votre IA finisse par apprendre à déverrouiller des portes ; puis vous pouvez mettre des couleurs sur les clés, pour corser les choses, etc.

TextWorld est un outil de chercheur, et devrait être utilisé par relativement peu de personnes ; de plus, pour l’instant, les IA sont relativement primitives, et les jeux qu’on leur crée aussi. Cela étant, la démarche est intéressante, à l’intersection entre la FI, l’IA et la génération de texte ! J’espère que ça vous aura intéressé !

P.-S. — il y a bien un autre article qui m’intéresse, « Text-based adventures of the Golovin AI agent », en 2017. L’idée qui m’interpelle, c’est qu’ils se focalisent sur les vieilles fictions interactives médiévales-fantastiques, et pour cela, ils commencent par faire lire plein de fantasy à leur IA pour qu’elle s’imprègne du monde et de ses conventions. Ça a l’air cool !!

Notes de lecture : la plateforme LIGHT

Hugo Labrande

On termine ce mois de l’intelligence artificielle sur notre site en beauté, avec un article de recherche tout récent, qui a paru il y a quelques semaines seulement ! La semaine dernière, on parlait de Textworld, un outil créé par des chercheurs de Microsoft Research qui permet d’interfacer des intelligences artificielles avec des fictions interactives écrites avec Inform, avec comme but que ces IA puissent apprendre à résoudre des petits problèmes avec un apprentissage par renforcement consistant à jouer à ces jeux. C’est un peu la démarche dont j’avais parlé dans mes deux premiers articles sur le sujet, ainsi que celle d’un article de 2015.

Aujourd’hui, on parle de LIGHT, et de l’article « Learning to Speak and Act in a Fantasy Text Adventure Game », par Urbanek et ses collègues de Facebook AI Research, dont le but est un peu différent : au lieu de chercher à apprendre à une IA à résoudre des énigmes et à avancer dans un jeu, et finalement pouvoir à incarner un personnage principal de jeu d’aventure, on essaie d’entraîner une IA pour qu’elle puisse réagir à du dialogue et à des actions faites par un joueur. En gros, une IA qui pourrait être un PNJ dans un jeu vidéo textuel !

L’outil LIGHT est simplement la plate-forme qu’ils ont construite pour interfacer des intelligences artificielles et des humains. Elle ressemble en quelque sorte à un MUD (multi-user dungeon), c’est-à-dire une fiction interactive à analyseur syntaxique qui se joue en multijoueur sur un réseau. Cependant, de ce que je comprends, ça n’est pas un jeu complet, avec des lieux dans lesquels on se déplace et des quêtes à accomplir ; il semblerait que les phases de jeu soient des phases d’interaction entre deux personnages, définis et décrits par le jeu, dans un lieu également décrit par le système et avec quelques objets. Les personnages peuvent se parler entre eux, faire quelques actions, et avoir des réactions ; l’idée est que l’ordinateur pourrait incarner un personnage, et un humain viendrait avec un autre personnage jouer avec l’ordinateur façon roleplay. Ce qui, tout compte fait, serait déjà assez incroyable, puisque vous pourriez converser et jouer (finalement, improviser comme une scène d’improvisation théâtrale !) librement avec un ordinateur qui joue un rôle en face de vous !

Un petit avertissement : cet article est plutôt dense, et je l’ai trouvé plus technique et plus difficile à lire que les précédents ; il y a aussi beaucoup d’appendices et d’exemples à lire. J’espère lui faire justice et ne pas me tromper trop… Commentaires bienvenus pour me dire si j’ai fait un contresens. 🙂

Collecte de données humaines

Pour entraîner une intelligence artificielle, il faut des données — beaucoup de données. Il fallait donc à la plateforme LIGHT plusieurs choses :

Des personnages, ayant une description de quelques lignes, un persona (une liste de quelques motivations écrites à la première personne, comme « je vis dans les bois tout seul » ou « je n’ai pas vu ma famille depuis des mois ») et la liste des objets qu’ils portent. Il y a 1755 personnages disponibles.

Des lieux, qui pourront influencer le contexte et le dialogue ; ces lieux ont une description de quelques lignes, une histoire, quelques objets et personnages qui sont présents ou peuvent être présents dans le lieu, et une liste de lieux voisins (cela pour pouvoir éventuellement les coller ensemble et générer une carte). Il y en a 663.

Des objets (au nombre de 3462), avec une description et des propriétés (portable, mangeable — oh, tiens tiens, les mêmes catégories que dans Inform).

Des actions (13 en tout), codées en dur dans le jeu, comme par exemple : « prendre : pour cela il faut que l’objet et le personnage soient dans la même salle et qu’on puisse prendre l’objet, alors l’objet est dans l’inventaire du personnage. » Encore une fois, quelque chose de très classique dans le cadre d’une modélisation des actions de base d’une fiction interactive à parser ;

des réactions (emotes), au nombre de 22, comme « applaudit », « danse », « fait un clin d’œil », là encore choisies par les auteurs de l’article.

Comment ont-ils obtenu des milliers d’objets, de personnages, et de lieux ? En déléguant la tâche à des micro-travailleurs, via la plateforme Mechanical Turk, qui propose de réaliser des petites tâches (souvent répétitives) pour de petites sommes d’argent. C’est souvent du travail ingrat, et les gens qui y participent ne sont pas très bien payés, si bien que ce genre de plate-formes est relativement critiqué (exploiter des humains pour qu’ils donnent un peu d’humanité que l’on peut ensuite donner à manger à une intelligence artificielle pour l’entraîner et remplacer les humains, non ça n’est pas de la science-fiction…). En tout cas, ça leur a donné beaucoup de choses sur lesquelles travailler.

Ils ont également (surtout) collecté des interactions, sous la forme de plus de 10 000 répliques et actions. Ces répliques ont été créées par des humains : la plate-forme LIGHT prend deux micro-travailleurs, leur donne des personnages tirés au hasard, dans un lieu tiré au hasard et avec quelques objets, et ils doivent faire une petite scène ; chaque personnage parle chacun son tour et a la possibilité de faire des actions et des réactions. Parmi les exemples donnés, il y a une conversation entre un sanglier et une fée, ou entre un roi et son serviteur, d’une dizaine de répliques chacune, détaillées en fin d’article.

Imitons leurs émotions

Après avoir collecté tout ça, c’est l’heure de mettre en place l’intelligence artificielle… et c’est là que je vais vous avouer que je n’ai pas vraiment compris les détails techniques. (Mais est-ce que ça vous intéresse, là est la question aussi !) Il y a des modèles de classement et des modèles de génération, qu’ils comparent avec des méthodes standard de data mining, et dedans il y a Bert Bi-Ranker et Bert Cross-Ranker. Ces deux-là sont les deux plus intéressants, et de ce que j’ai compris, Bert Bi-Ranker prend en compte le contexte d’un côté et les réactions/actions possibles (candidates) de l’autre côté, alors que Bert Cross-Ranker agrège le contexte aux réactions pour pouvoir les colorer ? Bref, Bert Cross-Ranker est mieux mais prend beaucoup plus de temps, mais Bert Bi-Ranker est quand même mieux que toutes les autres méthodes (bien entendu, vu qu’un article scientifique se doit de toujours être le meilleur du monde).

Comment jugent-ils leurs IA ? Ils les mettent dans des conditions réelles, celles où elles vont devoir opérer et prendre des décisions qui paraissent humaines  : ils reprennent des conversations, et ils les arrêtent à un moment, et demandent à l’ordinateur « quelle est la prochaine réplique ? » ou « quelle est l’action / la réaction suivante ? ». Ils font ensuite le même test avec un humain, et comparent les taux de succès. Une autre étape de test met les IA dans des lieux qu’elles n’ont jamais vues, et leur demande de choisir parmi des répliques qu’elles n’ont jamais vues.

Le résultat ? Un humain prédit la bonne réplique 87,5 % du temps, la bonne action 62 % du temps, et la bonne emote 27 % du temps ; ce bon vieux Bert a des taux de réussite de 75 %, 50 % et 26 %. Vraiment pas mal ! Sacré Bert. De plus, les taux de réussite sont du même ordre pour les tests réalisés dans des situations jamais rencontrées, ce qui est très encourageant : Bert a vraiment appris quelque chose qu’il peut transférer à d’autres situations pour agir comme un humain le ferait.

Pourquoi déterminer l’emote suivante est un problème si difficile ? J’avoue que je ne sais pas trop : après tout, on pourrait se dire que le problème est plutôt plus simple, puisqu’il n’y a que 22 possibilités, alors qu’il y a des milliers d’objets et de dialogues possibles. Cependant, une réaction du type « faire la grimace » est en réalité relativement floue : elle dépend du personnage, de son interprétation, de son caractère, de la relation entre les deux personnages, et de la signification de la réaction, qui peut être ambiguë ou en tout cas polysémique (rit-on pour partager un bon moment ou pour se moquer ?). En tout cas, Bert a besoin d’une trentaine de secondes pour trouver une réaction émotionnelle appropriée, alors qu’il ne prend que 2 secondes pour une réplique ; mais ils ont des diagrammes fascinants à la toute fin de leur article qui montrent que Bert a tendance à répondre à un coup par un coup, et enlacer quelqu’un qui pleure ou qui est content. Awww, il est trop choupi ce Bert.

Alors bien entendu, on n’est pas encore au stade où une IA pourrait tourner toute seule et discuter naturellement à un joueur. Cependant, il semblerait que si on entraîne une IA suffisamment bien et qu’on lui donne une grande liste de répliques possible, elle arrive à se comporter comme un personnage non-joueur similaire à un humain — c’est déjà quelque chose de très encourageant et intéressant, et que l’on pourrait voir débarquer dans les jeux vidéo du futur !

Inform 7 bientôt open source

Nathanaël Marion

Vous vous le rappelez peut-être que l’année dernière, Graham Nelson, le créateur d’Inform, avait parlé du futur de ce système. Nous n’avions pas eu de nouvelles depuis mais, à la convention NarraScope la semaine dernière, il a enfin annoncé ce que beaucoup attendait : Inform 7 devrait devenir open source d’ici la fin de l’année.

Voici donc un résumé de sa présentation, réalisé à partir de ses notes publiées ici. Elle est un peu plus technique que la dernière.

Pour les anglophones qui désirent lire la version originale, libre à vous d’aller directement à la page liée dans le paragraphe précédent. Pour les autres, allez quand même regarder si vous voulez voir les diapos.

Une drôle de métaphore

Graham Nelson commence par présenter Inform brièvement, pour ceux qui ne seraient pas familiers avec le langage.

Il enchaîne ensuite avec une réflexion sur les gros projets tels qu’Inform. Il dit qu’on utilise souvent la métaphore de l’architecture : avec un simple éditeur de texte, on peut faire des constructions parfaites, du plan au bâtiment achevé. Mais la conception d’un logiciel ne se déroule pas vraiment comme cela : on commence par des choses, on continue, on ajoute, on modifie ou on supprime, les gens l’utilisent même s’il n’est pas terminé, les besoins changent au fil du temps…

Pour corriger cette métaphore, il prend l’exemple de la Sagrada Família, une basilique en construction depuis 1882 et censée être terminée en 2032. Il s’étend un peu sur ce sujet avant de revenir à Inform.

Le plan original (2001-2015) était d’ajouter de nouvelles fonctionnalités, de corriger les bugs et, une fois par an, d’identifier la chose qui a été le moins bien implantée pour la refaire d’une meilleure façon. Pourtant, Graham Nelson dit que des maintenances de routine ne suffisent plus pour les vieux bâtiments, qu’il faut alors les fermer temporairement. Selon lui, cela est arrivé à Inform en 2015.

Après cette rénovation, Inform va devenir open source.

« Open source », cela signifie grosso modo que le code des programmes composant Inform 7 sera rendu public et que n’importe qui pourra y contribuer, le distribuer, l’utiliser pour créer un logiciel dérivé…

De quoi est fait Inform

Graham Nelson continue en parlant des composants d’Inform, qui est maintenant développé sur GitHub. Inform est écrit en C, en utilisant du literate programming. Cela a été expliqué la dernière fois ; rapidement, il s’agit d’une façon d’écrire sa source en mélangeant le code avec des explications afin qu’on puisse le lire comme un livre.

Cependant, cette façon de programmer n’est pas très commune aujourd’hui alors Nelson a développé sa propre solution, inweb. Celui-ci permet aussi de coller des modules ensemble. L’un d’eux, foundation, regroupe les fonction bas niveau qui faisaient partie du compilateur d’Inform. Maintenant, tous les outils Inform utilisent foundation.

Une autre chose qui a été réécrite est intest, l’outil pour tester Inform lors de sa conception. Ce qui était autrefois un script bricolé est maintenant un outil générique pouvant tester n’importe quel programme en ligne de commande. Un nouveau langage, Delia, a été conçu pour intest. Une des fonctionnalité d’intest est de pouvoir exécuter les 2000 tests d’Inform en parallèle pour que ce soit rapide (chaque test prend 3 secondes, ce serait trop long s’ils étaient effectués les uns à la suite).

Comment rendre Inform plus utile ?

C’est la question que s’est posée Graham Nelson.

Une façon est de généraliser les entrées du logiciel. Pour Inform, cela revient à autoriser d’autres langues que l’anglais pour écrire sa source. Cela a déjà été commencé (on peut déjà utiliser un peu de français avec Inform 7 6L38), mais il reste beaucoup de choses à faire. Rendre Inform open source permettra à des personnes (au hasard, moi :p) de travailler sur cet aspect.

Ensuite, on peut généraliser les sorties du logiciel. Jusqu’à maintenant, une source I7 était traduite en Inform 6, qui est compilé en un fichier jouable. Maintenant, la source sera compilée en une description intermédiaire, inter, qui pourra être traduite en I6, ou en tout autre langage.

Inter permet également de mieux pouvoir optimiser le produit de la compilation, en enlevant ce qui n’est pas nécessaire avant la traduction en I6 (ou autre).

(Pour ceux qui s’y connaissent un peu, tout cela a été en partie inspiré par LLVM.)

Avant, chaque morceau d’une source I7 était traduit en une fonction I6 parmi 91. Il fallait adapter tout cela pour inter, et ça a été long, et c’est pour cela qu’inter contenait parfois directement des extraits I6 (ce qui pose problème si on veut générer autre chose que de l’I6).

Mais ce n’est plus le cas ! Depuis le 6 mai dernier, inter ne contient plus de code I6.

Inter est très verbeux : une source I7 de 1000 mots est compilée en 285 000 intructions inter, qui généreront 80 000 lignes d’I6 ! Après avoir parlé du fonctionnement d’inter (c’est un peu technique alors je saute), Graham Nelson mentionne un problème : beaucoup d’extensions (dont les Standard Rules) incluent des extraits d’I6, et une grosse partie d’Inform 7 (les templates) est écrite en I6. Que faire si on veut générer de l’inter avec ça ?

On pourrait réécrire tout cela en inter, mais ça poserait problème aux auteurs des extensions. À la place, ce code Inform 6 est maintenant décompilé en inter, qui sera ironiquement retraduit en Inform 6 (ou en tout autre chose, d’où l’utilité de cette manipulation).

Inform open source

Enfin, la présentation se termine avec les conséquences qu’aura le fait de rendre Inform open source, sous l’Artistic License 2.0 pour être plus précis.

Il faudrait résoudre les problèmes de gestion : comment s’occupera-t-on des rapports du bug, des suggestions, des contributions ? Concernant les droits d’Inform, pour le moment, c’est Graham Nelson qui les garde.

La dernière sujet de la présentation est des suggestions de contribution que les gens pourront faire.

Parmi elles, un gestionnaire d’extensions, pour que l’on puisse choisir quelle version des extensions utiliser pour chacun de ses projets, au cas par cas ; un programme permettant de traduire inter en C# pour utiliser Inform avec le moteur de jeu Unity ; la même chose, mais pour compiler inter en JavaScript, pour qu’on n’ait pas à utiliser un interpréteur Glulx écrit en JavaScript (comme Quixe), mais plutôt que sa FI soit directement compilée en JavaScript, ce qui le rendrait plus rapide ; une application iOS pour pouvoir écrire ses FI sur mobile.

Et c’est la fin du survol de cette présentation. J’ai vraiment hâte que la nouvelle version d’Inform sorte, car tout cela a quand même l’air excitant. Et tout ce qui nous rapproche d’un Inform en français me rend assez heureux !

L’avenir de Ren’Py, le moteur de visual novel de référence

Nighten Dushi

En août dernier, le créateur et développeur principal de Ren’Py, Tom Rothamel, alias Renpytom, a donné une conférence où il a décrit l’avenir du moteur, tant d’un point de vue fonctionnalité que de sa philosophie. En voici un résumé.

Ren’Py

Ren’Py est un moteur de visual novel, un sous-genre de la fiction interactive hypertexte, créé en 2004. Il est gratuit, open source depuis ses débuts, et fonctionne sur Windows, Mac, Linux, Android et iOS. Il est maintenant reconnu et utilisé pour des milliers de jeux, y compris professionnels.

Il s’utilise via une série de scripts en Python. Son but n’est pas d’empêcher l’utilisateur de coder son jeu, mais de rendre cette tâche plus facile.

L’avenir de Ren’Py

Avec Ren’Py 7, tous les objectifs initiaux du créateurs avaient été atteints : l’essentiel de ce qu’un développeur a besoin est présent, et il était temps de définir de nouveaux objectifs pour le moteur. Voici les principaux axes de travail qu’il a annoncé, sur le court et le long terme.

Amélioration du portage Web

Depuis quelques mois, la possibilité d’exporter son jeu en HTML5 est officiellement prise en charge, grâce aux efforts et à la contribution de Beuc.

Même si beaucoup de progrès ont été faits depuis, les développeurs qui veulent utiliser cette fonctionnalité se heurtent à un problème : l’utilisateur doit charger sur son navigateur le projet en entier, ce qui la rend inutilisable sur de gros projets.

Renpytom espère améliorer cet aspect, principalement utilisé pour des petites démos pour le moment, avec un chargement progressif des assets du jeu. On peut espérer ces améliorations dans les prochains mois.

Réécriture du moteur en OpenGL

C’est une nouvelle très importante pour l’avenir du moteur. OpenGL est une bibliothèque de fonctions permettant d’interagir directement avec la carte graphique. Du temps de la création de Ren’Py, en 2004, ce type de bibliothèque n’était pas aussi répandu, ce qui a conduit à des choix techniques qui ne sont plus vraiment adaptés au matériel actuel.

Quelles seront les nouveautés apportées par ce changement ? Dans un premier temps, il permettra d’utiliser des effets de 3D. Il existe déjà une extension pour Ren’Py permettant de simuler un effet de profondeur entre différentes images. Cela peut vous donner une idée des possibilités de mises en scène qui s’ouvrent aux développeurs.

Il sera également possible d’aller plus loin et d’intégrer directement des modèles 3D dans une scène. Tom en fait la démonstration en montrant un environnement basique dans lequel il peut se déplacer.

Tout cela est est encore très expérimental, mais ouvre beaucoup de possibilités.

Enfin, l’autre avantage de la réécriture du moteur en OpenGL sera la possibilité d’y intégrer des shaders. Un shader est une sorte de filtre avancé que l’on peut appliquer à ce qui est affiché à l’écran. Il sera ainsi possible de modifier simplement les couleurs d’une image à la volée, de passer l’image en noir et blanc temporairement ou d’utiliser des effets graphiques plus avancés. De nombreuses possibilités s’ouvrent ainsi pour l’aspect visuel des jeux.

L’utilisateur bitsawer expérimente déjà depuis quelques années afin d’intégrer ces shaders dans Ren’Py, notamment pour ajouter du vent et déformer l’expression d’un personnage. Voici l’une des vidéos qu’il a fait pour présenter son système.

On parle ainsi d’un support officiel et plus facile de ce genre de fonctionnalité (qui jusqu’alors étaient simulées, en ajoutant des couches intermédiaires par exemple). Renpytom estime que c’est un projet énorme, qui prendra certainement plus d’un an pour correspondre à ce qu’il souhaite. Néanmoins, ces fonctionnalités arriveront petit à petit, avec des outils pour pouvoir les utiliser plus facilement et personnaliser le système.

Live2D

Demandé depuis très longtemps par la communauté anglophone, Ren’Py va officiellement supporter Live2D.

Live2D est un logiciel permettant de donner des mouvement fluides et en relief à des personnages, en se basant uniquement sur des images 2D. Ces modèles peuvent également être interactifs, comme le montre cette vidéo.

Jusqu’alors impossible à intégrer dans Ren’Py, cette technique pourrait arriver avant la fin de l’année !

Philosophie

Tom Rothamel a profité du fait que l’audience soit pour la majorité familière avec ce qu’est un visual novel pour passer plus de temps sur l’historique et la philosophie de Ren’Py.

Dans un premier temps, il ne souhaite pas que les nouvelles fonctionnalités mentionnées ci-dessus modifient l’expérience des utilisateurs qui ne souhaitent pas les utiliser : il veut ajouter de nouveaux outils, mais sans détruire les anciens.

Ren’Py, de sa nature open source, a été modifié par de nombreuses personnes pour le détourner de son usage d’origine: portage vers les consoles, création de RPG, de dungeon crawler ou d’autres mini-jeux. On n’est même pas très loin de pouvoir y faire tourner Doom.

Néanmoins, Renpytom ne souhaite pas à terme faire de Ren’Py un créateur de jeu généraliste. Selon lui, la force du moteur est le fait qu’il soit spécialisé pour créer des visual novels et des jeux similaires, ce qui lui donne un avantage sur des outils tels que Unity lorsqu’on veut développer ce genre de jeu.

La vidéo de la conférence

Vous pouvez retrouver plus de détails en regardant la conférence complète donnée à Animefest 2019.

Sélection de conférences de la Visual;Conference 2020 !

Nighten Dushi

Le 11 janvier dernier s’est tenu le webinaire annuel Visual;Conference, qui est devenu en quelques années d’existence un moment important pour les développeurs de visual novels indépendants anglophones. J’ai assisté à cette journée complète de conférences passionnantes et variées, et dans cet article, je vais vous présenter les quatre qui vous intéresseront le plus si vous créez de la fiction interactive !

Chaque vidéo dure entre 10 et 30 minutes et, si vous comprenez l’anglais, c’est un très bon usage de votre temps. À savoir que toutes les captations de l’événement sont disponibles gratuitement sur Youtube via cette playlist !
Merci enfin à l’organisateur, Randy Au, de proposer cet événement. 🙂

« Using animation to bring life to your visual novel » (Lucy Blundell)

Cette conférence a été donnée par Lucy Blundell, la développeuse de One Night Stand, un visual novel qui a rencontré un très bon succès critique, au point d’être finaliste à l’Independant Game Festival en 2017 pour sa narration.

Elle parle ici de l’usage d’animations dans un jeu, des avantages et des différents moyens d’en utiliser. Mais attention, l’animation, ça coûte cher à produire, et elle en a bien conscience : vous trouverez ainsi des exemples concrets correspondant à la majorité des besoins, et ne nécessitant pas un budget colossal.

Très riche en contenu et compréhensible, la conférence contient également de vrais morceaux de code pour Ren’Py ; très utiles si vous utilisez ce logiciel. [NDLR : Voici le lien.]  

« Teaching players how to play your visual novel » (Ruqiyah)

Beaucoup de ce qu’on prend pour acquis dans les FI ne sont pas évidents pour tout le monde : pourquoi on devrait sauvegarder ? Comment savoir si recommencer permettra d’avoir une fin différente ? Comment savoir à quel point ses actions ont des conséquences ?

Être didactique permet d’être plus accueillant pour les nouveaux joueurs, et ainsi d’élargir le cercle des lecteurs de FI ; c’est pourquoi je vous recommande chaudement de la visionner ! 🙂 [NDLR : Voici le lien.]

« Generating & Refining Concepts without Divine Inspiration » (Empish)

Vous avez peut-être du mal à vous fixer sur une seule idée, votre projet est encore un peu flou, ou vous avez du mal à communiquer clairement dessus ? Cette conférence vous montrera comment poser les bonnes questions, afin de vous concentrer sur l’essentiel !

La seconde moitié de la vidéo est consacrée à un petit jeu générant des idées via une série de questions ; vous pouvez l’essayer vous-même ici ! [NDLR : Voici le lien.]

« Capturing Subtle Emotions Using Choice Mechanics » (Florencia Minuzzi)

Une conférence courte, mais avec des exemples très concrets sur comment la conception des choix peut provoquer des émotions chez le joueur, et refléter celles du personnage qu’il incarne.

Le son est assez mauvais, mais le contenu vaut l’effort de l’écoute ! [NDLR : Voici le lien.]

Merci d’avoir lu cet article jusqu’au bout ! Je vous rappelle que toutes les captations de la Visual;Conference 2020 et des années précédentes sont disponibles gratuitement sur la chaîne Youtube officielle.

Bon visionnage, bonne journée, et à bientôt sur Fiction-Interactive.fr ! 🙂

Des nouvelles d’Inform 7 lors du Narrascope II

Nathanaël Marion

Vous souvenez-vous qu’Inform 7 devait devenir open source l’année dernière ? Ça n’est finalement pas arrivé, et Graham Nelson a expliqué pourquoi lors du Narrascope il y a deux semaines, en plus de donner plus d’informations sur sa vision d’Inform 7.

La présentation est disponible sur YouTube, et une transcription sur le site d’Inform. Que vous compreniez l’anglais ou non, je vous invite à au moins y jeter un œil, ne serait-ce que pour les diapos. Et aussi, ce qui suit ne sera qu’un résumé !

Le début donne un intéressant aperçu de ce que l’auteur d’Inform 7 pense de sa création. La seconde partie (à partir du « partage et de l’amélioration ») sera la plus intéressante pour ceux qui ne veulent qu’avoir des nouvelles sur le futur d’Inform.

Introduction

Intitulée « Second Annual Address By Man Who Still Hasn’t Done What He Said He Would Do » (« deuxième discours annuel d’un homme qui n’a toujours pas fait ce qu’il avait dit qu’il allait faire »), la présentation commence avec un rappel de ce qui avait été dit lors du Narrascope précédent, en précisant qu’Inform n’est toujours pas open source.

Il reparle aussi de l’influence qu’a eu la literate programming sur Inform, avec une belle image d’un programme en wenyan-lang, qui imite le chinois classique. (Voir une précédente présentation pour plus de précisions sur la literate programming.)

Il renomme finalement sa présentation avec un titre un peu plus sérieux : « Engaging with Inform ».

Les 5 étapes de l’engagement

Graham Nelson explique que tout logiciel propose une interaction simple : j’appuie sur tel bouton et il se passe quelque chose. Il propose aussi un engagement social, impliquant des groupes de gens faisant des choix, qui choisissent un logiciel en fonction de leurs besoins et qui façonnent leurs besoins en fonction du logiciel qu’il utilisent.

Graham Nelson nomme le processus par lequel un utilisateur fait entrer un logiciel dans sa vie progressive engagement, divisé en 5 étapes. Les voici.

La découverte

Pour que les gens découvrent un logiciel, il faut faire sa promotion, ce qui peut passer par un elevator pitch. Souvent, il s’agit d’une courte phrase montrant en quoi le logiciel est bien. Les premiers exemples donnés, pour des langages assez standards, se ressemblent tous (dans le genre « un langage simple et efficace pour créer des programmes fiables »), ce qui ne les démarquent pas vraiment.

Pour avoir de la visibilité, il ne faudrait pas dire « je suis le meilleur », mais « je suis différent ». Pour cela, Graham Nelson donne 5 critères inspirés de Thomas Kuhn :

la justesse (dans la résolution de problèmes) ;

la cohérence (avec soit-même et les autres) ;

l’étendue ;

la simplicité ;

le fait d’être fructueux (mène à de nouvelles idées).

Comme on ne peut pas vraiment être bon sur tous ces points, il faut souvent en renoncer. Inform renonce à l’étendue ; après tout, ce langage ne sert qu’à écrire des fictions interactives.

Inform serait donc un langage juste, cohérent, simple et fructueux. C’est comme cela que Graham Nelson espère que les gens voient Inform.

L’embarquement

On a maintenant l’attention des gens. Comment les convaincre de monter à bord ?

Les professeurs et les ateliers sont cruciaux, et Graham Nelson suggère deux principes.

Il faut tout d’abord aller là où sont les gens. Pour Inform, cela signifierait de montrer aux étudiants de la narration courte, avec états qui changent (comme un objet qui serait porté par des personnes différentes). En particulier, Graham Nelson ne pense pas que Cloak of Darkness, l’exemple classique de FI qu’un langage doit pouvoir implanter, soit bon : il donne une idée trop vieille, des années 80, d’une fiction interactive.

Le second principe est l’utilisation de métaphores, qui permettent d’organiser ses idées et de garder sa simplicité. Par exemple, pour Photoshop, ce serait l’analogie avec le dessin traditionnel (pinceau, gomme, etc.).

Pour Inform, la métaphore serait : « C’est comme si vous écriviez un livre. » Ses ingrédients principaux serait les relations et les règles. Et cec serait une bonne idée de montrer ces idées abstraites de relation et de règles à d’éventuels étudiants pour qu’ils puissent créer les leurs si nécessaires.

L’apprentissage par soi-même

Une fois qu’un utilisateur est monté à bord, il faut que l’utilisateur puisse s’améliorer par lui-même. C’est à cette étape qu’Emily Short et Graham Nelson ont surtout pensé au début des années 2000, ce qui a mené à l’écriture des deux manuels d’Inform : la documentation et le livre de recettes.

Peu de choses vont changer de ce côté, si ce n’est que beaucoup de gens demandent une version papier de ces manuels et que Graham Nelson y pense.

Le partage et l’amélioration

Quand un utilisateur devient suffisament impliqué, il voudra contribuer. Avec Inform, cela se passe avec son système d’extensions.

C’est à partir de ce moment de la présentation qu’on commence à avoir plus d’informations sur le futur d’Inform.

Inbuild

En effet, il a toujours été historiquement difficile de gérer les extensions avec Inform : on peut les trouver à plusieurs endroits sur la toile, en plusieurs versions, qui ne fonctionnent pas toutes avec toutes les versions d’Inform…

Inform viendra donc avec un gestionnaire d’extensions nommé inbuild. Il permettra de bien gérer chacune de leurs dépendances, de les « geler » dans le projet pour qu’on puisse le distribuer sans que les autres doivent réinstaller de leur côté chacune des extensions…

Il sera aussi possible d’avoir plusieurs versions d’une même extension installées, et elles suivront le versionnage sémantique, tout comme Inform. Le but étant qu’on puisse mettre les extensions que l’on a écrites sur GitHub, et inbuild les récupérera automatiquement.

Basic Inform

Une autre avancée est qu’il sera possible d’utiliser Inform sans les Standard Rules (qui définissent le modèle du monde, les actions et les relations utiles pour une FI, etc.). On pourra donc créer des programmes plus « standards » avec Inform. Cela grâce à la nouvelle extension Basic Inform, qui contient la définition de base du langage (qui était autrefois incluse dans les Standard Rules).

Il y a aussi la nouvelle notion de kits, des paquets précompilés en inter, qu’inbuild se chargera de générer au fur et à mesure.

(Au passage, Graham Nelson souligne ironiquement que c’est en janvier 2020 qu’il a enfin été possible pour la première fois d’écrire le traditionnel Hello World en Inform 7, grâce à Basic Inform.)

Ce qu’il y a dans la boîte

Le dernière étape de l’engagement est quand l’utilisateur veut savoir comment le logiciel fonctionne.

Aujourd’hui, avec la plupart des logiciels open source, même si on a accès à leur code, on ne sera forcéement capable de le comprendre et de l’appréhender tellement il est gros et complexe.

Graham Nelson ne pense pas qu’un programme doit être comme cela, telle une démonstration abstraite et mathématiquement correcte. Un programme est à propos de besoins d’humains réels.

Graham Nelson utilise donc un outil des sciences sociales, la description dense (« thick description »), qui consiste à ne pas seulement décrire les faits, mais aussi comment les gens les appréhendent et se comportent à leur contact.

Un exemple montré est la ville de Çatal Höyük, où les archéologues n’ont pas simplement décrit leurs fouilles, mais ont aussi tenus des journaux à propos de leurs sentiments sur ce qu’ils ont trouvé. Une description dense de Çatal Höyük implique ainsi de l’empathie.

Pour en revenir à Inform, simplement publier sa source serait une description ténue. Pour une description dense, il faudrait ajouter des raisons, des données, des discussions. On en revient à la literate programming, qui serait un outil idéal pour cela.

Graham Nelson ne s’étend pas dessus, car il en a déjà parlé lors de ses précédentes présentations. Ce qui permet de générer ces descriptions denses est inweb, qui permet d’ajouter des descriptions à la source, des liens, des vidéos, des téléchargements ou des équations mathématiques, et de générer un site contenant tout cela.

Conclusion

Graham Nelson termine en faisant le bilan de ce qu’il reste à faire avant de pouvoir rendre Inform 7 open source.

inweb et intest : terminé.

indoc, inrtps, inpolicy, inblorb : presque terminé.

Standard Rules, Basic Inform, les kits : presque terminé.

inform7 : sur 19 modules, 11 sont terminés, 7 en bonne condition et 1 nécessitant un travail plus sérieux.

Inform consiste pour le moment d’une description dense de 300 000 lignes, ce qui est probablement le plus gros programme en litterate programming.

Inform a donc bien avancé et beaucoup de choses sont résolues, ce qui n’était pas le cas l’année dernière. Graham Nelson prévoit de sortir une version bêta bientôt (même si pas maintenant).

Cette présentation a ainsi donné un aperçu de comment Graham Nelson conçoit l’avenir open source d’Inform, ainsi que comment le langage va s’améliorer.

Toujours pas de nouvelles concernant les traductions d’Inform, mais chaque chose en son temps !