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.
Nouvelle ontologie
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.
- Ils ne sont pas exhaustifs par rapport à un jeu.
- Ils sont surtout notables.
- Il peut y en avoir plusieurs par jeu.
- Exemples d’individus : les moves de Apocalypse World, la sauvegarde de soi dans Eclipse Phase, etc.
Visualisations
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

IA gen : 1 avantage 3 problèmes
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.
Avantage
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.
Problèmes
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.
Champs RDFS, SKOS ou DC
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, …
rdfs:label
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).
skos:altLabel
Synonymes du label.
skos:definition
Courte définition de une à trois phrases.
dc:description
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.
dc:source
URL ou référence bibliographique de la source d’information.
rdfs:seeAlso
Renvoi. Indique quel autre descripteur pourrait être utilisé en complément.
Apories restantes dans l’ontologie des classes
- La tentation est forte parfois de faire des doubles (ou triples) parents plutôt que de s’astreindre à un seul parent par sous-classe.
- Dice pool : est-ce que je créé deux sous-catégories linear dice pool et non linear dice pool ? ou je mets ces deux en dehors au cas ou il y aurait d’autres éléments linéaires et non linéaires ?
- Il faudrait que je trouve comment compter le nombre d’utilisation de chaque classe. Une classe utilisée une fois est peu pertinente.
- Est-ce que je sépare Magic dans une classe à part du reste ou je l’intègre dans les autres classes ?
- Dice mechanics : potentiellement profond + bien séparer les notions. Par exemple roll-under > roll under target number (une classe et sa sous-classe liée) devient : roll-under + target number (deux classes séparées à combiner si besoin).
- Bien écrire les labels des classes et des individus avec un vocabulaire contrôlé (à faire) :
- player character
- player
- gamemaster
- participants (P+GM)
- Bien décrire les définitions pour lever les ambiguïtés.
- Rédiger un dictionnaire des données.
Questions de recherche et hypothèses
- Est-ce qu’un individu indexé avec beaucoup de classes est un signe d’innovation, de fun, etc. ?
- Comment utiliser cette ontologie pour indexer un jeu au complet, plutôt que des briques d’un élément du jeu ?
- Comment aligner une partie de cette ontologie avec Wikidata ?
Références :
(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.






























J’ai récemment repris un projet que j’avais laissé en désuétude : la célébration des innovations de game design dans le jeu de rôle. Auparavant, j’avais inclus cette dimension dans la frise chronologique TTTTRPG (Timeline Tree of Tabletop Role-Playing Games). J’ai décidé de l’extraire de cette frise et d’en faire une ontologie séparée.
Ontologie
De manière plus détaillée, une ontologie est un système structuré pour représenter et organiser des informations d’un domaine spécifique. Elle ne se contente pas de lister des éléments ; elle établit des relations claires entre eux, créant ainsi un cadre pour la compréhension et le raisonnement. Dans notre cas, cette ontologie va reposer principalement sur deux éléments :
Dans cet exemple, la taxonomie va représenter tous les types de game design, ou plus largement tous les ludèmes (des bouts d’éléments de jeu). Les individus seront les game designs spécifiques et intéressants de jeux notables. Le nom du jeu est ajouté entre parenthèses après le label du game design.
Exemples :
Mon erreur du mois passé
J’ai commencé à construire une énorme taxonomie de classes et de sous-classes qui intégraient AUSSI les game designs de certains jeux DANS l’arbre des classes (souvent en bout/fond de sous-classes). Au lieu de séparer ceux-ci comme expliqué précédemment. Dans cette organisation, les individus étaient les jeux.
Ce n’est pas complètement mauvais en soi, mais cette organisation de connaissance a des limites :
Si on envisage de recenser de manière exhaustive tous les jeux de rôle et leurs mécaniques de game design, il est crucial de ne pas surcharger la taxonomie de classes avec une granularité excessive. Tenter de créer des classes pour chaque élément de game design spécifique pourrait transformer la taxonomie en un « arbre surchargé », potentiellement trop lourd et difficile à gérer.
Archive compressée contenant les 4 fichiers de cette étape erronée (dans une démarche de science ouverte) :
Comment concevoir une (bonne) ontologie de game designs ?
La clé est de trouver un équilibre. Il est préférable de maintenir une taxonomie plus générale et abstraite, en se fiant aux individus à indexer en parallèle. Chaque élément de design de jeu de rôle (un individu) pourra être décrit avec des liens précis vers les classes pertinentes de la taxonomie. Par exemple, plutôt que de créer une classe pour chaque type de dice pool utilisé, on pourrait avoir une classe plus générale dice pool, voire une ou deux sous-classe (linear dice pool, non linear dice pool) et laisser la description de l’individu spécifier le type de dé utilisé.
Cette approche permet de conserver une taxonomie claire et gérable, tout en offrant la flexibilité nécessaire pour capturer les détails spécifiques de chaque jeu de rôle via les liens entre la taxonomie et la liste des individus.
Créer une taxonomie de classes et de sous-classes
C’est à dire, créer une liste hiérarchique de concepts permettant de décrire, classer, rassembler, qualifier les différents éléments de game design existants.
Voici un aperçu de cette taxonomie dans WebProtégé :