Ce billet est la suite du précédent billet où je raconte la construction d’une ontologie des game design de jeux de rôles. Je diffuse quelques résultats de ce projet en construction.
En même temps que je travaillais les relations hiérarchiques entre les classes de game design, je développai les individus pour voir si le système fonctionnait et ce qu’il fallait corriger.
Désormais, les classes sont plus compactes et je continue à les nettoyer pour les rassembler encore plus, car ce qui fait la force d’une classe c’est de rassembler des éléments autour d’elle. Pour ne pas d’aller trop dans la granularité, je travaille aussi sur leur hiérarchie en tentant de ne pas faire des hiérarchies trop profondes et donc trop forcées. En séparant mieux les individus des classes, la taxonomie est considérablement simplifiée avec une factorisation plus étalée des concepts. Je me suis fortement inspiré du travail de Guillaume et Thibault Rioult et leur modèle P.E.R.S.O. (1) pour décrire les briques de game design. Plus particulièrement je me suis servi de leurs découpages en opérateurs fonctionnels (« opérateur de substitution » , etc.).
Chaque individu est désormais un module/ brique/ innovation de game design d’un jeu de rôle en particulier.
Le tout est construit dans WebProtégé, exporté en RDF/OWL (un format XML). De ce format XML, je le mouline dans 3 scripts Python pour faire des visualisations simples. J’ai créé un repo dans GitHub avec une exportation récente du OWL et les scripts Python. Les visualisations en HTML (en lien et en aperçu ci-dessous) sont disponibles sur GitHub.io.
Exemples de toutes les classes imbriquées avec les individus les utilisant :
Exemples d‘individus avec classes :
Exemple d’individus avec classes et (parfois) description
Pour certains individus, la description complète est placée dans un menu « Détails » déroulant (voir image ci-dessus). Elle a été générée automatiquement par l’intelligence artificielle générative de Google Gemini.
Dans la plupart des jeux très connus, Google Gemini a produit un texte de qualité dont la principale utilité a été de servir, après sa lecture par moi, à compléter l’indexation avec des classes manquantes qui m’avaient échappées. C’est un gros avantage selon moi ET une utilisation plutôt éthique (quand elle est déclarée) puisque le texte généré vient en soutien à une tâche. Il ne la remplace pas ou se s’y substitue pas.
Cependant, dans certains cas de mécaniques ou de jeux nichés, Google Gemini a produit du bullshit, certes avec des subjonctifs (would, could,…) mais de manière formellement convaincante si on ne connait pas les jeux. Ci-dessous, un extrait d’une tentative manquée d’explication de ce qu’est la mécanique d’approbation dans Prosopopée de Frédéric Sintes.
De plus, la semaine passée, Google Gemini a poussé agressivement son algorithme dans la plupart de ses produits (Android, etc.) et cela m’a rajouté une couche supplémentaire de rejet vis-“`à-vis de cet outil en particulier.
Enfin, le gain de temps est plutôt marginal par rapport à la tâche d’aller visiter quelques sites web et de lire par soi-même des explications. De plus, ces outils invisibilisent le travail des auteurs et des critiques qui ont étudié les jeux. Pour contrebalancer ce dernier point, j’ai ajouté dans le fichier OWL de WebProtégé les liens vers des sources authentiques.
Les champs peuvent suivre différentes normes pour décrire des données et des métadonnées. Elles sont spécialement adaptées pour le web sématique et les données liées. Dans un fichier RDF/OWL on peut rencontrer ces 3 normes pour décrire un élément. Pour chaque champ, la langue est codée en ISO 639 : fr, en, es, pt, …
Taxonomie des classes : Le nom du game design en général commençant en minuscule. La forme textuelle doit être la plus courte et la moins ambigue possible.
Individus : Nom du game design, souvent sous une forme d’une phrase courte ou d’un titre. Commence par une majuscule. Suivi du nom du jeu entre parenthèses (les parenthèses sont des caractères réservés pour cet usage).
Synonymes du label.
Courte définition de une à trois phrases.
Description complète au format MarkDown. Lorsque ce champ est renseigné, il est souvent issu d’un copier-coller de Google Gemini ou autre LLM si ces dernier ont produit une synthèse satisfaisante.
URL ou référence bibliographique de la source d’information.
Renvoi. Indique quel autre descripteur pourrait être utilisé en complément.
(1) Guillaume et Thibault Rioult, 2024, Interfaces ludiques entre système de jeu et fiction, outil de modélisation au service du game design au colloque « Le jeu de rôle a 50 ans. Et maintenant, que faites-vous ?… » à la Sorbonne.