Multi User Domain

Utilisation des technologies du web sémantique pour construire un jeu d'aventure en texte infini

April 23, 2021

Avez-vous déjà joué à un livre de Défis Fantastiques ? En gros il s’agit d’un jeux de rôle où l’on vous donne un choix, par exemple « Aidez l’homme », et si vous choisissez « Oui », vous êtes dirigé vers un numéro de page où l’on décrit le résultat de votre choix. Il s’agit d’une forme populaire et précoce de le genre de jeux du rôle qui a inspiré Donjons et Dragons, et a contribué à façonner le genre tel que nous le connaissons.

La couverture de 'Le Sorcier de la montagne de feu', un livre de Défis Fantastiques

Il est intéressant de noter que les conceptions de Défis Fantastiques ont donné naissance au jeu d’aventure textuel et au jeu d’aventure point-and-click, qui restent populaires à ce jour.

Image promotionelle de 'The Walking Dead' de Telltale Games, un jeu d'aventure populaire de type point-and-click, publié en 2012

Un domaine multi-utilisateurs est un monde virtuel multi-joueurs en temps réel et il est généralement basé sur le texte. Il s’agit d’un concept déployé dans différents domaines, notamment les jeux, où les joueurs partagent un monde virtuel dans lequel ils peuvent « choisir leur propre aventure ».

Depuis l’âge de 5 environ je suis fasciné par l’idée à créer un jeu avec les choix illimités. J’ai créé un jeu dans lequel j’étais le serveur moi-même. Je disais « Alors, qu’est-ce que tu veux faire ? » et ce que le jouer répondrait, je dessinerais. Le temps de rendu était terrible mais le jouabilité était génial. Chaque fois que j’ai essayé écrire un jeu si ouvert dans un livre comme Défis Fantastiques, je me suis heurté à un simple problème mathématique et je n’ai pas pu le finir. La vérité est que l’art d’écrire un jeu d’aventure narratif comme The Walking Dead est l’art de donner l’illusion d’avoir des vraix choix. En donnant un choix réel, vous constaterez que l’arbre des résultats possibles croît de manière exponentielle et devient rapidement ingérable. On doit tronquer les résultats et forcer que les choix conduisent à la même intrigue jusqu’à la toute fin.

Ce n’est pas le cas avec le Multi User Domain.

Une très brève introduction au Web sémantique

Pour les non-initiés, j’ai préparé une brève introduction sur les bases du web sémantique (en particulier sur les données RDF), mais vous préférerez peut-être passer directement à la suite.

L’information essentielle est qu’en RDF les données sont modélisées en graphes. Un graphe peut-être plus flexible qu’un tableau, je peux ajouter les nouveaux caractéristiques à une ressource à tout moment sans ajouter une colonne à chaque ligne d’un table. En plus les arêtes du graphe (les champs de la modèle) sont définis par les ressources URIs qui peuvent-être suivi afin de découvrir son schéma en ligne et ouvert. Les applications bien écrites devient interopérables, ce qui signifie que nos applications peuvent partager les données entre elles, sans qu’il soit nécessaire de le prévoir au moment de la programmation.

En Web 2.0 (le web moderne), la plupart des sites sont présentées sous forme de contenu lisible par un humain, au lieu d'une machine. En lisant l'HTML la machine connait comment vous afficher le texte, mais elle comprend pas la connaissance contenue dans le texte. Dans les applications la logique est bien écrite pour définir clairement ce que la machine doit faire avec les données du serveur, mais c'est le programmeur qui comprend la forme des données et bien la connaissance qu'elles encodent. La machine sait simplement « robot fait ». Dans le web sémantique nous servons presque toujours un certain type de données RDF. En RDF, les données encodent ses « sémantiques » (signification). En place de servir un mastodonte de texte à propos de Barrack Obama, on obtiendra quelque chose comme ``` :Barack-Obama a :Person ; # Barack Obama est personne :name "Barack Obama" ; # il s'appelle Barrack Obama :hasSpouse :Michelle-Obama . # sa femme est Michelle Obama ``` Il existe plusieurs formats différents pour exprimer le RDF, ici j'utilise Tutrle, il est lisible et populaire. Notez que les données sont exprimées en trois **trebles**: * « Barrack Obama - is a - Person » * « Barrack Obama - has a spouse - Michelle Obama » Pour être plus clair, voici le même contenu dans un graphique: Un graphe montrant un nœud, Barack Obama. Une arête étiquetée 'rdf:type' mène à un nœud 'Person', une arête étiquetée 'has spouse' mène au autre Person, Michelle Obama, et une arête étiquetée 'nom' mène au texte 'Barack Obama' Les nœuds du graphe sont **ressources**, à l'exception de son nom qui est un **littéral** - un simple valeur de type string. Les arêtes du graphe sont toujours appelées **propriétés**. ### Pourqoui est-ce que j'ai écris « :Person » au lieu de « Person » ? En brèf, c'est une abréviation. En intégralité, il serait: ``` <https://example.org/#Barack-Obama> a <https://example.org/#Person> <https://example.org/#name> "Barack Obama" . ``` (Tout est question d'URIs !) Donc si `https://example.org/#Barack-Obama` pointe vers le graphe que nous définissons ici, le graphe qui définit Barrack Obama, alors il s'ensuit que l'URI `https://example.org/#Person` pointe vers la définition du type **Person**, et bien que `https://example.org/#name` signifie la définition du propriété **name**. Notez que nous ne servons pas seulement les informations de Barrack Obama, mais aussi le schéma de ce que les données _signifient_. ### Les Vocabulaires rendent tout interopérable Les graphes qui définit quoi est une personne, un nom, un époux, etc, sont appéllés un « vocabulaire », ou paraeillement un « ontologie ». On devrait les partager et les réutiliser afin que mon application et des autres soient interopérables, qu'elles puissent se comprendre mutuellement. ``` <https://example.org/#Barack-Obama> a <http://xmlns.com/foaf/0.1/Person> <http://xmlns.com/foaf/0.1/name> "Barack Obama" . ``` Le même graphe, mais utilisant l'ontologie populaire [Friend-of-a-Friend](http://xmlns.com/foaf/spec/). Lorsque je conçois mon application avec des schémas communs, je sais que d'autres applications peuvent la lire sans avoir besoin d'une logique personnalisée pour mon application. On peut tous utiliser l'application qu'on veut, sans être liés à un service parce qu'il verrouille nos données.

Le jeux d’aventure infini en mode texte

Alors que les données SQL se caractérisent par leurs contraintes sur les données, les données RDF se caractérisent par leur ouverture. Je peux ajouter une propriété canFly à un stockage Car, sans avoir besoin d’effectuer une migration de base de données ou de définir cette propriété sur une autre voiture.

Ainsi à cet égard le projet Multi-User-Domain est un effort pour définir une spécification partagée pour utiliser les mondes virtuels, que les développeurs peuvent étendre et construire à l’infini.

Il y aura beaucoup de plaisir à construire un monde, même sans « aventure textuelle », simplement en créant une village, et en revenant dans 6 mois pour découvrir que ta village est maintenant une grande ville pleine d’histoires et de souvenirs. Vous pouvez rencontrer un chevalier, et trouve que vous avez un choix de lui défier en duel. Le serveur du monde n’a pas besoin de savoir ce qu’est un duel, il doit simplement permettre aux jouers et aux machines d’écrire dans le monde en RDF. En définissant des spécifications communes pour l’interopérabilité des services, le client peut découvrir un service qui peut se permettre de défier les chevaliers en duel.

Une capture d'écran d'un dialogue de 'Assassins Creed Valhalla' dans lequel il n'y a que deux choix, 'donnez-le aux marchands' ou 'financez le guerre d'Halfdan'. Un choix très restreint

Plus besoin de choisir le moindre de deux choix de rupture de rôle ! Je veux donner l'argent aux paysans !

En nous appuyant sur les propriétés d’ouverture et d’interopérabilité des données sémantiques, et en définissant des spécifications communes pour l’interopérabilité des services, nous pouvons créer un jeu décentralisé, construit spontanément et débordant de vie. Il peut continuellement surprendre les joueurs et les architectes des mondes qui le composent, évoluer et changer à jamais. Une communauté de mondes avec lesquels les humains et les robots d’exploration du Web peuvent interagir.

Bien sûr, cela implique que les histoires du jeux doivent être décentralisées, flexibles aux rebondissements des choix des joueurs. Toute personne qui a été Maître de Donjon connaît les périls de voir les joueurs faire dérailler les quêtes par leur comportements imprévisible, mais c’est souvent cette imprévisibilité qui rend Donjons et Dragons si amusant. En raison de cette propriété ouverte au cœur du projet, l’écriture des histoires sera moins « un grand arbre » comme des Défis Fantastiques et plus des connexions libres et des fédérations d’arbres d’évenements courts et flexibles, en adaptant spontanément comme le jeu lui-même. Mais découvrons-le en les écrivant !

Je suis intéressé, quel est le prochain étape ?

Rejoinds-nous dans notre serveur Discord et dit « bonjour » ! https://discord.gg/sauZA3jCK7. On veut construire une communauté inclusive pour les gens de tous niveaux et tous horizons :-)

Liens utiles: