Avant d'examiner les raisons profondes, je mentionnerais une raison superficielle, mais néanmoins très importante à long terme, de réaliser ce projet : ça me botte. J'aime programmer, j'aime voir se batir, au bout de mes doigts, par le biais du clavier, cette forme d'oeuvre d'art utilitaire qu'est un logiciel et, plus encore, c'est un exercice intellectuel parmi les plus plaisants pour moi que le travail d'abstraction nécessaire pour formuler algorithmiquement le fonctionnement d'un jeu.
Je transpose tout ce que je vois et rencontre, même fugitivement, en informatique. Quand je vois un livre, j'entr'aperçois un document électronique, quand je retiens le numéro d'une page, je pense à un signet automatique et quand je sors un steak de mon congélateur, j'imagine un inventaire automatique par puces radios...
Mais cette raison est superficielle car elle vaut pour tous mes projets faisant intervenir l'informatique, de près ou de loin.
La raison profonde est un constat simple : je n'ai trouvé aucun logiciel lié au JdR qui ne soit que vaguement potable. Si vous êtes l'auteur d'un de ces logiciels, c'est le moment de m'insulter en votre for intérieur et de le prendre mal. Mais lisez quand même la suite, c'est une faveur que je vous demande.
Tous ont des qualités, et tous ont d'énormes défauts. Aucun n'allie toutes les qualités qu'on peut trouver, dispersées, dans les autres logiciels. Et les défauts sont loin d'être triviaux, le premier d'entre eux étant que rares sont les logiciels libres. Ce qui veut dire que si un auteur se désintéresse de son bébé (il ne joue plus, préfère donner du temps à autre chose qu'au suivi de son logiciel, etc.), le développement s'arrêtera : les bugs resteront en place et les évolutions possibles ou nécessaires seront impossibles (ou illégales).
Ce qui amène ensuite au défaut majeur suivant : presque aucun n'est extensible ou modifiable, c'est-à-dire que les données du programme y sont inscrites en dur (listes de compétences, coûts lors de la création de personnage, tables de résultats, etc.). Avec des logiciels non libres, du coup, on est lié à la bonne volonté du développeur lorsque le jeu évolue : nouvelles compétences ou nouvelles règles ne seront gérées que s'il trouve le temps et l'envie (ou la compétence, parfois) de les intégrer. Ceux qui sont extensibles, de plus, le sont parfois de façon fort peu ergonomique. Personne ne voudra saisir une liste de 150 équipement additionnels un par un dans une interface conçue pour faire un ou deux ajouts mineurs.
Et en plus de n'être pas extensibles, ils sont rigides : ils n'envisagent à peu près jamais de s'écarter des règles pour lesquelles le logiciel est codé. Hors un postulat de base de nombre de MJ est que les règles ne sont intéressantes que quand elles servent le jeu. Quand elles le gênent, presque tous les jettent temporairement aux orties. C'est un exemple d'informatique mal conçue, qui force l'utilisateur à s'adapter au logiciel en lieu et place d'un logiciel qui s'adapte à lui.
Je veux donc créer un ensemble de composants permettant de modéliser virtuellement tout ce qu'on manipule en JdR : les dés, les personnages, les objets, les cartes, le temps, les actions, etc.
Ils seront distrtribués sous licence libre, bien évidemment, et j'espère que le plus grand nombre de rôlistes informaticiens mettra la main à la pâte. Même de petites touches de-ci de-là sont importantes, mises bout à bout : un type de dé exotique, un graphisme ou même une idée d'interface différente. Ce sont les petits ruisseaux qui font les grandes rivières, comme on dit.
Le projet sera décomposé en modules, et leurs dépendances entre eux seront réduites au maximum : certains peuvent être utilisés séparés du reste (ex.: les dés).
À terme, un des but est de pouvoir gérer une partie de JdR ou de wargame, ou de n'importe quel jeu traité, de A à Z. Pour certains, cela pourra aller jusqu'à jouer entièrement sur ordinateur, notamment les wargames ; pour d'autres, cela voudra dire gérer tout ce qui est directement modélisable. Pour le JdR, par exemple, cela n'ira probablement jamais plus loin que les règles, le terrain de jeu restant dans la tête des joueurs et du MJ (mais on peut imaginer gérer les positions et les déplacements des personnages, par exemple pour une poursuite ou un combat…).
Quoiqu'il en soit, on devra toujours pouvoir décider de se passer d'une partie des fonctions présentes : même si quelqu'un a codé une interface et des graphismes pour jouer à un wargame donné sur ordinateur, on doit pouvoir se contenter d'utiliser le logiciel pour calculer les coups, les dégâts et les mouvements permis, et jouer ceux-ci avec de vraies figurines en plastique ou en métal.
Dans l'esprit du JdR, encore une fois, on devra de plus pouvoir enfreindre les règles et désactiver certains contrôles ou ajustement automatiques. Et avant cette « extrémité », tous les paramètres devront pouvoir être ajustés simplement, et aucun ne devrait être codé en dur, sinon pour sa valeur par défaut. Ces logiciels devront être des outils au service du joueur, pas des carcans.
Je vais me concentrer d'abord sur le JdR, en ayant toujours en tête l'ouverture future sur d'autres jeux. D'abord les dés, puis la création de perso, et enfin la gestion des résolutions d'actions et des systèmes de jeu (par ex. les vitesses de course, les blessures, l'expérience, etc.).
Il y aura problablement tout de suite un module pour gérer tout ce qui a des caractéristiques, module qui
sera pratiquement utilisé partout. Pour aborder brièvement les aspects techniques, il semblerait naturel
qu'un objet Vaisseau ayant comme caractéristiques Blindage et
Vitesse soit représenté par un objet ayant comme données membres ces deux caractéristiques,
mais cela le rendrait peu extensible. En effet, lorsqu'une règle, optionnelle ou pas, ajoutera la
caractéristique Passagers, il faudra modifier l'objet, recompiler le composant et tous les
logiciels y faisant appel. Si l'objet possède plutôt une donnée membre qui est une liste dynamique de ses
caractéristiques, leur nombre et leur type peut éventuellement varier sans devoir toucher au logiciel ; on
ne change pas le code, mais les données qu'il manipule.
Comme je suis désireux de mettre au point des structures de données et des algorithmes qui permettront de représenter parfaitement et efficacement toutes sortes de jeu, je suis preneur de descriptions même très longtemps avant d'envisager vraiment de coder les jeux concernés. L'idée est que même si je ne code pas tout de suite, connaître tous les types de règles et de systèmes sur lesquels je vais tomber (ou sur lesquels d'autres que moi plancheront, dans l'idéal) me permet de préparer le terrain et de coder les briques de base de la façon la plus générique possible (cf. spécifications).
Une fois le JdR en grande partie opérationnel, ajouter les wargames ne devrait pas être difficile : si ce n'est pas déjà fait, il faudra rajouter la gestion de l'espace et des distances, tout le reste n'étant pas fondamentalement différent, en terme de technique, du JdR. Des personnages tentent des actions, se déplacent, infligent des dégâts et en reçoivent, etc.
© 2005 Pierre THIERRY