This post is a follow-up to the previous one, in which I described the construction of an ontology of role-playing game design. I'm sharing some of the results of this ongoing project.
New ontology
While I was working on the hierarchical relationships between the game design classes, I was developing the individuals to see if the system worked and what needed to be fixed.
From now on, the classes are more compact and I continue to clean them up to bring them together even more, because what makes a class strong is to bring together elements around it. To avoid going too granular, I also work on their hierarchy by trying not to make hierarchies too deep and therefore too forced. By better separating individuals from classes, the taxonomy is considerably simplified with a more spread-out factorization of concepts. I was strongly inspired by the work of Guillaume and Thibault Rioult and their PERSO model (1) to describe the game design bricks. More specifically, I used their divisions into functional operators ("substitution operator", etc.).
Each individual is now a module/brick/game design innovation of a particular role-playing game.
· They are not exhaustive in relation to a game.
· They are especially notable.
. There can be several per game.
. Examples of individuals: Apocalypse World moves , backup your ego in Eclipse Phase, etc.
Visualizations
Everything is built in WebProtégé, exported in RDF/OWL (an XML format). From this XML format, I mill it into 3 Python scripts to make simple visualizations. I created a repo in GitHub with a recent export of the OWL and the Python scripts. The HTML visualizations (linked and previewed below) are available on GitHub.io.
Examples of all nested classes with the individuals using them:
Examples of individuals with classes :
Examples of individuals with classes and (sometimes) descriptions :
genAI: 1 advantage 3 problems
For some individuals, the full description is placed in a drop-down menu (see image above). It was automatically generated by Google Gemini's generative artificial intelligence.
Advantage
In most of the well-known games, Google Gemini produced a quality text whose main use was to serve, after reading it by me, to complete the indexing with missing classes that had escaped me . This is a big advantage in my opinion AND a rather ethical use (when it is declared) since the generated text supports a task. It does not replace it or substitute for it.
Problems
However, in some cases of niche mechanics or games, Google Gemini has produced bullshit, admittedly with subjunctives ( would , could , ... ) but in a formally convincing manner if one does not know the games. Below is an excerpt from a failed attempt to explain what the approval mechanic is in Fréderic Sintes' Prosopopée.
Additionally, last week Google Gemini aggressively pushed its algorithm across most of its products (Android, etc.) and that added another layer of rejection to this particular tool.
Finally, the time savings are rather marginal compared to the task of visiting a few websites and reading explanations on your own. Furthermore, these tools obscure the work of the authors and critics who have studied the games. To counterbalance this last point, I added links to authentic sources to the WebProtégé OWL file.
RDFS, SKOS or DC fields
Fields can follow different standards to describe data and metadata. These are specifically adapted for the sematic web and linked data. In an RDF/OWL file, these three standards can be found to describe an element. For each field, the language is coded in ISO 639: fr, en, es, pt, etc.
rdfs:label
Class Taxonomy: The name of the game design, usually beginning in lowercase. The textual form should be as short and unambiguous as possible.
Individuals: The name of the game design, often in the form of a short sentence or title. Begins with a capital letter. Followed by the name of the game in parentheses (parentheses are reserved characters for this use).
skos:altLabel
Synonyms for the label.
skos:definition
Short definition of one to three sentences.
dc:description
Full description in MarkDown format. When this field is filled in, it is of-
ten copied and pasted from Google Gemini or other LLM if they have
produced a satisfactory summary.
dc:source
URL or bibliographic reference of the information source.
rdfs:seeAlso
Cross-reference. Indicates what other descriptor could be used in addi-
tion.
Remaining aporias in the ontology of classes
- The temptation is sometimes strong to make double (or triple) parents rather than restricting oneself to a single parent per subclass.
- Dice pool: do I create two subcategories: linear dice pool and non-linear dice pool ? or do I separate these two in case there are other linear and non-linear elements?
- I need to figure out how to count the number of times each class is used. A class used once is not very relevant.
- Do I separate Magic into a separate class from the rest or do I integrate it into the other classes?
- Dice mechanics : potentially deep + separate concepts well. For example, roll-under > roll under target number (a class and its related subclass) be- comes: roll-under + target number (two separate classes to combine if necessary).
- Write class and individual labels correctly with controlled vocabulary (to be done):
- player character
- player
- gamemaster
- participants (P+GM)
- Clearly describe the definitions to remove ambiguities.
- Write a data dictionary.
Research questions and hypotheses
- Is an individual indexed with a lot of classes a sign of innovation, fun, etc .?
- How can we use this ontology to index an entire game, rather than just bricks of a game element?
- How to align part of this ontology with 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.
No comments:
Post a Comment