19 oct. 2009

Implémentation d'un système de règle pour un jeu de rôle - Introduction

Même si ça peut paraître relativement simple, l'implémentation d'un système de règle pour un jeu de rôle est une tâche complexe. Il existe de nombreuses raisons à ça :

  • les règles elles même ne sont pas hiérarchisées : dans un système parfait, une règle particulière ne fait pas référence à une règle plus générale ; au mieux, elle se substitue à la règle générale. Dans le cas des jeux de rôle, ça n'est pas le cas. Les règles particulières peuvent non seulement se substituer aux règles générales, mais elle peuvent aussi les étendre ou les modifier de manière plus fine.
  • le nombre de cas à gérer n'est pa connu par avance : un jeu de rôle est un produit vivant. Un supplément va nécessairement étendre le système de jeu pour ajouter de nouvelles options. Avant sa parution, il est impossible de savoir quelle modification va avoir un impact sur l'architecture du code. Il convient donc d'ouvrir l'architecture au maximum, sans pourtant tomber dans le travers de la sur-ingénierie qui serait contre-productive.

L'ouverture impossible à prévoir ainsi que les références circulaires sont deux grand ennemis de l'architecte.

On a vu il y a déjà quelques années que le principe OCP (Open Close Principle), principe à appliquer afin d'ouvrir son code de manière à autoriser les extensions futures, nécessite de faire des choix dans son design. Puisqu'il est impossible d'ouvrir complètement le code, il convient de choisir de manière stratégique quelles sont les parties qui risquent d'être étendue. Une fois ces parties décidées, il devient possible de prévoir l'ouverture de code nécessaire à la gestion de futures évolutions. Mais si il est impossible de prévoir dans quel sens les règles d'un jeu peuvent être modifiées, comment faire pour ouvrir son code de manière stratégique ?

Les références circulaires posent en plus un autre problème : celui du couplage du code. Dans l'idéal, on devrait pouvoir arranger les classes d'un projet en strates. Plus on descend dans les strates, moins on est abstrait. Bien évidemment, les classes d'une strate ne peuvent dépendre que des classes de la même strate ou d'une strate supérieure, jamais des classes d'une strate inférieure. Il y a bel et bien une relation hiérarchique entre les classes. Dans le système de règle d'un jeu de rôle, il est relativement fréquent qu'une règle particulière très concrète modifie une règle plus générale et plus abstraite. Dans ces conditions, il devient difficile de générer un diagramme de classe élimine les références circulaires.

Bien sûr, difficile ne veut pas dire impossible.

Allez, on réfléchit un peu

D'un point de vue personnel, j'utilise principalement deux systèmes de jeu : le système D20 mis en place par Wizard of the Coast comme support du jeu de rôle Dungeons & Dragons, et le système BASIC utilisé par les jeux publiés par la société Chaosium, éditrice entre autre de l'Appel de Cthulhu (dont je vous recommande chaudement la 6ème édition française, qui étonnamment est légèrement meilleure que la 6ème édition en version originale). Le système BASIC est très simple : en fait, la création des personnages est rationalisée et ne nécessite aucune règle particulière qui aurait un effet quelconque sur une règle plus générale. Chaque personnage est défini par un certain nombre de caractéristiques et un certain nombre de compétences (qui peuvent dépendre des caractéristiques). L'équipement peut fournir des bonus lors de l'utilisation d'une compétence. Au niveau social, un personnage est défini par son occupation, son métier et les cercles d'influences sur lequel il a un impact. En terme d'architecture logicielle, on a un système purement descendant : on va toujours soit du général vers le particulier, soit du particulier vers le général. Le seul point qui échappe à cette règle concerne le métier du personnage - le personnage choisi ses compétences en fonction de son occupation professionnelle, et son métier en fonction de ses scores de compétence. Toutefois, ce système peut quand même être modélisé simplement par strates.

En terme d'ouvertures, l'ensemble est aussi relativement simple : les options de jeu autorise les joueurs à utiliser des compétences non prévues, ou du nouveau matériel, ou à choisir une nouvelle occupation ; de manière générale, un nouvel élément de règle peut être symbolisé par une nouvelle classes à une strate donnée. Il est donc relativement aisé de prévoir de manière stratégique les strates de classes qu'il faudra ouvrir afin de permettre d'éventuelles extensions des règles.

Dungeons & Dragons se révèle très différent. Même si les règles de la quatrième édition ont été retravaillée pour être plus simples et plus accessible, de nombreux points peuvent poser problème à l'architecte logiciel.

Si on ne prends en compte que les règles générales, on se retrouve dans une situation proche de celle présentée dans les paragraphes précédents et qui concerne l'Appel de Cthulhu. Un joueur choisi sa race et sa classe, puis détermine les caractéristiques de son personnage et ses compétences, puis choisit ses talents, ses pouvoirs et son équipement. Dans l'ensemble, le système reste descendant et peut être arrangé en strate. Le problème est posé par une simple petite phrase résumant la philosophie des règles : le particulier prends le pas sur le général. De fait, il est possible d'imaginer un talent qui ne peut être pris que si une compétence particulière a été sélectionnée au moment de la création du personnage et qui modifie une autre compétence.

Exemple de talent : persuasif
Condition : entraîné en Intimidation
Effet : le personnage bénéficie d'un bonus de +2 à la compétence Diplomatie.

Ce talent affecte la liste des compétences tout en étant dépendante d'elle. Mathématiquement, on se retrouve avec une référence circulaire évidente (les compétences affectent le talent qui affecte les compétence).

En ce qui concerne l'ouverture, de nombreux problèmes se posent. Quel que soit la strate de classes considérée, elle peut avoir un effet quelconque sur une autre strate de classes. Ainsi, un objet peut avoir un effet sur les caractéristiques, les compétences, les pouvoirs à disposition, les talents, etc. Un talent peut de même avoir un effet sur l'équipement accessible, les compétences, les caractéristiques, les pouvoirs à disposition, etc. De plus, en considérant bien le système de règle existant, il est tout à fait possible d'imaginer que la définition même des caractéristiques et des compétences puisse être modifiée. C'est déjà arrivé : ainsi, une compétence particulière peut voir son cercle d'action élargi par de nouvelles règles.

On le voit, l'architecture logicielle à même d'encoder un tel système regorge de pièges et sera difficile à mettre en place. D'une part, elle doit luter pour préserver le plus possible la notion de système en strate qui est nécessaire à l'application correcte de plusieurs des principes fondamentaux de l'architecture orientée objet déjà discutés dans ces pages ; d'autre part elle doit aussi permettre un accès à toute donnée modifiable, puisqu'elle ne peut prévoir la variété infinie des modifications au corpus de règle pouvant subvenir. Et comme ces deux désidérata vont dans le sens contraire, il va falloir réfléchir pour trouver des solutions acceptables...

La suite dans quelques jours...

Commentaires

1. Le lundi, octobre 26 2009, 11:48 par 3DArchi

Bonjour,

Effectivement, il va falloir réfléchir pour trouver des solutions acceptables.

La première idée qui me soit venue à la lecture du billet a été : utiliser un paradigme logique et centrer le problème sur l'évaluation. En effet, qu'est ce qui peut m'intéresser in-fine : déterminer un comportement du personnage dans une situation donnée avec :

  1. Des faits : sa race, sa classe, ses caractéristiques, ses compétences, ses talents, ses pouvoirs et son équipement.
  2. Des règles : décrivent la façon dont les faits se combinent entre eux.

Ensuite, je vais vouloir évaluer une expression contextuelle. Lorsqu'une décision doit être prise (est-ce que le coup va porter ?), alors on construit une expression associée (probabilite_coup_atteindre(personnage, arme, destination)) et on l'évalue avec les règles définies et les faits existants. C'est le premier jet qui me soit venu.
On obtient l'ouverture par la possibilité d'ajouter des faits et des règles. Le moteur d'évaluation reste lui fixe et indépendant du contenu effectif des règles et des faits.
C'est probablement parce que je me suis laissé guider par le 'pourquoi faire' plutôt que par le comment et que l'objectif du billet n'est probablement pas là.
Au delà du paradigme logique, la piste intéressante ne serait-elle pas de séparer le descriptif - les règles du jeu - du dynamique - leur évaluation pour la prise de décision ?

2. Le dimanche, juillet 4 2010, 19:43 par Ekinox

Oh ! Grande déception ! Une faute d'orthographe dans un titre ! (on réfléchit)

Plus sérieusement, encore un billet qui laisse présager une suite encore plus intéressante !

Bref, encore merci pour ce blog :)

3. Le jeudi, juillet 15 2010, 10:24 par Emmanuel Deloget

Oups. 

Merci !

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet