Un Gestionnaire de campagne sur le DDD ?

[Markus]

Dernier message de la page précédente :

(...)

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.

[LLyr]

Le modèle sgbd est ce qui se fera de mieux effectivement

Par contre évitons les tables de liaisons (sauf pour les cas de relation N N) dans notre cas un Fk (foreign Key, on lie a la table principal l'identifiant de la table secondaire Fkpeuple = id de la table peuple) est suffisant car 80% des cas sont des liaisons 1 1 ou 1 N (cas exemple de Markus, dans le cas du 1 N le Fk sera sur la table secondaire)

[squilnozor]

Bon oui, en effet, je ne parle que de tables N N. Ce sont elles qui apportent de la souplesse au modèle. Mais je n'ai voulu utiliser aucun jargon dans mon post. Mais si tu me relis, nulle part il n'est question de tables 1 1 ou 1 N.
Et pour répondre à Markus, en ce qui me concerne, si un jour je passe à l'implémentation, j'aurai seulement des classes personnages, lieux, etc., mais pas de classes magicien, Eauprofonde, et pas d'héritage. C'est uniquement la BDD qui gérera les hiérarchies. Mais je ne voudrais pas trop causer technique ici. C'est chiant pour les gens.

[squilnozor]

Je vais aussi répondre à Mordenkainen en ce qui concerne les fautes. Ce qui est puissant, c'est que le mot voleur, le mot magicien, le mot Eauprofonde, ne sont écrits qu'une seule fois chacun dans toute la base de données. Donc tu n'as pas la possibilité de les écrire parfois avec une faute, parfois sans faute, et de planter les recherches. Alors bien sûr, si au seul endroit où tu écris voleur, tu fais une faute, ensuite, chaque fois que tu fais une recherche avec voleur, tu auras la faute partout. Mais c'est pas grave ; tu n'auras qu'un seul endroit à corriger.

[Outsider]

Y a pas, programmeur (codeur) c'est un métier.

Mais à l'ancienne, une arborescence de dossier et dedans des fichiers textes, tableurs, image revient au même sauf que la recherche se fait à la main en partant du plus haut en monde manuel. On déroule l'arborescence jusqu'au doc recherché.
La limite technique c'est de ne pas dépasser 8 étages de dossiers et 256 caractères au total pour toute la chaine de l'arborescence et cela devrait bien se passer. Si on est rigoureux, une convention de nommage permet une recherche efficace sur les noms de fichiers.

Je reconnais que la solution à l'ancienne est bien moins pratique qu'une base de donnée. Mais c'est à la portée de tous.

[Markus]

C'est noté pour le coté technique un peu rébarbatif, je ne rentrerai plus dans les détails.

Pour Outsider, c'est exactement l'idée que tu présentes (trouver à l'ancienne à partir d'un mode de rangement). Mais disons que tu peux trouver ton info à partir de divers mode de rangement : par lieu, par niveau, par classe, par présence dans tel ou tel scénario, ...
En n'ayant qu'un élément (livre ou feuille de perso par exemple), l'outillage informatique permet de regarder ta recherche via le prisme que tu souhaites alors que le monde réel t'oblige à choisir une méthode de rangement fixe.

[squilnozor]

@Outsider : oui mais ce que tu proposes, ça oblige à éclater tes données dans des répertoires différents, alors qu'avec un modèle relationnel, tous tes personnages sont mis ensemble, en vrac dans une seule table. Et pourtant, tu t'y retrouves facilement.

Et surtout, ça ne gère pas pas les liens entre tables. Imagine que tu veuilles gérer les liens entre personnages. Tu as une table des personnages, et une table personnages_personnages dans laquelle tu stockes des données telles que (perso12, perso8, mariés), (perso32, perso47, rivaux pour le trône de bidule), etc. Avec un tableur, c'est la merde.
Même chose pour les factions et les liens entre factions, les dieux et les liens entre dieux, etc.

[szass]

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) ?

Essentiellement php avec une base oui.

@Squil :

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.

Alors oui et non. Le DDD tourne avec un CMS et un CCK qui permettent à eux deux (surtout le CCK) de faire plein de choses. L'avantage c'est que ça va vite d'implémenter des choses, pas besoin de tout coder à la main. L'inconvénient c'est qu'on est dépendant de la structure imposée et que juste avec le CCK on ne peut pas tout faire de base simplement.
Toutefois, il est possible de créer des tables dans la base de données (mySQLi), et de faire un script php externe au CCK (voir même de combiner les deux : CCK + script externe) qui appelle ces tables. Donc en toute logique, on peut tout faire.

Pour tout le reste de ton message : non, ça ne pollue pas le topic, pas de souci, c'est le bon endroit pour ça
Toutes les idées sont bonnes à prendre et je te sais très doué en SQL et structure de tables

Pour les fautes d'orthographe dans le nom d'une classe ou d'une race qui peuvent renvoyer de mauvais résultats, normalement ça devrait être bon : l'interface pioche dans le DRS (ou dans celles que tu as créée au préalable dans la catégorie Races ou Classes) les données existantes. Donc dans le formulaire d'un personnage que tu créés, tu auras ces choix disponibles.

Ensuite, admettons que tu as un personnage qui est Magicien 8, un autre qui est Guerrier 4 et un autre qui est Voleur 8.
Si dans le filtre tu souhaites afficher les personnages de niveau 4, il ne t'affichera pas le magicien ni le voleur (qui sont de niveau 8).
Si tu souhaites afficher les personnages de niveau 8, il t'affichera le magicien et le voleur. Si tu filtres encore sur magicien, seul le magicien apparaîtra dans les résultats.
Les champs Classe et Niveau sont groupés, comme les champs Source(s) et Numéro de page. L'interface comprend donc que telle classe est associée à tel niveau.
Ça fonctionne comme les filtres qu'il y a déjà sur le site (dans le DRS par exemple).

Pour les sous classes (comme élémentalistes) : élémentaliste n'existe pas dans le DRS, ils sont mentionnés dans les magiciens. Il faudrait donc créer les items suivants dans le DRS : Enchanteurs, Elémentaliste, Nécromancien, etc. Et préciser qu'ils appartiennent au Magicien.
De la même façon, dans les classes AD&D2 du DRS, il y a le prêtre, mais aussi les prêtres de tels dieux (pour les Royaumes oubliés). Et là le souci vient du DRS, de comment sont stockées les informations. Ça nécessitera de modifier les données pour faire comprendre que la classe Prêtre d'Amaunator ou Prêtre d'Akadie appartiennent à la classe Prêtre.
Autre chose encore : pour les monstres du DRS AD&D2, l'Aarakocra par exemple, dans le champ Climat/Terrain, il y a indiqué "Montagnes tropicales ou tempérées". Pour être optimal, il faudrait séparer ce champ en deux valeurs distinctes : Montagnes tropicales et Montagnes tempérées afin de pouvoir trier sur celles qu'on veut. C'est possible, mais ça nécessite de modifier énormément d'éléments du DRS (des milliers)
Si dans le champ Fréquence (pour l'Aasimon par exemple) il y a indiqué "Peu commun (dans les Plans Supérieurs) ou très rare", il faudra là-aussi séparer les valeurs pour afficher uniquement les "Très rare" ou uniquement les "Peu commun" via les filtres.
Il y a donc énormément de modifications du DRS à faire en amont
Là-aussi, ça peut prendre toute une vie comme tu dis.

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.

Oui là ça complique un peu le bousin.
Dans mon idée de base, le champ Lieu du formulaire de personnage sert juste à citer les différents lieux où le personnage peut se trouver, mais je n'avais pas pensé à inclure les horaires ou jours dans l'année de chaque lieu de chaque personnage

Quoiqu'il en soit, toutes vos idées permettent de définir une structure, de ce qu'on a besoin, de ce qu'il faut prendre en compte...
Certaines choses seront plus difficiles ou plus longues à mettre en place. On se rendra aussi peut-être compte que certaines autres idées sont superflues voire inutiles, ou remplaçables par d'autres meilleures.
C'est un peu le but de ce topic : tâter en premier lieu le terrain.

[squilnozor]

Oui, si tu as un perso qui est mago 8, un autre qui est guerrier 4 et un autre qui est voleur 8, pas de souci. Là où c'est plus compliqué, c'est quand tu as un perso qui est mago/guerrier 8/6, un autre qui est voleur/entropiste/barde 5/8/4 et je ne sais pas quoi, ça devient un sacré merdier d'implémenter des méthodes de recherches sans une structure de données très adaptée. Je sais que tu es super compétent et que tu t'en sortiras, mais quand même, c'est chaud.

[szass]

Oui, si tu as un perso qui est mago 8, un autre qui est guerrier 4 et un autre qui est voleur 8, pas de souci. Là où c'est plus compliqué, c'est quand tu as un perso qui est mago/guerrier 8/6, un autre qui est voleur/entropiste/barde 5/8/4 et je ne sais pas quoi, ça devient un sacré merdier d'implémenter des méthodes de recherches sans une structure de données très adaptée. Je sais que tu es super compétent et que tu t'en sortiras, mais quand même, c'est chaud.

Je n'ai peut-être pas saisi le problème, mais de ce que j'ai compris :
Tu n'auras pas un mago/guerrier 8/6. A la place tu auras un mago 8/guerrier 6.
Et donc, le niveau sera dépendant de sa classe associée.
Avec les filtres actuels du site, donne moi stp un exemple où la recherche s'en trouverait caduque, histoire que je cerne mieux le problème.
Dans le cas du mago 8/guerrier 6, si tu filtres par niveau avec comme valeur 6, le choix mago ne sera plus accessible.

[squilnozor]

Avec un modèle relationnel, tu auras :
- dans la table classes, une ligne avec un identifiant unique (par exemple classe25) pour les magos, une autre ligne (classe 33) pour les guerriers.
- dans la table persos, un perso (perso14) avec son nom, son sexe, son alignement, blablabla.
- dans une table classes_persos, des couples (perso, classe) et le niveau : ici, une ligne (classe25, perso14, 8) et une ligne (classe33, perso14, 6).
Si tu cherches tous les magos, tu regardes quel est l'identifiant de la classe mago -> c'est classe25, puis tu recherches tous les couples avec classe25 -> tu trouves le couple (classe25, perso14, 8) -> ça te donne le perso.

Avec un autre modèle, bin, je ne peux pas répondre, parce que je ne sais pas comment sont stockées les données, mais ça sera forcément plus compliqué. Dis-moi comment tu envisages le stockage, et comment tu comptes faire fonctionner le filtre.