Dernier message de la page précédente :

Oui c'est vrai.

Mordenkainen a écrit : ↑

Jeu 22 Juin 2023 19:17

Perso, je suis de la vieille école et je reste avec mon papier et mes dés. Chez nous, on bannit l'ordinateur et les smartphones qui pour moi tue notre jeu à petit feu.

Je rebondis là-dessus
L'interface ne sert pas à remplacer vos papiers, crayons et dés en cours de partie par quelque chose de numérique. Bien que cela sera tout de même possible si vous le souhaitez.
Elle sert avant tout à organiser toutes les infos de votre campagne (ou de votre scénario) sur un support numérique (qui plus est, connecté au DRS) plutôt que dans des cahiers ou des fichiers Word ou Excel ou autres, ou des fichiers jpg pour vos illustrations, etc.

En gros, au sein de cette interface, vous aurez toutes vos notes de campagne bien organisées par catégories, avec des filtres pour afficher les éléments que vous voulez.

Un exemple vaut mieux que mille mots :

En mode papier/crayon : vous avez 100 PNJ griffonnés à la main avec leurs caractéristiques dans un cahier. Comme vous êtes distrait, si vous perdez le cahier ou que du café tombe dessus pendant que vous préparez votre scénario, aucun moyen de retrouver les infos.
Si vous souhaitez juste avoir les infos des PNJ magiciens qui habitent à Eauprofonde, vous êtes obligés de parcourir les 100 PNJ pour savoir qui est magicien et qui habite à Eauprofonde >>> Perte de temps.
Et quand bien même vous retrouvez dans votre cahier tous ceux qui le sont (Magicien à Eauprofonde), si vous avez 12000 PNJ il vous faudra mettre des post-it ou autre pour vite les retrouver plus tard.

En mode Gestionnaire de campagne du DDD : ces mêmes 100 PNJ auront les mêmes infos que dans un cahier classique, mais vous pourrez les trier entre autres par classe de personnage et par lieux. En deux clics, vous pourrez donc afficher tous les magiciens habitants à Eauprofonde.
Et aucun risque de faire tomber du café sur ces notes, ou de les paumer.

L'exemple est pour les personnages, mais ça s'applique à tout le reste.

Présenté ainsi, c'est une aide précieuse quand on débute une campagne. Comme une campagne s'étoffe au gré des parties. Il n'y a rien de compliqué à actualiser en ligne la base de donnée de suivi. Et retrouver l'info recherché en quelques clics est intéressant.

Ce qui peut effrayer, c'est en cas de disparition du DDD ou un différent avec des membres suivi d'un claquage de porte, c'est dire adieu à sa campagne, à moins qu'il soit possible d'exporter les données en format traitement de texte régulièrement.

Outsider a écrit : ↑

Ven 23 Juin 2023 14:57

Ce qui peut effrayer, c'est en cas de disparition du DDD ou un différent avec des membres suivi d'un claquage de porte, c'est dire adieu à sa campagne, à moins qu'il soit possible d'exporter les données en format traitement de texte régulièrement.

1) Le DDD ne disparaîtra pas
2) Il y aura la possibilité d'exporter son contenu

szass a écrit : ↑

Ven 23 Juin 2023 15:05

2) Il y aura la possibilité d'exporter son contenu

Fallait le dire tout de suite. C'est mieux qu'un dégât des eaux sur une campagne manuscrite vieille de 20 ans.

Moi j'ai voté, Je trouve ça intéressant, Je ne m'en servirai pas.
Au passage l'option "A voir" ça aide pas. Je pense que l'idée c'est de savoir ce qui est intéressant de faire avant de se lancer tous azimuts.

Dans mon cas :
J'ai rangé mes crayons et mes gommes pour préparer, mais ils restent parfois utiles autour d'une table (et même en distanciel).
- Est ce que le Gestionnaire fera mieux que mon PC en terme de recherche ou tri ? J'en doute, j'utilise mon PC 12 à 14H par jour, introduire un autre système de recherche, c'est complexifier mes habitudes (désolé je parle un peu "industriel")
- Ma fiche de perso EXCEL (imprimable), j'y ai tellement inclus de règles, d'armes, de sorts et de tables XP/combat/modif caractéristiques... du Guide du Maitre ou Manuel du Joueur que je n'imagine pas en changer ou alors avec des arguments.
- Décrire les lieux, les villes, le bac à sable, c'est tout l'attrait d'un gestionnaire de campagne, mais après avoir testé kanka et un autre (dont je ne me souviens plus), je me suis vite arrêté parce que c'était un peu technique et un peu long, certes propre et efficace quand c'est dans la babasse ! Mais il y a tellement de lieu où les PJ ne passent qu'une fois...

Quand j'utilise Word, je parle à mon PC et qu'est ce c'est pratique et rapide ! J'enregistre le fichier sous [Nom de ville ou Nom du Donjon] et hop.

Pour la description précise des sorts, des monstres et des trésors, hourra j'ai le DRS et je peux même insérer un lien direct dans mon fichier Office !

Au final, l'idée me parait intéressante si quelqu'un n'a pas ce qu'il faut home made. Mais la concurrence kanka ou autre, elle existera toujours.
L'autre raison que je considère particulièrement, c'est d'avoir envie de créer quelque chose pour ma passion, cela vaut tout l'or de Smaug et là je te dis Go !

Pour démarrer "utile" szass, car je sens que tu as envie je t'inviterais soit à interroger sur l'attente prioritaire des utilisateurs, ou faire ce que tu as envie d'intégrer en premier, un module lieux, carte, PNJ, une idée qui permettra de convaincre des indécis ou de faire réfléchir ceux qui ont des idées pré conçues (comme moi )

Si tu utilises ton PC pour gérer ta campagne, et que cela te convient, alors en effet ce gestionnaire ne sera pas forcément utile.
Mais est-ce qu'avec ton PC tu peux, en vue dossiers/fichiers rechercher et trier les infos que tu souhaites. Normalement non. Sauf si toutes tes données sont dans un tableur (auquel cas c'est pas utile d'avoir des tas de fichiers pour chaque truc).

Si tu as un fichier par personnage par exemple (ou ville ou donjon dans ton exemple), et que tu ne veux afficher que les persos Magicien habitants à Eauprofonde (pour reprendre l'exemple d'un post précédent), tu ne peux pas.

Si tu veux copier/coller un lien du DRS dans un fichier, comme une classe de personnage, tu dois d'abord retrouver l'article correspondant sur le site, coller l'URL dans ton fichier, puis plus tard ouvrir le fichier pour le voir (sans compter qu'il faut aussi styler l'apparence du lien).
Dans le gestionnaire, tu auras accès à toutes les classes via une liste déroulante. Tu choisis celle que tu veux, et tu verras le lien affiché directement et déjà stylisé, et ce pour tous tes personnages.

En fait, ce sera un peu comme un tableur, mais avec une interface nettement plus jolie et pratique.

Ca parait très appétissant tout cela.
Peut-on avoir qq idées sur l'appareillage qu'il y a derrière ?
php avec une base (et un joli modèle au vue de l'attendu) ? python ? autres (une armée de farfadet qui ponde le HTML au regard de qui demande) ?

En tout cas, ça m'intéresse, et ça m'intrigue aussi

Moi aussi ça m'intéresse, mais quand j'ai déjà eu l'occasion de causer modèle de données du site avec Szass, j'ai eu nettement l'impression qu'il était très contraint par les outils du site et n'avait pas la possibilité de créer un paquet de tables comme il voulait. Après, je n'ai pas de certitude, il y a peut-être moyen de contourner ça, et dans tous les cas, même avec une structure de données non optimale, franchement, il fait des merveilles à chaque fois et je suis certain que si le gestionnaire voit le jour, il sera super pratique et super efficace.

J'ai un peu envie de causer structure des données, alors je vais le faire ici au cas où il y aurait des gens qui n'y connaissent pas grand-chose et que ça intéresse. Sans être moi-même un grand spécialiste.

La structure des données à laquelle on pense immédiatement, celle qui est intuitive même quand on ne connaît rien, c'est le modèle du tableur. Pour chaque concept central des données (par exemple les personnages), on a un grand tableau avec autant de colonnes qu'on veut (par exemple son nom, son titre, son surnom, sa classe de perso, son niveau, son sexe, s'il est mort ou vivant, si c'est un PJ ou un PNJ, le lieu où il habite, son peuple ou espèce de monstre, etc.). Si on a besoin d'une recherche, par exemple trouver tous les magiciens de niveau 6 ou plus qui vivent à Eauprofonde, c'est tout simple comme dans Excel, on fait des filtre sur les colonnes correspondantes (classe = magicien, niveau >=6, lieu = Eauprofonde). Ça marche parfaitement, pas de souci.

Sauf que... c'est vite très limité. Si dans ma colonne classe de perso, j'ai marqué mage ou mago ou magicen (faute d'ortho), le filtre ne va pas le trouver. Si le perso est voleur / magicien / maquereau, non plus. Il y a moyen de contourner tout ça, mais tout de suite, ça complique. Si dans ma colonne classe de perso j'ai mis voleur / magicien / maquereau et dans la colonne niveau j'ai mis 7 / 5 / 2, il faut configurer le filtre pour qu'il comprenne qu'il est magicien niveau 5 et que la recherche ne doit pas le renvoyer. Ça complique encore. Et si la classe de perso est une sous-classe de mago (je n'y connais rien, disons élémentaliste, j'imagine que ça existe), il faut arriver à faire comprendre au filtre que si on cherche un mago, alors les élémentalistes, ça compte aussi. Ou alors il faut renoncer à mettre élémentaliste dans le tableau, mais c'est dommage. Je suis certain qu'on peut contourner ces difficultés si on est fort en tableur, mais le modèle n'est pas optimal pour ça.

Pareil pour le lieu. Si un perso a sa résidence à Eauprofonde, mais qu'aux horaires de bureau il est au temple de Machintruc dans le quartier du BiduleChose d'Eauprofonde, et la nuit, dans son cottage d'un petit village de la banlieue d'Eauprofonde, et tous les étés à Honolulu, on voudrait bien faire figurer ces infos, mais dans un tableur, c'est compliqué, surtout si on veut pouvoir faire des recherches automatisées.

Le modèle de données qui gère très bien tout ça, c'est ce qu'on appelle le modèle relationnel. Il est plus complexe, moins intuitif au début, mais très souple et efficace, et il devient naturel quand on a peu l'habitude. Un principe de base, c'est que dans chaque cellule d'une table, on veut une information unique. Par exemple si on a une table « personnages », on pourrait choisir de conserver une colonne pour le nom, une pour PJ/PNJ, une pour mort/vivant/autre, une pour son sexe, une pour son alignement (si vraiment on y tient), etc. Mais si on veut gérer les cas où la classe de perso ou le lieu d'habitation ne sont pas uniques, alors on dégage les colonnes correspondantes, et on en fait d'autres tables. Par exemple une table « classes » avec des colonnes qui pourraient être le nom de la classe en anglais, le nom de la classe en français, et tout ce qu'on juge utile, une table « lieux » avec des colonnes nom du lieu en anglais, nom du lieu en français, catégorie du lieu (ville, forêt, école de magie, tout ce qu'on veut), etc. À chacune de ces tables, on ajoute une colonne « identifiant » qui gérera un identifiant unique, par exemple perso1, perso2, perso3, lieu1, lieu2, classe1, etc. Ça n'est pas indispensable, mais ça sert par exemple à différencier deux persos qui ont le même nom. Et ça a d'autres intérêts (voir plus bas).

On crée en outre des tables qui font des liaisons entre ces tables, en stockant des couples d'identifiants. Par exemple on crée une tables personnages_lieux dans laquelle on stocke des couples du type (perso2, lieu5), (perso2, lieu6), (perso5, lieu14), etc. Et après, si je veux lister les persos d'Eauprofonde, je cherche quel est l'identifiant d'Eauprofonde, disons que c'est lieu52, puis je cherche tous les couples qui contiennent lieu52, et ça me donne tous les persos qui ont Eauprofonde dans leurs « lieux ». Et rien ne m'empêche d'ajouter d'autres colonnes à la table personnages_lieux. Par exemple je pourrais ajouter une simple colonne commentaire dans laquelle j'écris tout ce que je veux, et je me retrouve avec des lignes telles que (perso2, lieu52, tous les jours aux horaires de taf), (perso2, lieu57, l'été en vacances), etc.

De la même manière, je peux créer une table personnages_classes avec des couples d'identifiants, et je peux rajouter une colonne niveau qui tombe vraiment à pic. Je me retrouve avec des couples (perso3, classe5, 8), (perso3, classe11, 3), etc. C'est très pratique à utiliser et très efficace ; ça résout un tas de problème. Mais ça nécessite de beaucoup réfléchir à quelles sont les tables et les colonnes utiles. Qui plus est, on n'est pas emmerdé par les fautes d'orthographe ou les orthographes multiples, puisqu'on utilise uniquement les identifiants. Par exemple si classe12 = voleur, alors le mot « voleur » est écrit une seule fois dans toute la base de données, et plus précisément, dans la table classes, à l'intersection de la ligne d'identifiant classe12 et de la colonne « nom de la classe en français ». Il n'y a aucun risque de l'écrire parfois avec une faute d'ortho comme dans un tableur, et de planter les recherches.

Je vais prendre un autre exemple pour illustrer l'la puissance du modèle : je peux créer des tables monstres, sources, environnements, et pour les lier, des tables monstres_sources et monstres_environnements, et ensuite, si je pars d'un monstre, j'ai immédiatement tous les environnements où on le rencontre (marais, souterrain, ruines, etc.). Inversement, à partir d'un type d'environnement, j'ai tous les monstres qui vivent dans cet environnement (c'est-à-dire que j'ai une table de rencontres). Si je pars d'une source, par exemple le Fiend Folio, j'ai immédiatement tous les monstres de cette source (en gros, j'ai la table des matières du Fiend Folio). Je peux même, si je suis très courageux, créer une colonne numéro de page, et là, j'ai vraiment la table des matières du Fiend Folio. Si je pars d'un monstre, j'ai immédiatement tous les ouvrages où ce monstre apparaît, avec éventuellement le numéro de page. Et dans les sources, bien évidemment, je peux ajouter les DRS ou d'autres sites. Donc si je m'intéresse à un monstre en particulier, disons le gnoll, je peux voir qu'il est décrit dans les règles de base de D&D en page truc, dans le Fiend Folio, dans le DRS D&D, dans le DRS AD&D2 (avec pourquoi pas une colonne avec l'url directe de la page du gnoll dans le DRS), dans le Dragon mag #xxx (avec pourquoi pas une colonne commentaire dans laquelle je peux préciser que c'est l'écologie du gnoll), etc. À mon avis, c'est super si on a envie de consulter tous les articles portant sur un même monstre.

On peut créer une table des auteurs, une table des jeux/versions des jeux, etc. Tout ce qu'on veut. Évidemment, plus on est ambitieux, plus c'est un liavart de guedin de tout saisir.

Une dernière précision : dans le modèle relationnel, c'est assez simple d'introduire un concept de « hiérarchie » dans les tables. Ça traduit une sorte de notion d'inclusion des lignes les unes dans les autres. Par exemple, dans ma table classes, si j'ai une ligne pour le magicien et une ligne pour l'élémentaliste, je peux indiquer que l'élémentaliste est inclus dans le magicien, et si je veux, je peux créer une ligne élémentaliste d'air, et indiquer qu'il est inclus dans l'élémentaliste. Ensuite, si j'effectue une recherche sur les persos qui sont des magos, la recherche va prendre les magos ainsi que les sous-classes de magos, les sous-sous-classes, etc. Pareil pour les lieux. Je peux indiquer que le quartier Trucmuche est inclus dans Eauprofonde, que le temple de Machinchose est inclus dans le quartier Trucmuche, etc. On peut faire ça dans quasiment toutes les tables. Dans ma table des monstres, je peux avoir dragons > dragons métalliques > dragon de cuivre, etc. Ou un truc du genre animaux > oiseaux > rapaces > faucon. C'est extrêmement pratique pour des recherches à plein de niveaux.

J'en parle parce que depuis pas mal d'années, j'ai une base de données avec à peu près tout ça. Bien sûr, il y a assez peu de contenu parce que ce que j'aimerais, ça n'est pas m'en servir juste pour une campagne perso, mais pour référencer tout ce qui existe pour tous les jdr du monde, donc il faudrait plusieurs vies à plein temps. Je la complète au fur et à mesure de ce que je lis. Mais je pense que la structure est à peu près au point ; ce qui manque, c'est les données. Toutefois, rien n'empêcherait des MD de s'en servir pour des campagnes perso, en ne remplissant que ce qui les intéresse. Après, l'autre gros manque, c'est qu'outre la base de données, je voudrais coder un jour une interface web pour la saisie et les recherches. Si je veux un jour partager mon liavart, c'est indispensable, parce que juste une base de données, ça n'intéressera personne. Mais ça fait des années que j'y pense et je ne m'y suis jamais vraiment mis.

Bon, je ne sais pas si c'était un pavé compréhensible et/ou intéressant, mais c'est (en très simplifié) ce que je fais, et je me suis dit que c'était le bon endroit pour en parler. Désolé pour ceux que j'ai perdu en route, et Szass, si tu penses que je pollue ton thread, pas de souci pour déplacer le post (mais pas pour le supprimer stp, j'y ai passé du temps).

Bon, j'avoue avoir été perdu assez vite. Je ne vois pas trop la différence avec Excel. Les fautes tu les trouveras partout ? Après dans Excel on peut faire des listes déroulantes mais il est vrai c'est très vite limitées comme méthode. Bref, il faudra que je relise ta prose mais je suis sûr que tu as certainement raison ! Merci pour cette explication pour des ignames, non ignares comme nous. Je vais me coucher moins con même si je n'ai pas compris. Rome ne s'est pas construite en un jour.

Nota : Une personne un jour m'a parlé dans Excel de l'algorithme de recherche de Levenshtein mais je n'ai pas plus compris.

squilnozor a écrit : ↑

Sam 24 Juin 2023 01:48

(...)

Je suis assez en ligne avec ce que tu dis.
Je me demandais si on avait un modèle SGBD, ou des modèles objets (classe, personnage, monstre, lieux, ...) que tu peux instancier et te permettrai de gérer cela.
Dans cet exemple, pour gérer les kit de ADD², tu aurais par exemple magicien qui hériterait de classe, et élémentaliste de magicien ; à la propriété est_magicien, tu auras oui pour tous les mages et l'ensemble de ses héritiers.
Tu peux faire de même avec les lieux, en ayant un approche monde / région / ville / lieux-dit ou place, pour reprendre ton exemple Lieux => Toril => SwordCoast => EauProfonde => temple_truc_muche

Enfin, c'est un peu comme cela que j'avais imaginé un PMT en ptyhon en tout cas.