|
Alpha & Oméga
|
Ce fil à pour but d'exposer un peu une idée à moi, pas trop nouvelle mais que je me sens de plus en plus prêt à amorcer ces derniers mois et de récolter quels que retours et surtout idées d'améliorations.
Le but est un jeu, ou plutôt un logiciel de support de jeu, destiné à permettre des parties de jeu de rôle à l'ancienne, mais via le net. Un peu d'historique Pour aider à comprendre j'écris un peu comment l'idée est venue, mais vous pouvez sauter ce paragraphe si vous êtes pressés A la base cette idée est issue d'une discussion sur JoL avec d'anciens rôlistes qui comme moi, regrettaient de ne plus faire de jeu de rôle sur table, très différent au final du jeu de rôle qu'on trouve dans les jeux en ligne, mais ne pouvaient plus le faire pour cause de disponibilités réduites ne permettant plus de bloquer une nuit complète pour se déplacer, s'intaller autour d'une table pendant 6 heures et avancer un scénario, à cause des obligations que tout adulte a et qui font que ce n'est pas du tout aussi facile que quand on est par exemple étudiant. Nous nous sommes donc décidés à essayer de faire des parties de jeu de rôle à l'ancienne, mais via le net, avec l'utilisation d'outils de communication comme Skype et IRC. Plusieurs parties ont eu lieu, avec un maitre de jeu, une ambiance assez conviviale et d'assez bon résultats. Même si l'usage du net à cependant gêné certains aspects, les outils ont amenés des possibilités qui n'existent cependant pas IRL assez motivantes, comme la possibilité au DM de donner des informations secrètes à un joueur sans que les autres puissent s'en apercevoir, au groupe de joueurs de se séparer en deux, menant deux actions différentes en deux lieux différents sans que le DM ait à choisir un des deux groupes et faire attendre l'autre, etc. L'exemple majeur qui m'a montré l'utilité et l'intérêt de ceci fût dans un scénario d'intrigue où les joueurs avaient tendance à comploter dans leur coin certains autres joueurs, la possibilité d'avoir plusieurs canaux de discussion, un par sous-groupe, assurant alors une totale discrétion. Cependant, les outils disponibles se sont avérés limités sur certains points: à cause de cette séparation, espionner obligeait le DM a recopier tout ce qu'il voyait dans un canal dans l'autre, changer de lieu ou de sous-groupe obligeait à des manipulations technique pour changer de canal... etc. Un principe intéressant donc, mais pas très bien desservi par le manque d'outil adapté ... d'où l'idée d'en faire un qui le soit. |
29/09/2010, 12h04
|
Un jeu de rôle sur table... virtuelle.
| Suivre |
|
|
Partager | Rechercher |
|
Alpha & Oméga
|
Objectifs de l'outil de jeu
Le but est de fournir un outil permettant de faire des parties de jeu de rôles à l'ancienne, non pas en fournissant un moteur de règles pour tel ou tel jeu, ce qu'un maitre de jeu peut très bien gérer lui-même avec un simple outil de lancé de dés, mais plutôt une gestion des canaux de communication entre les joueurs/maitres de jeu pour donner une représentation réaliste de ce qu'un personnage peu voir ou entendre sans que les participants aient à lutter avec la technique. Les points que je voudrais impérativement que l'outil permettre sont donc: - Forte accessibilité: aucune connaissance technique poussée ou gros PC ne doit être nécessaire pour l'utiliser - Cartographie: un maitre de jeu doit pouvoir tracer une carte simplifiée des lieux relatifs à son scénario en moins d'une heure pour les cartes les plus complexes, les enregistrer et les partager avec ses joueurs - Gestion du positionnement des personnages: en cours de partie, les joueurs et le maitre de jeu doivent pouvoir positionner leurs personnages visuellement sur la carte et les déplacer en respect avec les données de la carte - Gestion des éléments perçus: l'outil doit pouvoir évaluer à l'aide de la cartographie ce qu'un personnage peut voir ou entendre des actions des autres personnages en fonction de leur position respective et des obstacles présents - Imagerie: Le maitre de jeu doit pouvoir superposer un dessin des lieux à ses cartes s'il le désire, et attacher/retirer des images visuelles à des positions sur la carte quand il le désire |
|
29/09/2010, 12h05
|
|
Je pense que tu dois connaître, mais sait-on jamais, connais-tu Rolistik ? Je suis d'accord qu'il n'est pas parfait par contre il est libre et donc modifiable pour correspondre plus à vos besoins.
J'ai cherchais il n'y a pas longtemps à monter ce genre de projet, j'avais pas mal d'idées en tête et mes camarades me proposaient quelques (bonnes) idées qui seraient bien d'implémenter. Le soucis c'est que niveau développement logiciel je n'ai aucune expérience et c'est plus ou moins un projet en sommeil que je réveille de temps à autre car Rolistik nous convient bien au final même si il n'est pas parfait. |
|
29/09/2010, 12h16
|
|
Alpha & Oméga
|
Rolistik est un bon outil, cependant, il a un objectif un peu différent de ce que je veux faire avec cet outil.
Rolistik tente de fournir tous les outils qui existent sur table (dés, dessins à main levée, caches...), alors que le projet que j'ai en tête, se concentre plutôt sur le fait d'apporter quelque chose qui n'y existe pas, sans changer empêcher tout le reste (mais dans forcément le gérer: d'autre outils, dont Rolistik, peuvent être utilisé). Ce quelque chose, c'est la gestion physique de la perception des personnages: gérer automatiquement, à partir de la position des personnages et de la cartographie faite par le maitre de jeu, ce que le personnage voit et entend à un moment donné. C'est un élément qui est amorcé dans NwN 1 et 2, mais très imparfait: on ne voit pas un lieu qu'on a pas exploré, on entend pas un chuchotement qui est fait trop loin, on n'entend pas un personnage dans une autre zone.... cependant on voit à travers une porte fermée si on a déjà exploré le lieu derrière, on entend à travers les murs, on entend pas dans la zone à côté même si cette zone n'est séparée par aucun obstacle physique et que les personnages ne se situent qu'à deux mètres, etc. De plus NwN n'est pas fait pour jouer "comme sur table": la cartographie prend beaucoup trop longtemps (des heures pour une seule pièce parfois), les forts graphismes laissent moins de place à l'imagination, et le maitre de jeu est lui-même limité par le moteur de jeu au lieu d'être omnipotent... sans compter qu'il faut un bon PC, ce que tous les rôlistes pur et dur n'ont pas. En fait, je vois cet outil et Rolistik comme complémentaires: on peut ouvrir les deux pour une même partie en ligne, utiliser Rolistik pour les jets de dés, les tracés à main levée, les discussion hors-personnage, et ce logiciel pour les actions RP et la gestion des déplacements/lieux/cartes afin de profiter de cette fonctionnalité que j'essaie de développer ici |
|
29/09/2010, 12h49
|
|
Légende
|
C'est une idée intéressante que d'autres ont effectivement eue aussi. Un jour on m'a dit "oui mais non ça sera pas bien parce que patati patata". Mouais. Je pense que ça reste faisable.
Toute la difficulté sera de déterminer quelles sont les features communes à tous les jeux auxquels tu voudrais jouer avec un tel outil, quelles features annexes peuvent être implémentées sans que ça gène les jeux qui n'en ont pas besoin, tout en se limitant pour rester un jeu "papier crayon" libre plutôt qu'un MMO abstrait. Voici quelques idées qui me viennent là comme ça en réponse à ton post. - On a un espace de jeu potentiellement infini dans lequel évoluent les joueurs. - Le MJ peut à tout moment dessiner sur cet espace pour faire joli, ainsi que placer des murs. Un peu comme quand un MJ "papier crayon" prend un papier pour griphoner un vague plan pour montrer aux joueurs l'agencement des lieux. - Le MJ peut dézoomer pour avoir une vue globale de la partie, ou de l'endroit qui l'intéresse. Facile à implémenter si les dessins du MJ ne sont composés que de quelques traits vectoriels. - Les paroles des joueurs sont locales. Si le joueur A dit "Bonjour les enfants !", les joueurs proches voient une petite bulle au-dessus du joueur A avec marqué "Bonjour les enfants !", les joueurs plus loins voient une bulle avec marqué "Bauur é fan !", et les joueurs qui sont trop loin ne voient même pas la bulle. Avec de la technologie moderne, les bulles sont remplacées par les joueurs et leur casque-micro. - A tout moment le MJ peut "drag & drop" un joueur pour le téléporter ailleurs. Ca permet au MJ de changer de décor, de faire des ellipses... - Le MJ peut changer la vitesse de déplacement des joueurs à volonté. Ca permet de simuler un moyen de transport ou une blessure. Bien sûr comme de toute façon le MJ peut téléporter les joueurs, il peut à tout moment dire "non en fait tu peux pas aller là parce que tes trois jambes ont brûlé tout à l'heure", et remettre le joueur là où il est sensé être. Le fait de pouvoir changer la vitesse de déplacement du joueur n'est qu'un outil qui peut favoriser l'immersion puisqu'alors le MJ n'aura pas à systématiquement dire aux joueurs qu'ils vont trop ou pas assez vite, ou à les déplacer à la main. - Rajoutez à ça un système permettant aux joueurs de communiquer anonymement à leur MJ pour tout ce qui est question sur l'univers, tentative de manipulation secrète, ou, d'une façon générale, tout ce qui n'est pas gérable dans le modèle ci-dessus. Tout ça permet, en quelques traits du MJ sur le terrain, de gérer automatiquement les déplacement et les groupes, et ainsi de gérer automatiquement les trahisons et compagnie. Mais il ne faut pas aller trop loin. Par exemple, on pourrait se demander comment, dans ce modèle de jeu, les joueurs pourraient se parler par télépathie. Je propose que le joueur A dise au MJ (dans un canal privé) "je dis télépathiquement au joueur B qu'il est moche" et le MJ dit au joueur B (dans un autre canal privé) "tu entends A te dire que t'es moche par télépathie". Je crois qu'il ne faut pas essayer d'implémenter ce genre de détails autrement. Evidemment, dans un jeu où on est des entités divines qui n'ont pas de présence physique et donc pas de position dans l'espace, ce système ne servirait à rien... Cet exemple montre qu'il n'y a pas de point commun à tous les jeux de rôle et qu'il faut faire très attention dès qu'on implémente une feature, car elle va peut-être réduire le champ des possibilités... Mais pour résumer : avec un espace infini, griphonable par le MJ, dans lequel peuvent se déplacer les joueurs, les MJ pouvant forcer leurs déplacements, et avec un système de voix locales et de canal privé pour parler au MJ, je pense qu'on a déjà une bonne partie de ce dont on a besoin. Et surtout, ce n'est techniquement pas très éloigné d'un paint collaboratif, et ça on sait que ça existe et que ce n'est pas très dur à programmer. Donc ça serait un outil tout à fait faisable. Après on peut envisager des bonus genre des langages de script pour édicter des règles de combat, afin de gérer des statistiques des joueurs et de lancer les dés automatiquement. Mais je pense que c'est loin d'être la priorité. Un exemple de script : Code:
function tour_de_combat(a, b) =
let perdant =
if a.force > b.force then b else a
in
if perdant.dexterite < 2d10 then
begin
perdant.vie <- perdant.vie - 1;
afficher (perdant.nom, " s'est pris un coup")
end else
afficher (perdant.nom, " a esquivé")
 Est-ce qu'un langage de script est facile à intégrer, me direz-vous ? Pour moi oui, programmer des interpréteurs ou compilateurs est mon dada, je fais ça très vite. Edit : bon je m'aperçois que j'ai fait un post très décousu et que rolistik implémente certainement une bonne partie de ces idées. Je m'en excuse, d'habitude je fais plus d'efforts quand je post, mais là j'ai pas le temps 
|
|
29/09/2010, 13h10
|
|
Roi / Reine
|
Très intéressant, faire des parties de donjons et dragons *_*
Malheureusement je ne pourrait t'être d'aucunes utilités, enfin je peut t'encourager si tu veux 
|
|
29/09/2010, 14h06
|
|
Alpha & Oméga
|
Ca perds tt l'aspect chaleureux du jdr Table.
Un bon Bar tranquille, un bon Gros pichet, qq verres, et spartit pour l'aprem. Je trouve ca super froid, le teampseak & consorts. Y'a cette barrière a franchir. Pas besoin de vraiment dessiner, c'est trop long et fastidieux. Au besoin juste croquer des passages spécifiques. Tout l'intérêt du jdr papier, c'est justement tout laisser le travail a l'imagination. Moins au pose de choses, plus il y a de liberté d'action. |
|
29/09/2010, 14h13
|
|
Alpha & Oméga
|
DooMeer, ce que tu dis est assez intéressant. Toutefois dans le but de gérer dynamiquement la perception des personnages, je pense qu'il est nécessaire que le MJ fasse le plus gros de sa cartographie avant la partie.
Pour le système de combat, cela dépasse le cadre de ce que j'essaie de faire pour le moment. Je ne cherche pas à faire un moteur de règles de compétences/combat/jets opposés, mais plutôt pour le moment un système de représentation graphique cohérent de ce que chaque personnage peut capter en fonction de sa position et de la topologie des lieux propres au scénario du MJ Ce qui me mène un peu à ceci: Idée d'approche Puisque la majorité des fonctionnalités (déplacement, positionnement, perception) repose sur la cartographie du maitre de jeu, je pense que le principal point qui déterminera la forme de l'outil est justement comment on trace une carte et comment cela impacte le jeu des joueurs. Par souci de simplicité de gestion et de tracé pour le maitre de jeu, la méthode la plus simple de tracé me semble le quadrillage: chaque zone serait donc un grand quadrillage ou chaque case représente un espace suffisant pour contenir soit un personnage, soit un "obstacle" inclus dans la carte. 1- Définition d'une case De manière interne, pour le moteur de jeu, toute case contiendrait un lot de caractéristiques qui serait la suivante: - Le facteur d'isolation pour chaque type de "perception" : Il s'agit en gros de dire à quel point l'obstacle va amoindrir la capacité d'un personnage à capter ce qui se situe derrière. - Le facteur de pénalité de mouvement Il s'agit de dire combien de facteur de mouvement les personnages doivent avoir pour entrer dans la case - Un jeu de "transitions d'états" Il s'agit de la capacité pour une case de changer de nature en fonction d'une action d'un personnage Quelques exemples: Une case occupée par un mur: - isolation visuelle: 100% (on ne voit pas pas à travers un mur) - isolation auditive: 90% (on peut entendre à travers un mur, mais c'est difficile) - pénalité de mouvement: 100 (aucun personnage n'a assez de mouvement pour entrer dans un mur) - transition: aucune Une case inoccupée: - isolation visuelle: 0% (on voit sans problème à travers un nombre illimité de cases inoccupées) - isolation auditive: 2% (un personnage ne va plus rien entendre une conversation normale à plus de 50 cases inoccupées) - pénalité de mouvement: 1 - transition: aucune Une porte fermée: - isolation visuelle: 100% - isolation auditive: 50% - pénalité de mouvement: 100 - transition: "ouvrir la porte" => la case devient une "porte ouverte" Une porte ouverte: - isolation visuelle: 0% - isolation auditive: 2% - pénalité de mouvement: 1 - transition: "fermer la porte" => la case devient une "porte fermée" Le maitre de jeu disposerait d'une palette de type de cases qu'il pourrait déposer sur le quadrillage contenant les définitions les plus basiques, il pourrait aussi en créer d'autres en saisissant de nouvelles valeurs, en fonction de ses besoins, comme par exemple: "nouveau type de case > brouillard" : - isolation visuelle: 20% (on ne voit pas pas plus de 5 cases dans le brouillard) - isolation auditive: 2% - pénalité de mouvement: 1 - transition: "sort de vent" => la case devient un "espace inoccupé" Durant la partie, une case peut se voir ajouter 2 types d'éléments dynamique: - un personnage, si un joueur y positionne le sien ou si le DM en pose un - une image épinglée par le maitre de jeu (l'image peut-être annotée) - un son décrit par le maitre de jeu 2- Gestion de la vision: En jeu, les cases de la carte apparaitront en différente teintes selon le % total d'isolation visuelle des cases situées entre le personnage et la case en question: - Case visible (pas plus de 80% d'isolation): La case apparait en blanc, tout personnage ou image située dans la case sont pleinement révélés au joueur qui contrôle ce personnage. Il voit aussi les annotations du maitre de jeu. - Case à faible visibilité (entre 80% et 99% d'isolation): La case apparait en blanc terne, tout personnage situé dans la case est montré, mais sans son identité ni son portrait... une image située dans ce lieu apparait en fonction du choix du MJ quand il l'a épinglée soit floutée, assombrie ou alors carrément remplacée par une autre de son choix - Case invisible: La case apparait noire si le joueur ne l'a jamais vue et grise sinon (il sait la topologie du lieu, mais il ne la voit pas véritablement: il s'en souvient juste). Aucun personnage ou image située dans une telle case n'apparait au joueur 3- Gestion de l'audition Voilà en gros le principe qui pourrait être appliqué pour l'audition: Tout dialogue écrit par un joueur ou son décidé par le MJ se "propage" en perdant de la netteté dans les cases adjacentes. Il commence avec une netteté de 100% dans sa case de départ et perd un % égal à l'isolation de chaque case qu'il traverse. Si un son arrive dans une case par différents cheminements, c'est celui qui termine avec le plus de netteté qui gagne (par exemple quelqu'un parle derrière un mur, mais il porte ouverte juste un peu plus loin dans le dit mur: pour arriver à la case du joueur soit le son traverse le mur avec une pénalité de 90%, soit passe par la porte et finit avec 8% de pénalité... c'est donc un son de netteté 92% qui arrive au personnage au final car on compte la plus petite pénalité) Dans l'interface de dialogue RP, un joueur voit tous les écrits "auditifs" (dialogue ou son déposé par le MJ) qui atteignent la case de son personnage avec au moins 1% de netteté. Toutefois, en dessous de 50% pour un dialogue, des lettres de l'écrit sont tirées au hasard pour être masquées: par exemple si la netteté d'un dialogue est de 25%, la moitié des lettres du dialogues seront masquées au hasard pour représenter le fait que le personnage entend assez mal ce qui se dit. Le joueur peut faire défiler un curseur dans la fenêtre de dialogue, une flèche s'affiche alors sur son personnage pour indiquer dans quelle direction il a entendu le son ou dialogue. Si ce son ou dialogue venait d'une case visible, elle est affichée en surbillance. Pour les dialogues, dans le cas particulier où il vient d'une case clairement visible, la fenêtre de dialogue afficherait par souci de simplicité le nom du personnage ayant prononcé le dialogue afin d'avoir à faire défiler le curseur autrement que dans quelques cas spécifiques. 4 - Imagerie Les cases étant définies par propriétés, elles peuvent être source de confusion sans d'avantage de détails: par exemple, un joueur ne peut pas savoir si il ne voit pas derrière une case parce que c'est une porte, un mur, un rocher ou autre chose sans plus d'indication. C'est pourquoi la dernière étape de cartographie serait pour le DM de dessiner ou fournir une image qui s'affichera derrière le quadrillage de carte, en transparence, et qui donnera une représentation simplifiée des lieux. Le deuxième mécanisme d'imagerie serait ensuite les images épinglées dans des lieux, souvent représentant un détail du décor ou un objet particulier... chaque image peut contenir une description ou une image alternative en cas de mauvaise visibilité, mais aussi une règle d'affichage (j'en parlerais plus loin) Enfin, le troisième mécanisme d'imagerie seraient juste les portraits des personnages. |
|
29/09/2010, 14h15
|
|
|
Ce n'est pas faux Ataraxie, mais de nos jours on se fait pas mal d'amis via internet qui habitent à plus de 100 Km les uns des autres, de tels outils permettent de les rassembler autour d'une activité qu'ils aiment et veulent pratiquer ensemble. Pour le pratiquer régulièrement je peux dire que ce n'est effectivement pas la même ambiance et que c'est plus dur de rester concentré sur la partie en court, mais ça reste une expérience conviviale et agréable.
|
|
29/09/2010, 14h18
|
|
Roi / Reine
|
Le problème c'est que jouer avec des gens à ce type de jeu est compliqué.
 Ah, les jeux avec un livre où l'on faisait sont histoire ou avec ses personnages de plombs *_* (J'ai que 15 ans et j'y est beaucoup joué. Comme quoi... )
|
|
29/09/2010, 14h18
|
|
Alpha & Oméga
|
Zengaluh n'a pas tord, et puis il ne faut pas oublier l'historique de cette idée:
C'est une idée faite pour ceux qui ne peuvent malheureusement plus trouver le temps IRL de se déplacer et de verrouiller un grand nombre d'heure libres pour faire une partie sur une vraie table et doivent se contenter pour faire du "vrai" jeu de rôle de communication online, plus facilement accessible à n'importe quel moment. Dans ce cadre, je suis d'accord qu'on perd pas mal de l'aspect convivial, mais on y peux rien... tout ce qu'on peut faire c'est de voir si on ne peux pas en retirer quelques avantages en compensation, et c'est là que ce projet intervient, en proposant une "feature" impossible en partie sur table: la gestion de la perception des personnages, qui peut-être un vrai plus dans pas mal de scénarios. |
|
29/09/2010, 14h27
|
|
Légende
|
Je réponds à l'idée de Moonheart.
Je suis entièrement d'accord avec ton prélude, il faut écarter le système de combat dans un premier temps, un bon jdr n'en a pas besoin de toute façon. C'est d'ailleurs pour ça que je proposais de l'avoir sous forme de système de scripts à faire écrire par le MJ (ou sous forme de bibliothèque) : ça ne fait pas partie du noyau de l'outil, ce sont des modules à part. Par contre je ne suis pas convaincu par l'approche par case, pour plusieurs raisons. D'abord ça implique d'avoir un monde carré et moins organique qu'avec une approche où le MJ dessine à la Paint. C'est franchement dommage pour un outil sensé se rapprocher de l'esprit papier crayon. Ensuite techniquement ça limite la taille du monde, puisqu'il faut stocker chaque case en mémoire. Ca prend donc de la place. Enfin et surtout, ça veut dire que le MJ doit remplir les cases une par une, ce qui est fastidieux. Le MJ veut faire un mur d'un point A à un point B ? Il doit modifier toutes les cases entre A et B. Avec des cases plus grandes, c'est moins fastidieux, mais encore moins organique et on ne peut plus faire des petits objets. Le choix de l'échelle est donc lourd de conséquences. C'est pourquoi je propose à la place un système entièrement vectoriel. On ne place pas des cases mais des lignes, dont on ne stocke que le point de départ, l'arrivée et les propriétés comme la couleur. Ou alors on peut même utiliser des courbes de Bézier, c'est très simple à programmer. Ca résout tous les problèmes que j'ai énoncés plus haut : - le MJ peut dessiner à la souris, et le programme stocke chaque point du trajet du curseur pour en faire une courbe ; - pour faire un mur entre A et B, le MJ trace un trait entre A et B, c'est tout ; - on ne stocke que les traits, pas l'espace vide, donc le monde est presque infini ; - pas de problème d'échelle dans un monde vectoriel, puisqu'on peut zoomer et dézoomer à l'infini, ça ne change rien. Evidemment, le calcul de la perception est un peu plus complexe à réaliser en vectoriel, mais ça reste possible. Après tout, c'est fait dans tous les FPS aussi bien pour le son que pour optimiser le nombre de polygones dessinés, et c'est dans un espace 3D alors que nous on se limite à un plan 2D a priori (pour faire des étages, on fait plusieurs plans). Par contre, tes propriétés des cases pour la propagation du son et de la lumière sont intéressantes. On peut dans un premier temps les appliquer aux traits. Un mur ne propage pas la lumière, une vitre sale la propage mais pas entièrement. Le son est bloqué par certains types de traits, etc. Alors ok, ça ne permet pas de modéliser du brouillard. Si vraiment, VRAIMENT t'en as besoin, et bien il suffit de rajouter des zones fermées sous forme de polygones. Mais pour le brouillard on peut s'en sortir beaucoup plus simplement : le brouillard s'applique en général à toute la zone donc il suffit d'augmenter la vitesse avec laquelle la perception diminue avec la distance  Pour les portes ta proposition est du domaine de l'astuce et je pense que ça n'a pas sa place ici. Perso je me passerais du système de transition. Si vraiment le MJ veut gérer ça il peut modifier la map en temps réel quand les joueurs ouvrent et ferment des portes. De toute façon il faut présenter la map comme un ensemble de blocs, chaque bloc étant un ensemble de traits vectoriels, et le MJ peut bouger, supprimer et ajouter des blocs en temps réel. |
|
29/09/2010, 15h06
|
|
|
Au lieu d'un système de case j'avais pensé à un système d'aimant que l'on peut activer permettant ainsi de tracer des lignes bien droites et éventuellement placer les joueurs.
Dans ma petite tête j'avais pensé un peu comme un MMO, une interface tchat avec onglets où l'on pourrait créer ses propres canaux en y invitant qui l'on souhaite et avec un canal commun à tout les joueurs. Quant aux cartes plus ou moins la même idée d'onglet ou l'on attribuerait des autorisations définies par le MJ ou un joueur pour faire des apartés. Et tout un panel d'outils plus ou moins important en fonction du statut de l'utilisateur, MJ ou joueur. |
|
29/09/2010, 15h28
|
|
Alpha & Oméga
|
Ton systeme me fait penser au webgame que je developpe depuis pas mal de temps mais avec moins de parametres.
J'ai deja mis en place la possibilite au joueur de creer ses propres cartes en case par case comme tu l'as detaille, avec un choix de texture, decor et ressource donnant des malus ou bonus suivant le type de perso. Genre une sirene n'aura aucune penalite de deplacement sur l'eau. Et sur le desert, toutes les races auront 20 points de penalite. Et si tu fous une colline sur cette meme case, une seconde penalite de 20 s'appliquera au mouvement sur la case. Par contre comme mon systeme prevoit la creation de planete pouvant aller jusqu'a 1000x1000 (soit 1 000 000 d'enregistrements), avec un plan de 20x20 affiche a chaque fois, c'est sur que tout remplir peut etre galere. Mais j'ai allege la creation avec des raccourcis claviers permettant de poser la texture au survol de la souris sur la case ou par simple clic. J'ai aussi implementer le systeme de brouillard de guerre, genre un arbre cache les cases qui sont derriere lui. Mais ca reste du oui ou non, parce que calculer des % suivant l'angle de vue de chaque joueur, ca peut etre casse gueule. J'ai meme foutu un systeme de fuseau horaire pour que l'heure de la journee ne soit pas la meme sur toute la planete. Et en ce moment j'decouvre les sockets qui me permettront de faire les systemes similaire au MMO a integrer a mon jeu. Bref y a bcp de moyen de realiser ce que tu souhaites mais faut y aller petit a petit si tu veux pas te fourvoyer. Et parfois accepter la simplification car certaines idees peuvent etre casse gueule. |
|
29/09/2010, 16h24
|
|
Alpha & Oméga
|
DoomMeer, je pense que tu n'as pas très bien compris l'idée de la cartographie comme je la vois.
Ce que je propose pour le tracé de la carte, ce n'est rien d'autre qu'un Paint où au lieu d'avoir une palette de couleurs, tu as une palette de propriétés: tu cliques dans la palette pour sélectionner "mur", tu cliques dans les outils sur l'outil "trait", "brosse" ou ce que tu veux, puis tu traces la limite du mur. Au final, ce n'est donc pas plus fastidieux de tracer une carte que de dessiner sous Paint, mais certes, le "quadrillage" que je propose est un peu gros... La raison en est simple: cela facilite de beaucoup tous les calculs, et donc la légèreté de l'outil, si on peut considérer que les personnages n'occupent qu'une seule case, car sinon il faut se poser plein de questions comme "et s'il ne voit que 11% des pixels situés à droite de l'espace occupé comme le personnage?" ou encore "qu'est-ce qui compte pour la netteté d'un son: la bordure ou le centre de l'espace émetteur?" Le quadrillage n'a de toutes façons pas de vocation à être affichée, car il est juste une simplification pour le calcul de perception et de déplacement... ce que les joueurs voient à l'écran, c'est l'image de fond appliquée à la carte, qui se révèle à fur et à mesure que les joueurs progressent et donc retirent les cases noires appliquées par le quadrillage, et qui peut-être tracées aussi finement que le veut bien le MJ. De plus, l'exemple du brouillard n'est pas celui le plus net pour l'intérêt de mettre des propriétés aux espaces vides: cela peut-être une portion de tunnel encombrées de décombres, un simple rideau bouchant la vue, ou autre. Certaines applications ne peuvent pas se résumer à "changeons les propriétés de toutes les cellules vides de la zone" Pour les transitions, ma pensée est que je ne vois pas le DM aller retracer la carte à chaque fois qu'une personne ouvre ou ferme une porte pour modifier les estimations de perception: je préfère donc un système légèrement automatisé, où les joueurs peuvent (parfois moyennent une autorisation technique comme "le joueur X connait le code de déverrouillage") changer les propriétés d'un ensemble de cases en effectuant une action sur leur interface (ex: "ouvrir la porte") en fonction de ce qui a été défini par le DM. Je trouve que c'est une nécessité ergonomique, et non une simple astuce. |
|
29/09/2010, 16h38
|
|
Alpha & Oméga
|
Quels bonne idée si tu as besoins d'aide tu peut me MP
|
|
29/09/2010, 16h48
|
|
Légende
|
Je suis toujours pas convaincu. Il y a des vraies raisons pour lesquelles les formats de dessin vectoriels ont été développés. Il y a des raisons pour lesquels on utilise des polygones et non pas des voxels pour faire de la 3D.
Pour avoir quelque chose de convaincant il te faudra des cases assez fines. Des cases de la taille du personnage comme tu le propose ça donne quelque chose qui n'est pas organique, moins immersif. Ca impose une contrainte très, très forte sur l'environnement alors que tu cherches à reproduire l'expérience papier crayon, par définition très libre ! Alors ok tu peux chercher à créer des astuces, par exemple en ayant des personnages qui tiennent sur plusieurs cases à la fois. Mais c'est du domaine de l'astuce, c'est moche, c'est pour contourner une limite de ton système qui pourrait être contournée juste avec du vectoriel. Le calcul des lignes de vue et compagnie avec du vectoriel n'est pas si compliqué que ça hein. Ok faut quelques optimisations, par exemple des quadtrees pour filtrer rapidement les points testés. Ca se résume à du ray tracing en fait, en beaucoup plus simple puisqu'on n'a pas de réflexions et de réfraction qui sont ce qui rend le raytracing aussi lent. De plus on peut se permettre d'utiliser une faible résolution, contrairement au ray tracing. On peut en fait utiliser la même résolution que celle que tu proposes avec tes cases, et donc obtenir une complexité équivalente ! La différence c'est qu'avec le vectoriel, cette résolution peut être adaptée à la volée... Enfin pour les portes je ne suis absolument pas convaincu du tout, du tout. Dans un JDR, une porte, soit elle ne sert à rien, soit elle est protégée. Une porte qui sert à rien, une fois ouverte elle reste ouverte jusqu'à la fin en général. Une porte qui est protégée, que ce soit par la simple peur des joueurs qui se demandent ce qu'il y a de l'autre côté ou par une serrure ou un digicode, les joueurs mettront longtemps à la franchir. J'ai déjà vu des ouvertures de porte prendre presque une heure dans un JDR IRL (avec des joueurs - moi inclus - un peu boulets, admettons). Tout ça pour dire que dans un JDR on n'ouvre pas autant de portes que tu veux nous le faire croire, et que s'il suffit au MJ de faire un glisser-déposer de la porte pour la mettre ailleurs c'est pas ce qui va demander le plus de boulot. Note qu'avec du vectoriel, le MJ pourrait juste déplacer un des deux points constituants le trait de la porte, pour l'entrouvrir plus ou moins par exemple, ce qui n'est pas possible avec des cases. Ce qu'il y a de fatiguant pour le MJ dans un JDR ce n'est pas les portes... Il y a des problèmes bien plus importants à résoudre avant. Par exemple, admettons que tu veuilles cacher un objet important, par exemple une missive quelconque dans un bureau. Comment tu vas modéliser ça ? Si tu dessines le bureau, les joueurs vont se douter qu'il contient quelque chose. Après tout, pourquoi tu dessines un bureau, là ? L'autre solution c'est de dessiner des bureaux partout dans l'univers du jeu mais ce n'est pas la bonne solution. On parle de décors tracés rapidement et schématiquement comme sur une feuille de papier, après tout ! Non, la solution ce n'est pas d'implémenter les portes, ni les bureaux, ni les objets cachés. La solution c'est que l'environnement ne serve qu'à gérer les déplacements et la ligne de vue. Le reste, c'est conté par le MJ. Sinon on n'est plus dans le domaine du jeu de rôle sur table, on est dans le domaine du jeu de rôle sur ordi. Ca n'a rien à voir et on sait bien à quel point ça demande du boulot, même quand on a déjà le moteur comme sur NeverWinter Nights. |
|
29/09/2010, 17h07
|
|
Alpha & Oméga
|
Je notes ces remarques sur le tracé. Tu as peut-être raison sur le fait qu'il ne faut pas que je fasses un quadrillage si gros, mais alors je dois réfléchir à comment gérer le fait que les personnages tiennent sur plusieurs "pixels".
La solution simple serait de ne considérer que le "centre" du personnage pour tous les calculs, mais cela fait qu'il y aura des cas un peu approximatifs, comme par exemple le cas où le moteur n'affichera pas un personnage alors qu'il est évident que son bras dépasse d'un recoin de mur... Pour les portes, je vois bien que cela te chagrines, mais le problème c'est que je ne vois pas comment faire une gestion de la perception sans... Soit tu considères toutes les portes comme ouvertes par défaut, mais dans ce cas, tu entends et voit toujours tout ce qui se passe dans une pièce supposée être fermée... ou dans laquelle les joueurs essaient de se planquer (tu peux redessiner la porte, mais alors ca vend immédiatement le fait que quelqu'un si planques) Soit tu considère toutes les portes comme fermées par défaut: mais dans ce cas, le DM doit intervenir à chaque déplacement de joueur qui passe une porte, et là cela devient pénible, surtout si les joueurs se séparent dans un lieu plein de portes style "on fouille l'hôtel" Le système de transition n'est pas super compliqué à mettre en place, et il solutionne ce problème élégamment, en plus d'offrir tout un tas de possibilités sympathiques... passages secrets préparés à l'avance, chausse-trappes, etc. |
|
29/09/2010, 18h12
|
|
Héros / Héroïne
|
DooMer, tu pinaille sur des détails d'implémentation
tu peut parfaitement émuler un système a cases a partir d'un système a vecteur, et si des gent veulent des cases, pourquoi les en priver? après tout, ca simplifie tellement de choses, comme : le combat, l'illustration de la case , les déplacement, les problème de "je dessine un passage mais le perso est trop gros" , etc... Ensuite, tu ne peut pas attendre d'avoir que des MD qui savent dessiner au vol comme ca  (même si de toute façon, il faut des outils de dessin )Non, c'est pas important de toute façon. Le but de Moonheart, c'est d'ajouter de la "physique" en plus sur le plateau de jeu traditionnel. Donc par dessus le plan, rajouter la propagation de la lumières, les problèmes de "flou" et d'isolation du bruit , et une simulation plus précise des champs de vision , voir des effet physique ou magiques. Ça implique donc de prévoir un minimum l'environnement avant, histoire de placer les sources de bruit/lumière AVANT que les joueurs ouvrent la porte, sinon, ca n'as aucun interet ^^ Y a des question plus intéressantes, comme : *Est ce que les joueurs peuvent se déplacer d'eux même ou le MD doit prévalider? *Est ce que les joueurs on le doit de voir ou ils peuvent arriver? ils ne sont pas sensé savoir a l'avance que courir a travers les éboulements est plus/moins rapide que faire le tour, en particulier si ils doivent fuir... Citation :
|
|
29/09/2010, 20h37
|
|
Légende
|
Concernant le problème des collisions et des bras qui dépassent, je pense qu'on s'en fiche. Je ne crois pas qu'il faille chercher à faire quelque chose de réaliste. Après tout, c'est du jeu de rôle sur table, même virtuelle ; le but est de laisser place à l'interprétation et l'imagination. Si les joueurs sont raisonnables ils n'essaieront pas d'abuser du système, et s'ils le font, le MJ leur fera tomber une cathédrale sur la tête (c'est la tradition).
Du coup vous pouvez me faire remarquer qu'avec ce raisonnement on s'en fiche aussi de la portée de perception sonore et visuelle. Oui mais non, parce que ça permet de faire des groupes et des trahisons sans que les autres joueurs ne soient au courant. Dans un JdR sur table, même si le MJ part dans la pièce d'à côté, les joueurs savent qu'il se passe quelque chose qu'on essaye de leur cacher. Alors d'accord, les joueurs sont sensés faire la différence entre leurs connaissances et celles de leur personnage. Mais c'est pas si évident. Alors que là on peut avoir un système dans lequel les joueurs ne se doutent de rien. Pour le système de transition, je suis d'accord que c'est facile à mettre en place. Mais je soutiens que ça ne doit pas faire partie du noyau dur du système ; c'est une feature qu'on rajoute. Or, en design, quelque soit le domaine, il faut d'abord chercher à avoir le noyau le plus expressif possible. C'est tout. Après une fois le noyau implémenté rien n'empêche de rajouter des features Mais je pense qu'il ne faut pas non plus trop compliquer. Il vaut mieux bien réfléchir au noyau avant quoi. Après tout y'a plein d'autres façon de faire la même chose. Après si tu me sors 10 exemples pertinents qui s'encodent facilement à partir du système de transition et qui ne s'encodent pas facilement autrement, alors d'accord Tout ce que je veux dire, c'est que ce n'est pas la priorité.Citation :
Citation :
Citation :
Citation :
Le jeu de Go a très peu de règles et pourtant il est extrêmement puissant. Quand on fait du game design on essaye d'avoir la même chose. Quand je design des systèmes de type pour mes langages je fais la même chose. Et ça doit aussi être vrai quand on design un système quelconque. Ca permet d'avoir un système bien plus facile à maintenir et à comprendre, que ce soit pour le développeur ou l'utilisateur. Donc moi quand je fais du design j'essaye toujours de simplifier au maximum. Quand je ne peux plus simplifier, j'implémente. Ensuite je teste, et si je vois qu'il manque vraiment des trucs importants, alors je les ajoute Au fait, c'est quoi le D de MD ? Donjon ? Pour moi le maître du donjon c'est une sorte de boss et ça n'a rien à voir avec un MJ
|
|
29/09/2010, 23h04
|
|
Alpha & Oméga
|
Je pense qu'il faut différentier deux notions dans le système de cartographie:
- la structure physique de la carte, qui décrit les propriétés influençant le positionnement et les perceptions des personnages, mais que les joueurs ne voient pas vraiment, hormis à travers les limites de perception qu'elle leur impose durant la partie - l'image de fond, qui est en fait la vraie carte que voient les joueurs Je persiste à penser qu'un système vectoriel est trop lourd et trop complexe pour les besoin qu'on a lors de la conception de la structure physique: les joueurs et DMs sont forts bien habitués à la notion de "cases" dans lesquels ils peuvent placer les personnages d'un jeu et tolèrent fort bien les petites limites que cela impose. L'image de fond, elle, peut-être sans peine vectorielle, mais je ne prévois pas d'intégrer un outil pour la concevoir dans le moteur principal: pour moi on dessine cette image sur paint, photoshop ou autre et on l'importe dans l'outil de jeu... et après on pose la structure physique par dessus. Pour le système de transition, je retiens l'argument que cela n'est pas indispensable à l'objectif premier du logiciel. J'en ferais donc un module optionnel. Il faudra juste que je prévoie un système d'interface par laquelle un module peut dynamiquement modifier la matrice physique d'une carte. |
|
01/10/2010, 11h51
|
|
Alpha & Oméga
|
Citation :
L'idée c'est donc, via la matrice physique, d'automatiser 90% de ces questions via la préparation de la carte par le MJ: il place tout ce qui est le plus basique, les choses visibles ou audible immédiatement dès qu'on est à portée de perception, les mouvements possibles les plus communs, etc... et ne laisse en suspens que les point qui vont réellement requérir sa présence sur place car trop dépendant de la situation en cours (ce qui me fait penser que je pourrais ajouter une propriété "alarme" sur les cases qui enverrait un signal au DM quand un joueur arriverait sur celle où elle est activées et qui correspondrait à celles où il sait qu'il va aura à gérer une telle chose) Donc oui, les joueurs sont pour moi sensé pouvoir se déplacer sans le DM, conformément aux règles de pénalité de mouvements de sa carte... mais le DM doit pouvoir aussi placer une exception pour forcer les joueurs à lui demander dans certains cas (c'est le cas d'un lieu avec pénalité 100% partout: il n'y a alors que le DM qui peut faire bouger les personnages dans cet endroit, ils ne le peuvent pas eux-mêmes) Pour ce que les joueurs peuvent voir de leur déplacement, c'est une bonne question. Pour moi les joueurs peuvent seulement voir les cases directement adjacentes qui leur sont accessibles avec leur mouvement restant (qui se rechargerait donc avec le temps), pas jusqu'où leur total actuel peut les amener. |
|
01/10/2010, 12h11
|
|
Légende
|
Citation :
J'ai l'impression que tu trouves les cases plus simples juste parce que t'en as l'habitude, justement. Alors que les cases c'est surtout bien pour des jeux au tour par tour. Au niveau implémentation je crois que je ne pourrais pas te convaincre sans l'implémenter. Peut-être que je le ferai. Pour que le MJ dessine, j'ai l'impression que c'est plus simple de tracer des courbes à la souris (ou même avec une tablette graphique) que de placer des cases, parce qu'avec des cases t'auras trop de retouches à faire. Je dis ça par expérience puisque j'ai pu utiliser les deux systèmes : les courbes vectorielles dans l'éditeur de flash par exemple, et les cases dans les éditeurs de niveau comme celui de starcraft ou dungeon keeper. Et avec cette expérience je suis persuadé que le vectoriel est bien plus adapté à du JdR papier. Pour finir si tu sépares l'aspect physique de l'aspect visuel, ça demandera au MJ de faire un effort pour que les murs physiques soient les mêmes que les murs visuels. Et si l'aspect physique est à base de cases, alors le MJ devra de toute façon dessiner des murs carrés pour être cohérent. |
|
02/10/2010, 13h34
|
|
Alpha & Oméga
|
Citation :
Citation :
|
|
02/10/2010, 13h59
|
|
Légende
|
Alors c'est sûrement un problème de vocabulaire, mais pour moi un JdR papier n'est pas forcément au tour par tour. Un jeu au tour par tour implique que tout soit discrétisé et régulé. Dans un JdR papier, en général seuls les combats sont au tour par tour. Et encore, y'a des jeux dans lesquels ce n'est pas le cas. Ca dépend aussi du MJ. S'il vous raconte ce qui se passe et que vous ne lancez pas de dés mais décrivez vos actions avec des mots, pour moi ce n'est pas du tour par tour, parce que vos actions sont continues. Y'a aussi des jeux dans lesquels on ne combat quasiment jamais.
Remarquez que ce n'est pas du temps réel non plus puisque le temps ne s'écoule pas à vitesse réelle mais à la vitesse où le MJ est capable de faire avancer l'histoire. Dans un jeu au tour par tour, chaque action ne peut durer qu'un nombre entier d'unités de temps. C'est une restriction très forte. Alors que l'intérêt du JdR sur table c'est justement qu'il n'y a pas de restriction a priori, puisque le support de jeu c'est l'imagination des joueurs. Alors d'accord, si pour toi "jeu de rôle" signifie "porte-monstre-trésors", tu risques fort d'avoir du tour par tour. Mais ce n'est qu'une catégorie de JdR parmi tant d'autres. |
|
02/10/2010, 15h30
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|