• L'autre jour, je suis tombé sur la numérisation d'un supplément de Cassus Belli "Manuel pratique du Jeu de Rôle". Sa lecture est intéressante. Même si beaucoup de contenu est très poussiéreux et sent bon une pratique du JdR un peu dépassée, il y a toujours quelques infos à en retirer.

    Je voudrais revenir sur l'article "Comment sauver un scenario". Celui-ci explique comment se tirer d'une impasse dans laquelle la partie serait arrivée.
    Je pense que dans un système de joueurs classique, chacune des situations bloquantes décrites peut être évitée en amont.
    Pour cela, listons les 3 causes communes de ce genre de positions inextricables.

    « C'est la faute à pas d'chance »

    La première cause typique d'une impasse est lorsqu'un résultat d'un jet de dé bloque les PJs. Que ce soit pour être passé à côté de la perception nécessaire à la suite, ou plus directement pour avoir causé la mort d'un protagoniste (PJ compris).
    C'est l'un des risques avec les SRA Aléas. Pourtant, il est facile de ne pas tomber dans ces pièges.
    L'un des corollaires du principe "le système de jeu n'est pas important" est "le système de jeu ne sert qu'à aider le détenteur de l'autorité à prendre une décision qu'il ne pourrait déterminer seul".
    On en trouve souvent une reformulation sous la forme "ne jetez les dés que lorsqu'il est intéressant que vos PJs ratent".
    Bref, l'idée est de se dire que si un jet de dé peut conduire à une situation bloquante, il ne faut tout simplement pas le faire.
    Attention, on parle bien d'une action qui est censée réussir, mais qui en cas de pas de chance et d'échec critique va entraîner une fin précipitée de la séance. Donc, sont exclus les jets pour une résolution dont l'échec est intéressant ou au moins encore jouable, ainsi que ceux qui sont obligatoires de part la cohérence de l'histoire. Si ces derniers posent un problème, c'est qu'on est dans un des deux cas suivants.

    « Ça me paraissait marrant sur le coup »

    Il peut arriver qu'un joueur fasse faire une action stupide, ou même suicidaire à son perso. Ça va d'une accusation du Prince de la ville sans aucune preuve, à la charge d'une armée, seul. Peut importe le système de jeu, la cohérence de l'histoire peut pousser dans une impasse (mort, emprisonnement pour les 20 prochaines années, protagoniste qui s'échappe et effectue son rituel final…)
    Dans le système de joueurs classique, où le MJ est détenteur de l'autorité, ça se résout très facilement : c'est au MJ de reprendre le contrôle du personnage. Non, le noble éduqué ne va pas apostropher le roi, il sait qu'il doit passer par son chambellan. Non, l'aventurier non suicidaire et sans honneur ne va pas tirer l'épée devant la vingtaine de gardes. Non, l'équipe du SWAT ne va pas pousser l'otage dans l'eau pour le protéger des terroristes, du moins pas avant de lui avoir délié les mains et les jambes. Non, un geôlier consciencieux ne va pas laisser une cellule ouverte durant sa pause, juste car ça peut être amusant…
    Ceci peut être fait subtilement, surtout quand le joueur n'a pas conscience d'aller dans le mur. Du genre : "ton perso sait, par étiquette, qu'en rentrant dans la salle il doit se présenter aux officiers". Ou "ton perso sent que s'il continue à insulter les flics, il va se faire coffrer et passer la nuit au poste". Après, on peut aussi laisser le choix une fois la mise en garde faite. "Tu es certain de vouloir ramasser l'arme du crime à main nue ?" ou "Tu me confirmes que tu jettes un œil par la fenêtre alors qu'un sniper vient d'abattre ton collègue ?"

    En fait, ces conseils ne sont pas limités à se protéger contre les points de non retours. Ils permettent d'assurer la cohérence de l'histoire, de l'univers, et du canon de la fiction. Par exemple, ils concernent notamment la question de la différence entre les connaissances, les réflexes, l'expérience et le bon sens des personnages et ceux des joueurs, et qui est un point fondamental sur lequel je reviendrai un autre jour. Il est important de ne pas faire semblant de l'ignorer, et de savoir s'en saisir pour améliorer l'expérience de jeu de la table.

    Mais tout de même, par principe du jeu de rôles, toute action relativement cohérente devrait être possible, même si cela met les personnages dans une situation insurmontable qui non seulement n'était pas prévue par le MJ qui devra rebondir, mais rend caduque tout ce qu'il avait préparé derrière. Et malheureusement, cela peut arriver sans même que l'on puisse blâmer les joueurs.

    « Il suffisait juste de parler au majordome ! »

    Le dernier cas de blocage qu'un MJ peut rencontrer est lié à un scenario scripté (je précise car ils sont loin de l'être tous). Plus précisément, lorsque des scènes, des passages, des dénouements ont comme prérequis des actions précises et réussies des PJ.
    Le cas typique est celui d'une enquête qui nécessite des indices spécifiques pour être dénouée.
    Précisons tout de suite que ce n'est gênant que pour le MJ. En effet, si le but du scenario était d'empêcher une catastrophe, et que les PJs ont échoué en étant passé à côté de l'intrigue, ils pourront toujours poursuivre l'histoire avec la gestion des conséquences de cette catastrophe. Les joueurs n'ont même pas à savoir si c'était prévu, et si le scenario comportait des directives de jeu pour cet aspect.
    Mais avec l'hypothèse d'un MJ qui a besoin de se reposer sur le scenario durant toute la séance, il faut donc éviter les situations qui le ruineraient irrémédiablement.
    Et bien ceci, ça ne dépend pas des PJs, et ça s'anticipe, simplement en relisant bien le scenario.
    Il est assez facile de repérer (d'autant plus avec de l'expérience) les points défaillants, que j'appelle carrément erreurs. Par exemple, on ne devrait jamais trouver "quand les PJs feront ça", mais à la place des "si les PJs font ça".
    Dans les scenarios d'enquête, il existe des conseils spécifiques à base de redondance de pistes, mais il ne faut pas s'y limiter. Que faire si les persos ne trouvent strictement rien ? S'ils ne comprennent pas l'intrigue, alors l'intrigue doit venir à eux. Des PNJs, des lieux, des scènes, des conséquences… De nombreux éléments peuvent croiser leur route par hasard ou poussés par leurs diverses motivations. C'est ce genre de précisions qui sont nécessaires pour qu'un scenario soit un minimum correct.


    Bon, beaucoup d'évidences dans ces conseils. Mais au moins ils serviront pour ceux qui n'auraient pas pensé qu'au final, mieux vaut prévenir que guérir.


    votre commentaire
  • logo du web sémantique

    Le Web Sémantique est un concept ambitieux imaginé notamment par TBL (inventeur du web et directeur du W3C) concrétisé par plusieurs technologies.
    L'idée maîtresse est de faire un web des données au lieu d'un web des documents. Un web où l'on pourrait automatiquement agréger des données ou naviguer de l'une à l'autre, au lieu de devoir le faire à la main en lisant les documents.
    Exemple concret : si le GROG fournit une représentation sémantique de ses données, une librairie pourra donner une liste de livres qu'elle vend, en pointant vers les données du GROG. Une ville pourra référencer sémantiquement toutes les librairies qu'elle contient, et ainsi un habitant pourra, avec une simple et unique recherche, trouver si on vend quelque part dans sa ville (et où) la dernière extension de L5R.

    Techniquement, voici comment ça marche :

    La première brique est le RDF, norme du W3C pour modéliser des données.
    Le but est de pouvoir tout représenter, comme ça, dès le début, le modèle est évolutif, et les agrégations possibles. Pour cela, le modèle reprend le principe universelle de la phrase (sujet, verbe, complément) pour définir des triples, de la forme (ressource, propriété, valeur) et (ressource, propriété, ressource).
    Exemple :

       La ressource <http://www.legrog.org/jeux/livre-des-cinq-anneaux> est un <Jeu>
       La ressource <http://www.legrog.org/jeux/livre-des-cinq-anneaux> a pour nom "Le Livre des Cinq Anneaux"
       La ressource <http://www.legrog.org/jeux/livre-des-cinq-anneaux> est édité par <http://www.legrog.org/editeurs/alderac-entertainment-group>
       La ressource <http://www.legrog.org/jeux/livre-des-cinq-anneaux> est édité par <http://www.legrog.org/editeurs/edge-entertainment>
       La ressource <http://www.legrog.org/editeurs/alderac-entertainment-group> a pour nom "Alderac Entertainment Group"

    Le deuxième principe est d'utiliser des URI comme identifiants (assurant ainsi l'unicité, et dans le cas d'URL déréférençable, l'accès à plus d'information)

    La deuxième brique est le schéma RDF (RDFS), encore une norme du W3C, pour définir classes (sous classes), et propriétés (et divers autres infos).
    Par exemple : on définit la classe <Jeu>. On définit la méthode "a pour nom" qui à un <Jeu> associe un littéral. On définit la classe <Éditeur>. On définit la méthode "est édité par" qui à un <Jeu> associe un <Éditeur>.

    La troisième brique (et la dernière dont je parlerai ici, même s'il y en a d'autres) est SPARQL, toujours une norme du W3C définissant un langage de requête sur des données RDF, assez proche du SQL dans l'esprit.
    Exemple :

    select ?a, ?jeu WHERE ?a est_une <personne>, ?a auteur_de ?jeu, ?jeu categorie <MedFan>, ?a présent_à ?conv, ?conv date ?date FILTER ?date > 2015-01-01

    Cette (pseudo) requête va renvoyer la liste des auteurs de jeux MedFan (et ce jeu) qui étaient présent à des convs s'étant déroulées depuis le 1er janvier 2015.

    Encore plus techniquement, pour implémenter tout ça, il y a plusieurs façon de faire. La meilleure est de faire du full web sémantique :
    Un triplestore pour stocker le RDF (la base de donnée), une bibliothèque dans le langage de notre choix pour injecter et manipuler les triples, et une API SPARQL pour faire des requêtes (qui pourront parfaitement être utilisées par la couche business par exemple).

    Quels avantages par rapport à des bases de données relationnelles ?

    Interopérabilité :

    Vu que les données utilisent le même format (les triples : RDF) et réutilisent le plus souvent les mêmes vocabulaires (les schémas : RDFS), l’agrégation de données est immédiate.
    Ex : si un site expose une base des conventions rôlistes, un autre des salons littéraires, et un troisième des salon de jeux de sociétés, les participants pourront décrire à quels événements ils vont se rendre, et une personne pourra rechercher ceux qui ont au moins participé à un événement de chaque type.

    Évolutivité :

    Vu que le modèle permet de tout décrire, il n'est jamais un frein à des ajouts ou des enrichissements.
    Ex : Supposons que l'on manipule les 2 entités suivantes : Rôliste, et Association. Et la relation : un Rôliste est membre d'une Association. Et enfin, on a une requête qui renvoie la liste des membres d'une Association. Ça se fait bien avec une base relationnelle. Par contre, le jour où on se rappelle qu'une Association peut aussi être membre d'une autre Association, côté web sémantique, il suffit le modifier la relation membre pour dire qu'elle peut avoir une Association comme sujet. Et on ne change rien à la requête. Côté base relationnelle, il faut un nouveau champ, une nouvelle table de liaison, et la requête doit être revue.

    Recherche :

    Le modèle RDF a été pensé pour faciliter la recherche d'information. D'une part, l'héritage des classes permet de trouver des ressources qui correspondent à un type demandé. D'autre part le principe simple et léger de triples permet de rajouter des conditions très facilement, sans avoir à manipuler de multiples jointures.

    Visibilité :

    Lorsqu'on a réuni des données dans une base relationnelle, il faut développer des APIs, ou des pages web (qui ne pourrons généralement pas être réutilisées). Avec l'approche sémantique, plein de possibilités : export des triples en RDF (réutilisable directement, contrairement aux exports SQL), API SPARQL (rien à développer), affichage d'une ressource en XHTML ou RDF selon la requête, et dans le cas du XHTML enrichissement par RDFa (ce qui en plus augmente le SSO). Bref, quand on a fait un gros travail de récupération de données, et qu'on veut avoir de la visibilité, il vaut mieux utiliser les possibilités offertes par le web sémantique.

    Et pour les rôlistes ?

    Pour revenir à ce qui nous concerne, le but serait de structurer les données du Grog (pour les jeux, les auteurs et les conventions), et si possible celles d'Opale (les utilisateurs, les parties) de façon sémantiques, afin de pouvoir profiter de tous les avantages listés plus haut, à commencer par pouvoir répondre à Je cherche un jeu medfan humoristique et sans dé, dont un des auteurs a écrit au moins un scenario WoD officiel, Je cherche une partie avec ce jeu en one-shot, sur Paris et environs, et dont au moins un des autre PJs a déjà présenté son jeu amateur en convention et J'ajoute à mon calendrier toutes les conventions à venir, à moins de 100km de chez moi, et où il y a la possibilité de faire des murders.


    Pour information, j'ai déjà communiqué cette proposition aux sites concernés.


    2 commentaires
  • Aujourd'hui, nous allons traiter d'un sujet qui entraîne souvent polémiques et débats : les joueurs qui ne partagent pas leurs infos.

    Avant de voir des méthodes pour gérer/empêcher cela, quelques explications pour détailler pourquoi ce n'est pas forcément un comportement à éviter.

    Garder des infos fait partie du roleplay

    Dans un jeu de rôle (au sens commun du terme), les joueurs interprètent des personnages distincts. Ils ne forment pas un grand tout unifié qui prend ses décisions en commun. Si c'est cet aspect qui vous intéresse, regarder plutôt du côté des jeux coop, de Il était un fois, ou des jeux "à rôles" (comme Boule de Neige). Non, ici, les personnages ont leur conscience et leur libre arbitre propre. Ils peuvent être extrêmement liés entre eux, cela ne les empêche pas de garder des infos, volontairement ou non.

    En effet, on a tous un jour menti à nos parents. Cela ne veut pas dire qu'on n'ira pas leur porter secours au terme d'une quête héroïque s'ils se trouvent en danger... Les persos peuvent former la plus parfaite symbiose, on trouvera toujours des cas où le mensonge par omission s'impose (cela va de l'info dramatique dont on ne veut pas inquiéter son partenaire, à une chose honteuse que l'on veut cacher)

    Par ailleurs, l'information peut ne pas être transmise par simple oubli, que le personnage pense que c'est un détail sans importance, ou juste qu'il n'ait pas une mémoire d'éléphant...

    Dernier point, les PJs peuvent tous vouloir échanger des infos, mais ne pas en avoir la possibilité concrète (Par exemple, dans une enquête en huis clos, où les PJs font des petits groupes pour mener leurs investigations dans cette ambiance suspicieuse : ils ne peuvent pas se regrouper à la vue de tous pour échanger leurs infos en chuchotant).

    Donner des infos exclusivement à un joueurs augmente l'expérience du jeu

    Il existe de nombreuses raisons de donner des infos à un joueur, et de voir ce qu'il va en faire. On ne va pas parler ici du genre de scénarios type politiques ou intrigue où les persos des joueurs ont des objectifs individuels, ou vont devoir se tirer dans les pattes : ces cas là sont évidents.

    Une première raison est de laisser le RP particulier d'un perso s'exprimer. Par exemple le MJ peut amener un perso vantard à trouver le cadavre de l'enemi du groupe. Le joueur pourra faire mentir son perso en affirmant avoir tué en personne cet ennemi. Il sera d'ailleurs particulièrement intéressant de voir les différentes façons de traiter l'information pour chaque RP.

    Une autre raison est celle du téléphone arabe. Les persos, comme dans la réalité (sauf exceptions) ne sont pas infaillibles. Le MJ peut faire exprès de ne donner l'info qu'à un joueur pour voir comment se dernier la transmet au reste du groupe, au risque de faire des erreurs (ce qui sera évidemment géré par le scenar).

    Encore une raison pour finir : le MJ peut vouloir mettre en avant un perso (car exemple lorsqu'il est joué par une personne "timide" qui n'ose pas trop proposer des idées ou des actions, et qui reste écrasée par le reste du groupe). En lui donnant une information, et en lui laissant bien le choix dans la façon de la relayer, le perso va pouvoir s'exprimer, et arrêter de suivre passivement le reste du groupe. (Attention : il y a des joueurs qui aiment jouer passivement, ou du moins dans certains contextes, et qui n'apprécieront pas forcément cette initiative)

     

    Pour finir, on trouve également des cas évidents où l'information ne peut être partagée : lorsque les PJ sont séparés (kidnaping, PJ mis hors d'état de combattre, PJ ayant réussi un jet de percep mais (de façon RP) ne désirant pas réveiller le reste du groupe car il a entendu une chouette, recrutement individuel, commanditaire personnel...)

     

    En conclusion, permettre à certains PJ d'avoir une information, et leur laisser le choix quant à son traitement est loin d'être une erreur à éviter : cela fait partie du jeu, en plus de l'enrichir.

     

    Cependant, il y a des cas où l'on souhaite éviter cette situation (MJ débutant, groupe de joueur ne souhaitant pas ce fonctionnement, campagne nécessitant une cohésion surnaturelle, ou ne pouvant se permettre des "pertes de temps" dans le traitement des infos...)

    Voyons alors quelques moyens pour gérer ces cas.

    Le premier point est un traitement avant les premières parties : mise au point explicite aux joueurs, blindage des BG.

    Mais lorsque les parties sont commencés, et qu'on ne peut pas renvoyer de joueurs, il reste deux points où intervenir.

    Consolider le scenario

    Il s'agit de façon évidente de construire le scenario de façon à ce que les joueurs n'obtiennent aucune info individuellement.

    Pour cela, le premier des points à gérer est de ne pas trop laisser les personnages seuls. Donc, outre le fait de ne pas inscrire dans le scenario ce genre de situation (le noble du groupe est convoqué...), il faut aussi empêcher (le plus possible) les PJs de partir dans leur coin. Ce n'est pas évident, et cela nécessiterait un article complet. En attendant, parmi les premières astuces, citons l'autorité qui impose une mission ou une direction, des liens de BG "artificiels" ajoutés en cours de scenar pour resserrer les persos, ou le rythme soutenu qui ne laisse pas de place à l'éclipse discrète d'un petit malin.

    Masteriser collectif

    L'autre point à travailler est la façon de masteriser. L'idée est de faire comprendre que les infos ne seront pas secrètes, et concrètement, de les donner de façons collectives.

    Par exemple, le MJ peut refuser de prendre à part un perso. Si le joueur viscieux proteste "les autres PJs ne peuvent pas être au courant", répliquer "les autres joueurs sont suffisamment intègres pour ne pas mélanger ce qu'ils savent et ce que leur perso sait".

     

    Ainsi, selon moi, le spectre des infos non partagées ne devraient plus faire peur. Si l'on ne veut pas de ça à notre table, il est assez facile de l'éviter. Et si on accepte de l'intégrer dans nos parties, on obtiendra des séances plus difficiles à gérer, mais plus jouissives.

     

     


    votre commentaire


    Suivre le flux RSS des articles de cette rubrique
    Suivre le flux RSS des commentaires de cette rubrique