Enfin, nous allons boucler cette suite d’article avec un point de vue plus terre à terre pour mieux comprendre le lien entre les besoins et les enjeux.
Pour conclure le propos
Nous arrivons au mot de la fin. Il n’y a donc aucune hiérarchie de bien ou du mal, de mieux, de meilleur entre différentes façons de voir un système de jeu.
Mais de toute façon, c’est un pamphlet pour écrire des jeux de rôle twitter !
Histoire d’éviter ce genre de commentaire débile et de devoir y répondre, je prends les devants et j’explique.
Comprenons nous bien, en informatique, si avec un code de 10 lignes, on en fait autant au résultat qu’avec un code de 5000 lignes, c’est mieux. Le code sera plus facile à faire évoluer, à comprendre, à maintenir, … il sera moins lourds à l’exécution et offrira sans doute un résultat plus performant. Mais dans certains cas, les 5000 lignes seront sans doute nécessaire… ou peut-être 4999.
Alors, il n’y a pas de mauvais jeux ?
En fait, si, mais très peu… Trop formaliser va pousser les joueurs à reprendre leurs libertés sur l’interprétation des règles les moins satisfaisantes, autant se limiter aux points sur lesquels les enjeux sont les plus forts. Mais ça ne fera sans doute pas une mauvaise mécanique pour autant une fois simplifiée par les joueurs.
Le vrai risque, là où on va tendre vers la conception d’un mauvais jeu, c’est dès lors qu’on va piocher des « trucs qui marchent » à droite ou à gauche pour tenter des les amalgamer dans son système. Elekasë en est une belle illustration. La somme des mécaniques qui marchent ailleurs ne fait pas forcément un moteur de jeu optimal et performant.
